Good design - Doom II Hell on Earth

Good design doesn’t age

A couple of days ago, I was watching the ending credits of Doom II: Hell on Earth. And while doing that, I couldn’t think of anything else but what a masterpiece I had played.

For those that are not familiar with the game, Doom II is a game released in 1994 by id software, creators of the first person shooter (FPS) genre. The game was a sequel of the highly acclaimed Doom, launched just a year before. The mechanics of the game are quite simple: explore the levels finding keys to open doors that would lead you to the level “exit” while killing anything that moves.

The enormous success of Doom and it’s sequel was due to the technological revolution that they meant for the medium. But now, 23 years later, the games are as good as they were at the time. Obviously the technology is not a factor anymore. There are (literally) hundreds of FPS games, all of them with more possibilities in terms of control and movement.

Why are they still so good? Then answer is on the level design. Every single level on Doom II is an experience. The levels have “something”, that makes you explore every single corner of the map. Look for every enemy to kill. And while doing so, the game innovates constantly, putting you in situations you haven’t been before. I think the last few levels (26th to 30th or so) are absolutely amazing. They’re difficult, frenetic, almost stressful, but you can’t stop playing. You NEED to see what’s after the next corner, door or portal. And that’s simply invaluable.

That’s why Doom II is still relevant almost 25 years after its launch. Good design doesn’t age, a well design product will never be completely obsolete. And this applies to more than just video games. Thanks to my friend Sergi, who is an interior designer, I know that the most famous and well designed chairs, were designed on the first half of the 20th century. And at Ford, they’re still trying to do a modern version of the Mustang that looks as good as the 70’s models.

When you create something, whatever it is, pay attention to the design. That can be the difference between a product easily forgotten and one that lasts forever.


Good fail

For a few weeks, if not months, the idea of participating on a game jam has been in my mind. My friend Jordi has been doing it for a few years now, and I have the feel that it’s been very positive for him. It has helped him develop his abilities as a designer, has boosted his creativity and has helped him to be productive and try lots of different things. For those who don’t know who Jordi is, he is the founder, game designer, writer, lead programmer (and more) at Deconstructeam. And their first commercial game was born on a game jam – Gods Will Be Watching.

So, a couple of weeks ago, I discovered that the Adventure Game Jam was starting. This jam is a two weeks competition where you have to develop an adventure game. It seemed like a good opportunity to me, so I subscribed. The competition ended last Friday and, what can I say? I failed. Big time. I’m not even close to finish the little adventure I started. I didn’t prepare at all for this competition and I had a number of social commitments I couldn’t cancel. Plus, you know, a full time job (and it’s also coding…).

But even failing at it, I have to admit it feels like a good fail. Though I didn’t accomplish what it was intended, I’ve learned a number of things about game development and about myself. I discovered that:

  1. I can be creative under pressure.
  2. My Photoshop skills are better than I thought.
  3. My web development knowledge can be handy in some situations.
  4. Developing tools can be fun.
  5. Working with limitations is a good thing. It keeps you focused and makes you scope the project better (I say this like I finished the project…).

With that in mind, I’ll keep working on this little game for a couple of weeks. I can’t promise I’ll finish on that time. Currently, I’m struggling a bit combining a full time web developer job and game development (and a life :P). But I feel like this few days of “failed” game jam are very valuable. I hope to participate in other competitions in the future and continue learning as much as I did on this.

The Curse of Pargo WIP

TCOP Devlog 2: Camera & character control

Camera and character control are two aspects of games that are closely related. Since the start of third person 3D games, when Sega Saturn and Playstation came to life around 1994, cameras have been a pain for developers. Games like Tomb Raider, Resident Evil, Metal Gear Solid or Super Mario 64 had different approaches that worked on some levels and failed on others. Since then, there has been some advancements on the subject. Resident Evil 4 introduced a new type of camera, closer to the player, that has become an standard for third person shooters (specially thanks to the success of Gears of War). 3D platformers are almost extint, but Nintendo still launches 3D Mario games regularly (thank god) and they have tried different approaches. First, they evolved the camera seen in Super Mario 64. That is, behind the character but keeping some distance and from a higher ground. The other approach they have tried is the one seen on Super Mario 3D Land and, specially, Super Mario 3D World . This camera follows the character, but not from behind the character. They keeping a big distance and height from him, and they only rotate when it makes sense on the context of the level.

My game camera

I’m explaining all this because that last approach is the same I’m following on The Curse of Pargo. I got to this through experimentation. Initially, my intention was to use an isometric view and leave full control of the camera angle to the player. This approach was seen recently in another Nintendo game, Captain Toad Treasure Tracker.

My game has some similarities with Captain Toad’s game, but as soon I implemented it I realized that this camera wouldn’t work. The main reason is that I’m making the game for PC, and rotating the camera with a keyboard sucks and the mouse was out of the picture. Using the free camera was a pain, and as soon as there was any obstacle you were force to rotate a camera that didn’t feel responsive or precise.


After failing with the free camera, I decided to go on and try a camera with fixed angles. The camera was still manual, but the player could rotate between the 4 corners of the level. This approach wasn’t bad, but I felt it was limiting me to work on small levels for it to work properly. I’m not going to do huge levels, but I wanted to do something bigger than what you can see on the video over this lines.

Although I wasn’t happy with the result, I thought the idea of the fixed camera angles could still work doing some changes. The first change was to follow and rotate around the character instead of just the level, keeping always the same distance to the player. That allowed me to work with larger levels. To avoid a “mechanic” look of the camera, I decided to give it some delay towards the movement of the character. I also used a Unity function (Transform.lookAt) that allows for an object (the camera) to look to another (the player). This gave the camera a very smooth feel. Combining this smooth movements with the fixed angles/positions worked pretty well but also created an issue with the character control.

Camera based control

As I said at the beginning, camera and player control are closely related on 3D games. In this game I’ve worked with an 8 directions control, depending on the camera. That means that pressing up will always get you away of the camera, down close, etc. That didn’t work that well with the free camera because of the keyboard, but now, with the camera constantly adjusting its position, it was an absolute mess. To avoid this issue I came up with a simple solution. I could take the angle of the camera and find out  which of the fixed positions/angles is currently active. The movement of the player it’s then conditioned by this fixed predefined angle, not the real camera angle. This approach works surprisingly well, and now I feel like the combination of camera and character control are good. The character feels responsive and coherent at all moments, while at the same time the camera system is simple, smooth and works really well.

Right now I’m experimenting with camera triggers. It’s a way of automatize the camera rotation and make it easier for the player. I’m not convinced with this approach 100%, as it’s been seen in a number of games and it always has the same problem: the player doesn’t expect the camera to move and that leads to deaths or annoying situations. I will continue experimenting with it as I create levels for the final game. I believe cameras in games should never get in the middle, so hopefully I’ll make it work.

Below you can have a quick look to the current state of camera and control:


Also in case you want to check out the code I leave the player controller and the camera controller.

The Curse of Pargo Devlog 1: defining the basics

Hi there! I’ve been pretty busy for the past few weeks. After finally killing this, I took some time off of development. Coding is what I do for a living, so sometimes is difficult for me to find the inspiration and the will to go back to coding. It’s easier to relax, watch some Netflix or play a game.

But the thing is that, the few weeks I took off I couldn’t stop thinking about what project to start next. I had a few ideas and I finally decided to work on a puzzle game. This time I wanted to do things a bit better than last time> To do so, I created a little document defining the main aspects of the game. Last time I didn’t do anything like this, so I was working without direction. That’s a really bad idea, specially when you have tendency to lose focus easily like me.

The first thing I did was to do a brief description of the game and what I pretend to achieve with it. I came up with this:

Puzzle-adventure game. It takes elements from Captain Toad, Bomberman and Minecraft. Every level is a puzzle that combines different mechanics like breaking blocks, recollecting materials and keys and fight enemies. It’s a slow-pace game focused on combining the different mechanics. The goal on every level is to reach the final treasure chest.

With this on paper I started to describe the controls of the player:

  1. Movement: 8 direction based control, camera based. That means that the directions of the character will be modified with the movement of the camera. The character moving and turning has to be fast, smooth and precise so the player can react quickly to level events. Though the game won’t have much action there will be some enemies, and elements that can kill the player.
  2. Bomb: bombs are not planted on the ground but thrown slightly forward. Could we thrown further if the player leaves the fire button pressed?
  3. Action: activate buttons or push boxes.
  4. Structure: build and place a structure based on a recipe we collected before. Each recipe needs materials.

I also defined different types of objects and interactions that would be seen through out the game:

  1. Bombs: the player can throw them to break blocks or attack enemies.
  2. Destructible blocks: player can throw a bomb next to a block and destroy them with the explosion.
  3. Bounce pads: Sonic-like platforms that impulse the player up in the air.
  4. Collectible objects:
    • Doubloons: like coins in Super Mario or rings in Sonic. Collect 100 to get a life.
    • Keys: colored keys that open specific doors, like in Doom and other games.
    • Construction blocks: every time you break a destructible block you’ll be able to collect a construction block. Use it later to construct structure that help you finish the level.
    • Recipes: recipes will let you construct different structures to solve the puzzles.
  5. Wall and floor buttons: used to activate mobile platforms or open doors.
  6. Boxes: like in a lot of adventure games, you will be able to move boxes to help you reach a part of the level otherwise unreachable or activate floor buttons.
  7. Structures: when the player has acquired a recipe and enough construction blocks, he’ll be able to create structures that help him solve the levels.

Lastly, I wrote some lines regarding tone, setting and visual style:

The game will aim for a relaxed, fun style. The game is not child oriented so there can be swearing and violence. Something along the lines of LucasArts/DoubleFine games.


Very colorful, cartoon-like. I feel something close to Sea of Thieves or Fable Legends characters could work really well. The environment will be pirate-like and probably should use Monkey Island as main inspiration.

As you see, I decided to place the game on a pirate setting. I guess I’ve seen too much Black Sails and too many videos of Sea of Thieves 😛 Anyway, is something I quite like and I thing it’ll fit well with the little story (more like an outline) that I have in mind.

Technology-wise I’m gonna keep working on with Unity. My previous project had a lot of fighting with the engine, but now I feel I know how to solve deal with a lot of things. This time I want to focus more on the design and create a polished gameplay experience, and if I have to start from scratch with another game engine that won’t happen.

Also I’m making the move to Maya LT. This version of the software is aimed to indie devs and, as far as I know, has all the features I might need. On the audio front I’m undecided about what to do. It’s an unexplored area for me, but this time I would like to do something better, make some music, sounds effects, etc. We’ll see how that goes.

On the following weeks I’ll keep talking about the process I’m following with this game. I hope you enjoy this kind of content, let me know what you think!

Note: the main picture is by Glenn Carstens-Peters, see his work here.

Unity prototype

Developing my first game prototype in Unity

Last year I started working with Unity, one of the most popular game engines in the world. I’ve spend months developing a little prototype that I’ve finished this past weekend. Don’t expect anything flashy. This is just the fruit of my own learning process.

Talking about learning, I’ve learnt a lot this few months. Not only about Unity or game development, but about myself. I know now that creating a scope, some constraints can help you stay focused in what is important. And that plays big when you’re like me.


Anyway, I’m gonna talk a bit about Unity. This engine has become very popular for a few reasons:

  1. Compatibility with Windows and MAC OS
  2. You can target over 20 platforms (PC, consoles, mobile…)
  3. Powerful and, at the same time, easy to use
  4. Huge community of devs
  5. You can use it for free (with some restrictions)

The most important of the previous points is the third one. It is true that Unity is powerful. There are a bunch of complex, good looking games developed with it. But I’ve come to know that if you want to get really good results you’re  going to have to invest a serious amount of time on engineering (or paying for assets in the store).

For example, the physics engine that comes with Unity is a pain in the ass. The collision system does some weird shit and it makes it a bit unpredictable. Of course, everything can be worked out, but sometimes you spend a lot of time on things you thought would be working by themselves.

Same happened to me with lighting and shades. I have a background in modeling and animation, so I’m used to the options provided by softwares like Maya and 3Ds Max. The surprise comes when you find out that the basic shaders that come with Unity are not great. You can do your own but good luck with that. Is not something on reach for everyone.

On the bright side, I have to say that I really like the environment and work flow of Unity. It feels really intuitive and I’m sure that the Unity team has spent a lot of resources on making a good user experience.

I plan to continue working with Unity in the future, though I also plan  to checkout other options, more specifically Game Maker Studio.

The prototype

Ok, so the prototype is a shoot ’em up or shmups. A classic spaceship like game. I’ve created a full level with different enemies, attack routines, etc.

It also features a mid level boss and a final boss at the end of the level. I tried to make more complex routines for these enemies, and I feel they are quite fun.
As you kill the enemies you earn points and as your score increases you’ll get some power ups that will make your life easier.

If you want to have a look to the prototype you can download from my Google Drive for Windows and Mac OS. I haven’t had the chance of trying the Mac version, so if someone tries it let me know how it works 🙂