I am developing a video game. It's like recent versions of Monopoly or the forthcoming Super Smash Bros. Brawl in that the player can customize the "house rules" in detail. But I'm not going to release the next version of this game until I figure out how I plan to implement the loading of custom rule sets. How would the user edit these? By changing the source code and recompiling the game By changing a text file and compiling it to a binary file that the game loads By changing a text file that the game loads By editing the file within the game, like step charts in StepMania The game has three front-ends that share the same underlying game logic. It's likely that a different solution will be best for each of the front-ends: Allegro: Full read/write file system. Nintendo DS: Most popular cards allow the program to read and write a file system on an SD card through a loadable "DLDI" driver. Some cards automatically load an appropriate driver when loading a .nds (executable) file, but others do not, and these people would need to be walked through the process of using dlditool-win32-gui to add the driver directly to the .nds. Game Boy Advance: The GBA Movie Player (CF version) and a few other cards support DLDI. But a lot of GBA users are on NOR cards such as Flash2Advance, which have a read-only file system. NOR cards usually have one writable .sav file per program, whose size is fixed at 64 KiB, and it can be difficult to get these files on and off the card reliably. The system has only 256 KiB of main RAM, and the parser and/or editor have to be designed with this in mind. And typing the name of each new rule set is tedious on the system's controller, which amounts to a GBA plus two face buttons and two shoulder buttons. Would it be a requirement that the user be able to create and manage thousands of configurations, bounded only by disk space? Would it be a requirement that the user be able to merge rule sets from lists downloaded separately, or between lists created on different platforms? Would it be a requirement to maintain a high score chart for each rule set? And to what extent would it be a requirement that user-defined rule sets from an old version of the program work in a later version? [Split from Lockjaw topic because it pertains just as much to games other than Lockjaw, or for that matter games that don't have falling blocks at all.]
This stuff sounds pretty technical and a little out of my league, so I'll just say that I very much favor the current system for Counter-Strike. In CS, the game saves all the settings (key binding, options, screen settings, macros, scripts, the colors of the aim thingy, etc) into one file. This is great because if you're new, you can just go to some professional team's website, download your favorite player's settings, and you know you're not at a disadvantage. On the other hand, the game also allows you change these settings at anytime by using the chat window. It's a very good system, I think. Secondly, be careful to distinguish what is a rule and what is a setting. In CS, the rules are set by the server (so many players per team, so many minutes of game play, this is the goal, etc). On the other hand, the server will identify some of the player's settings and say no-no, can't do that here. How this applies to Tetris and record keeping, I say keep it simple and practical. For whatever goal set (time attack by line limit, line attack by time limit, score attack by time limit, reverse time attack by diminishing lock delay, etc, let the player pick whatever settings she pleases. So you can have some default goal sets, and then players can make custom goal sets--distinct records for each, but not for the millions of combinations of settings for each. Then maybe sometimes a setting is significant enough to drastically effect gameplay-- like Akuma in Super Turbo. In Super Turbo, he's banned. Maybe the majority of players don't like deep drop, or certain wall kicks and macros, or whatever, then as part of that goal set, these are banned. That's the best system I can come up with.
In practice, I believe that if the GBA and DS versions included a hard-compiled library of popular configurations, then 99% of users would be happy. If new settings become popular, then you could simply include them in the next version.
This is probably a combination of the above: Create a program that can create rule sets. Allow it to save in a native format, that the PC version can read. You may also wish to put a ruleset editor in the PC version. Have it export a binary "chunk" (like, 256 bytes or so... I don't know how large a ruleset would be) that contains a few rulesets. Then create a patching program that can insert that chunk into a byte-aligned area of the GBA and DS roms, in a similar way to how DLDI-patching works.
Precompiled stuff can be disadvantageous if the goal is to have users create configurations/rules and share with other internet users. You should consider Mac/PC/GNU+Linux users. I think the loading of text file is nice.
Then the rule set files at least on Allegro will look much like the current lj.ini files. This leaves the handhelds. But the Game Boy Advance doesn't have a file system to speak of. Instead, it has a makeshift read-only file system in ROM and one writable file, limited to 64 KiB in size, and the system is likely to lose power when writing to this file. I have to put custom rule sets, high score tables for custom rule sets, custom speed curves, and custom rotation systems in this file.
