I’ve tried so many different ways to create what you might call a templated approach to designing arcade games. In some cases it’s worked. In others it simply hasn’t.
To a certain degree I play safe with established game mechanics. River Raider, Dungeon Adventure and Galactians all follow a tried and tested model that was employed successfully to games that are 30 years old.
I always create a design document of sorts and dump it in the root of my game project. It’s extremely crude and carries the file name _devnotes.txt
Here’s an example using my current project Distant Orbit:
Game file: DISTANT ORBIT Destroy, avoid and collect across a sprawling, scrolling landscape with the ultimate goal of destroying the alien communication tower. Player must protect his Energy Bar (Shields) as his starfighter comes under attack from alien craft. Comm towers are protected by energy generators that must be destroyed. These are the same as obstacle sprites but have a special type of "ENERGY" for the collision detection. A visual indicator shows the number of energy towers that remain. Aliens - avoid and destroy Bonus aliens - avoid and destroy for released bonus, e.g. laser enhancement, fast-lasers, replenish energy Alien laser bombs - launched from alien surface craft ( avoid ) Energy pool - on the floor ( fly over to gain energy ) Dark matter - on the floor ( avoid or lose energy ) Environment obstacles - on the floor ( avoid ) Energy tower - glowing obstacle ( destroy ) Alien saucer - hovers over terrain in the near distance and launches energy bombs toward the player - not sure how to destroy this yet - if at all ! Gems and powercells - on the floor ( collect ) There will be heavy emphasis on the avoid / collect dynamic. A skillful starfighter pilot will be able to shift between obstacles and collect valuable items whilst gunning down advancing aliens. Tower becomes vulnerable when all energy towers are destroyed ( icon lights go out as each tower goes down ) Level ends when tower is destroyed. Cut sequence showing the starfighter leaving the planet. Show analysis of the spoils from the planet and award bonus points and achievements, i.e. All planet aliens destroyed, mothership destroyed, collected 100 powercells Cut sequence showing the starmap and selection of next planet. Possibly inject a running storyline.
It occurs to me that this is actually how I work. I’m not one for tremendous amounts of planning upfront. I’d much rather get my hands dirty with code and some basic “placeholder” artwork and try to mould a game from what I have. A kind of organic approach if you like.
With some games it’s easy to do this since you know the basics of the game’s design based on the “classic” game that it borrows from. But with other games, such as Distant Orbit, it’s a little more tricky.
When I am faced with actually having to balance the game’s design aspects myself I tend to start with what the player has and see it in terms of what he is trying to protect.
So in the current case I naturally consider the starfighter and how I must protect it. What is the worst case, what could possibly go wrong and what would I need to do / obtain to prevent these things from happening. ( Something of a CBT approach to game design !? )
This naturally leads me to thinking about an appropriate adversary and presents some questions that need to be answered and understood.
- How do I control the player sprite ?
- How do I attack / avoid ?
- What is my short term goal ?
Once I’ve understood these things I can identify how best to challenge the player.
With a game like Dungeon Adventure ( which was essentially Pac-Man with magic ) it was simple. There is little room to move, the player had to think a few steps ahead so place required objects where the monster will tread.
I like to inject a few ideas in to the game and play them before approving / eliminating them. Again very organic. If I like it, it supports the ultmate goal of the game and it “feels” OK to play then it stays.
With mobile gaming you always have to think of the device and its limitations. I only ever target touch screen control so a few things must be assumed.
I loath and detest on-screen buttons and joysticks. It’s lazy and un-necessary. So to get the best out of the game it makes sense to have a few things happen automatically. Laser firing, item collection, trigger points for certain actions such as opening doors. Again, if it works it stays.
Whilst there is harmony in the process I am happy that the game is going in the right direction. As Jackson Pollock said “it’s only when I lose contact with the painting that the result is a mess.”
I strongly believe this. When it’s going well and the design elements are slotting in to place such that the end product is fun and rewarding great things can happen. Good ideas follow good ideas. Having confidence and belief in your work sends you on a journey of design and development that you ultimately return to in future work since you “got it right”.
The rub here is of course that you end of with a shelf loaded with game projects at varying stages of development. I currently have as many games on the shelf as I do completed. There’s some damned good stuff on that shelf and when I find the right amount of inspiration I will complete them all. Sometimes it’s just the way it goes.
If I lose touch with the work I move on.