Month: August, 2013

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!

Read the rest of this entry »

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:

Read the rest of this entry »

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):

Read the rest of this entry »

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:

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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.
  • Read the rest of this entry »

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.

Read the rest of this entry »

Can you write a game in one week?

Do you have half a dozen unfinished game projects lying around? Have you switched tools or programming languages more than once trying to get that first game finished? Does it feel like your enthusiasm for a new game project takes off like a rocket ship, but then dwindles and crashes into the ground with too little to show for it?

If so, don’t despair: there are many issues to overcome, so getting started is understandably hard.

The problem

If you have put time into writing a game of your own, and you haven’t been able to complete it, there are three main likely reasons:

Read the rest of this entry »