I am going to use this post to describe a game design I’ve been working on for about a week. I’ve given this project the codename Oracle’s Eye. Just because, really.
Why a codename? After working on FuseGB for June’s Game in a Day, I realized that sometimes the game doesn’t end up the way you planned. The game in the end didn’t have anything to do with Fusion, so the name was weird. Unfortunately, my project folder and Subversion repository was already using the name, and I didn’t want to mess around with it. If I use a codename, however, I can change the name of the actual game and not worry about how it will affect my development environment. The real name only matters when I publish it.
Anyway, Oracle’s Eye won’t be anything special. I am purposely trying to design a small game that can be completed within a month. In fact, it may be that what I’ve come up with will have to be reduced in scope even further. I need more experience and shouldn’t stop just because the game might not be very original or fun. I can concentrate on innovation and fun when I know more about how to make a game.
Basically, I am thinking about making a game like The Adventures of Lolo and Boxxel. The player will have to move about the screen, pushing objects around, and trying to get a Ball into the exit. Some objects are moveable, some are destroyable, and others can be activated.
The main object will be a Ball. The Ball will sit until acted upon. Then it will continue until redirected or stopped by a wall. To make the Ball move, the player can “kick” it by walking into it. A Ball can also be shot out of a cannon if the player walks into it to activate it.
To maneuver the Ball, the player can manipulate different objects in the level.
Some basic objects I plan to have in the game:
- PIPES can redirect balls
(wow, does this look bad) - GRINDERS can split ball into multiple balls and shoot them in multiple directions
- WALLS can act as angled banks to bounce balls
- PITS will steal balls
- ENEMIES will fire upon player along straight lines and can be destroyed by balls
- WARPS will transport an object to another spot
- ARROW blocks will force objects in one direction
I can already see that a number of these will not likely make it by the end of August, but having more ideas than can be used doesn’t hurt.
The player won’t be able to do more than walk around. No shooting or button presses are needed to do actions as everything will be based on contact. If the player touches an object, the object gets moved or turns on or gets activated or whatever. I’ll probably track input to reset the level and to pause the game, but otherwise the controls will just move the player in four directions.
For simplicity, the levels will be “rooms” that can fit entirely on the screen. Rooms will be made up of permanent walls, an exit, and various objects.
Obviously the above is a bit too general, so it would be quite a stretch to call it a design document. I think calling it a guideline should be accurate, though.
Sounds like a good plan. Nothing gets you working better than a deadline. 1 Month sounds like a good time frame because it forces you to really trim down your design to the essence of the game, but still gives you enough time to put some spit and polish into it. Good luck and I look forward to seeing the results.
Left by Make Mac Games on July 27th, 2005