Spacecrash: designing a one-week game

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…

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:

I have been looking forward to the next day every time I read your post. This project of yours is honestly an incredible resource for newly starting developers (like myself.) I truly appreciate the time you’ve already invested and I can’t wait to see what you come up with. It’s too bad that you didn’t make yet *another* side-scroller, but I’m really interested in vertical movement and collisions.

In any case, I wish you well on your endeavors. Potentially when I’m a world famous game dev myself, I’ll find a way to pay this forward.

I think it would be great to add some shields as a variety. Like make the player steer to grab the shield. So in case of a collision the player won’t die from the first try. Also it would be great to add some kind of life system (tries) so that a player could try and re-do a level from it’s previous death.
Would be nice to have a boss fight at the end of the level.
Also for a better experience it would be nice to set up a few on ground enemies which can throw (shoot) objects at the player.
I spent all my childhood playing games like “Sonic Wings” at the arcade machines.
I suggest checking out this game it’s also, i bet we can implement a lot from it.