What About Minigame Project?

[kagato]

I think this is a great idea. I've thought of doing something similar on the PSP (my current homebrew platform), but haven't acted on it yet. So I might as well share my ideas here.

Warning: long post. Brain dump 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.

What do people think? Too much information?

 

[Game_over]

Actually the right amount of information, I'm on the same page as you in many aspects. In my mind, a project like this would definetly take a community effort.

 

[azmodean]

A thought I had while reading this thread, how hard would it be to have a library of standard art assets you could pull from for your game, or perhaps have art packs you could list as a dependency and use them? Speaking for myself, I am a programmer and interested and capable of writing game code, but I have basically no ability to create art assets myself, so especially with the theme of "rapid-development minigames", I thought it might be a good match to (optionally) seperate the coding and art production tasks.

As a (simple) example, you could have old-school sprite array images (either standard with the main program or as loadable components) and a mechanism in the scripting language used to import those images for use as game sprites. as time goes on the community could accumulate a large number of these art assets, and the task of creating a good-looking game gets that much easier. (though of course well done original art assets for your game would add that extra level of polish)

 

[TaG]

A thought I had while reading this thread, how hard would it be to have a library of standard art assets you could pull from for your game, or perhaps have art packs you could list as a dependency and use them? Speaking for myself, I am a programmer and interested and capable of writing game code, but I have basically no ability to create art assets myself, so especially with the theme of "rapid-development minigames", I thought it might be a good match to (optionally) seperate the coding and art production tasks.

As a (simple) example, you could have old-school sprite array images (either standard with the main program or as loadable components) and a mechanism in the scripting language used to import those images for use as game sprites. as time goes on the community could accumulate a large number of these art assets, and the task of creating a good-looking game gets that much easier. (though of course well done original art assets for your game would add that extra level of polish)

With that as a basis, the net step would be skinnable games - just change the art pack to another. Might not work but could be a helluva laugh. Let your imagination run riot!

I do like the idea behind this thread - I'll watch with interest.

 

[Ryzure]

QUOTE
Warning: long post. Brain dump follows.

I fully support every bullet on that list Kagato; That is exactly what I was thinking, especially the "sandbox engine" idea.
This makes it so much easier to make a game, and encourages creative users to add their own content! Not everyone can code, so using scripts inside a premade engine is just about the only way to make a "game".

QUOTE
Actually the right amount of information, I'm on the same page as you in many aspects. In my mind, a project like this would definetly take a community effort.

If you start this endeavor, please let us know! I'm positive you'd get enough community effort to bring this project to fruition.

QUOTE
..how hard would it be to have a library of standard art assets you could pull from for your game..

Another excellent idea. I believe Game_Over mentioned 3D games too, so I hope it wouldn't be limited to only sprites. :rolleyes:

... and I now I've gone and wet myself. Good day.

 

[kagato]

Glad to se we're all on the same page on this one.

In my mind, a project like this would definetly take a community effort.

Absolutely. The beauty of a project like this is lots of people can contribute -- in fact, it pretty much depends on it. The game will really shine when it's got a massive number of minigames, which would be a lot of work for one developer.

However, the core engine itself is probably a one-man job. Anyone volunteering?

A thought I had while reading this thread, how hard would it be to have a library of standard art assets you could pull from for your game, or perhaps have art packs you could list as a dependency and use them?

I totally agree. 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.)

 

[Game_over]

I thought I throw this together before I hit the sack for the night, just an idea...

 

[senquack]

I thought I throw this together before I hit the sack for the night, just an idea...
*snip*

Wow, that looks clean, uncluttered, and just plain awesome. I suggest a centralized scores listing (outside of each individual game) that can list overall high scorers as well as high scorers for individual games.

 

[Ryzure]

I thought I throw this together before I hit the sack for the night, just an idea...

That looks like an excellent layout!

 

[TaG]

@Game Over.
That looks real nice. Have you tried it at real size? (If not, try Arialia's little app..) The text across the bottom looks small and the little game views are just a tad too small IMO. On the Tango screen on the above link there are 3x4 with plenty of space but your view takes up a chunk of the right hand side too, so maybe 3x3 or 3x4 max.

I presume you are thinking of using up and down button for navigation?

 

[Game_over]

Thanks man, I just put that together in inkscape with that resolution, but as you correctly assumed, not really in real world dimensions.

Text size was the thing that had me scratching my head while putting it together. Since the Pandora is at such a high resolution with such a small physical screen I'd assume it's better to make the text "stick out" more.

I didn't know he had that program I'll try it now...

EDIT: oh and that picture is actually slightly smaller than 800x480, thick white boarder included. I'll do some more concepts as well. The game views are really meant to be small icons of the mini game and you whatever you select shows up to the view to the right just like the original. Since it's at a higher res than GP2X, then allot more icons can show and a larger main view can be used.

If any of you have concepts please post them here.

 

[javaJake]

If you ask me, this should fit right in with the TINXL project.

 

[kagato]

Pretty good layout... I'll post some mockups with further suggestions a bit later on, when I have more time.

 

[ashadocat]

Well in you wanted to have an easy to use game maker you could use stencyl (if it's ever released) or novashell. novashell has my vote because it exists and has an AI system that would be especially good for puzzle games.

 

[Game_over]

Man I forgot about novashell, stencyl sounds pretty cool too. I'm thinking we should consider that whatever system we decide on if we do this, should be thought of as a container/modular program; meaning that the program completely customizable in parts (however we should have a basic skeleton that should be the standard, and universal), and also as open to as many formats, regarding content, as possible. As far as the TINXL project is concerned, I can't wait to here more from it, I'm looking through some old post about it as I speak as I didn't follow it at all. More mockups from me later.

 

[Game_over]

Just wanted to add another small concept to show that this discussion is no where near dead. andora1:

For those of you who haven't read this discussion yet, you should- it's only like three pages deep.

 

[PSyMastR]

Seems good. I like the idea of the 2 player battle. But instead of giving each of them seperate games, maybe have each player select N games, and then it randomly selects 1/2 from player 1's list and 1/2 from player 2's list

 

[Game_over]

Thanks, those was really for giving each player an association of games they previous played and garnered them their highest score, for strategic effect. I just put that together in like 15 minutes and forgot to show highscores, but I'll make some more concepts later.