A major part of the project involves distributing microcells (fixed areas of the world) between a series of worker nodes both statically and dynamically. In order to test methods of achieving this, I created a small testbed application which simulates the task without networking. It is capable of using various methods to distribute cells, both at the start of the application and as it runs, both controlled by a central server and initiated by worker nodes and gives graphical and numerical feedback.

The images below were taken with a greatly reduced number of cells, and the work involved in processing each cell is artificial: there are no pathfinding characters yet. However hopefully it demonstrates to some extent how division of the world takes place, and allows me to easily test distribution methods before using them in the proper simulation.

Coloured by number of characters per cell.

Initial block distribution.

Random distribution for comparison.

Block distribution with dynamic passing after time.

As the actual application I am working on is written in C#, I used XNA to create the images here. As it is possible to render XNA frames to a windows form application with little difficulty, this is also the approach I will employ for visualising the complete project.

The most useful thing I can share is the class diagram this was based on. It’s rough, it doesn’t detail methods or member data, and it’s far from beautiful, but perfection is an easy trap to fall into. I thought it was better to have a functioning library and an ugly diagram than a work of art demonstrating a library which I then would have no time to create.

The current phase of the project is far more interesting in my opinion, and thankfully should result in something slightly more visually interesting. It concerns the division of the world, hierarchically, into microcells. This spatial partitioning, and more importantly the assignment of work to specific processors is fast becoming the major focus of the project, and I hope to follow up with more on that topic shortly.

EDIT: I have replaced the original diagram with a still-ugly but slightly more descriptive update (if you actually view it at a decent size, that is). The majority of member data and functions are still missing, but hopefully the few I’ve added will make my intentions slightly clearer.

Scottish Game Jam, the branch of the event in which I participated, was hosted at Glasgow Caledonian University, organised by the fantastic Romana Khan. Nine teams took part in the Saltire Centre, an impressive (though bright) space, loading up on caffeine and sleeping on couches (if at all).

My team “Frat Boys from the Hood” consisted of Abi, Jess, Andrew and myself from Abertay joined by Alex, a third year student from Glasgow Calendonian. Working on a theme of deception and constraints mandating that we must include “a sink, a wink or a rink”, we built the 2d side-scroller “Panda Dragoon: Bees on Ice” with the aid of the Unity engine.

The game places our panda protagonist in a black and white world, fighting deceptive and equally monochrome foes. Gliding through an ice rink, the player must switch between black and white in order to see enemies of the opposite colour. However, switching also empowers these enemies—the player must be cautious—causing them to change form and cause increasing damage. Luckily, the player is equipped to defeat these creatures by firing bees from its mouth. The aim is to progress as far as possible as the game increases in speed, achieving a maximum score.

Although the event overall was non-competitive in nature, Scottish Game Jam welcomed judges from Denki and Real Time Worlds to critique the resulting applications and to decide on a winning game.

Much to our surprise We Won!

It was really reassuring to make such a self indulgent game, for ourselves and not for a nominated target audience, and yet have four out of five judges award it their highest score. Obviously the game has flaws, we made it in 48 hours, but with another week of tweaking at some point hopefully we can create something compelling and genuinely fun.

Overall, I had a fantastic time and would encourage any developer, especially artists, to take part next year. It’s amazing how much you can learn and achieve in just two days.

Download and play The Game.
Global Game Jam
Scottish Game Jam

I ended up trying two options: .Net Graphics support (which uses GDI) and everyone’s favourite image manipulation tool ImageMagick. My aim was to create bright an horrible images, to ensure they don’t remain in the project by mistake, with text on them to show what object my many cubes and spheres represent.

First up, my C# script. It created the fantastic texture you see above, and can be run from a windows command line as
> DefaultTexGen.exe Text_To_Write FilenameToCreate.bmp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

using System;
using System.Text;
using System.Drawing;
using System.Drawing.Imaging;
using System.Drawing.Text;
 
//creates a default texture with text on it
namespace DefaultTexGen
{
    class Program
    {
        static void Main(string[] args)
        {
            //check whether arguments were passed
            if (args.Length < 2)
            {
                Console.WriteLine("Please run with arguments for image text and output file name.");
                return;
            }
 
            //get name and output file from arguments
            string name = args[0];
            string file = args[1];
 
            //set width and height (square), could get these from args too
            int dimension = 256;
 
            //create the bitmap
            Bitmap genmap = new Bitmap(dimension, dimension);
 
            //apply the colour and text
            FillTexture(genmap);
            WriteText(name, genmap);
 
            //output bitmap
            genmap.Save(file);
            Console.WriteLine("Image " + file + " created.");
        }
    }
}

This relies on two further functions. The first of these colours the image with a simple gradient, but could be replaced with any colouring function.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

        //fill a bitmap with a random gradient
        //could replace with other colouring function
        static void FillTexture(Bitmap _target)
        {
 
            //set random r,g,b values between 0 and 1
            Random rand = new Random();
            float rCol = (float)rand.NextDouble();
            float gCol = (float)rand.NextDouble();
            float bCol = (float)rand.NextDouble();
 
            //fill each pixel
            for (int x = 0; x < _target.Width; x++)
            {
                for (int y = 0; y < _target.Height; y++)
                {
                    Color pixColour = Color.FromArgb((int)(255 * rCol), Math.Min(255, (int)(x * gCol)), Math.Min(255, (int)(y * bCol)));
                    _target.SetPixel(x, y, pixColour);
                }
            }
 
        }

The second actually writes the text to the image. It calculates a font size to fit the given string onto the texture.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

        //Fit and write text to a bitmap
        static void WriteText(string _text, Bitmap _target)
        {
            //calculate the font size to fit the text to the image
            //pixel width in monospaced Courier New = 0.833 point size
            const float fontReduce = 0.833f;
            const float edgePadding = 20;
            float size = ((_target.Width - edgePadding) / _text.Length) / fontReduce;
 
            //set the max font size to 25
            size = Math.Min(size, 35);
 
            //set up font and graphics
            StringFormat format = new StringFormat();
            format.Alignment = StringAlignment.Center;
            Font font = new Font("Courier New", size);
            Graphics graphics = Graphics.FromImage(_target);
 
            graphics.DrawString(_text, font, Brushes.Black, _target.Width / 2, _target.Height / 3, format);
 
        }

I’ll be honest, the second solution (with Imagemagick) is simpler, more flexible, and creates better looking textures.
As an example:
convert -size 256x256 plasma:tomato-steelblue -font Arial -pointsize 20 -draw "text 10,20 Default_Texture" TextureToCreate.jpg
Produces the following image:

Creating a batch/shell script to calculate the correct font size and run this command should be trivial, leading to some disgusting, but useful, textures.

I figured as a quick introduction I would work on a clone of Rotation, an Asteroids/Duo/Space Invaders sort of game which I created in Flash a couple of years ago.

Overall things went (slightly surprisingly) very smoothly. Initially I had to cling the script reference but once I had a better idea of the functionality available, everything started to come together. I don’t have much experience with comprehensive game engines like this, but Unity certainly seemed to provide far fewer “Why on earth was it designed like that?” moments than I’ve experienced in the past; it also took far less time to get a general overview of in the first place. I can already see how this tool could be useful for quick gameplay mock-ups as well as complete, commercial products.

So do I wish Unity had been a possibility when we worked on Some Assembly Required last year? I’m not sure. In some ways, I think it perhaps makes things too easy when it comes to games programming as a learning experience. Sure, there are a lot of great features and we almost certainly could have created a more complete game in the short time we had available, but at the same time we wouldn’t have learned about using and integrating 3rd party libraries, structuring the application overall or converting and importing troublesome assets.

That’s also a reason I’m hesitant to keep working on this project – I’m not sure I’m getting as much from it as I could by tackling something more technical or in a different language. We’ll see what time permits though, as working on a game to completion is obviously a challenging exercise in itself and it seems possible that having the engine there would allow me to focus on difficult problems while the other stuff is taken care of.

Since I’m not terribly sure this project will make it any further though (I do have an honours project to take care of, amongst other things), here’s the little segment I’ve completed so far:

• You’ll need the Unity Web Player.
• Use left and right arrows to rotate your ships.
• Use space to shoot the cubes (asteroids. Probably thrown through space by bugs we’re at war with on some distant planet)

Anyway, if you’ve given Unity a try leave a comment below and let me know your experiences!

The programs I’ve been working on are in C#, though I’d be interested to try other .NET languages. In each, I processed thousands of entities allowing each to rotate and bounce around a window. Different methods of splitting up and dealing with this work in parallel were experimented with.

Rendering, which was performed separately and was responsible for a fair amount of overhead, could be simplified or rearranged to increase overall frame processing time. However, as the graph below (from my first program created) shows there was a noticeable difference between using one and multiple threads. I’m using a dual core CPU on my laptop, and with the application limited to a single core the gain was far less significant; I hope to see whether using a quad core CPU would offer a further gain in the near future.

Although not shown, using 32, 64 or even 1024 threads caused far less of a performance hit that I had expected. The time spent creating the threads at the beginning of the program was notable, however, as was the increase in memory requirements.

We pitched our games to the other participants on Friday, having only just managed to meet up the morning beforehand. Luckily we’d managed to agree on a game design through online meetings on Skype, but there were elements that we didn’t fully decide upon until we met face to face.

This morning (early this morning) we got together in Whitespace to actually start work. The team is composed of two programmers, two artists and an audio producer, and while we have roles and some idea of what we each need to achieve it’s hard to know exactly what we will end up with until we get to know each other better.

Waj, the other coder, and I settled into development over the weekend before by developing a particle system manager and a flexible 2D game framework respectively (we, of course, couldn’t start work on the game until today). Luckily, we have XNA at our disposal which should make a big difference to what we can get through in the timespan. Today however, much of each our time was spent simply merging code: lacking an SVN client on the university computers we were attempting to simply use Dropbox. Scary, and time consuming. Hopefully tomorrow we can make use a portable command line SVN client to keep track of changes.

Another issue we’re facing is in terms of work distribution and each having our own coding standards. As you might imagine, most of the problem is with communication – to a small extent because we don’t know each other, but mostly because we barely had time to come up with a game idea, let alone come up with task lists and naming schemes. We’re working things out the best we can as we go along though.

So, hopefully on friday we’ll have a simple top-down 2D game to share! Wish us luck.

Me: “But Abi! Surely I should work on bug fixes rather than implementing Depth of Field.”

Project Manager: “No, Hazel. You must work on awesome graphics effects.”

Me: “Sweeeet.”

Ok, so I’m paraphrasing a little but if there was a film of the actual situation I’m pretty certain this would have been the dialogue. We’d been talking about macro-photography inspired depth-of-field effects for a while but I wasn’t sure we’d actually find time to get it working. In reality, it took less than a day to implement, didn’t kill our framerate and (I think) looks fantastic.

Although I’ve really only been sharing bright and shiny screenshots of our game, it actually progresses from a sunny farm through to a dark and creepy forest. Naturally, this meant it was time to focus on implementing a coherent lighting model for the level. At the moment we’re working with ambient lighting, two directional lights and two spot lights per short section of our game.

In addition, I’ve been looking at methods for shadowing and shading. Each bee is an intricate model, but scaled down it would be easy to lose a lot of the detail. As you can hopefully see in the following images, shading adds some depth and makes the bees appear far more three dimensional.

Shade by distance from ground.

Shade when normals point down.

Combined Shading Techniques.

Combined With Lighting.

 
 Similar techniques applied across the entire scene also improves the overall appearance, with and without lighting:

 
 Finally, here’s an additional happier version of the shot above, just to show the difference a change in lighting can make:

In previous programs I’ve tended towards simply returning boolean variables from functions which would otherwise be void to indicate success or failure, created log files to keep track of problems and used asserts for checking critical components. Ignoring, for now, the fact that I just plain wasn’t using these methods often enough, there are several problems with this approach.

First, it employs three seperate methods for dealing with error handling and recording – I can use each method to relate to the others but this results in several lines of code just dealing with something which may be an error, and could lead to inconsistancy.

The second problem was that not enough information was being passed and recorded. Returning a boolean variable from a function only gives you two options – either the process succeeded or it didn’t – when in fact the situation is often more complicated than that. In particular for offering logging and debug output a more verbose output type becomes useful.

My solution was to create a simple result class encapsulating the information to be passed back from a function, and a seperate handler class to output or log these messages.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

 
class Result {
public:
	Result(ReturnResult _result, std::string _location, std::string _message);
 
	bool success();			//A boolean representation of the result value
	ReturnResult value();		//The value/type of the result
	std::string location();		//The location string from the message
	std::string message();		//The error message
	std::string valueString();	//The value as a string for logging/output
 
	static ResultManager *ResultMgr;//set a result manager so results can be handled on creation
 
private:
 
	ReturnResult m_result;		//type of result being returned success/error severity
	std::string m_location;		//class/module/function being returned from
	std::string m_message;		//description of the error/success/test
 
};
 
//severity of any errors resulting
enum ReturnResult{
 
	RESULT_SUCCESS,			//success which happens frequently (eg every frame)
	RESULT_SUCCESS_CRITICAL,	//success in a critical component
	RESULT_ERROR_TERMINAL,		//errors required the program to quit
	RESULT_ERROR,			//errors which might be recovered from
	RESULT_WARNING			//minor errors, which may cause problems later
 
};

I think this is all pretty straight forward – the result class contains 3 pieces of data: the type of result generated (of type ReturnResult – the enumeration shown above), a string indicating where the result originated and a string with a message to give more information on the error or success. This keeps the class to a minimal size so that creating and passing results around doesn’t become an issue, but gives enough information for interpreting, logging and tracing errors.

Also a member of the class is a static pointer to a result manager which will handle these messages. When set, this means that the result messages can be handled (logging, outputing immediately or even exiting the application) as they are created rather than having to get hold of and processing each one individually. This allows for consistant decisions on how messages should be handled, and prevents error handling obscuring the actual functionality of the application.

Errors can be created, processed and returned in one statement like this:

1

return HError::Result(HError::RESULT_ERROR, "Graphics Setup", "Pixel format could not be set.");

If you’d like to check out the complete code for results and the result manager, I’ve uploaded it here: Source Code. Feel free to modify and use it under the terms of the MIT License, or get back to me with improvements or suggestions.