Although the first round was taking place on the day before an exam, myself and two other students from Abertay took part. This round involved answering ten programming questions: 9 based on the C++ language and a final question focussing more on object oriented design.

I wasn’t sure what to expect beforehand (other than a vague notion that reversing a string in place might be involved) but found actually sitting the test to be quite a relief! Although I wasn’t 100% sure all my answers were spot on, there weren’t any concepts which I was unfamiliar with. It certainly increased my confidence (or at least reduced my sheer terror) concerning programming tests I might face when applying for a job.

I was pleasantly surprised to be told that I was one of the eleven programmers who had reached the second round, a more open-ended programming task. For this we were given an uncompleted and incorrect Asteroids like game, and tasked with fixing and improving it within seven days. Working with someone else’s code was an interesting exercise, and I aimed to uphold their programming style and standards as much as possible. I hadn’t touched DirectX or DirectInput in some time, but I didn’t find it hard to get back into; nothing in the codebase was particularly surprising or unfamiliar.

The only downside of the problem was the short timespan, as I also had coursework deadlines and continued work with Digital Colony and on my dissertation to contend with. I successfully submitted a corrected and improved application, however it would have been nice to dedicate more of my time. I’m still waiting on the results of this stage, so I will of course update the blog when I hear back. Since I worked on someone else’s codebase I’m unsure whether posting screenshots of the application is acceptable, however I may also follow up with those at a later date after seeking permission.

Image used under Creative Commons license from Computer Science Geek.

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.

After much thought, even considering changing my topic entirely, I’ve managed to focus my initial idea into a project which should be feasible within the (very limited) time available. As with last week, I’ve been provided some questions to help progress with the project, this time considering my research question.

First of all though, here’s an overview of my idea which has been refined greatly since I last discussed it. My previous suggestion was still very broad, so I tried to narrow it down in three main ways:

1. Limiting the type of geometry to be produced.
2. Choosing a focal point for the project: compiler design, language design or geometry creation.
3. Selecting a specific feature of language design to investigate.

After more research and some pen-and-paper attempts at how the language and geometry might function, I decided that creating plant or tree models based on L-systems would be an area where the use of a scripting language could be particularly beneficial. When considering L-systems and fractals, the idea of an infinitely repeating shape or process comes to mind. Through designing a language which uses types of lazy evaluation, this concept of infinite repetition can be upheld even though only the minimal processing required to produce or render the geometry will actually be performed.

1. What is the focus of your project?

• Language design
• Evaluation strategies and non-strict evaluation
• Compiler design
• Procedural geometry
• L-systems, graftals and fractals

Practical aspects of the project will require investigation of all these elements to some extent, however the research focus should remain on language design and in particular how lazy evaluation relates to geometry creation.

2. What information do you need to find out about?

• I have identified several general sources to expand on my knowledge of compiler and language design. It will also be necessary to seek out resources which relate more specifically to this project.
• In terms of procedural geometry I will need to study the creation of organic (plant) models based on L-systems. Luckily, there is a wealth of information covering a range of topics in this area.
• Previous attempts at creating fractals and procedural models from scripts will need to be investigated in order to compare them to the solution I hope to produce.
• It will be necessary to look at existing non-strict languages and their design.
• Information regarding model file formats will have to be obtained if it is decided that the language should produce geometry directly rather than outputting functions for its creation.

3. What Experimental work do you need to perform?

The majority of practical work will involve designing a language and implementing a compiler for it. Alternatively, an existing non-strict language could be extended; however, this might well prove a more significant task than creating a new, but very limited, language.

A simple way of demonstrating the output of this should also be implemented, however this should be a minor consideration.

4. How will the information that you obtain allow you to answer the research question?

Currently, one of the most prominent issues with my research question is that it is mainly subjective. Although it should be easy to consider ways in which the solution does or does not add to the field of generation of procedural models, it would not produce numerical results which could be compared to existing options. I hope that demonstrating that the language created can successfully create plant models would suffice to answer the research question in its current form, however I would appreciate advice on how the question or project might be modified to provide a more objective comparison.

Image thanks to Kevin Dooley.

YinYangYou, our game, is a top-down two-player race to collect energy and skew the balance of the playing field. By throwing orbs into their opponents’ “holes”, each player can increase the amount of ground they control on the opposite side of the board, eventually claiming an entire side and winning the game. A range of exotic energy pickups, such as time control and hole switiching, add variety and tactical elements to the gameplay.

Developed using XNA, our prototype includes all the features we originally planned – although that isn’t to say the week went without a hitch. Lengthy code merges, a lack of shared source control and model import problems were exacerbated by the fact that having just met, our communication levels were far from ideal. However, by remaining flexible and getting to know each team members strengths and weaknesses, our workflow improved hugely throughout the week.

Even though this project was really short, I feel I got a lot from it. Spending time in groups with the same people for the past year let us refine development and programming methods which worked very well for us. Suddenly being dropped into an entirely different group challenged some of my beliefs and ideas, and reaffirmed others. The opportunity to talk to industry mentors about this game and about development in general was also hugely beneficial.

Finally, I just want to say thanks to Iain Smith for organising the event, all the mentors and other participants for their help and to the rest of Team Be for making YinYangYou a success.