Here we have the design I did to participate in a game design contest. Whether I get mentioned or not, I like this design enough to shelve it under the “possible” projects. There was a limit of 500 words, so I kinda had to compress things a little bit. You know, I was surprised by how much I could say with just 500 words and an image. It’s a wonder why I always needed more than that for almost every single post. But now? No sir, I’m absolutely sure that I’d never, ever, need more than 500 words to talk about something ever again. That’s right, no more than 500 words, can you believe it? It’s impressive how powerful brevity can be. Every word tells it’s own story, and I think I squeezed every single drop of juice from every single word. But if every image is worth a thousand words… does that make my entry 1500 words long? Heh, I hope I don’t get disqualified for that! That’s something I wouldn’t want to experience. No sir …. Where was I? Oh, right, brevity. It’s awesome. Like, totally.
Alright, alright, I hated it. I had to gloss over half of what I had to say, but I guess this was a good exercise for learning how to get to the point instead of dancing around it. Also, it appears that my brief encounter with brevity and self-constraint didn’t teach me a god damn thing.
Anyways, the entry in question:
The game is primarily vertical, with levels spanning the two screens and the main character staying on the bottom one. The levels would be populated with objects with different properties. Some levels would have air currents affecting all movable objects.
Since this game revolves around objects, let’s define the main properties that can be assigned to any of them:
- Can stick to any surface (like the main character).
- Can be moved with the stylus.
- Is tethered to another object by a rope.
- Can hurt the player character if he touches the surface.
- Can be activated or change state when tapped.
- Is pinned to the background.
- The main character can’t stick to it.
- Has it’s own gravity pull.
- Can be thrown like a slingshot.
Yeah, that last one isn’t very self-explanatory. In a few words, it could be considered like a less restrictive jump mechanic. The player can tap the object and then drag in the opposite direction he wants the object to go. Sort of like a slingshot. The more the player drags, the more force the jump will have and the more distance the object will fly.
The player controls one character with the stylus. This character sticks to almost any surface, or in other words, he can walk on walls and ceilings. The player can tap anywhere on the screen and the character will walk to the closest point. To jump, the character makes use of the property number 9. Once in the air, the player can do swipes with the stylus to correct the jump in the direction of the swipe.
Main Campaign Mode
The player has to get the main character to the finish line of every level.
Timeline challenge Mode
A series of levels where each one lasts 10 seconds and there are at least 4 playable characters that have to reach the goal. At the bottom of the touchscreen there’s a timeline with each second marked and above it there’s a little menu with play, pause, rewind and fast forward buttons. When the game is paused, the player can issue his commands that when unpaused will play out. There’s a maximum of 8 commands at once and the game can only be paused on each second (press pause and the game will do so when it hits a mark in the timeline).
These levels work as puzzles and the characters would have to interact with each other to get to the exit.
The player can pick any level that comes with the game, or a blank slate. Once selected, the level starts in pause mode with a menu where the player can destroy any object or create one by choosing from any sprite already in the game or by drawing one, then choosing the properties and then placing it in the game. Select which object is the main character and then you can hit “Go”. Once in action you can pause again to continue modifying the level.
That’s it, that’s my whole entry. It’s so compressed that I’m left wondering if it’s actually readable or not. So, to clarify a few things, here’s the addendum:
Perhaps this wasn’t clear enough, but objects generally tumble and rotate “realistically” (as real as it can be on the DS hardware). That means that an obstacle can be just a huge pile of boxes and the player can go through it in various different ways. For example: drag an object, with properties 2 and 8, and let the boxes fly towards it like flies attracted by the light; then deposit your load of boxes somewhere else. Another way of doing it would be to crash repeatedly into the pile of boxes until you can pass through. Or maybe you could just cling to a rope, swipe left and right with the stylus to build momentum and then launch yourself against the mighty pile of boxes.
Oh, right, ropes, how could I forget about those?
Ropes are implemented with ragdoll physics, and that means that they react to currents, other objects clinging to them (added weight) and gravity. Some enemies as well as the player can cling to ropes, climb up and down and swing around.
Currents follow a preset path given the limitations of the DS (fluid physics are not exactly easy to process). Just like everything else, it can be modified on the sandbox mode: Once selected, a series of dots show where the path of the current is. Naturally, these dots can be moved around, deleted and created. On a side note, it would be interesting to have the speed factor specified on each dot instead of having the whole current of air be the same speed, although I’m not sure if the benefits in gameplay outweight the added programming difficulty.
Oh, and I guess it goes without saying, but the currents are visible since the player has to be able to predict what forces will be affecting him once he jumps (which are: air currents, gravity and stylus swipes).
Levels can have their own gravity, so it’s possible to make a more or less traditional platfomer (albeit, a traditional platformer with a very weird jump mechanic). As expected, this is also customizable, so the direction and intensity of a level’s gravity can be modified in the Sandbox mode.
Wow, there’s not even the slightest mention of “enemies” in the entry. Curse you word limit.
One of the enemies I designed was pretty much a slightly modified goomba: a circular object with the properties 1 and 4, that moves continually in one direction. Enemies can only be killed by being crushed with objects, so the main character himself doesn’t actually kill anything, things just fall and kill things around him (player taps on an object, object detaches from rope, flies for a few seconds and lands on an enemy, crushing it to death with gruesome results (an explosion, puffs of smoke and a particularly satisfactory *ding* sound)). Of course, if the player gets a powerup, the enemies are toast.
In just a few words, the difference between normal objects and enemies is that enemies can be killed and they move around according to an algorithm instead of a set path.
Yes, this is something I wanted to include but since it ultimately didn’t expand on the design itself, I ended up cutting it out of the entry.
Anyways, the most fatal flaw of this design is that it could be incredibly hard to program or prone to slowdown. Due to this, levels should be designed with a very hard limit to the amount of objects on screen, which would translate directly into Sandbox Mode. I don’t know about you, but that sounds to me like a pretty frustrating restriction (for the level designer and for the player).
The other flaw that I can deduce from playing the game on my head is that it’s easy to try to tap an object and miss. Which shouldn’t be much of a problem, except that when the player taps the screen, the main character tries to walk to the closest point. So, the player tries to activate an object by tapping it, but he misses and the character starts to walk there. It can get pretty frustrating, especially if the character dies because of it.
But these two problems can be addressed! How? Oh, I don’t know, maybe by developing the game on the PC and using the D-pad?
Since here in my own blog I don’t have to follow the constraints of the contest, I’d like to change two parts part of the original design: First and foremost, I’m really doubtful that the full game I have in my mind can be developed on the DS without comprimising at leasst something, so there are two routes I can take: Develop it for Wii or develop it for PC. Something tells me the latter is the obvious choice, but I wouldn’t discard the former just yet. I can dream right?
The other thing that I would change is movement, of course: For moving left and right, I’d definitely use the D-pad. Also, when clinging to a rope, pressing up or down will make the character move up or down the rope (how would I do this without buttons? Maybe I’d have to have the up and down buttons show up on the screen when the character clings to a rope … which is a patch more than anything else). I have a d-pad and I’m not afraid to use it, dammit.
Wow, more than 1600 words already? Guess the entry was actually a third of what I wanted to write, not half.