Mini-Game Marathon
by J Lesko · in Game Design and Creative Issues · 12/16/2004 (8:01 pm) · 9 replies
As I mentioned in Tom's .plan thread, I've been thinking of doing 24 Games in 24 Hours.
Insane? Yes. But, oh, the chicks will dig it! Maybe not...
Anyway, I like this idea because it kind of shifts the challenge from "WHAT game can you finish in 24 hours" to "HOW MANY games can you finish in 24 hours."
However, as much as I like the idea of achieving this goal through my own heroic effort, after reading a couple of the responses, I realized it'd probably be more fun to get other GID'ers involved somehow. So, here's what I'm thinking...
Prior to the next GID (hopefully GID9 for me) I can create a Crap Game Engine -- meant for churning out a variety of simple, custom (and crappy) games very quickly, that are meant to be distribute as part of a meta-game, a little something like Wario Ware. This way during the actual GID, I can shoot for my personal goal of 24 games, and also open it up for anyone else to contribute as many games they'd like.
I figure each sub-game will involve a config file and whatever resource files that conform to a preset format. It should take no longer 10-30 minutes to finish a game. In fact, since I'm shooting for quantity over quality, the games should be almost intentionally bad (but playable). Since there will be no scripting involved and the bar will be set very low, art-wise, anyone should feel comfortable submitting a crap game or two, or ten. Programmer art will be appreciated, possibly more so than tolerable art!
I believe I can make it general enough to allow for the basic 2D genres (platform, shooter, paddle, maze) but retarded enough so that you aren't tempted to spend time making it good. And hopefully enough weirdness to allow for some creativity in the mechanics (but not TOO creative!) Each subgame should only take about a minute to win, tops.
Of course, each contributor will get credit (or blame) for their subgame in the game itself.
Well, anyway, that's it. Anyone interested in this? =)
Joe
Insane? Yes. But, oh, the chicks will dig it! Maybe not...
Anyway, I like this idea because it kind of shifts the challenge from "WHAT game can you finish in 24 hours" to "HOW MANY games can you finish in 24 hours."
However, as much as I like the idea of achieving this goal through my own heroic effort, after reading a couple of the responses, I realized it'd probably be more fun to get other GID'ers involved somehow. So, here's what I'm thinking...
Prior to the next GID (hopefully GID9 for me) I can create a Crap Game Engine -- meant for churning out a variety of simple, custom (and crappy) games very quickly, that are meant to be distribute as part of a meta-game, a little something like Wario Ware. This way during the actual GID, I can shoot for my personal goal of 24 games, and also open it up for anyone else to contribute as many games they'd like.
I figure each sub-game will involve a config file and whatever resource files that conform to a preset format. It should take no longer 10-30 minutes to finish a game. In fact, since I'm shooting for quantity over quality, the games should be almost intentionally bad (but playable). Since there will be no scripting involved and the bar will be set very low, art-wise, anyone should feel comfortable submitting a crap game or two, or ten. Programmer art will be appreciated, possibly more so than tolerable art!
I believe I can make it general enough to allow for the basic 2D genres (platform, shooter, paddle, maze) but retarded enough so that you aren't tempted to spend time making it good. And hopefully enough weirdness to allow for some creativity in the mechanics (but not TOO creative!) Each subgame should only take about a minute to win, tops.
Of course, each contributor will get credit (or blame) for their subgame in the game itself.
Well, anyway, that's it. Anyone interested in this? =)
Joe
About the author
#4
I'd be interested in having a look at the structural setup once you had something going. I'm interested in the idea, for sure. If it happens at the same time as GID, I'd have to decide which I was going to focus on, and it would probably be the GID.
Nintendo also did microgames with Mario 64 DS, interestingly enough...
-- stay
12/17/2004 (7:54 am)
So, would people wanting to contribute need to use your engine, then? How much ahead-of-time would it be available for playing around? What sort of engine are you thinking of? (2D? 3D? torque-based? OpenGL based? DirectX based? GDI based?) I'd be interested in having a look at the structural setup once you had something going. I'm interested in the idea, for sure. If it happens at the same time as GID, I'd have to decide which I was going to focus on, and it would probably be the GID.
Nintendo also did microgames with Mario 64 DS, interestingly enough...
-- stay
#5
Creating a new engine for this == bad. It's much, much better to use something existing and instead pre-GID focus on getting a framework going in that engine for running the microgames. By this I mean a real simple "launcher" application with a simple API (perhaps just config files, maybe more if needed) for tieing games into it. Some other framework for the chosen genre for the games may be needed, too. For example, if it's decided to make 24 adventure platformers, then some work would need to be done for that.
This framework needs to be finished at least a week, preferably 2, before the GID. People need time to get used to it. Even if its simple enough to pick up in 5 minutes. Every other time we've tried out new engines in GID, there's always been a large drop out due to not wanting to learn a new engine during a GID.
Thus, a very important factor is that the engine used for this should be something everyone taking part is at least semi familiar with already. That probably means it has to be Torque, which is a good choice anyway as it's been proven many times over to be good for GID.
I don't see this happening in time for GID9. Perhaps some experimentation in this area for GID9, but I'd see this as something more attainable for GID 10 or 11. Perhaps by then Torque 2D will be out and we can use that :)
I like the idea and think it should be done, but I also think that it needs to be thought through a bit more first.
T.
12/17/2004 (8:43 am)
OK ...Creating a new engine for this == bad. It's much, much better to use something existing and instead pre-GID focus on getting a framework going in that engine for running the microgames. By this I mean a real simple "launcher" application with a simple API (perhaps just config files, maybe more if needed) for tieing games into it. Some other framework for the chosen genre for the games may be needed, too. For example, if it's decided to make 24 adventure platformers, then some work would need to be done for that.
This framework needs to be finished at least a week, preferably 2, before the GID. People need time to get used to it. Even if its simple enough to pick up in 5 minutes. Every other time we've tried out new engines in GID, there's always been a large drop out due to not wanting to learn a new engine during a GID.
Thus, a very important factor is that the engine used for this should be something everyone taking part is at least semi familiar with already. That probably means it has to be Torque, which is a good choice anyway as it's been proven many times over to be good for GID.
I don't see this happening in time for GID9. Perhaps some experimentation in this area for GID9, but I'd see this as something more attainable for GID 10 or 11. Perhaps by then Torque 2D will be out and we can use that :)
I like the idea and think it should be done, but I also think that it needs to be thought through a bit more first.
T.
#6
If the engine is Torque, I would be unlikely to participate, myself. No offense - Torque is amazing and cool and obviously great for GID, but we as a company have not invested in it (with money or time) and are unlikely to do so right away. Torque2D might actually be more interesting to me for this type of event.
I may not be a big loss anyway - I'm only a 1-time GID veteran and as I mentioned I might prefer to work on a GID instead of 24GI24H anyway. But I still think it's a great idea!
-- stay
12/17/2004 (10:29 am)
That's cool.If the engine is Torque, I would be unlikely to participate, myself. No offense - Torque is amazing and cool and obviously great for GID, but we as a company have not invested in it (with money or time) and are unlikely to do so right away. Torque2D might actually be more interesting to me for this type of event.
I may not be a big loss anyway - I'm only a 1-time GID veteran and as I mentioned I might prefer to work on a GID instead of 24GI24H anyway. But I still think it's a great idea!
-- stay
#7
Tom, good points, and I'm glad to hear this now, before I decide to do any real work.
We might be talking about slightly different ideas, though. My scope is so small that the term "engine" is probably overkill, at least nothing approaching the power of Torque (or even LOGO, for that matter). The process of creating a game will probably be more like using a level editor for a game made in the 80's: very restrictive and a lot of predefined assumptions.
The obvious reason I'm shooting for the unified approach, as opposed to the "dispatcher" framework I think you are referring to, is to factor out all the common little things that tend to eat up dev time like clock display, instructions, input, etc. Each subgame would reside in a smaller viewport, with the HUD elements (such as they are) handled by the engine.
In the spirit of finishing games fast, the media and game configuration would be primitive, partly to discourage excess tweaking to get things "just right". The main limitations:
-- win/lose only, no score/levels/lives
-- always ends after a certain time limit (no more than 90 seconds)
-- 1 player object and 2 other object types
-- 1 player projectile and 1 enemy projectile
-- input limited to arrow keys, space bar, and mouse click/drag
-- no variables other than a single counter to ++ or --
-- events limited to collisions, input, and counter
Because the limits are clearly defined, providing an editor becomes easier. Making a game would involve:
- Using the game editor to fill out config form and create graphics
- Define the sprite spawn points and player movement zone
- Finished -- it's Miller Time!
Media limitations:
- background: 32x20, 2-color, (scaled up to 320x200)
- player and other sprites: 16x16, 1-color, 2 frames, optional x2-scale
- projectile images: 8x8, 1-color, 1 frame
- Predefined 16-color pallette
- 8 pre-defined sounds
Explosion/death animations would be dynamically created by the engine. The final games would obviously be very retro looking, unless you want to overwrite the editor-created image files.
Of course, a lot of these limitations could just be self-imposed by different developers using different platforms, but it'd be nice for anyone to just crank out a single retro-style game and not have to worry about the boring details that inevitably crop up. It would also be nice people with no programming or art experience to contribute after the GID. Because the bar is set so low and the games have such a small scope, I think people would be more willing to make something.
Granted, this might actually feel too limited for some people, but since I personally plan on cranking out a lot of games with it, I'll try to find the right balance. The challenge to myself with this is "how many small, but fun games can you build using a very limited set of resources? (and without getting bored)" and laying out the boundaries for that.
Joe
12/17/2004 (2:01 pm)
Thanks Josh, it looks like those bastards at Nintendo already stole our idea! =)Tom, good points, and I'm glad to hear this now, before I decide to do any real work.
We might be talking about slightly different ideas, though. My scope is so small that the term "engine" is probably overkill, at least nothing approaching the power of Torque (or even LOGO, for that matter). The process of creating a game will probably be more like using a level editor for a game made in the 80's: very restrictive and a lot of predefined assumptions.
The obvious reason I'm shooting for the unified approach, as opposed to the "dispatcher" framework I think you are referring to, is to factor out all the common little things that tend to eat up dev time like clock display, instructions, input, etc. Each subgame would reside in a smaller viewport, with the HUD elements (such as they are) handled by the engine.
In the spirit of finishing games fast, the media and game configuration would be primitive, partly to discourage excess tweaking to get things "just right". The main limitations:
-- win/lose only, no score/levels/lives
-- always ends after a certain time limit (no more than 90 seconds)
-- 1 player object and 2 other object types
-- 1 player projectile and 1 enemy projectile
-- input limited to arrow keys, space bar, and mouse click/drag
-- no variables other than a single counter to ++ or --
-- events limited to collisions, input, and counter
Because the limits are clearly defined, providing an editor becomes easier. Making a game would involve:
- Using the game editor to fill out config form and create graphics
- Define the sprite spawn points and player movement zone
- Finished -- it's Miller Time!
Media limitations:
- background: 32x20, 2-color, (scaled up to 320x200)
- player and other sprites: 16x16, 1-color, 2 frames, optional x2-scale
- projectile images: 8x8, 1-color, 1 frame
- Predefined 16-color pallette
- 8 pre-defined sounds
Explosion/death animations would be dynamically created by the engine. The final games would obviously be very retro looking, unless you want to overwrite the editor-created image files.
Of course, a lot of these limitations could just be self-imposed by different developers using different platforms, but it'd be nice for anyone to just crank out a single retro-style game and not have to worry about the boring details that inevitably crop up. It would also be nice people with no programming or art experience to contribute after the GID. Because the bar is set so low and the games have such a small scope, I think people would be more willing to make something.
Granted, this might actually feel too limited for some people, but since I personally plan on cranking out a lot of games with it, I'll try to find the right balance. The challenge to myself with this is "how many small, but fun games can you build using a very limited set of resources? (and without getting bored)" and laying out the boundaries for that.
Joe
#8
Joe
12/17/2004 (2:42 pm)
I also want to add that I'm not really proposing this as a replacement for anyone's GID plans, but wanted to open up the option for anyone who wants to toss in a game or two if they have slack time during their "real" GID project. Joe
#9
You're right, I think we were thinking of different things. I think your idea is actually attainable on your own as a GID in itself. Spend the GID making the engine and then the games would be so quick to make you could churn them out probably a lot quicker then 1 game an hour.
Come to think of it, what you've mentioned is kind of what I meant by experimenting first in GID9. Perhaps when T2D has shipped it's worth trying it out on a bigger scale based on lessons learnt from Joe's micro-engine.
Steve,
Ah, I didnt know you didnt have TGE. I see your point there, for you it wouldnt be as viable a GID choice if you've not used it before. The more I think about it the better I like the T2D idea anyway :)
Hmmm...
Joe's idea would merge well with T2D. Potentially a framework could be built to allow "any" T2D game to run inside it, with for example a common high score table "API" and other niceities. It could be used not only as a cool "X games in 24 hours" thing, but as a showcase for the fruits of that GID. It seems to me that this would be a pretty easy thing to pull off with T2D. Could probably do something similar with TGE for 3D games too, though the need for C++ changes there may hamper that a bit.
There is lots of potential here :)
T.
12/17/2004 (3:08 pm)
Joe,You're right, I think we were thinking of different things. I think your idea is actually attainable on your own as a GID in itself. Spend the GID making the engine and then the games would be so quick to make you could churn them out probably a lot quicker then 1 game an hour.
Come to think of it, what you've mentioned is kind of what I meant by experimenting first in GID9. Perhaps when T2D has shipped it's worth trying it out on a bigger scale based on lessons learnt from Joe's micro-engine.
Steve,
Ah, I didnt know you didnt have TGE. I see your point there, for you it wouldnt be as viable a GID choice if you've not used it before. The more I think about it the better I like the T2D idea anyway :)
Hmmm...
Joe's idea would merge well with T2D. Potentially a framework could be built to allow "any" T2D game to run inside it, with for example a common high score table "API" and other niceities. It could be used not only as a cool "X games in 24 hours" thing, but as a showcase for the fruits of that GID. It seems to me that this would be a pretty easy thing to pull off with T2D. Could probably do something similar with TGE for 3D games too, though the need for C++ changes there may hamper that a bit.
There is lots of potential here :)
T.
Torque Owner Joshua Dallman
Default Studio Name