jonbho

So we’re going to make a game from scratch in one week. We better define our goals quite well beforehand, or we will waste the time allotment just making up our minds. Also, the scope better be limited, or there is no way we will get it done in such a short timeframe. But if we really focus, and we use every trick in the book, it’s likely we can do something pretty cool.

Goals and constraints

Here are the main driving factors when thinking up what to do:

• This is not a toy example. The game has to be cool enough to play and show around. We need interesting gameplay, a few effects and some polish.
• We only have one week. A week passes by fast. So: few variations of enemies/puzzles/skills if any, no complex physics or behavior. No time to do detailed level design, so go for simple procedural content generation, tweaked to provide some sense of progress.
• We don’t have a graphics artist for this project. I am collaborating with a great artist in a project I’m working on, but I don’t want to abuse his time. So we’ll have to either use abstract programmer art, or get some graphics available online.
• We’re trying to keep things simple for instructional purposes. Try to use a simple set of techniques.

Apart from these constraints, there are a couple of extra things I want to contemplate:

• Mobile-ready: although we’re going to develop the game to run on desktop systems, I’d probably like to port it to mobile later on. This means I have to be careful about some things. For example, the size of the screen (classic iPhone aspect ratio is 2:3, Android is all over the place). But mainly, the game controls and experience should consider mobile: short sessions, small touchscreen, no keys… Many modern mobile games amazingly only use a single control (“push anywhere on the screen”). Some games go even as far as merging the two main actions into one, such that a single screen tap will do both: fly & shoot (Jetpack Joyride), or jump and punch (PunchQuest). We are not going to do something so ultra-focused, but let’s keep this kind of thing in mind.
• I want a finished game. I want to complete some game elements within the project timeframe that most starting developers never get to: some sense of progress, a usable game menu system, and a few other touches here and there. So, although the most important thing is the gameplay, and the more days it has dedicated to it, the better it will come out, we will have to practice restraint and make sure gameplay work doesn’t blow up and eat the whole project budget.

Mulling over these concepts and looking for an interesting concept that fits, I went more or less down the following thought process:

• Our game will have to be built around a simple core mechanic that provides enough depth to prove interesting. Think “Tiny Wings”, it gets you a huge amount of playability out of very little content.
• I’ve always loved vertical scrolling shoot-em-ups. I grew up playing Terra Cresta on the arcades. This type of game could work…
• …and there is an awesome set of freely available graphics from Tyrian, a game of a similar style, generously provided by Dan Cook, who is the original artist. It’s fortunate that our gameplay is nothing like the original, so we are not risking any comparisons here.
• So: retro-graphics sci-fi vertical-scroller shoot-em-up it is. Portrait playing field, where you fly a spaceship upwards, and the terrain scrolls downwards as you advance. Your role is to steer the ship avoiding obstacles, and shoot. That sounds like it to me.
• Thinking about mobile: the classic vertical shoot-em-up experience really doesn’t work very well on a touch screen. No directional control or buttons. Tapping for each laser-shot turns from being fun on an arcade cabinet to being annoying on a touch-screen. But maybe we can do something: focus the game on the steering rather than the shooting. Tiny wings, Temple Run, etc… is fun with just jumping and turning, so it’s definitely doable. Let’s make the player focus on avoiding obstacles (rocks, meteors, space debris…).
• I’ve always been interested by the difficulty of landing a plane (on a flight simulator that is). If you’re not careful, it’s too easy to pitch the plane up or down too much, and then pushing too much in the opposite direction to correct it often escalates the situation into something more difficult. Maybe we can get something similar steering our spaceship left/right, with a nice dose of inertia.
• We’ll keep some shooting, even if as a non-critical element, adding some interest to the gameplay. We’ll decide how much weight to give it as we implement and test it (no point deciding all details now with too little information).
• Controls limited to left, right and shoot could work fine.

This is starting to look like something. We can have the main gameplay focused on manoeuvring the spaceship and avoiding obstacles. These obstacles can be generated procedurally, randomly and/or in patterns. We can probably find a lot of depth in this. Assuming the difficulty progresses as you advance in the level, the better the player is at this, the longer they will last. Not unlike a modern infinite runner (although I want levels in the game to have an end).

The speed of the game is an important factor. I haven’t mentioned it above, but I’m thinking about a pretty fast game. The world will scroll quite quickly, and it’s not just background decoration obstacles to avoid will be in this world, not “floating” slowly over it, so you have to react fast. It’s definitely a skill game requiring good reflexes. Maybe, this speed can be increased in each level for increased difficulty – we’ll see.

One last important point: a game based only in avoiding things has a limitation: the game can do some great effect when you crash into something, but it’s hard to do a nice, rewarding effect associated to not crashing, which is what should actually be rewarded! Positive feedback is much more hooking. So I thought about adding something to pick up to make the player try to steer to get things, not just to avoid things. Rather than random coins, let’s try to add “fuel” that you have to pick up which works also as fuel for the ship. It can be used as an additional way to let better players last longer.

Scaffolding

The core game mechanics is the most important thing, either that hooks the player, or everything els is unimportant. But you also need some kind of progress around the game: levels, progress, game types… and I want to show the whole process in the project. So let’s draft it up:

• Single-player gameplay only.
• Three levels, for variety and progress. We’ll switch graphics and difficulty will grow.
• Possibly, a “time-attack” mode could be added for infinite depth. We’ll see.
• In principle, we’ll have no player progress. We’ll remain open to considering this though.
• High-scores, credits/help, and the main interface to starting a game should be enough menus.

Schedule

Here’s roughly how I’m planning to organize the work during the development week:

• Day 1: Set up app skeleton. Load some resources and use them for rendering. General game logic base. We should be flying a ship over a scrolling background at the end of the day, and at least seeing some other elements flying around.
• Day 2: Core mechanic, gameplay, control, obstacles, and advance over the level
• Day 3: Work on the main elements of gameplay: collision response, picking up juice, shooting.
• Day 4: Level progress. Generating level elements, and generation of different levels. Both content and look.
• Day 5: Menus and general non-core game experience.
• Day 6: Build some kind of installer and deployment system, we want to release at the end! “Reflection” day. Other random stuff that is sure to be stacked up pretty high by then.
• Day 7: Details. Polish. Balance and gameplay adjustments. Anything we come up with.

I can already see several missing gaps in this plan: some gameplay variety with different elements, something special needed at the end of a level or the game… Bu it’s ok, I don’t have to nail everything, I will work it out as I go along. But, if we are going to make our target, we should not deviate much from the roadmap above.

I’ve seen multi-million dollar budget projects get started on a one-page-long design document with a similar amount of detail as above. There are always unknowns, and if you are really “risking it” creatively, there should be some. But the “general envelope” better be under control. The time estimation doesn’t look too unrealistic (only a bit). All in all, this is not that different from how many full-size projects are done. Let’s take the plunge and figure out the rest along the way!

And if you want to be notified when new articles to help you become a games developer are ready, just fill in the form below: