With Spacecrash we’ve seen how to complete a game. Here are my conclusions and next steps.

sc-action-screenshotI started the Spacecrash one-week-game series with a question: “Can you write a game in one week?”. But the main point was addressing the reasons why people get stuck trying to complete their first game: be it for lack of technical skills, excessive scope, or a lack of a clear game concept and focus. After dedicating the whole last week to doing the project and sharing it, I’d like to review the thoughts of that first day in the light of what we have done.

[Note: I am not calling this a postmortem because there is one pending thing I still have to do, which is to balance the gameplay difficulty and content generation. I plan to do this in the next few days and do a proper postmortem after that. But I did want to think about and post the conclusions shortly after finishing the series.]

How did Spacecrash help with the main reasons why peple don’t finish games? Here are the details:

Continue reading

Spacecrash day 7 of 7: game complete!

Screen Shot 2013-09-01 at 11.04.16 PMOk, so the last day arrived and I had a chance to do the following critical things:

  • Fixed the pending bugs (hopefully all of them)
  • Adjusted gameplay: completely removed fuel, and removed manual accelerating/braking
  • Added sound effects for crashes, explosions, rockets, spaceship engine, etc…
  • Added particle-based explosion effects
  • Added cool techno background music
  • Added score to in-game UI
  • Beautified main menu, completed info & credits
  • Made the game save and restore options and current progress

The end result is that we have something that looks very cool, watch:

Spacecrash: Day 7 of 7 from Jon Beltran de Heredia on Vimeo.

Continue reading

Spacecrash day 6 of 7: installers and more

So let’s do the last remaining piece of the puzzle. If you are going to deliver your game to players, you will have to package it nicely for them to download and install. The packaging process is different for newer platforms such as iOS or the Android Google Play marketplaces, but for Windows and OS X, this means building an installer. This will package everything nicely together in a single file that the user can download and double-click, and which will leave the game in the conventional location for installed apps on their system.

Since we are doing Windows and OS X mainly, I will build installers for these. I use package managers for Linux, but I haven’t really looked into how those are built – if anyone can shed some light about this in the comments, together with how to tackle the multiple-incompatible-Linux-package-managers issue, I will be grateful!

Continue reading

Spacecrash day 5 of 7: fonts and menus

mainmenuSo today I took the time to add some text-based menus. Nothing out of the ordinary, but something necessary for any complete game. I spiced up the menu just by having graphics from the game in the background – this is a common trick by all cost-conscious game developers since time immemorial!

KromaskyFirst thing I needed some way to draw text. OpenGL doesn’t provide any built-in way to do so, so you need to do it your own way. The simplest thing is to prepare a texture with your font, and paint pieces of this texture for each character. You can see the texture right next to this text (this is a font by Marc Russell from SpicyPixel – thanks!), and here is the code to do the text drawing using this font:

Continue reading

Spacecrash day 4 of 7: multiple levels with cool, varied graphics and gameplay

tiled_background_3I initially planned to have only 3 levels, but turning that into 9 looked more sensible: completing a level is a positive reward for the player, and thus it will help us provide them with a better experience. So let’s get started trying to generate nine levels with varied graphics and progressive difficulty.

Both variety and progression are very important to providing a satisfying game experience. Let’s start with the graphics which are the easiest here, thanks to Dan Cook’s Tyrian graphics. I initially planned on having three “worlds”, thus three main sets of graphics, and three levels in each world with progressing difficulty. But given the Tyrian graphics easily allow more variety, I have decided on having 9 different looks, one for each level.

Level graphics

Having a look at the Tyrian graphics, I saw some interesting things for level background graphics. Have a look at this piece (shown at 4x size):

Continue reading

Spacecrash day 3 of 7: gameplay revamped

sc-screenshot-day3After we started to get some gameplay yesterday, let me take a bit of time and recap where we are. During the project, you have to focus and often need to work as fast as possible, but it’s important to raise your head every so often and make sure you know where you are and where you’re heading.

We are starting some gameplay out of the prototype in the current stage. It is sometimes genuinely fun to fly the ship manoeuvring between the rocks. The variety is low, but still it’s proven a bit of a challenge requiring me many attempts to reach the end of this level as posted yesterday: the end of the level is defined by the constant #define RACE_END 100000.f at the top, since each screen is 1500 units high, this means you need to fly 66 screenfuls without dying to complete it.

There are a few gameplay elements that are sure to add to the experience, at least in variety: my idea is to allow the ship to self-repair slowly by spending fuel, and I also want to add shooting rocket, extra clumps of fuel you can pick up, and also the possibility to slow down / accelerate at your own will. Apart from these gameplay elements, there are quite a few things I’m planning to add only for it to look, play and sound cool: sound effects, particle effects, nice background graphics, animations…

But let us not lose focus. All the elements above (both gameplay elements & all special effects) will not “fix” the core experience. That is something that is essential to the core gameplay. And there are some “gotchas” with the current model.

As a player, I'd stop playing after stumbling upon this. Not good.

As a player, I’d stop playing after stumbling upon this. Not good.

The main limitation in the current gameplay is that the totally “random” distribution of rocks creates a very uncontrolled experience. You can fly for quite a while without encountering more than random easy-to-avoid rocks, and suddenly, you can stumble into a barrier formed by several rocks which there literally isn’t any way to avoid. This is tremendously frustrating, and it totally kills the player experience. The player wants to think that this is about their skills, and it’s very important for them to know that, when they fail, it was because of a mistake of them, and that they could fix it next time.

Don’t get me wrong, luck can play a role, even an important one. I have been playing plenty of Candy Crush Saga myself lately… and you can bet I think is more about luck than about anything else… but still tremendously addictive. But the point is that in CCS you still have some doubt about whether luck was the cause or not, and you can at least always play, even if you don’t beat the level! In Spacecrash, when you confront the player with a barrier of rocks without a single gap, they just feel insulted.

How can we address this? I can think of three different ways:

Continue reading

Spacecrash day 2 of 7: core gameplay

Screen Shot 2013-08-28 at 12.39.40 AMToday is more “gameplay day” than anything else. We have to try and squeeze some gameplay out of the game concept we are working with. I’ve spent a few hours and it’s starting to show some promise.

First thing: you want to start playing as soon as possible, to get a feel of the gameplay experience. It’s less important to have great sound & graphics feedback, you can easily imagine that. But you need the core control & game result. In this game, I’ve implemented crashing into obstacles and a life/energy bar as soon as possible. After that, it starts to be a game, since you can die!

One concern I have with this design is that, since content generation will be random, it will be quite difficult to control. I will try to use patterns and pattern sequencing to control this better (for example: define a level by sections, and manually control parameters controlling the random generation of each section). But still, you don’t have all control. To me, this means it’s better to make a game which is somewhat “forgiving”: crashing into an obstacle shouldn’t finish the game, since we won’t even be sure we won’t generate situations where it is impossible not to crash into something.

Continue reading

Spacecrash day 1 of 7: game skeleton

shot0Time to get started. Today I am going to set up the main project skeleton, project directory, get it to compile on both Windows and OS X, set up loading textures, and get a spaceship to fly over some kind of scrolling background. Plus possibly have a few things flying around.

Setting things up will be a bit painful, since there are a lot of small things to configure correctly. Projects, modules, etc… if you are not all that fluent in C/C++, and something isn’t easy to understand, don’t despair: follow the instructions to set it up, ask your doubts on the comments, and remember that we will only be doing this type of stuff today, since once things are set up we will be concentrating in the game code. I am going quickly here, so you will be able to put in the time and effort after this week, and be able to understand all the details of today’s work when you look at it more slowly.

Continue reading

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.
  • Continue reading

One-week-game: getting ready

Ok, so if you want to benefit the most from the one-week game I’m going to “live develop”, the best thing you can do is to follow and develop along. You can just read the source code and other materials I post, but nothing beats doing it with your own hands too, and seeing the thing grow from nothing into a cool little game.

Let me review the two most important things now: the previous knowledge you should have, and how to set up your development environment.

Required knowledge

First thing, you need to know some programming. It’s impossible to get up to speed from zero into game development in one week.

But if you have some experience programming in nearly any common language (java, javascript, python, php…), then it should be really easy for you to get up to speed.

Continue reading