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.

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: 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

Or:

  • 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.

jMonkeyEngine

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.

Thoughts on Maps for Shyft

Posted October 1st, 2010 in Game Design by Charles Micou
As Callum pointed out earlier, the map we’re working with for testing is not one you’d want to use when actually playing a game. First of all, it needs to be fair. This usually implies symmetry or randomness (which I will get on to further down), or both. More importantly, however, a good map needs to be interesting.
Consider the map below:
This map looks quite nice: the trees are by the water and the mountain, and everything is spread out in an even way. What really matters about this map, though, is that there are multiple strategies a player is likely to consider:
So, we have Player 1 starting in the bottom left, and Player 2 starting in the top right. Because roads provide such a large bonus to movement, mobilising troops towards the centre of the map (A) is very easy and the fastest path to the enemy. However, the choke points caused by the bridges (B) mean that you can hold off your opponent. The alternative is to go round the sides, passing through (C). Note that because of the very defensive terrain near (D), it would be wiser for Player 1 to attack along the bottom of the map whereas Player 2 would be better off going along the top. This slight imbalance means that you either have to scout or preempt your opponent.
This constitutes what I would call a fairly good map. If you had the added complexity of resources (which we might get around to adding at some point) and construction of units, many resources placed in the centre and perhaps a few along the flanks would make this map more fun.
Our criteria for maps, such that they could be generated via some seed numbers (and perhaps a selection of other factors) would have to be as follows:
-The two teams can reach each other

-Tiles are assembled correctly (i.e. rivers the right way around)
-The map is symmetrical (simply because this makes balancing so much easier)
But what about if we want good maps:
-There is more than one route to the enemy
-There is imbalance in these routes, such that decisions have to be made by each player as to which route to take
-Aesthetic appeal and ‘common sense’ in placement of tiles (this is a hard, yet interesting bit)
-There is ample space to manoeuvre troops, but also choke points
I am all for a random map generation option: it gives the game a longer lifespan, can be more fun under certain circumstances and provides variety. However, if 10 or 20 maps similar to the above (which was not by any means a challenge to make) could be played to provide this variety, the quality of the random maps would need to be quite good to compete. It looks like if we want to give the game more longevity via maps, letting the user use Tiled to make their own is the best option at this point.

What is an algorithm?

Posted October 1st, 2010 in Game Design by Callum Lawson

A algorithm is defined by both the algorithmic problem and its solution. An algorithmic problem is the characterisation of all the legal inputs for the algorithm and the desired outputs for those inputs. This is a rather trivial example of an algorithmic problem:

  • Given a set of numbers (i.e 5,9,7,2,1,5) return how many numbers are divisible by 3.
For the above set of numbers the answer is 1. One could easily write a function that would give this output:

for input(a,b,c,d….) output(1) 


This would provide the correct output for the example set of data but not all possible sets of data – it is not an algorithmic solution. An algorithmic solution is one which will provide the correct output for any legal input. The pseudo-code below would be an example of an algorithmic solution for this problem.

(1) create variable a
(2) for – number of numbers in the set
           if – current number is divisible by 3
           add one to variable a
(3) return a


This code would produce the correct output for this algorithmic problem regardless of what the input is as long as it is a legal input (a set of numbers). It does not matter if the set is 5 numbers or a million – the correct result will be returned.

After claiming that my line of sight code in the previous post was an algorithm I realised that I do not know the definition of one. So I did some research and wrote the above. In hindsight I think I was correct in calling my code an algorithm.

Shyft GUI

Posted October 1st, 2010 in Game Design by Charles Micou
I’m Charlie, and since Callum’s ability with programming far surpasses my own, I have stayed pretty much completely out of the code so far. However, as the slightly less graphically challenged member of the pair of us, I have so far done most of my work on potential content, graphics, GUIs and gameplay mechanics.
The way the GUI has come along so far is very interesting, as it has sort of evolved with the way the game is going so as to keep the code simplistic while making the GUI as intuitive and easy to use as possible.

The earliest GUI design was simply a way of displaying the information that we knew we’d need:

This was then refined to a slightly less conventional layout, with commands for units on the sides (map background image was taken from Advanced Wars as a placeholder):
Comfortable with the shape of something similar to the above, we expanded it to accommodate some of the features we decided to add:
After some refining of the above, we have finally settled on the bar you see on the right dynamically adapting to which tile the user’s cursor is over, or which tile has been selected. This will mean that we can display more things in more space as and when they are needed.

Map Randomisation

Posted September 30th, 2010 in Game Design by Callum Lawson
I was recently thinking about how I could generate a playable random map for my tile based strategy game. I can foresee many difficulties with this. Below is a sample map created in the map editor:
This map although not very well balanced looks sensible. The roads are connected and features such as trees and mountains are grouped in semi-realistic clumps. The river is also continuous and flows from one side of the map to another. If this sort of result is to be achieved my a random map generator it will need to follow these rules:
  • If the tile is blank there must be a chance that a feature is placed on it. This should be larger if adjacent tiles contain this feature.
  • Roads and rivers must form a closed loop. (counting the map edge as closed).
  • If there is a road or river section in an adjacent tile and it is “facing” into the tile it must be continued.

  • (Optional) The map be balanced in terms of resource and position or be symmetrical.

Ideally the chance of each feature (i.e. hills,woods,mountains) being placed in tile should be determined by an initial value and the tiles surrounding it. If this was a case the user could define the initial chances by selecting an option such as hilly or woodland before generating the map while the affect of nearby tiles could help produce the desired “clumping” of features.

I intend to try and write some pseudocode which achieves these effects soon.

Line of sight algorithm

Posted September 29th, 2010 in Game Design by Callum Lawson

I have been trying to find a algorithm which when given a integer which will determine “sight range” will produce a two dimensional array containing all the x,y values of tiles which fulfill x+y<=sight range in both positive and negative directions.

This is the method I used to accomplish this:

for (int y=0;y&lt;mapHeight;y++)
{
for (int x=0;x&lt;mapWidth;x++)
{
if(currentMap.getUnit(x, y)!=null)
{
int sightRange = currentMap.getUnit(x, y).getMovementRange()/2;
for(int sightStepY = -sightRange;sightStepY&lt;sightRange;sightStepY++)
{
for(int sightStepX = -sightRange;sightStepX&lt;sightRange;sightStepX++)
{
if(x+sightStepX>=0&&x+sightStepX&lt;mapWidth&&y+sightStepY>=0&&y+sightStepY&lt;mapHeight)
{

if(sightStepY>=0&&sightStepX>=0)
{
if(sightStepY+sightStepX&lt;=sightRange)
{
currentMap.fogArray[x+sightStepX][y+sightStepY]=0;
}
}

if(y+sightRange&lt;mapHeight){
currentMap.fogArray[x][y+sightRange]=0;}
if(x+sightRange&lt;mapHeight){
currentMap.fogArray[x+sightRange][y]=0;}


if(sightStepY&lt;=0&&sightStepX>=0)
{
if(sightStepX-sightStepY&lt;=sightRange)
{
currentMap.fogArray[x+sightStepX][y+sightStepY]=0;
}
}

if(sightStepY&lt;=0&&sightStepX&lt;=0)
{
if(-sightStepX-sightStepY&lt;=sightRange)
{
currentMap.fogArray[x+sightStepX][y+sightStepY]=0;
}
}

if(sightStepY>=0&&sightStepX&lt;=0)
{
if(sightStepY-sightStepX&lt;=sightRange)
{
currentMap.fogArray[x+sightStepX][y+sightStepY]=0;
}
}

}}}
}}}

Fog array is the two dimensional array which states if the tile should fog(1) or not (0).
Here is an example of the result when rendered in the game:

I think the above is rather messy and was achieved with a good deal of trial and error. I’m sure there is a more elegant way of achieving this. Any suggestions would be appreciated.