An overview of my time as a game developer

If I remember correctly, around two years ago I first used SDL. At that time, I rendered everything though simple rendering and devised a really simple framework. That framework went through a few revisions, through which I understood what OOP really meant (at that time, it simply meant not having to copy the basic “map” initializer for to every of it’s sub class… only later I would learn what polymorphism really meant). That framework really sucked and I never finished it. A friend would sometimes say that there had to be an easier way with flash, since there were so many games done for it.

One day I saw a nice game on Kongregate and searched what was used on it. My only hints were the game name, it’s developer blog and a small ‘f’ (like this one default, but bigger). After some time I learned about Flixel and started experimenting with it. I quickly liked it. A lot! It was like the framework I wanted to do but much better. And I could make games in flash using it! This was around September and I somehow learned about Ludum Dare soon afterward. So, on December of that year I took part of Ludum Dare #22 and finished my first game ever (there were a few prototypes before, but let’s ignore those…).

Since then, I took part of every Ludum Dare there was and although I’ve had a few failures I still haven’t missed a dead line for any of those. During this time I’ve been improving mainly on making graphics, polishing and coding. I still have to get better at making a fun and well designed game and at writing music. I’ve also made a game for the 2012 GMB, and submitted two games for this years SBGames (those weren’t even selected, but oh well…). But the most important thing that happened to me this year was the One Game a Month.

I took part of it from January to April, and the games I made for it really helped me understanding how to polish a game and how hellish developing a game can be. Since I didn’t have a real work schedule, I would work on my games every free time I had. I thought it was a bad idea but I couldn’t help it since I really like making games. Well, on April I already started to struggle a lot to finish something, and was only able to do it thanks to that month’s LD. From may onward I wasn’t able to do anything at all. Only after July’s vacation I went back to making something (I started a stupid HTML5 engine and then there was the SBGames).

Sometime after the last Ludum Dare I started writing a game framework in C++. Different from two years ago, this time I’m using OpenGL for rendering, but I’m still using SDL for everything else.The idea is somewhat similar to Flixel, since that is the framework I’ve most used and it’s really like how I think a game should work. I’m planning to soon release a port of my first game, Loneliness, using this framework. It’s mostly done, but I still want to work on it a little more… Two things that I still want to do is to make a shared library of my framework and to be sure it can run on Linux. I tried to run it on my desktop (that runs Ubuntu), but it’s graphic card only supports OpenGL 2.X, and I need OpenGL 3.1 (and GLSL 3.30).

Well, this post has become long enough. I don’t think I can add anything else to it without having to write a lot more. Sometime later I shall post about one of my previous projects or the current framework. I’ll definitely publish my game’s port here (but I don’t know when)..,

Until then!


The boring side of (bad) OpenGL game development

For some time now I’ve been working on porting my “first” game (there are some prototypes that shouldn’t be considered), Loneliness, from Flash to Windows. The tools I chose were C++, SDL (a combination I had previously used) and OpenGL. The engine is almost in a functional state, which means the game is almost looking the same as it’s web version. Behind the scenes, though, there are many completely different stuff, not only for the hardware accelerated stuff.

Something that is really bothering me is the use of a single texture. I find the use of an texture atlas fun and interesting, but having to centralize a 20×24 sprite in a 32×32 square somewhat annoys me. I actually don’t know if this is necessary, but I remember reading about it fastening renderization. Another thing I may be doing unnecessarily is to keep (almost) every tile in a single texture atlas (I’ve yet to use glDrawElementsInstanced or any other function call that should make batched draw), but that’s something I wanted to do.

The real problem isn’t actually having everything in a single texture, but not being able to procedurally draw stuff. In Flixel, there are some functions to draw on a sprite. This was used in the game over screen, to display a simple window. The way I have made things so far, I can’t actually do it (in a pretty and not hack-y way) without adding the full window sprite (it should be 128×128) to the texture atlas or by implementing tilemap. I could implement it (it actually already has been implemented, but for text), but I’ve been too lazy to do any of those lately. But I’ll do it… eventually…

On a side note, my last LD entry is on hold until I finish this game (and probably another one). It’s a nice li’l game (I liked it quite a lot), but I still haven’t made enough upgrades no call it a decent post-compo version… It’ll will be done when it has to be done, and I hope that time is before December.

Too sleepy right now to proof read this (and if I did, I would probably discard it). So I blame the sleepiness and rush in which this was written for any mistakes.