This is a repost from the original forums (which are back up right at the moment, but could still be a bit flaky).
Original thread.
Posts are
here and
here.
LONG POST FOLLOWS:
There are several minigame-games around, like Mario Party and WarioWare, but my favourite is
Bishi Bashi.
You could say it's the "purest" example, in that it consists
entirely of minigames (no world map or boardgame getting in the way), so that's where I'm drawing my inspiration.
- The main program provides the overall game engine, menus, and a scripting environment. (lua, fenix, python, whatever -- lua's my personal preference.)
I'd use a compact scripting language over native binaries for the minigames -- for ease of development and maybe portability, but mostly so you can sandbox the environment the games run in. If you're offering downloadable executables during the game, a bit of security is worth having. It should also help keep the minigames nice and small.
- I'd also encourage a standard format for all the games -- ie, each game must provide a logo/icon, display instructions, return a score within a known range (eg. 0-10 points) for aggregate scoring, respect a given time limit, etc. So instead of completely handing over control to the minigame, maybe the main game calls the help() or game() function for each frame of the loop, and controls the other factors externally.
- At the main menu, you can pick Single Player or Multiplayer; Multiplayer options are Take Turns, Join Net Game or Start Net Game.
Game types are Pick a Game (single player only), Play [N] Games (where N is a selectable #), Marathon (play every game) or Tournament (Multiplayer only, #games determined by #players).
- Games can support a minimum and maximum number of players. Most games should support a minimum of 1 player, but may require 2 or more for versus-style games if the developer doesn't include AI players. Likewise, most games should support multiple players (perhaps via splitscreen for solo-style games). If the current number of players isn't supported by the game, it isn't listed for selection.
(Take Turns requires 1 player support, as only one person plays at a time.)
- You're then presented with the game selection grid. Pick a Game launches that game immediately, and returns to this screen again afterwards; other modes let you select as many games as are needed (or select Random Play and let the program pick them for you), and plays through until finished.
- If you've joined a net game, and you don't have all the minigames, you are asked if you want to download them. If Yes, they are added to your game library, otherwise you are disconnected from the server.
- If you're playing Take Turns, each player is asked to enter their name (and optionally select an avatar, if supported). For all other game modes, this info can be stored in the game settings.
- Now the minigames are played in random order. First the instructions are displayed, the game is played, then the aggregate score table for that round is shown. (In Take Turns, each player sees the instructions and plays, and the scores are shown once everyone's played that round.)
- Finally you get the pretty end-game graphics and final player scores, and you're returned to the main menu.
----
There should be a core set of assets available to all the games, not only to make development easier but also to help tie the games together a bit. If you've played Bishi Bashi, you notice recurring themes and familiar sounds & visuals throughout. They're all completely bizarre, but it all makes a strange sort of sense when put together.
Player avatars, for example, should be defined outside the minigames, and available to all of them. (Perhaps just a character head that can be placed on other sprites.) It could be a defined sprite format; with front, side & back views, as well as different expressions (default, pain, win, lose etc). Ideally it should also support palette swapping so each player gets a different colour, or if you limit the number of players (eg. up to 4) then each sprite could have a colour-mapped version.
We'd want the game to be expandable too, so there needs to be a way of adding to those core assets in the future. I don't see why art packs couldn't be shared in the same way as the minigames.
A side note: for required resources like avatars, I wouldn't allow incompatible alternatives (such as 3D versions). If someone adds an extra avatar sprite, it can be easily shared... but if a game wants to use 3D avatars, it would need an extra art pack -- which might not contain a version for every avatar, and then you're left with a missing resource that needs to be filled.
Let's say the games are packaged as a zip file, with a manifest (like a Java JAR file), and some standard filenames (for the main code, game icon, etc).
The manifest might look something like this:
Code:
name: Mini Rally
players: 1-4
requires: dirtpack, cars, kagato_pack1
If a minigame is downloaded and you don't have the required art packs, it downloads those too.
(Note that I'm thinking the packs are downloaded from the hosting player, not from an internet server; that way games can be shared even without a net connection. Downloading new minigames would be done separately, say from the Options menu.)
