Haunted House

Posted February 3rd, 2013 in Game Design, Games, Porfolio by Charles Micou

Haunted House is the working name for our first delve into XNA: a platforming game that centres around the usage of light to complete levels. We wanted to call it Torchlight, but it seems that we were beaten to it.

The protagonist of our adventure is a little boy who has flown his remote controlled plane onto the roof of a large, abandoned mansion. In typical ghost-story fashion, he sets out in the middle of the night to retrieve his lost toy. Within the mansion, he finds ghosts that roam around. Some even try to chase him. Fortunately, his trusty flashlight causes them to freeze in their tracks as he navigates the crumbling ruins of a building and jumps his way ever higher.

There’s a lot of interesting stuff going on in Haunted House, the most obvious of which is the lighting engine. As it’s fairly key to the gameplay, a lot of effort was put in to making it look smooth and work with the graphical style. While the game is probably going to end up a bit lighter (it’s a bit hard to see where you’re going at the moment), we really like the ambiance it gives to the levels. Also new to us is the integration of smooth animations and jumping mechanics, as platformers that don’t handle well are simply no fun to play.

We’re currently at a stage in development where a lot of the basics are in place (physics, animations, lighting, controls, level loading) and we have a lot of potential to make a fun, short and more original game than some of our previous efforts. We started working on this project just before sitting our Pre-U (A-level equivalent) exams, and so it was cut short because we felt that getting into university might be somewhat important. With those out of the way came a new constraint on our development: university work takes up quite a lot of time! We’ll be coming back to it and polishing it up, possibly over the summer of 2013, possibly sooner.


Posted February 3rd, 2013 in Games, Porfolio by Callum Lawson

Players use a BASIC-like language to write “Code Warriors”, which then battle it out in virtual memory with the aim of forcing the other program to execute an illegal instruction. The document below is the specification for PiCore a programming game for the Raspberry Pi. The repository can be found on github at https://github.com/callumlawson/PiCore.

Space Pirate

Posted February 3rd, 2013 in Game Design, Games, Porfolio by Charles Micou

We entered a 30-hour coding marathon in January 2013. The theme was announced on the day as ‘Space’, and so this is what we sat down to produce:

You are a merciless, space-faring pirate; terror of the seven solar systems. You make your living by raiding innocent science vessels, but they’ve started to catch on. Now, the ships that you board are armed to the teeth with defence turrets, landmines, heatrays and poisonous gas traps.

While we never really came up with a title (the time constraint meant that pretty much every second was spent coding and designing), ‘Space Pirate’ is a top-down bullet-dodging game that is unforgiving and challenging: one shot and you’re dead. The levels are procedurally generated from little ‘blocks’ of rooms, each with their own configuration of traps. You need to find your way to the control room, hit the self-destruct button and make your way out of the ship under time while grabbing as much loot as you can get your pirate-hands on.

It was a fun game to play, and it was running quite nicely after the time limit expired. Despite this, we want to continue to add to it: we think we’ve hit on something very playable and addictive, and all the tools are now in place to create more rooms and traps efficiently. Look to see more of this in future.

This project was written in XNA and guest-starred Lawrence Esswood on the programming team.

Shyft Released

Posted July 28th, 2011 in Games by Charles Micou

Go download it now!
If you like it let us know about it in the forums.


Shyft: Progress report

Posted April 1st, 2011 in Game Design, Games by Charles Micou

Shyft has recently had a few technical setbacks (exploding hard drives count, right?) and so was swept under the carpet for a few weeks while Callum and I did other things. We’re now back with a vengeance and hope to finish up a beta/alpha release this April.

Currently, we still need to do the following:

In the code:

-Polish the GUI: It’s still a little edgy in places, but looking pretty good

-Add a ‘Reinforcements’ game mechanic: Most of the code for this was done, but was lost in the hard drive incident

-Add 4-player/3-player multiplayer support: Currently it only supports 2 players, both over LAN and hotseat mode

-Troubleshoot LAN multiplayer: It occasionally goes a little funny and so needs some fixing

-Make modding support more robust

-Enable playing of mp3 files to make music filesize shorter

-Make the dropship helicopter able to transport units

-Add  your turn, victory and defeat graphics

-Add healthbars

-(maybe an explosion animation)


Out of the code:

-Bring the map count up from 4 to about 10

-Produce tutorials on how to make new maps and mod

-Finish off the help section

-Test and balance units

-Add updated music


It’s more than likely that we’ll come up with other things before it’s released, as well as a few other tweaks. It is equally possible that I have forgotten something.


Here’s a 4 player map I worked on a while ago, in the second image you can see the grid and reinforcement zones. (Click to enlarge)

A Method for Isometric Hexagonal Grids

Posted January 7th, 2011 in Game Design by Charles Micou
From what I’ve read, hex grids are pretty fun stuff. Isometric view is also pretty fun stuff, so I’ve put two and two together and decided to find out how to do this:
Hex Grids
The grids can come in two forms. I’ve seen them called Vertical/Horizontal, Staggered/Straight and other names. The difference between these two is which way you line up the parallel sides with the compass points. It either has to line up in the y-axis or the x-axis:
It is up to personal preference which one to use. I preferred the case where the vertical sides are lined up, because not being able to go straight into the screen always felt wrong to me. I will be using that orientation in my examples.

Hex Grid Coordinate System
There are several ways to do this. http://sc.tri-bit.com/Hex_Grids#Coordinate_Systems explained in quite a bit of depth all of the methods I do not plan on using. At the bottom is mentioned “Trapezoidal” with a brief explanation. This is what I understood by trapezoidal:
However, on that same site an example was given a few pages in, and I understood the difference between convention and what I was doing: the angle between the axes one conventionally uses is half that of mine. The reason I am going against convention is because of the way my axes allow for an easy correct draw order in isometric (therefore, I think the reason convention is not done this way is because hex is not usually used isometrically).
Movement in (my version of) the Hexagonal Grid
This grid means that we can move as follows:
So, from 1,2; we can move to:
  • 1,1
  • 1,3
  • 0,2
  • 2,2
  • 2,3
  • 0,1


  • x, y-1
  • x, y+1
  • x-1, y
  • x+1, y
  • x+1, y+1
  • x-1, y-1
So this really is not very different from your standard square-tiled system.
Isometric Coordinates
To add in isometric view, we simply need a height, or ‘z’, coordinate. This simply determines how far above of the x and y coordinates to draw the tile. From a graphical point of view, we need to flatten our hexagons slightly and give them another face to make them into hexagonal prisms.
Draw Order for Hex Isometric
This is where my slightly unorthodox method of assigning coordinates becomes useful: drawing the graphics in the correct order. First, we draw the layer z=0. The order in which tiles are drawn are determined by the sum of their x and y coordinates.
Then we repeat for the next layer: z=1.
I may or may not write some (pseudo)code for this. It was simply done out of curiosity, since I had no intention of actually including this method in a game. However, now that I have realised how relatively simple it is to do, the only real constraint is not being able to make very convincing isometric graphics.


Posted December 14th, 2010 in Games, Porfolio by Charles Micou

Shyft was in the works across 2010-2011, and we finally decided that we were happy enough with it to release it to the world and move on. Please do note that it is still far from a definitive ‘final release’ build, and that (while not completely plagued with glitches) it will still play up at times.

Download it here: Shyft. The map editor can be found here: http://www.mapeditor.org/

It started off as more of a technical exercise than a plan for a fully-fledged strategy game. We had a load of things floating around that we wanted to get working: LAN multiplayer, a map editor, pathfinding, music… the list goes on. For a long while we didn’t think much would come of it, but in the end we were pleasantly surprised. Shyft has turned out as a nice, clean and simple turn based strategy game with a lot of potential for casual user-end customisation, balancing and modding.

Notable Features:

  • LAN/Online Multiplayer (note: it is a direct connection, so the host will need to forward port 25565 if not playing over LAN)
  • Custom Map maker support
  • Easily editable tilesets
  • Hotseat mode for two players at one computer

We would recommend you start up a game for yourself (if you’re wondering which map, Snowy Peak is a personal favourite) and play a friend. Having them run straight into your carefully planned artillery trap is definitely one of the more satisfying moments you can experience. The game involves a lot more strategy than you’d think at a first glance, especially on a well made map, so you might want to have a go at that as well. We’d love to see any custom maps you come up with, so just drop by our forums. A quick tutorial on how to make maps can be found here.

In theory there is still a lot you could add to Shyft: A campaign mode, a custom campaign maker, single player AIs of varying difficulty, animations, more sound effects… But getting carried away with more and more features is what pushed this release so far back in the first place. Well, that and breaking hard drives, university applications, A-Levels and what have become fairly intense school lives. Please forget that we ever even mentioned an April release. We don’t plan on leaving Shyft here and moving on, there is still the truckload of tidying that comes with all the bugs you find in a beta release, as well as a few other things we have thought of but didn’t get around to implementing. That said, it’s also a great weight off our chests to finally have a fun, stable, working version. It was a lot of fun to make, and we hope you enjoy it.

Yay, screenshots!


Old article during development:

We will be releasing an alpha version of Shyft in the near future. When we do, you’ll be able to find it on this page.

Currently, this game is 100% multiplayer, whether over LAN or on the same computer. The aim is to direct your troops to secure a battlefield’s key locations and destroy the enemy’s forces. Players take turns moving their units and attacking, allowing each unit to move and attack once before their turn is over (or the time for their turn runs out). To win the game, players will have to use the correct units in the correct locations: securing chokes with long-ranged units like artillery, blocking the way with heavy tanks and gathering intel by scouting with air units. The landscapes are varied and have different effects: some tiles will provide you with additional cover, giving you a defense bonus when under fire, and some terrain can be harder to cross (or impossible for some units, like boats on land). The key locations are marked by large towers. Depending on the towers you control, you will get bonuses: increased damage, greater line of sight, reinforcements… Shyft has a great enough variety in its unit, building and terrain combinations to make for a game with fairly strong strategic depth.

Shyft is also very easy to customise, even if you don’t know any Java. You can make your own maps in Tiled with the game’s tile-sets. You can even make your own tile-sets, your own units, or reskin the graphics to your liking with Tiled. The interface for editing maps is very intuitive (actually quite fun, and nothing like the map editing in The Calling of the Seals, we promise). We are hoping that if Shyft becomes in any way popular, there will be a large amount of custom maps in circulation that anyone can play. And if you’re worried that you’re joining a game that you don’t have the map for, don’t worry: some genius server code takes care of that for you.

Shyft was born in the summer of 2010: after Callum had worked on the Android platform for a little while making Orb-Wars, we decided that we needed some more experience before we could produce a game that would be marketable as an app. Because it was more in the actual ‘making-of-a-game’ field we felt needed to progress more, we moved back to the standard Java platform ready to make a new game. We weren’t quite sure what type of game to make. We quite liked tile-based games and we weren’t so keen on having everything animate, so we eventually settled on an Advance Wars style tiled based strategy.

The two main things that we would be gaining from this were multiplayer support and a more efficient way to handle the production of maps. Callum single-handedly produced both a hefty chunk of server code and an attribute loader. The multiplayer works both over LAN and in hotseat form. The attribute loader reads files that can be edited entirely in Tiled, so it’s very easy for pretty much anyone to make a map for the game (provided they set up Tiled in a specific way, which has caused us a few troubles in the past).

The graphics of Shyft have changed significantly throughout the course of its development. Charlie originally made all of the graphics himself, but we soon decided that if we wanted to make this game a solid long-term project, they needed to be of a higher standard and there needed to be much more of them. Luckily, we stumbled upon an abandoned gaming relic from 1992: Hard Vacuum. This was a real time strategy game that was never released, and so the team artist (Daniel Cook) decided to release the graphics royalty free so that they wouldn’t go to waste. The tile-set linked on the site was incomplete in many places, with transition tiles missing and only half the units and buildings shadowed, but the artwork was perfect. The style was exactly what we had been hoping for. Everything wasn’t formatted just right, and it all needed putting into a tileset, but that was taken care of easily enough. We went from 41 tiles to over 700 and from 7 units to 12. Charlie also tore apart the GUI, originally made for tiny 420*300 px screens, and used it as a template for the final interface. Shyft is by far the prettiest game we’ve ever produced.

The funny thing about Shyft is that we could, given infinite time and patience, just keep adding to it. It’s already pretty much playable, but there is so much more that could be done. We could add AI, smooth motions, a campaign mode, team games, alternate game-modes, more units, maps that went around in circles, special abilities… This project is only really going to end when we say ‘Stop. It’s time for something new.’

The Calling of the Seals

Posted December 13th, 2010 in Games, Porfolio by Charles Micou

The Calling of the Seals really was our first attempt at making any game, ever. It’s several years old right now, and while it was a cute initial project, we have half a mind to disown it as something we never produced. Scroll down at your own peril, and watch out for Turtlebears.

The Calling of the Seals was our first project, an RPG in the style of early tile based console games. If you want to play it, you can download it right here: The Calling of the Seals.

The game follows the standard RPG plot: evil forces are threatening the fictional land we didn’t name, so to save the day hero must break ancient seals in temples. A play-through of the game takes about forty minutes for me, so when you’re figuring out puzzles and the like it will probably take a little longer. A lot of the time is taken up by having to go heal yourself, this was a little oversight in game design. The environments are varied, as are the enemies, and you can upgrade and swap weapons, as well as buy healing bandages (spoiler: which are an absolute must for one of the bosses). Each temple has its own puzzle: teleporter mazes, light-switch puzzles (one of the few things I’ve coded that was ever used!), falling through pits to avoid ghosts and pushing blocks on to pressure pads.

The battles follow a style similar to the Gameboy Pokémon games: you walk across an enemy’s field of vision and this initiates a turn by turn fight until one of you is dead. The bosses in the game do not have special moves, but the final boss (which is lacking a graphic and an actual place in the game) has a few lines dedicated to healing himself. There aren’t really any secrets in the game, only a few easter-eggish NPCs on the eastern side of the main city. If you’re at a loose end and want to play a slightly buggy, partially unfinished RPG then feel free to download the game here. Oh, and if it’s too boring to finish in one go: it has saving.

TCotS was where both of our programming and game designing careers started off. The code was pieced together and guessed at, disregarding dozens of conventions and making a bit of a mess in a few places. All the graphics were hand-pixeled and each map carefully sketched out on paper before feeding it through the incredibly tedious procedures we had got ourselves tangled up in with newbie-code.

This is a little harsh on TCotS: we really enjoyed making the game, and learned a lot about what not to do. The game is definitely not an all time classic, but it has its fun moments and has its charm. As Callum put it when we were deciding what made us actually like the game: “It has soul.”


Posted December 13th, 2010 in Games, Porfolio by Charles Micou

Orb-Wars is an arcade game for Android phones.

The objective of Orb-Wars is to fly your spaceship between black holes and around obstacles to safety. It plays a lot like a mini-golf game: each level has its own optimal solution, and you aim to complete the level in as few ‘shots’ as possible. You control the ship by rotating it and then giving it a burst of power.
There are a few differences, the main one being that it is all done in real time. Unlike a golf game, you can fire again midway through a shot. After all, this being set in outer space, you never actually stop. As you bounce off walls, your ship’s shields gradually weaken and will eventually fade away. If you hit anything after this, you lose a life. The black holes provide an interesting mechanic: with a little practice, you can fling yourself around corners without hitting walls; but get it wrong and you spiral to your death.

The game is very, very unfinished, and has been gathering dust for quite some time, but if you have an Android phone and you want to play through the first 3 levels, you can download the game here: Orb-Wars.


Posted October 5th, 2010 in Game Design by Charles Micou
Although we are currently limited to 2D in a big way, and our projects for a while yet will still probably be top down (perhaps iso with overlapping to mimic 3D if I somehow develop artistic ability overnight), I cannot stop drooling over this: http://www.jmonkeyengine.com/
The running at over 1000 fps at times might be a little excessive, but I doubt a cap would be to hard. This opensource Java engine is still an alpha after all, and it looks like it has a whole lot of potential.
Callum and I would need to switch from using Eclipse to netBeans, but it’s far from the end of the world, and well worth it by the looks of things. 3D is just one of those things that makes everything better.
I should probably stop daydreaming and get back to doing some work since this is such a long way off, but maybe in a year’s time we’ll have some 3D up and running.