Mojotron 2 Design Brief
An open-source Robotron/Gauntlet cross-over, for MS Windows and Linux.
Mojotron 2 will combine the fast paced destruction of a shoot-em-up, with the exploration and loot of a Gauntlet-like top down adventure.
To date, Mojotron hasn't had much of an environment beyond a few crates to hide behind. Mojotron 2 will have scrolling, 2D tiled levels, with indoor and outdoor areas. That's full immersive 2D, no 1.5D trickery here!
The game will be presented from an overhead 3/4 view reminiscent of 16-bit console RPGs. (note: this is not an RPG, but we might steal the stats ideas anyway)
Like Silkworm, Mojotron 2 will have 2 characters to play, with differing control types:
Mojotron 1 had a weird bonus system a little like Poker, except with fruit. I don't think anybody really figured it out, so I'm trying something quite different this time around.
Health will be the number of fruit you carry. You'll start off with 2 slots and can expand that to 5 slots.
The problem with health systems is that when the player is on or near full health, it's wasteful to take health items. So they end up hoarding them, and back-tracking around trying to find the items they left behind. This isn't a fun activity.
In Mojotron 2, there will be 2 meters that can be filled with fruit: health, and bonus. If health is at it's maximum, fruit taken goes on to the bonus meter instead. (and if health is lost afterwards, the bonus meter is unchanged.) If the bonus meter reaches 3, you get to choose an upgrade.
This will mean it's always in the player's interests to grab health items (fruit), so they don't have to give it a second thought as to whether it's a good idea or not. This should quicken the pace of the game.
This also means more health capacity makes it harder to get upgrades. That encourages people to postpone constitution upgrades, a risky strategy that will increase tension.
Explosives will play a big part in Mojotron 2. They'll be good for taking out rooms of enemies, and secrets will be able to be uncovered by blasting into caverns, through walls etc. I'm going to write code that procedurally generates shockwave graphics, and throws around fireballs and shrapnel. If this happens off-screen, none of this stuff will get done, and damage will be computed by radius. This should allow explosions to scale to limitless size...
This is no fun unless you have destructable walls, and I see no reason why ALL the walls can't be made destructable. I have a layer-based level format, and an explosion could just erase the tiles on the walls layer, to reveal the rubble beneath. A little tricky to do with 3/4 view tiles, but I think it can be done. And if level designers want to make an area completely inaccessible, they can surround it with a pit or a forcefield or something.
Laying multiple sticks of explosive will cause the explosion to become much larger. If the player is prepared to spend their entire collection of explosives, they can turn half a level into a smoking wasteland. (and lose a life trying to escape the firestorm)
There will also be a very simple inventory system for secondary weapons and temporary powerups. (yes, most of the twenty or so powerups from Mojotron 1 will make an appearance). It'll consist of about four slots, a Use button and a Cycle button. Each slot can contain an item with a certain amount of charge or ammo in it, and identical items will get 'stacked' in one slot. For example, to lay explosives you'll hit the Cycle button until explosives are highlighted, hit Use to set one (holding it down for more), then hit use again to trigger it.
Will this project get finished?
I completed Mojotron 1 to beyond what I initially planned, and I believe I will be able to make the time commitments necessary to get this version coded.
However, graphics are a really big job, and realistically, I don't think I can complete this project without help. Hopefully I can get enough publicity, and if there's enough interest in 2D game artwork, we can get a good team together.I need your help:
Gameplay ideas and code are welcome too. I don't believe in sticking rigidly
to a design doc. : )
Join the mailing list:
Check out the source code via CVS: