Jump to content
  • Advertisement
  • entries
    1212
  • comments
    1738
  • views
    1144368

Thanks for the dialog

Sign in to follow this  
johnhattan

100 views

Big thanks for all of the comments yesterday. It's all really valuable and I'm taking it into account.
Wow, it's almost like we have professional seasoned game-design types here and not just a buncha teenaged kids who are only after the latest kewl frag-fest. I once again wish death on the Gamedev Lounge forum :)
Two other facets of the design that I need to detail that will certainly affect the process. . .

Fact one

Perfect scores in Shi Sen are rather commonplace. Unlike something like Voracity (where perfect scores are nigh-impossible), it's not all that difficult to "beat the game". Much like the standard Mahjongg/Taipei/Shanghai game, it is possible to make a configuration of tiles that's impossible to beat, such a configuration doesn't happen very often with a random tile placement.

In casual play (i.e. without a helper-bot), I'd guess that the odds of me being able to get a board down to zero tiles is about 1/6. Only a bit more difficult than the "classic" Mahjongg puzzles.

Hence, I don't think that having a separate table of perfect scores will work. Even Klondike (aka Windows Solitaire) wouldn't need such a "ring of honor", and the odds for beating that are about 1/20. It's either all or none with the perfect scores.

However, I'm now leaning towards only storing perfect scores from a usability standpoint. Much like Klondike, with a little play you (or at least I) take a "win-lose" attitude. In Klondike, if you place all of the cards and get the little bouncy animation, you win. Anything else is a loss, no matter what the little score display in the corner says.

I think that users will roll their eyes if the system brings up a "Good job, enter your name in the high score table!" if they're stuck with 98 tiles remaining on the board. That'd be like Windows Solitaire saying "You can't place any more cards. Enter your name for the high score table."

Fact Two

This is a technical limitation. I'm using Flash for the games and a tool called Zinc to make the Flash apps look and act like first-class apps. One thing Zinc provides is a way for Flash apps to open and save files (like high score tables) to the user's hard drive. Flash itself has no file functionality for obvious reasons (or if it's not so obvious, it's so I can't write a web page ad that overwrites files in your Windows directory if you don't want to buy my V1aGr4 knockoff).

That being said, Zinc's file save-n-load is rudimentary.

Really rudimentary.

Specifically, two functions. . .

mdm.FileSystem.saveFile(filePath:String, dataToSave:String):Void

and

mdm.FileSystem.loadFile(filePath:String):String

So basically if I call loadFile, it stuffs the entire contents of a file into a String that I can then parse and massage at my leisure. Once I've made any changes to that string, I can write the whole goldurned thing back out.

And that's pretty expensive if that file wants to get big, both in memory and disk access. Zinc does have database access, but that's even more unruly, as it requires an ADO, MS Access, or MySQL data source, which is way outta line for a casual game.

A little no-install-required database like SQLite would solve that problem in a jiffy, but that'd require me to write some glue-code in C to bridge between SQLite's sophisticated functions and Zinc's rudimentary methods for talking to DLL's.

And that'd stretch the schedule. Especially since I haven't written a line of C in years.


Compromises compromises.
Sign in to follow this  


5 Comments


Recommended Comments

My first suggestion would be to build a dummy score file that would simulate a full table so you could see just how much of a hit it would be (assuming you haven't already done that).

If the file is definately too big to handle in a reasonable about of time, you might consider breaking it down into more manageable chunks.

If 100,000 games were more manageable, have separate files for games 0-99,999, 100,000-199,999 etc. 10 separate files could contain all 1,000,000 game records.

Then you'd just need to load the file that the current game would be found in.

Share this comment


Link to comment
MS Access? You mean... a Jet powered database? IMHO this is good enough for a casual game (and the user don't require MS Access, you only have to redistribute a single DLL and your mdb file)

Share this comment


Link to comment
I was under the impression your score-saving was done on your web-server. I apologize if my recommendation made no sense. [grin]

Try breaking your scores up into two kinds of file: The master high-score table (holding the 10 best scores, which you must retain at all costs) and the "score log" of boards by date (or century of boards like mithrandir's implementation).

So you'd get a new score, check to see if it beats anything in the highscore table, then if not, shove it in the score-log somewhere and your user will probably forget about it. You could even have some kind of "game play" history screen ordered by date (if your files were based on date) so your players could look back on if they've gotten any better over time.

You can speed this up even more by putting the board ID and the current date together, and then naming the new file after that, so you immediately know which file to look in (also consider a basic hash routine). That way, when you get a new high score on a board you can just iterate through the files that begin with your board ID (without even having to open the files that don't begin with your board ID -- big speed savings here) and check that file for a superior score.

Of course, directory iteration supposes that Flash can do that. I don't know if it can.

Share this comment


Link to comment
Hmmm... crippled language challenges are always fun [grin]


What are Zinc's DLL call features like? It probably wouldn't be hard to toss up a quick C DLL that exposes a single "RecordScore" function with all the file-munging logic wrapped up inside it. (Or heck, make it a dozen functions - it's not really that hard.) That way you can get the bonus of low-level file parsing and not have to sacrifice using Flash for your high-level game logic.

C would really be ideal for a binary file format anyways - I could probably bang out a DLL that does the basics of such a format in a couple of hours tops. Assuming Zinc has reasonable support for passing parameters to DLL functions, your ActionScript side could be as simple as a one-line call to the C DLL.

Another interesting potential perk here is that you could bundle all of your needed low-level logic into a single library DLL and share it across your standalone puzzle games.



Just thinking out loud here [smile]

Share this comment


Link to comment
Also, GDNet has many coder-types who have used sqlite (myself included) and might be able to hack you up some C. Dunno if you want to offer some money, but I bet someone would do it for free.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!