L’Mac?…. Oui!

I guess I should admit it – I’ve been sidetracked over the last few days. Yesterday was not a particularly eventful day, the only real feature I got was mouse picking for tiles (and that caused far too many headaches for what it’s worth…) and sorta hit a dead end on what is the next logical step for progressing the engine.

Of course, when a decision needs to be made, what better place than to do it on IRC? The conversation went waaay off topic as always, and we started exchanging screenshots of our desktops (I did say way off topic) and my “real” desktop is my Mac not the Windows machine. So I restarted and thought… why can’t Overload run on here?

The Mono project is an open source effort to create a .NET implementation that can run on all operating systems, not just Windows. I gave it a try and wow – 1 compile time error! Saddly, runtime was far worse. Firstly there’s no Direct3D support on Macs, so the Direct3D renderer is already useless. Secondly, the System.Windows.Forms implementation in Mono is custom, not native to the OS. It also just didn’t seem to work, so I’ve slightly moving things around inside Moebius, Overload’s engine. Moebius now has now dependancies on SWF and all window management is handled by SDL. It is one more essential dependancy, but it’s not huge – and SDL is quite easy to redistribute.

Renderers are now given a handle to window created by SDL and are in charge of attaching themselves to the Window. I haven’t got Direct3D working with this yet, but it should be a pretty easy task. I wrote an OpenGL renderer and 6 hours later… here we are!

 

It’s exciting to know that Overload is capable of supporting multiple platforms now, and I’m glad to see that I’m finally capable of managing a cross platform project. Now, just got to wait for Daniel to get back from IOWA – and we can start some real development!

Control Freaks

Whew, what a fun day this has been! I got side-tracked from doing some useful work and spent time refactoring a bit of the Engine and generally tidying things up for the first few hours this morning. The result is that everything now has XML documentation, and I’m more happy with the structure of the engine (only minor moves). I started work on controllers as well. Now, controllers are not currently needed in the engine… but they will be! So please don’t attack with that huge YAGNI stick, because we are, honest!

Being me, I wanted to make the most efficient implemantion possible, while also sticking to being as clear and reusable as possible. However, it’s hard to just say “this is efficient” and “this isn’t efficient” without some hard facts, as all good programmers know, so I sat down and wrote some profiling utilities. Moebius, the engine for Overload (which I may open source, who knows), now has a lovely profiling API for what I’ve needed so far.

A discussion over at GDNet started by myself about ways to implement this controller system gave a few ideas. So, I typed out some code of how I’d like the system to look, and then added the profiling API on top. Here’s the code:


TestSubject subject = new TestSubject();
Profiler profiler = new Profiler();

LambdaIncrementerController lambdaController = new LambdaIncrementerController(delegate(float newValue) { subject.Value = newValue; }, delegate { return subject.Value; });
ProfileResults lambdaResults = profiler.Profile(delegate { lambdaController.Update(1); }, 1, 10000, 500, 5);

subject.Value = 0;
InterfaceController interfaceController = new InterfaceController(subject);
ProfileResults interfaceResults = profiler.Profile(delegate { interfaceController.Update(1); }, 1, 10000, 500, 5);

subject.Value = 0;
AttributeController attributeController = new AttributeController(subject, "Value");
ProfileResults attributeResults = profiler.Profile(delegate { attributeController.Update(1); }, 1, 10000, 500, 5);

The final system there utilizes reflection. By searching the “subject” for a property which has the ControllableAttribute, and it’s ExposedName set to “Value.” I have had prior experience with Reflection in .NET and I’ve never found it particularly speedy. This was reflected (ha! sorry…) in my profile results; the AttributeController was about 100 times slower than the other 2 – y’ouch!

I did get slightly more sidetracked though today… This sure is a case of YAGNI! I decided that it would be nice to include some graphics in this blog post, and thought a graph visualizing the profile results would be good. I don’t have Excel though, nor the space to install it on this 5GB Windows partition, so I thought if I could get some SVG graph output, then I could just chuck it into Inkscape. The only thing I could find was a Ruby module, and I couldn’t be bothered to install Ruby just for that, so I wrote my own SVG grapher (yea, cause that was faster than just downloading Ruby…)

So, here’s the results of profiling the two potential candidates:

 

Pretty neat I think! But I’m still torn between which system I want to take. Both are as efficient as it’s going to get (without exposing public fields instead of properties, but I’m not doing that) – and have there advantages and disadvantages. I think when I get round to writing specific controllers I’ll just decide if it makes sense for a controller to control any arbitrary value, or if it is very reusable. KeyFrameController, would be a perfect time to use my lambda/anonymous methods, but FadeOutController would be a good time to use the interface controller pattern (with IFadeable).

Lost again…

Have just spent all day reading, coding, pulling hair out, deleting code, and starting again… but I can finally say that I’m getting somewhere! I decided that we’re going to need some path-finding in the engine to perform user interaction intuitivly, and sat down to implement the A* algorithm. One thing I don’t understand is why there seem to be about 5 different descriptions of the algorithm… Either way, I worked through it, and now thoroughly understand the algorithm’s basics, and have a worked system. My algorithm has turned out this way:

1. Create some holder lists. I have a list for all nodes, a priority queue for the open list, and a simple list for the closed list.
2. Add the start to the open list. Standard step, push the start node onto the open list, with a priority of 0.
3. Begin looping. Until the open list is empty
   1. Get the current node. Dequeue from the open list, which uses a min-heap to give the node with the lowest cost.
   2. Fetch all sucessors. Query the world with for all sucessor tiles (neighbours) around a point.
   3. For-each sucessor:
      1. Find a node. I find a node from my “all nodes” list that has this tile attached to it. Nodes are an adapter for tiles, and allow parenting. If it’s not in the “all nodes” list, I create it and append it.
      2. Update the node. If this node is not on the open or closed list, and the cost of moving from the current node to this sucessor node is less than the original cost of this sucessor node, update the G & H values for the node, and change it’s parent to the current node.

Seems to work a treat! I haven’t done any profiling yet, currently I’m trying to reduce the current coupling between the world and tiles with generics to make this even more reusable (everyone hates class coupling!), but to be honest, this is not a realtime game, so I’m not sure it’s essentially that this path finding is blazingly fast so I will leave optomization for now.

Here’s a shot of the results of path finding, the orange path is the result of path finding, to the tile near the water. I updated the tileset slightly as well, and improved the alignment between tiles slightly – so hopefully it looks a bit more sechsey 🙂

 

(Another) New Beginning

I’ve settled on a project now, that is slightly more fun than Asteroids (although that’s actually turned out to be a much more fun project than I originally anticipated!). Asteroids is on the “when-I’m-bored” pile now, and I might release the source to it a bit later. So, what’s this new project? Well, I had a lot of designers giving some great ideas forward, but something that caught my eye was a project called “Overload”, designed by Daniel. We’re essentially going to be working on a computer version of a standard table-top mini game, but it will have (hopefully) a fair bit more game-play when we’re complete.

One of the major reasons this grabbed me so much is because, somewhat ironically, I’ve never actually played a table top mini-game! However, me and Daniel played a pen & paper version over MSN – both printing out a grid and making counters, and communicating dice rolls over MSN.

As with usual tabletop games, you place your units (we have squads of units that move together) and then take turns moving units, or co-ordinating attacks. But we also have some nice twists in the game – weapons can blow up in your hands from excessive use, we have extra “phases” in each round – such as hacking computers, setting up artillery, calling in air strikes, which all sound cool to me! Stuff like this might be normal in tabletop games, but I like the idea of it, and it seems novel.

Now, on to some technical details. Daniel has said from the start that this should be a hexagonal-tile game and this sounds good to me. I’ve not done a hexagonal game before, so it will be a fresh challenge. I spent a bit of time doing some research on them – and more first naive implementation was, well… awful. But like they say: code one to throw away! So I found some great resources after a brief spell of Googling and turned up Amit’s Game Programming Information, a site I regarded well for A* information, but also happens to have a great lot of information on hexagon based games.

A visualization of the co-ordinate system Overload uses.

That’s the co-ordinate system I’ve decided on. It seems a natural system, and works well with standard formulas such as tile-to-tile distance, with these co-ordinates. To store this in the world I’m using a 2D jagged array, rather than a multidimensional array due to the performance implications. I know, it’s premature optimization, but a jagged array is really no harder than a multidimensional array, so it seems worth it. As for the array mapping, here’s what the above map looks like in memory:

The same map, but now visualized as it is stored in arrays.

Quite simple really, and mapping between array co-ordinates and to hexagonal co-ordinates is relatively simple (although did cause some scribbling on paper 🙂

ToHex(x, y) = { -ceil(x / 2.0) - y, floor(x / 2) - y }
ToArray(x, y) = { y - x, floor( (x - y) / 2.0 ) }

Also, I think the array representation looks quite similar to actual in-game look, so I’m using bitmaps to represent the maps at the moment, with different coloured pixels representing different tile types. No point inventing a file format just yet 🙂 I have got this rendering as well, which I’m quite happy about, because at least this means something is working! The rendering is a 2D-in-3D system, currently with a Direct3D9 implementation, but I’ve abstracted it out to work with hopefully any renderer.

Our first screenshot, woohoo!

Edit: 28/12/2007 – Fixed typo on the hexagon coordinates diagram, thanks Zao!

Obligatory “Hello, World!”

It’s got to be done I’m afraid!

My name is Oliver Charles and I’m an undergraduate comp. sci. student at Lancaster University, UK. I’ve been interested in computer programming since the age of about 12, and took a major interest in graphics programming at about 15. I’m useless at completing projects, so while it would be nice to show some past work here – I sadly have nothing to show (and I can never keep a website for more than a few months :P).

Currently I’m trying to complete a game however – a dead basic one in fact. Asteroids! I could have wrote Asteroids years ago, but I never did – I got my interested in graphics programming and engine design, and never really did much actual game programming. Overtime this lead to me getting bored of programming, so I’ve decided to work on Asteroids. Of course, now that I’ve been doing this for a few years, I’ve built up experience – so I’ll hopefully be sharing information about my engine and it’s design on this blog, along with pictures when I’m ready 🙂

More (interesting) posts to come!