Week 9: Shadows

Do you notice the difference between this:

EUTS 2016-02-14 20-19-48-29and this:

EUTS 2016-02-14 20-19-59-55That’s right, shadows! (I kinda spoiled it with the title). I implemented a first version of shadow mapping for the game. It’s still in a very early state, but it’s surely working.

Jagged edges are very noticeable, and still have to implement some optimizations like cascaded shadow maps, but this will definitely come in next weeks as I want to spend some time working on improving the shadow mapping implementation.

And that’s it for now, see you next week!

Week 8: Gamepad, hanging and camera work


  • Added gamepad support.
  • Player can now hang to the edges.
  • Added collision debug info.
  • Camera work.

Hello again!

I managed to scrap a few hours after work and in the train. I must say working in the train it’s really pleasant, and it goes to show how little do gamedevs need to work on their projects (just a laptop?).

Anyway, back to action with some more work on Babel! Because this week’s time to work on the project was so spare I had to focus on small tasks.
First of all, I implemented gamepad support using XInput. As any good platformer, Babel is meant to be played with a controller and because I was focusing on gameplay lately, it was clearly the moment to support it. And damn it feels better to play with a gamepad.

And now that you bring up gameplay 🙂 the player is now able to hang onto the edges of the walls. It was a bit frustrating to almost make the jump and just fall. Also, the player is now able to ascend to higher places by climbing from edge to edge. It still has to be fleshed out, but definitely works for now.

In the debug department, the game displays the collisions of the player, which gives info about the normal, contact points, etc… of the player with other entities. This has been very useful to debug the hanging feature. To go with this, now the game can be paused to make inspecting the debug values in an specific moment easier.

Debug values show collision contact info
Debug values show collision contact info

Related to this, I’ve also added a Reset button which returns the player to the start of the game. Also, when the player falls it spawns back to the last platform it was before the jump. Because, seriously, it was getting pretty annoying to close and reopen the game every time I fall, which is pretty often 🙂

Finally I’ve also put some work on the camera! I’m pretty happy with the results honestly, because it highlights the fact the game is shown in a 3D space, even if the gameplay is just 2D. It adds depth to the game.

And this is it for now, hope to see you next week!

Week 6: A bit of movement, a bit of art style

Hello again!

Following last week’s work, I’ve worked a bit more on player movement. I’ve added lateral movement parametrization, as you can see here:

EUTS 2016-01-24 19-54-18-29

Note the cubes the player is standing on. These are now the official Test Platform Cubes™. What this means is that I have some plans for player movement and gameplay in mind, and I needed a way to easily prototype, so they’ll stick for a while. Really looking forward to pour some time on this so I can show you guys what I’m planning.

Also, if you have been following the updates, you’ll notice that the game looks very different. I haven’t decided the game setting yet, but being from Valencia (and living in Barcelona) I kind of want the game to have a mediterranean style. I’ve taken some paintings as reference for the color palette, with lots of blue and bright colors. How will this mesh with the Babel/go-up-a-tower concept? Well, I have some ideas, we’ll see… 🙂

You can also notice the distorted edges giving a painting effect:

EUTS 2016-01-24 20-14-19-04
I can already hear Joan Manuel Serrat

This is achieved with a simple postprocess effect that distorts the image based on the pixels’ depth and a perlin noise texture. As you can see, the objects far away have significant distortion, while the ones in the camera focus have little to no distortion.

And that’s all for now! It’s probable that the next week I’ll post close to nothing, because I will be on vacation in Euskadi with the delightful Clara, I’m really looking for it!

Thanks for reading!

Week 5: Collision management, Player controller

Hi again!

This week I focused on gameplay, specifically player movement.

But before that, I had to implement a basic collision management system, so the player can detect, for example, if it’s touching the ground. Nothing fancy here, I just collect the collisions that happened on the last physics frame and pass them to the player. This way, the player can check them when updating, and act accordingly.

Babel’s player movement is going to be a long, arduous task to get right, as I want it to be the core mechanic of the game. That’s why I’m priorizing it before adding graphical features.

Iterating is key when it comes to gameplay, so I added a debug panel to control the movement parameters and debug the player state, which lets me tweak the values and get the feeling right. This week I worked on the jumping, so I added a bunch of variables that can be tracked in the debug panel that shows if the player is on the ground, if it’s jumping, etc.

EUTS 2016-01-17 19-56-47-89
“JumpState: Ready” sounds so badass.

This already has paid it’s dividends, as it helped me fix some bugs easily 🙂

Also, as you can see, there are some parameters ready to be tweaked. Those control how high the player can jump, how much time has to pass between jumps, and others.

Lateral movement can also be tweaked:


Right now lateral movement it’s in a rough state, as it doesn’t have acceleration and still doesn’t feel right. More on that next week!



Week 4: Code refactor, usage code first, back to work


This was a pretty busy week for me, as my vacations are over and I’m back to work. Sadly, this will probably mean that  the updates will be less meat-y from now on. Still, I’ll give my 100% 🙂

This week’s work is pretty much code refactoring, here’s an example. As some of you know, Babel is mostly written in C. Until now, some of the functions that operated on single-instance state objects such as RenderState or KeyboardState were something like this:
void EUTS_RenderState_bindShader(EUTS_RenderState *renderState, EUTS_Shader *shader)

However, I know there will be only one RenderState in the game, so I created a global RenderState object and stripped the first argument from such functions:

EUTS_RenderState _renderState;
void EUTS_RenderState_bindShader(EUTS_Shader *shader)

This, I think, makes more sense, and API is now cleaner.

Loosely related: something I noticed is that, in previous projects, I used to write code making assumptions on what problems it could solve. The thing is, in most cases you don’t really know which exact problems you’ll have until you face them. By making such assumptions, I was creating problems I didn’t have, thus making the code more complex and gaining nothing.

Following Casey Muratori‘s advice, now I try to write usage code first. If the code can be improved, I will definitely notice it after using it, and then I’ll be able to make improvements based on actual experience, and not on some problems I think I’ll need to solve.

Until next week!

Week 3: Frustum culling, physics and happy new year


  • Mesh components.
  • Frustum culling.
  • Physics components.

Happy new year!

Sadly, this week I have no eye candy to show and it’s gonna be a brief post. I spent quite a lot of time organizing the render data and code in components.

However, I’d say the most important thing this week is Frustum Culling, which consists of only rendering the objects inside the view frustum. Here’s how I did it:

  1. When loading the meshes, extract their bounding box.
  2. When the rendering starts, construct the view frustum from the View and Projection matrices. This results in 6 planes: front, back, bottom, top, left and right.
  3. For each object, check if its bounding box is inside the 6 planes. If not, discard the object. Render it otherwise.

This is a very basic but important optimization, because the levels will consist of many objects but only a small portion will be visible at a given moment. For the fun, I’ve made a very un-scientific test, where I put an array of 900 columns in the scene, and the camera scrolls through them. Without culling, the game runs at ~35FPS. With the culling activated the game runs at 60FPS. Note that both were in Debug configuration. I still don’t have a Release one working, so I force myself to keep the game at 60 FPS for now, and can detect a framerate drop. I’m aware that when the game becomes more complex this won’t be feasible, but I think it’s a good exercise for now 🙂

In an unrelated note, I’ve also embedded Box2D in the project and started setting up the physics components, along a debug render component to show the physics bodies associated to the objects.

Debug Box2D shapes rendered
Rendering physical shapes is pretty useful to debug gameplay.

Next week I’ll try to further improve the entities pipeline and start doing some Box2D physics tests.

See you in a week!

Week 2: First in-game screens


  • Started coding.
  • Basic rendering and pipeline working.
  • Added fog and depth of field.

It’s been a weird week because I’m on Christmas vacations and I’m back in my hometown for a few weeks. Despite that, I’m satisfied with the amount of work I’ve been able to put on the project.

This week’s been all about code! I set up the project and started working on the rendering side of things. I’ve been building the code upon a small DirectX11 codebase I was working on prior to Babel. By now, the code supports mesh, texture and shader loading. For the meshes I have a very rudimentary pipeline that looks like this:

  1. Create the model in Blender.
  2. Export to collada (.dae) to the Content/Meshes directory.
  3. Run a .bat script that iterates over all the meshes in such directory and converts the collada files to a .mesh file in a custom format. This is done by using a simple custom converter, which interally uses Assimp to read the mesh.
  4. The final .mesh files are stored in Resources/Meshes directory, ready to be read by the game.

This pipeline can be vastly optimized, but it’s perfectly fine for now.

Also, I’ve been working on some rendering effects, like fog and depth of field. These are very primitive right now, but I’m happy with the results. I’ve built a small scene which I hope will end up being a playable prototipe level. Here are some screens and gifs (all in-game, unlike the concept from last week):

Some camera movement:

Some lighting tweaking:

A higher-res screenshot:

Definitely not representative of final quality :)
This thing needs anti-aliasing ASAP.

So that’s all for now, see you next week!

Week 1: Lots of thinking, a bit of working


  • Game about climbing a huge tower where the player feels dwarfed by the surroundings.
  • Few enemies, lonely setting.
  • No shooting, focus on fast movement.

First week of work!

During the past week I’ve been rapidly iterating between some ideas and concepts, trying to come up with a game setting I’m comfortably working on with my limited set of skills. Also, I’ve been doing some research and decided on some key points regarding the feel I want the game to have, gameplay wise.

The only thing I was sure of coming into this week was that Babel will revolve around the idea of going up a massive tower, where the player will feel tiny compared to the giant structures. Now, those who know me know that I’m all about lights, lasers, bullets and explosions, so the idea of a vertical shooter (kind of an inverted Downwell) was the first to come up to my mind. However, after some hard-thinking I’ve decided to ditch out the shooting in this game, and I’ll explain why.

Lately I’ve been thinking a lot about two concepts. One of them is the treatment of enemies in videogames. Most games treat enemies in an impersonal way, usually appearing in large numbers, and soon they are seen as just moving targets that need to be killed to move on. Including a shooting mecanic would probably mean following this path and I don’t really feel like going that way. Now, there are good games that shy away from this, like Shadow of the Colossus or Titan Souls (with varying grade of success), and I kind of dig the idea of having few meaningful  enemies.

The other thing I’ve been thinking about is movement and level traversal. In a game about climbing a tower, the way the player moves around is a, uh… pretty important aspect of it. My idea is to make the player feel very swift and agile, using the environment to traverse the level quickly, and I want this to be the key gameplay of the game. Mirror’s Edge comes to my mind in this regard, the level traversal was fantastic. I can’t say much more about this, because achieving the right game feel is all about prototype testing and iteration and it’s no easy task , so let’s see how the next months pan out.

Finally, I’ve toyed with some concept renders to try and figure the art style for the game:

One of the concept renders
Player using acceleration and jetpack thrust to cover a large gap.

I dig the idea of desaturated environments and saturated foreground/main objects. Nothing set on stone though…

We’ll that’s all for this week, next week is Christmas and I’m on vacation, but I’ll make sure to come up with something!

Week 0: Starting Babel and declaration of intent

Lately I’ve become  a bit obsessed over how to manage to work on side gamedev projects after 8 hours working/programming at the office. And everytime I think about it the same idea comes to mind: If I manage to periodically tell people about what I’ve worked on, it will keep my motivation up to keep working, so I have something to show the next time, and so on.

And that’s what I’m trying to do here. I will use this blog and my twitter to keep a constant stream of reports for a fictional audience.

After some the less-creative projects I’ve been working on (Chip-8 emulator, tinkering with DX11…) and lots of hours of gamedev-related-but-purely-technical tasks at work, I really feel like making a game. This implies lots of technical work, of course, but also comes with designing, prototyping, iterating, etc, which I really fancy right now.

Because ideas alone aren’t worth shit, I can openly talk about what I intend to do (who knows where this will end up). The idea is simple: a 2D vertical platformer where the player ascends through a tower (hence the name, Babel) shooting and jet-packing around. Graphics will be 3D (models, not sprites) and I intend to do this from almost scratch in C with maybe a little bit of C++, and DirectX11.

I’ll admit I seriously considered to use Unity or, specially, Unreal to get rid of some heavy parts. But I know almost nothing of both engines and I enjoy infinitely more spending lots of time to roll out my own solutions than learning how to use one. And it’s more rewarding. And more didactic. So yeah.

So, bottomline: I’m making a game and I will post about it here once a week without fail, even if I don’t have much to show. Just a little work matters. I spent a week tweaking a single asset? Good, it’s more than nothing. Hell, I’ll post here even if I did nothing so I can be publicly shamed. Also, I will post media whenever possible: screenshots, videos, gifs, audios, concepts, whatever.

Wish me luck!


Week 0: Starting Babel and declaration of intent

Week 1: Lots of thinking, a bit of working

Week 2: First in-game screens

Week 3: Frustum culling, physics and happy new year

Week 4: Code refactor, usage code first, back to work

Week 5: Collision management, Player controller

Week 6: A bit of movement, a bit of art style

Week 7: Absolutely nothing!

Week 8: Gamepad, hanging and camera work