So I Finally Took Time to Make a Game


I had many “reasons” to make this game. First and foremost, since I’m a gamer (since years ago), I have always wanted to make my own game. I have always wanted to feel what it takes to make all these masters pieces I love to toy with. I would bet most of us here feel the same. Besides, porting is nice and all, but I somehow reached a limit at what I was able to port. By the end of 2012, I scored way more failed ported projects than successful ones (my GL knowledge was clearly too limited). Then I had a tough year (moving is a pain; and still having rough times…) so no time to hack. By the end of 2013, I started having some free time back. Looked like a perfect timing to start my own game.

[ This is guest post by Sebt3, long time porter on the Open Pandora, and first time game designer for Schmuppan, his first shoot’em up game. ]

So the project started. My whole programing experience resumed at panmines (arguably not a game). I started by looking at it and list what I dislike about it :


– no animation at all : it can just display the memory representation of the game
– using C++ yet no real usage of OO concepts
– missing ton of features (no UI management, no texture loading, no text rendering, no music, etc…)

What I liked in it that’s not common in gaming : no loading time, so it was fine for a very quick gaming session.

At this point I was not even sure if the game would 2D or 3D, let alone the game type I was targeting. The real motive was knowing howto.

Code designs and optimizations

So the first thing I did was converting the code from C++ to C code : I’ve ported many games where the coders have over-used the OO features, in the end you end-up lost in what is going on. I wanted to retain control on that.


For the neophyte : While the C language is universal, it is rather bare metal and provide few features to the programmer. C++ is an enhanced version of C featuring many functionalities like inheritance (which allow better code sharing), standard list management and many more.


Then, I thought about the resources loading problems. More often than not, gamers are presented loading screen. While I get that loading complex model and all might takes time, I’ve seen many games that does many transformations on assets while loading them. Say they deliver every level design in XML files, which are 1st loaded to memory, then parsed, transformed to an intermediary status, which is parsed by another part of the code that finally produce the memory structures the game will use. I call insanity on this. Sure it helps while designing the game as you don’t need to assemble the data on each test, but that’s pushing the problem on your users ! The data the game load have to be ready to use directly in a single load from disk to game memory structure in a single pass.

But as I did not wanted to reinvent this wheel, I looked for available solution for this problem.

Physfs ( have been my first idea as I saw it used in many games. It is nice and provide tons of features for games, yet it did not cover what I was really looking for : storing data structures.

Then I thought about EET ( After a rapid prototype, I was very happy with the result. I was able to store complex data structure freely and have it restored in memory even with correct pointers and all. With that, I’m able to have a complex 3D model loaded ready to be rendered in a single pass with a reasonable performance.

Beside EET come with its little companion : EINA, which provide many useful stuff :

– lists management functions with a great deal of performance in mind (faster than STL implementation)
– Fixed math based function

My dev environment.
My dev environment. (click to enlarge)

As a DBA, I know data-models are game changer performances wise. Many games I have ported, use a virtual representation of the game, but when rendering they convert that view into something drawable. To reach 60fps, this conversion have to occur 60 times per second, so you’d better have that optimized. But if the data-model you use can be directly used by the GPU, no more need to convert the data from the game perspective to the drawing engine perspective. Winning tons of cycles. So I decided to maintain the memory structure required to draw to GLES and base game information on this and not the other way around.

OpenGL profile tool. (click to enlarge)
OpenGL profile tool. (click to enlarge)

The other data-model problem I was aware was : the SGX in the Pandora doesn’t like state changes and also prefer grouped data to more calls (at least as long as performance is a question :D). In this respect, the OO design where every object have its own drawing method (that set the status to what it want) is not a good idea. Sprites have to be rendered as groups. Say all the bullets have to be drawn in one single pass.

The good news here is : the rendered objects will be rather simple, after all, a sprite is just a single quad, or in case of GLES a pair of tri. So grouping there shouldn’t be too hard. To make things even easier (saving on the array realloc), the memory structure will have a max size initially allocated. Let’s name that a renderGroup. It’s just a struct formed of :

– the vertices array
– the texture coordinate array
– the indices array
– a maximum reached for each array.

Beside, once created, a drawable doesn’t need to change its indices array. That’s good news as it’s the only data set that is impacted with grouping so the indices array is requested when creating a new sub drawable in a render group. The created drawable structure have pointer to the place they have their space allocated. Here is how it look in pseudo (not presented as-is to a compiler)  C code :

typedef struct drawable {
float *vtx;
float *tex;

typedef struct renderGrp {
float *vtx;
float *tex;
int *indices;
int maxvtx, curvtx, maxind, curind;

renderGrp* createRG(int maxvtx, int maxindices) {
ret=calloc(1, sizeof(renderGrp));
ret->maxvtx = maxvtx;
ret->maxind = maxindices;
ret->vtx = calloc(3*maxvtx, sizeof(float));
ret->tex = calloc(2*maxvtx, sizeof(float));
ret->indices = calloc(maxindices, sizeof(int));
return ret;

drawable* createDrawable(renderGrp *g, int indcnt, int *indices, int vtxcnt) {
// build drawable struct
ret=calloc(1, sizeof(drawable));
ret->vtx = g->vtx+3*g->curvtx;
ret->tex = g->tex+2*g->curvtx;
// update rendergroup

for(int i=0;i<indcnt;i++)
g->indices[i+g->curind] = indices[i]+g->curvtx; // adding the padding due to previous items
g->curvtx += vtxcnt;
g->curind += indcnt;
if (g->curvtx<g->maxvtx && g->curind<g->maxind)
return ret;
return NULL;

Once there, you can use the drawable structure as you would do when not grouping. Simple right ? well not much, there is 2 issues left :

– how to handle/reuse objects deleted out of the array
– when should the array be reduced so there aren’t too many objects dawn (as the longer the arrays are the slower it will be rendered).

I’ll let these 2 questions to the reader 🙂

On the bright side, with this method, the number of GL calls your game make is constant. So the render time is also rather constant too (as long as the array size doesn’t grow too much). If you manage to have the event loop on a constant length too, you won’t have much surprises.

On a side note, as I want the data ready to render, the tile-maps have to be stored pre-rendered. So this code block appear twice in my code : once for runtime (used for enemies and bullets) and once for tile-maps in the data packer code. So tile-maps are just large renderGroups.

The blurry tilemap. Did not work as expected.

Actually too large renderGroups, sending the whole maps for every frame was very expensive as the GPU have to go throw the whole array every frame and drop most of the points as they are off-screen. So I added a hack :

The tile-maps are pre-rendered by columns, then only the columns on screen are rendered. the trick here is very simple : when calling glDrawElements, point it to the indices where the left column start, and the count is always the number of dots the tile-maps have on screen 🙂

Finally, a last point I want to discuss about game code design : fixed point math. As I read everywhere that fixed math are faster than usual floating point math and EINA provide fixed math function (and EET also provide storage for fixed data type too). I tried this way. In the end of the day, the performances gained on the CPU doing math is lost on the GPU (probably converting back to floats). All in all, there are not much gain. the performances are more or less on par. I guess if my game engine had a complex physics engine with a lots ongoing in the event loop, then there would be a gain. (Sprites are moving on simple paths, collisions detections are rather simple. In the end the game mechanisms are very very basics here). On the other hand, I wouldn’t like having to write this physics engine using fixed math : the problem with fixed math is that the code is way less readable. Fixing a bug here would be a major pain. I’m definitely unsure there is a real gain going this way. At the very least, don’t start designing your engine this way…

I for one, will probably go with simple integer math next time as precision isn’t that a problem when gaming, and nothing stop you to have 10int value for a single pixel on screen, so one could simulate sub-pixel movement good enough this way, yet with not floating math performance impact.

In the end of the day, for performance, there is only 3 things that matter : profile, profile and profile 🙂

Assembling assets

That part of the game making was very new to me. Panmines score no assets at all 🙂 Oh and my artistic abilities are sub-par. (I say sub-par because I love myself, otherwise I would just say shitty :D) So I needed assets for your eyes and your ears. Beside, as I scored no previous game, managing to get artists on my project would have been at best hard. Understand them : No proof that the coder will finish the game (so many artist have worked on game assets for a game never released) and not a single demo of what he can code so the probability that the artistic work is dropped in a trash can is very high…


Luckily, there are tons of games resources available on the net. Sprites-sheets are legions so are tiles-sheets and 3D models. should definitely be your first stop while gathering assets. But don’t stop there, there are just so many other gaming resources available. OGA just made the one you’re allowed to use easier to find. And by allowed to use I mean, the licenses of the asset allow you to redistribute it and use it in a game. In that hunt the problem is often : there is no licenses attached to it. Which pretty much mean : you’re not allowed to use this unless you’ve asked to author (which come at a large cost : finding him back)

I’ve settle only on asset with a CC0 license attached to it. Yet I find it nice to great the artists that allowed me to do this game, so even if I was not required to do so, I created a simple credit screen. For me that sound like the way to say : thanks 🙂


I want to drop a note on SFXR : if you’re looking to build a set of samples sounds and you want to get the retro feel to your game, this tool is perfect for you. Very easy to use and very pleasing results.

All in all, don’t underestimate the time you’ll spend on this. Assets hunt have probably accounted for a quarter of total time spend on the game for me.

Building the game and… finishing it

Before starting this project, for me creating a game was just :

– Doing a few Google searches to compile the data
– Writing the game code

And that’s it… Well, if I got a lesson while doing this game is : this is damn wrong. This account for less than a quarter of my time on this game.


Writing the engine has been done in 3 weeks more or less. The hardest part have been writing the animation framework as I was completely scared : I never did that and it looked so very complex. It took me 3 weeks (not counted in the previous 3 weeks obviously) to get out of the torpor and realize that, step by step it was doable. The rest of the of the time, I was just coding the design I set at first. On a side note, don’t write your own game engine if your specific target is not to learn how to. There is so many existing engine, there is one for you out there without any doubt. I for one will very probably reuse someone else engine for next game (if that ever happen). There is so many version of the wheel out there that your version won’t add any values (works also for mine :P)

As the game mechanics are very simple, most of it have been wrote in a week or less.

Yet making this game have lasted over 6 months (nearly 7) for a real total of about 3 working man months of work. So where most of this time was spend on ? On parts I did not expect spending time :

– finding suitable assets
– building levels
– polishing it
– reading about good game design and the difference between good and bad one
– polishing this game even more


I’ve already discussed finding assets, next point : building levels. I was expecting this to be rather fast once I had the tile-sheet and sprite-sheet. Building the tile-maps are easy using Tiled (btw, thanks to Canseco who ported this gem to Pandora at the exact moment where I needed a tile-map editor) and converting tiled data to the format I’m using in game is rather easy (xml file for the win). I was not even targeting a given level of coolness on these tiles-maps. All I wanted was : having different background for each level. No real goal on the final look, nor a strong story to support using theses maps.

Yet, doing a single maps took me at best 3 hours and I was completely exhausted after doing a single map. (and these 3 hours have been only once I was very used to the process, the first one took me over a day). But there way worst : doing the enemy maps (aka where the enemies will show up and to do what) is even harder and time consuming. That’s because there is way more parameter to take into account :

– the planned difficulty
– mixing enemies behaviors to fight boredom on the player
– etc…

Sure first level is simple, the next become more complex. And the further you’re into your game the more complex it get. Does the player got this upgrade or not ? Is this level beatable in “normal” condition ? Ho why do I tell “normal” condition ? Simple : when designing the level 6 you don’t want to go throw level 1-5 before being able to test. So you start the game at level 6 and tries to give you a good bonus set. But once you’ve finished the level design you need to start a game from level to test your previous assumptions.


When I finished level 8 and tested the game up to level 8 I never have been able to reach level 8 : the 6 one was definitely too hard and the difficulty gap was too wide. So I needed to redesign it to be less hard.

And while you’re polishing the levels, you also discover that many other things need more polishing.

The game had no visual depth, adding a little shadow to the player/enemies definitely added to the visual (yet I’m sure you did not even you realized that there where a shadows for these before I told you).

The impression of speed wasn’t there. On suggestions, I tried many solutions to give that impression of speed, barely gave up on that after a series of failures then though about adding clouds. These clouds definitely add to the impression of speed.

Yet adding these clouds also added to the difficulty level: at first I added them in a too light color. Yet the bullets are noticeable because they are light. So with clouds, dodging the bullets was a pain. I needed to alter the clouds color so this effect is mitigated. But one shouldn’t darken these clouds too much as it would ruin the visual. Finding the right balance have hard here : I had to balance the impact on the visual with the impact on the game difficulty.


There are so many details one can falls in and takes ages to finish. I’ll keep the too long list of other details that occupied my mind for me, but you got the idea : every single detail count. Even a semitransparent layer of enhancing visuals can impact dramatically the game feeling. At this point, building a game is not a science based on fact but art based on feelings.

All in all, having a game engine up and running isn’t that hard. Having your game mechanics up is also very simple and doable. The hard part of writing a game is a part you don’t even think it exist when you start doing it. So staying motivated working on your code base can be a problem. Once you’ve realized that there is way more behind a game than just code. It start becoming a problem. Now I understand why there is so many unfinished games floating around, why there is so many game engines with no game. Finishing playing a game can be hard at time but building this game is a pain in the …..


There is another point that have, more than once, pushed me to the limit of canceling this project : realizing that the probability that this game will be more played overall by all its player more than the time I spend on is rather thin. Look at it : 3 months full time is 2400 hours. Which sound like a minimum of time I spend on this. But as the game can be finished in 10mn, to be played more than the time I spend on it, the game have to be finished at least 14400 times. The Pandora community is over 4000 members wide. Let’s say that half of them downloads and play it (very unrealistic), it would mean each downloader should finish the game at least 7 times. How probable is that ? Yeah, close to 0. So using the happiness the game will bring isn’t enough to motivate you.

Even worse : by the fact that you completely ignored most of the work involved in making a game, you already know that nobody will ever know how long you spend on this. And you already know that you *will* have comment on how lame your game is (… compared to commercial grade stuff). So you know the feedback won’t be on par with all the effort you put in this.

You will need to find the motivation to finish way deep inside you if you start a game, here is a few tricks I used to make me finish this :

– Having a team of beta-testers as soon as possible. Have known games creators in this list, so you’ll have quality feedback and the required kick in the ass to keep moving once in a while.
– Set a deadline and tell everyone your target date. Make sure that all those will ashamed you if you miss it (and be sure to be able to handle that as you *will* miss that date :D)
– Make sure someone will hate you if you cancel the project. In my case it was my wife 🙂 I spent so much time on this game (thus not with her) that she would kill me if all that “lost” time was lost for nothing…

Now that this project is behind, I have gathered tons of respect for all those that finished a game before me. Every single game making man definitely deserve everyone kudos. At least for the pugnacity he demonstrated by finishing it. Now that being said, I just can’t grasp how these “do a game fast” compo can happen like “ludum dare”.

Seriously how one can finish a game in a week, let alone 48h hours…

You can comment below, or on the Hacker News Thread as well. 

Leave a Reply

15 Comments on "So I Finally Took Time to Make a Game"

newest oldest most voted
Notify of

Impressive work and ambition to get this game done. Why didn’t you pick html5 for example ?
I know that it wasn’t as optimized as it is in the current version but you would’ve had some advantages as well such as: less time coding, cross platforms and simply to port to mobile as an app with webobjects
You can save a lot of time going with html5 for example, probably you could save even more if you know how to work with some gaming framework.


Well that sounds like a bit like why bother with all this cooking stuff when you can have servants do all the work for you.


I wrote a 2D game engine some time (4+ years ago) in Java. The hardest part for me was getting assets (sound and 2D art namely). I must say thanks for showing sxfr and openGameArt; completely new to me.


Great job! My partner and I spent three years making our own 2D game engine and game as well:

We initially built it in ruby, but found it was too slow; then pascal but found out it wouldn’t work so well on Android; then finally Java. We’re going to release the engine some day — it uses XML files to configure all of the actors so maybe it will be useful to teach basic parallelism to kids or something…


Very nice blog post :). There’s just so much stuff that goes into making a game most will never notice, yet those small things make the difference between a polished game and shovelware.

I can proudly notify you that I have played my ~7 playthroughs worth, though I haven’t finished the game yet (gotten to level 7 IIRC). Will keep trying :). Wanna race? Will you finish Wars: Commando before I finish shmuppan ;)?


Congrats! I’ve been working on my own project for almost a year now, but it’s one thing to start and another to actually finish something! 🙂


sorry the offtop but what happened to the RSS on this site? I’m constantly getting parsing errors.

Steven Craft
Good read! I understand all of your pains and I think you have done an amazing job getting this game finished and on the repository! The only people that understand what it takes to make a game is the people who have actually made a game! NOT the people who almost made a game NOT the people who made an engine (which they claim allows games to be made easily) NOT the people who have recompiled existing projects for the Pandora NOT the people who follow every project in great detail but haven’t made anything for themselves So well done… Read more »


About Tiled, say thanks to Linux Game Cast crew, even if i don’t like what they say about our little devices/contributions…

SFXR is wonderfull, and it works quite well inside LMMS.

I tried to make a few games over the years, contribute to FLOSS with upstream patches and now as a maintainer, and still feel that i did just only a little puzzle part.

Maybe i should finish something and update less, 😉


A very good article, for a very good game.

I’d like the technical details, but also all the psychological turmoil description 🙂

Hmmm, interesting that you count your investiment in creation time and compare it with investment in play time. Never though of that.