The stat-o-matic app is now able to grab scores from the database and display 'em. One thing it'll eventually do is grab your username from the Flash-cookies and pre-fill the "handle" text-box, so it'll default to your own scores.
Also I'll have an indicator for an empty graph, saying "hey, choose a game up there to show some stats". Until then, though, I still have the random graph data.
Anyway, open up a new browser window and go to http://www.thecodezone.com/statomatic.php
On the first graph (scores), enter "flyman" in the entry field and "poker patience" in the checkbox and press "go". Since PP is the only game that currently posts to the new database and I'm currently the only user with enough scores to make a meaningful graph, stick with these.
You should see a cute little bar-graph. If you click on a bar, you can see a little more detail on how well I did for a particular day.
Anyway, the usability question is this. . .
Click on the rightmost bar. Note the date. This is my score for TODAY!
As any Daily Puzzle player knows, scores are kept hidden until the following day. But, since the stat-o-matic page is set up to let you look at stats for anyone, you could use this as a sneaky tool to check on the scores of your greatest rivals in the high-score tables, thus giving you a clue as to the score you'll need to win.
When I first noticed this, my first reflex was to say "well, all I have to do is not show graph data from today". But then I wondered. Would it foster competition to allow you to peek at someone's score for today?
It's not like cheating's a monster problem for my games (mainly because it's really easy to cheat at about half of 'em), so should I allow an avenue for a sneaky player to gain an "edge" in the name of fostering fiercer competition?
My inclination is to not send scores for today. After all, it's fairly easy to spot the cheats in the high score tables (hint: They're the ones who make perfect scores in 18 seconds), but there's little indication that I'm peeking at the Pop Pies regulars and playing the game repeatedly until I beat their scores.
So I'll probably dump the today-bar.
Just thinking out loud.
Now then, regarding Mac games. I'm really almost there. My biggest problem is my utter lack of expertise with the Mac platform. I have Zinc for OSX (the Flash standalone EXE builder) and it works just fine building standalone Mac games. And I have a little Mac mini for building and testing. I built a couple of games on it, and they mostly worked.
But I have a lot of unanswered questions that'll take some time to research. Hopefully you OSX types can help me out.
Biggest issue is with SQLite. I chose to use SQLite to maintain data in the games (settings, high score tables, etc) because it's dirt-simple and requires no installation and runs on everything. Only problem is that SQLite didn't have a Zinc interface, so I had to roll my own for Windows. It was fairly straightforward, although I did have to write a little "glue" DLL because Zinc's DLL-calling interface doesn't support callbacks, and the SQLite DLL returns query-rows via a callback function.
Once that was working, installation for Windows is quite simple. All I have to do is copy sqlite3.dll (the SQLite engine, precompiled for me at sqlite.org) and SQLiteZinc.dll (the glue DLL I wrote) into the same folder as the games, and everything's happy.
Now then, the Mac's gotta work almost entirely differently from that. Zinc's method for talking to an external program in OSX is via the command-line or via AppleScript. While I could compile SQLite as a shared library (OSXese for a DLL) and talk to it with AppleScript, the folks on the MDM forum say that the command-line would be a better way to go even though it seems on its face to be more kludgy.
And then there's the question of deployment. While OSX 10.4 and later have SQLite included somewhere in the bowels of the OS, the older OSX's don't. That means that I need to include SQLite in my distribution. And I can't find a working SQLite for OSX binary distribution anywhere. Which means that I'll have to build the SQLite binary myself.
Then there's the case of PowerPC versus Intel. Right now I assume I'll have to build two sets of games and two SQLites -- one PowerPC native and one Intel native. Or is it better form to make a fat binary out of everything? And how do I do that?
And then there's the case of distribution. My puzzle pack, for example, contains six games. Since each game requires the SQLite and SQLiteZinc DLL, I didn't bother packing the DLL into the games themselves. I just left 'em in the directory so they could all share the DLL. This makes loads of sense from a size standpoint because the SQLite engine, while small for an SQL database, is of nontrivial size, and packing the DLLs into each game would bloat up the installation and download size.
But that don't seem to be the Mac way of doing things. Best I can tell, each game should be a self-contained archive that contains all of its runtime information within itself.
So it appears that to be a well-behaved Mac app, each puzzle must be a fat binary that also contains a fat binary of all of its required runtime components contained within itself. And that's gonna make the games REALLY HUGE --probably four times the size of the Windows games!
Then there's the installer issue. Most Mac apps I've seen don't have installers. You just download a little "virtual disk", then drag the app into your app-folder and (optionally) put it on the OSX dock for launching. While I could certainly do that, what of uninstalling? It would absolutely be bad form for me to leave behind a database of settings if the only uninstall instructions I gave were "drop the games in the trash can". I'd much prefer to have a nice friendly installer that sets up the games for you along with an uninstaller that will obligingly remove all traces of my game from your system, but I think that'll make the OSX folks cry "port".
So, as you can see, I have a few things I need to iron out logistically before I can even start on making my "run anywhere" game actually run anywhere. If any of you OSX folks out there can help me iron out all this, I'll try to make it worth your while.
When you say compile SQLite as a shared library, you mean the actual database package, not a client for it, right? Seems like overkill to me, seeing as it is already included with the newer OSX releases
I would have two builds: a pre-osx 10.4 and a Tiger build. The tiger built shouldn't include the SQLite shared library -- the pre-tiger one should. Tell he users, however, that they can use the Tiger version if they have SQLite installed on their system.
Intel can run PPC builds using Rosetta. You don't need a special build. If you wan't to make one, it shouldn't be too hard. The only issue is that you have to make sure any libraries you are using are either Universal, or you have both the PPC and Intel versions. When making the Intel side, you must use entirely Universal or Intel versions of libraries. For the PPC side, all Universal or PPC versions. Then you can use a little program called "lipo" to smash 'em together. That will create a Universal build.
If I were you, I would just worry about getting a PPC version working. I don't forsee that you will need the huge speed boost of compiling to native Intel instead of just having Rosetta take care of interpretting the PPC code. If you think about it, Apple had to make Rosetta pretty fast anyway because there was NO Intel software when the new Macs came out. They had to give them the ability to run the PPC software, and run it well.
As I said before, I would go with the pre and post Tiger release styles. Don't worry too much about package size.
Probably.
Not quite true. It isn't bad form for you to leave information in the User's /Library folder (/Users/user_name/Library/). This is common practice. This way, if a user chooses to reinstall a program, their data will still be there.
Well, hopefully that helps out. This is all just my opinion -- but I have been using my Mac for about a year and a half now and that is what I have noticed about mac development.
Good luck!