Continuing our look at my first-semester project on creating a game. Last time we looked at the research stage of things - picking a genre, identifying the key players in that genre and what worked for them, and perhaps what didn't work so well. Knowledge we could apply to the creation of our own game.
My game was to be a parody of sorts of the classic Super Mario Bros. Its original name was Bus Route Runner, based off a personal experience of mine where I missed the bus to school and decided to run the entire route to get there in time for an excursion (instead of, you know, going home and calling a parent to take me instead).
Dumb anecdotes aside...
Step 2 - Conceptual Design
So I wanted a platform game, like Super Mario Bros. I had already analysed several other platformers, and now needed to come up with a number of things for my game. These included
- a player character design
- level designs
- object design
- enemy design
- power up design
So I started sketching stuff up.
|Storyboard for the opening cutscene of the game before the player gained control.|
I initially used a striped tie for this character's design, but it was pretty hard for me to sprite and the initial way I had drawn diagonal stripes didn't lend itself well to sprite flipping. In sprite based games, you may notice that characters are designed to be symmetrical. It's a lot easier to flip the sprite around (and saves a lot of memory) through a single line of code like
than it is to create a separate sprite. This information would have helped a lot when it came to animating the character, but I'll get to that later. For now, more crappy conceptual art!
Some simple power-ups, based off power-ups I had observed in other games which worked.
Obstacles and enemies, based on the setting of the game. Apologies for crudeness, a lot of these were whipped up the night before a tutorial so that I had something to show to my class and tutor.
|The end-of-level flag and school. Crudely designed, again. This part was meant to parody SMB a bit more than the rest of the game, just sad I wasn't able to implement this.|
|Tutorial signs and terrain in levels.|
Looking back, the last of these images is the most interesting to me in terms of design. I've always been a fan of games which forgo wordy tutorials in favour of subtly hinting you about what does what in an interactive way.
Take the beginning of Portal 2, for example. A computerised voice first tells you to go and look at a painting on the wall and tells you it is art - to show you how to move around and change your viewpoint. Shortly afterwards, a helpful character known as Wheatly busts into your room and asks you to talk. A spacebar prompt appears, but it only seems to allow you to jump - not the kind of feedback Wheatly was intending, but he plays along anyway.
The game has just taught you its basic controls, while remaining interesting and without breaking the fourth wall. There are a lot of other examples I could have used here, but there are also a lot of games that don't do this and resort to that screen full of text or a diagram of a controller with arrows shooting out in every direction. That's bad.
Since this was a platform game I didn't need to use a design element like this. An alternative would be to use some brief text at the bottom of the screen which would fade in if the player hadn't moved after a few seconds. But it was cool to explore some different ways to show what to do... even if the signs drawn above probably weren't the best and wouldn't have helped much.
|List of concepts to include in the game|
One last thing before I go, since this blog is getting way too long as it is. This was a list of things which I wanted to include in the game and what would be included. The bottom list was a list of stuff which I could cut if time ran short (which it did). Normally this list would be a lot longer, especially when working with a team, because you would need to convey clearly to everyone in that team what everything in the game did. It's great having a neat concept in your head, but you're not going to be able to do everything yourself. If you want that vision to match your final product, you need to write your concepts out clearly, otherwise once you delegate roles to other team members who knows what you'll end up with.
At this point last semester, I had bought a book on programming games with Flash and had done a few tutorials. I had a bit of experience creating sprites, but probably not enough to finish all the assets for a game in time for a deadline looming just six weeks away. And while I had programmed a few things in C++ and VB.net in the past, creating a full, working flash platformer was not the place to start here.
Never underestimate how much work you have to do and the skills you have. While it's great to be innovative and ambitious, you need to know your limits or else you won't get off the ground.
Next: Part 3 - Development and Where it All Went Wrong
Author's Note: remind me to never play with the formatting on blogger again. Or the font styles. Editing is a pain the ass.