gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Game Design > Configurability of multi-platform game?

#149146 - tepples - Wed Jan 16, 2008 1:06 am

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?
  1. By changing the source code and recompiling the game
  2. By changing a text file and compiling it to a binary file that the game loads
  3. By changing a text file that the game loads
  4. 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:
  1. Allegro: Full read/write file system.
  2. 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.
  3. 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?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#149171 - nipil - Wed Jan 16, 2008 9:11 am

While a,b,c are in increasing difficulty, they are basically reserved to people tinkering with your game. From a player's point of view, the only viable solution is d. Which is, of course, the most difficult for you to provide.

Quote:
Would it be a requirement that the user be able to create and manage thousands of configurations, bounded only by disk space?

It all depends on what types of player you want to target. If your aim is the "mass" (no criticism inside) then install-and-play, with easy/simple/accessible options, is what you want. If you want to build an engine on which people create their complex content, then the audience will of course be smaller. Of course, if you provided both options, you could target all of us. Finally, to the word "create" i would say yes, as you want to induce people into playing with your toys, and limiting their creativity isn't good. To the word "manage" i would definitly say no. Noone likes to manage, order, sort and maintain things when its mandatory. Some do it for fun, but they are quite few. For the management part, you would have to provide some hints/means of organizing the configurations (sort/classify for creation, filter/search for play-mode selection)

Quote:
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?

Again, as above and below, a good option is to aim on simplicity. if you'll provide a central database/repository you manage yourself, then the easier way is doing the possible merge on your side (on the server maybe, or something similar). Moving this option to the game would only bring other problems inside what's not necessarily linked with the game : imho "Divide and rule" is the best technical approach. Human-wise, Goethe said something like "Unite and rule", but that doesn't apply here.

Quote:
Would it be a requirement to maintain a high score chart for each rule set?

If the player's achievement in your game is shown by he score, then i'd say yes. And separate score table is a must, except if you manage to create an homogeneous way of scoring, across the game modes. Which is, again, unlikely.

Quote:
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?

It up to you to decide which level of backwards compatibility you want to keep. With that said, you can choose, from version to version, to support a certain version of your "input" config files. For example game v1.2 might handle rules 1.0, 1.1, 1.2 ; but game version 1.7 might want to support rules versions 1.4 to 1.7. Though you might want to consider using major versions for easier user interpretation (ie all 1.x game version support 1.x rules set, all 2.x game version support 2.x rule set, but not 1.x). Finally, you might want to provide a means to port the old rule-sets : either a simple editing howto (to do it by hand), or better, an automated tool to do so. And of course, port the "included/standard" rulesets yourself with each new versions. Standard-install modes are often the most played (if they are correctly designed, of course) : think of windows' solitaire...

Finally, i don't know how far you're already into it, but it seems you're focused on management issues right now. My advice would be to handle game mechanics / design / modes first, if you haven't done it yet. At least some sample modes, for you to actually get something that plays, on any version. These are really important, as they define what your game's doing ; otherwise you'll end up with a nice, polished engine, which you realize might not be adequate when you start building content. Another piece of advice would be to start coding it on the most restrictive plateform you're targeting to ease your porting work. Or you could plan it to have 100% fonctions on the best one, and less on other devices : 100% on DS, maybe 75% on GBA etc... Harder to achieve, and you would frustrate gamers on less powerful devices. And of course work on one plateform at a time ;)

#149195 - gauauu - Wed Jan 16, 2008 4:01 pm

What he said :)

You definitely need an in-game UI for managing that stuff. But I wouldn't think the in-game UI would need to have full support for downloading/importing/merging/etc. Just maybe for editing the active settings, or maybe letting you save a few "profiles" and use/edit one of them.

But for the PC versions, I would recommend storing these in some sort of easy format, so people who are a little more competent can manage them themselves.