Saturday, January 30, 2010

Holy Hole

No. This is not the build up to a perverted pun. That said, let’s get on with the game!

Holy Hole was our entry for the 2009 campus party quick-compo, a coding contest with just 3 day’s time from concept to finish. It came in 4th, not bad, but not great either.

The game play is basic, you can only let the balls that match the criteria (color, shape, …) into the hole. Clicking at them sends them flying. The more balls of the correct criteria that get in, the more points you get. There are also different power-ups available.

Menu Pause

Let’s get technical then. The game is completely coded in C# and XNA (which we learnt the day before the competition started, just for that purpose) and a bit of XML for the high score. There was no up-front design here (no time!), I did it with 2 people which I trust and have worked a lot with so communication was just sort of telepathy.


So, some specifics, here is the class diagram generated by visual studio.


Main Systems:

  • Ball Manager and Balls
  • Scene Manager and Scenes
  • Combo Manager and Combos

Then the XML team:

  • High Score
  • Load/Save Data

And finally some nice graphics:

  • Spotlight
  • Particle Emitter and Simple Particle

So that’s another game done. The team this time was Maria (Chuel) Cabezuelo, Victor (CyanCrey) Villanueva and me, Jaime (Ying) Barrachina. Music credit goes to Pablo (Undi) De la Ossa.

You can find the SVN here and a direct download here.

Tuesday, January 19, 2010


Caged is a RPG game written by me and my team* in our first year (2007) at the university. The game development was difficult as hell, and fun as hell as well. I learnt to design the architecture and lead a team, while teaching the team to code. One of the most rewarding experiences in my life.

CagedMenu CagedGame

The game is written C++, using SDL and TinyXML as only support libraries. We worked on the Dev-C++ IDE and SVN. It has 20+ game levels.


  • A scripting engine which feeds cut-scenes and dialogues from XML
  • A sound engine based of SDL_mixer
  • AI for the bots, with path finding, decision making and message system.
  • Core, with entity manager, event system, clocks and timers, log system, resource manager, FSM…
  • Physics with collision detection and some neat force driven steering behaviors.
  • Graphics. SDL isn't meant to be used as a Gfx engine, so the camera,  the GUI, and so on was also fun to make.
  • Integrated game editor, to make all the xml maps for the game.
  • Life-saver debug mode xD

CagedEditro CagedDebug

In the end, one year and 200k lines of code later, the game was completed. It won 2nd place in two different contests, “tu tambien puedes” and “CDV 2008”.

Just wanted to share my first game with the world :) Game SVN here and direct download here.


  • Jaime (Ying) Barrachina
  • Victor (CyanCrey) Villanueva
  • Maria (Chuel) Cabezuelo
  • Catalin (K_ta) Costin
  • David (Coper) Garcia

(You know who you are ;) )

  • Jusep
  • Alberto
  • Kiwi
  • Yuna (Script writer)
Special thanks
  • Javier (NeoM) Belenguer (Our life saver, really)
  • Wynter (Zerotri) Woods

Monday, January 18, 2010


What's this game about?

You control a evil mastermind that's bent on taking over the world! Or at least his city.

To accomplish that, he will find and recruit as many minions as he can, and send them or lead them on missions, for the good of mankind. And of course, himself.

Where is it set?

This game is set in a small city in our age and time. You will move all over it, it's almost completely visitable, and under it, as your base is in the sewers.

What do you control?

You control small, big headed minions, each with his unique personality and stats.

How many do you control?

At any given moment, you can control up to 8 minions, tough you will usually be controlling your avatar, the evil mastermind.

What's the main objective?

Conquer the world!

This is one of the games I’m currently developing. I’m not going to say anymore about the general game design, as it’s an idea I hope to use for personal stuff, and because this blog is about the technical side.

So, let’s get technical then. The game is written in C# and XNA. It might or might not be the definite language for the game, as right now I’m using the whole thing as a prototype. The game is for windows, I’ll worry about porting and the like when I’ve actually got something.

Hum, the architecture then.


Ignore the green boxes. Right now I’ve got, starting from Game, the branches that end at: EntityManager, MapGrid and Modes done, including the Entities (as far as collision and animations are concerned), and all that hangs from MapGrid.

A quick overview of the stuff so far, and I’ll update as I code along.


A state machine that changes Scenes. It has only one scene active at any given time, and Scenes are discarded, not saved, when a new one is selected.


States the game can be in. Structural purpose.


The main scene of the game, it provides content, NOT logic. This might be a bit hard to understand, but basically, once playing, we need a second state machine to keep track of how we play. More often than not, from one play mode we don’t change the content  but instead the changes are more subtle, and while we don’t want to just cram all the possible options for every situation in the PlayScene, it doesn’t make sense to swap to a new Scene and reload all assets, logic or whatever.

For example, in the game I could have the fighting, normal and dialog modes. In all of them the same graphics are still loaded, the player still is on screen, etc… The changes here are more along the lines of player control, dialogs shown, Bot decision paths…

That’s why I introduce…


Mode is the thread of your process, so to speak. PlayScene is always in a Mode, and modes can be swapped in and out easily. Modes dictate the logic the resources of the PlayScene must follow. They hold all the logic of PlayScene, and are used as different “logic paths” for the game components to follow.

And logically, Modes don’t have any “content” themselves, apart of the needed to run their own logic. You could say they are the cartridges in your gameboy, and call the shots in all the components of PlayScene.


It’s a collection of zones, as well as an actual map where to choose a location. Only basic functionality to support one scene is implemented right now.


It’s a place with a map, scenario items and entities, so the class has the necessary tools to handle them.


Holds the tiles, the scenario items and a tile-collision map generated from the load files of terrain and scenarios.

And… that’s all for now. Entity deserves his own post, and the rest isn’t really developed yet. I’m still deciding what to code next… maybe some input, or perhaps some basic path finding and random movement.