The Ancient Armies Blog

Firstly, I’d like to welcome José to the project as a new external tester. Hope you have fun!

Work this week has again been concentrated on resolving outstanding issues. Many of the issues were quite trivial – if a little hard to diagnose. However, the one that has been burning most of my time this weekend is unformed units.

These dastardly units work exceedingly well on my laptop, but when the same build is installed on my main and more powerful machine, they exhibit big performance issues and other weird artefacts like random height changes!

This issue is unlike any other that I have faced because the symptoms only occur on my main machine(!) despite the version under test being identical on both machines. I was expecting that it would be my laptop having all the problems as it is a truly ancient machine. But in a bizarre twist of fate and possibly design, the laptop has no issues whatsoever - instead it’s my uber-mega-system which is having the problems.

What could be causing my faster machine to perform worse than my very slow machine?

I had a theory….

I suspected that the faster machine had a much higher throughput within the main render loop of the game. I further theorised that if there was a task involving a lot of processing power going on, the faster machine would theoretically call it more often than the slow machine – in fact, much more often! So in this case it pays not to be so fast!

After running Ancient Armies through my debugger it became obvious that there were a few places where the code was getting bogged down.

Whenever a unit is moved in Ancient Armies the software checks every vertex point of that unit against the underlying map to get the height information for that vertex. In addition, the system effectively recreates the unit’s vertex buffer based on the newly gained height information. It is this system that allows units to ‘terrain-follow’ when being moved around and to extend their heights when they are on the edge of a slope.

Two things occurred to me here:

1. Checking every vertex of a mesh is highly inefficient. Firstly the mesh has to be locked and unlocked – an expensive operation. Secondly, why bother testing so many points? There is no real need to. Unformed units are especially susceptible to this as they have a much higher polygon count than their formed unit siblings.
2. Also why bother recalculating the vertex buffer every time a unit is moved? After all, we only really need to do it when the unit experiences big changes in ground elevation, such as going up or down a hill. Again this is an expensive operation as buffers need to be locked and unlocked and once again our unformed unit fairs badly in this respect due to its high polygon count.

So what is my solution?

It would be a multi-pronged solution. The first thing I wanted to do was create a height finding technique that doesn’t require as many sample points and has no requirement to lock and unlock the unit’s vertex buffer. Basically, I wanted it to work with no dependency on the number of vertices within a unit. Next I would prevent the unit vertex buffers from being calculated unless transitioning hill elevations and finally I would ensure that the main render loop has a governor installed on it to limit its maximum throughput.

On to part one. How was I going to make vertex height checking more efficient on my units?

The cunning scheme I hatched was to rely on the fact that all my unit shapes have concave polygonal shapes. Concave polygons have no vertices whose coordinates fall inside the bounds of the other vertices within the shape. In plain English terms this means that I only need check the height at the few critical points of the shape that define its external boundary.

What is more, these points could be stored outside of the vertex buffer, which means that I would no longer have to take the performance hit of locking and unlocking the vertex buffer! Woot!

I set about modifying my code to dynamically calculate these  boundary points. The screenshot below shows the points that my new code calculated as the boundary sample points for a standard square formation (click for full size image):

Cool Eh?

With the new algorithm the above unit only requires that four height samples are taken, a vast improvement when compared to the original system’s twenty one. So even for a unit that is not unformed, the savings in performance are huge – especially when one considers the number of calculations that go on under the hood to calculate each height precisely. It should be noted that the red sample points are only there for debugging purposes - they will obviously not be around once coding has finished!

So is that it?

Nope.

I took the liberty of making my sample point algorithm intelligent. Not intelligent as in HAL2000 intelligent, but intelligent as in being able to take a unit’s overall size into account! To show this in action here is a screen shot of a much larger unit – the Macedonian Hypaspists (click for full size image):

Here one can see that my algorithm has realised it is dealing with a relatively long unit and as a result it has calculated more sample points on the x-axis of the unit! Of course my cunning algorithm also works in depth (click for full size image):

Next I moved on to wedge units (click for full size image):

And of course my algorithm takes unit size into account for wedges too as shown below (click for full size image):

I’ve also started work on Rhomboid shaped units too, although these are not yet coded to dynamically allocate points based on size. (click for full size image):

I still have more work to do to completely resolve the unformed units issue. Obviously, Rhomboids need to be finished off and circular units need to be addressed. In addition to this I will need to put code in place to only update a unit’s vertex buffer when necessary, IE when going up or down a hill. Plus I would need to add a governor to the main render loop. All in all quite a lot to keep me amused!

What else have I been up to this week?

Well, I managed to find some time to setup my own email server and integrate this server with my issues system. As a result whenever work is carried out on an issue or a build is released, the relevant people automatically get an email informing them what’s going on!

I have also carried out further work on the tester’s forum in terms of stylistic design and providing enough documentation to get the testers going.

In terms of my fight against the issues raised by my testers, I think I’m winning – *cue cheesy grin*  (click for full size image):

As one can see the number of outstanding issues as indicated by the blue line has taken a substantial dive!

That’s it for this week.

Laters

RobP

This week I have been busy fixing issues and enhancing my home development environment.

The first thing I did is migrate my code forensics and issue management systems over to a MySQL database. Doing this is recommended by the company that produces this software and gives me the ability to directly tweak the tables. Although this generally isn’t recommended I have already used it to fix some issue resolutions after I changed my work-flow process.

Next up, I have been spending time increasing the integration between Fish-eye, JIRA and Perforce. The results of my efforts now mean that Fish-eye is now ‘Issues’ aware and JIRA is now linked into my source code in such a way that I can now see the source files that got changed for each issue and even be able to carry out code forensics simply by clicking on them – the image below shows the new functionality (Click to see full size):

Another thing I have been looking at this week is my release process – or lack there-of. Up to now I have simply been developing code and building as and when I needed to. These builds overwrote previous builds, so I only ever had access to the latest build. What is more there was no real versioning – being the only person on the project I didn’t see the point.

However, now that I have some external testers, I decided it was time to implement a proper build and release process. This has now been implemented and now handles such things as when each build should be released and what should be in it. I have also put in a version numbering system in place and a process to ensure that I can build at any version I so choose. This means that issues can now be reported in a specific version and fixed in a specific version.

The eagle eyed amongst you have probably noticed the new link on the right to the testers forum. That is another new addition that I have been working on. It will soon be live as a private forum for all testers and myself. Hopefully it will be useful for discussing issues and generally enabling communications between many geographically separated parties.

Right now my intention is to continue with resolving issues as the highest priority and using my limited time to try and stay ahead of the issues raised. The graph below shows how I’m doing in this particular area:

As can be seen the fight between me resolving issues and them being raised is pretty much even at the moment. The blue line at the bottom shows how many issues I have unresolved at any one point in time. The blue line shows that I’m ahead of the curve – but only just.

What’s the breakdown on these issues? After all 15 issues sounds quite a lot!

Well the breakdown is as follows:

So in reality I only have 6 bugs – it is these 6 bugs that are my highest priority. Once they are nailed a few of the improvements will be tackled – some in parallel with the bug fixes. Once it becomes apparent that I’m on top of things I will then continue with brand new functionality.

One interesting bar graph that’s worth a look is the spread by component graph. This can be seen below:

The above chart shows a break down by component of every issue ever raised. It should be noted that many issues affect more than one component – hence the elevated issue count. From this chart I can see where the potential problem hot-spots are and which components are pretty stable. Some of my more stable components are not even on this chart because they have no issues against them.

The great thing with my home development setup is that I can obtain a wealth of highly accurate project management information at the touch of the button with no real overhead due to my tight tools integration!

In terms of the fixes I’ve been looking at, the big one this weekend was a memory leak in the map editor – yes another one! This one differs from the last one in that it only ever occurs every time a new map is loaded into the same instance. This one took quite a few hours to nail, but was important because the testers were reporting the editor crashing after loading just a few maps. The graph below shows memory usage for the pre-fixed version and the post-fixed version. As one can see – the leak has been well and truly plugged!

Other than the above, most of the other issues I have been looking at have been pretty minor – though I do have some juicy ones to look forward to this week.

It seems that over the past few weeks my role on the project is moving from just merely a technical one to a much more project manager orientated role. I think this is a good thing for the project as it will focus what I need to do and hopefully result in the better use of my time.

Now on to the title of this post!

Yes – I am looking for one or maybe two additional testers. I want to pick these people fairly randomly, so I will settle my choice based on a competition!

All you need to do is watch the video below of me practicing on my guitar and tell me at robertapollard@hotmail.com what song you think I’m playing  and a small description as to why you would like to test on this project. The winner will be picked by picking a person with the correct answer and the person that convinces me that they are the one for the job.

There is no game as such at the moment. Just a Map Editor, Army Editor and Scenario Editor. So the testing will probably take a while, but at the end of it all testers will get a full copy of the game – when I eventually finish it – just remember this is a home project

On to the Video! Good Luck!

Laters

RobP

This week I have achieved quite a lot, despite only having the Sunday to work on the project.

The first thing that happened this week is that for the first time ever, other people are now in possession of my Ancient Armies binaries! Fixing the installer last week was a critical issue that had to be resolved before distribution of the binaries could be achieved.

Does that mean I’m Alpha or Beta testing yet?

Nope – Sorry!

The binaries are out to a very small handful of people to play with and let me know what issues they find. This is effectively ad-hoc testing of my components that will provide additional coverage over and above my developer style testing. The results of this test program have already proved fruitful with another eight issues and enhancements already being reported!

Looks like I’m going to be having my work cut out for me!

Again, as last week, the primary purpose of this phase of development is to kill bugs and maybe add some enhancements where they have been requested by my testers. At first I didn’t think I’d have much to show as many of the fixes I have been carrying out are below the surface. As a result all I was going to leave you with was this photo of my ‘office’ (click for a larger image):

Cosy eh?

Fortunately, the work I have been carrying out has turned out to be more interesting than I thought, so I have some additional screenies for you.

First up was an issue where protracted resizing of the main window would result in a crash. This one was quite difficult to trace and actually took me a little over 2 hours to nail.

I soon discovered that the issue only showed itself when a map had trees on it. I traced this further and realised that the issue was related to the vertex buffers used for the new trees. For some reason these buffers were not freeing up their memory even when being disposed and set to null! In effect my map dll had a memory leak!!!

In the end I came up with a cunning scheme where the relevant vertex buffers would only needed initializing at start up, thus preventing the memory leaking during re-size operations. The difference in memory usage can be seen below:

The first bump on both graphs is the state of play after a map has been loaded. The subsequent bumpy bits are the result of me furiously changing the size of the user interface. As can be seen, after the fix the line is effectively flat (no leak) except for two small bumps that are promptly released properly.

One bug fixed!

On to the next issue!

John-Paul, one of my testers didn’t like the fact that the map editor never displayed the min and max allowable values that the user could enter to set the size of a new map. They in effect had to take a guess as to what they could legally enter into the map width and map depth fields.

I agreed that this was an issue and decided to fix it. Whilst I was there fixing this issue I decided that I would also change the look of the ‘New Map’ dialog to fit in with the rest of the system.

A screenshot of the updated dialog window can be seen below:

Looks pretty cool eh?

At this point I also decided to add additional flexibility to the mapping system. Can you tell what it is by looking at the above screenshot?

Yup – it’s the new foliage option.

This option now allows users to pick the type of foliage they want to go with their base terrain. Previously, the system would only allow European trees for grass terrain and tropical trees for desert terrain. The new system gives the user the option of picking either type of foliage to go with either type of base terrain.

As an example, if I was creating a map based on a battle in India, I can now select tropical trees to go with the grass terrain (click for a larger image):

Conversly, should the user wish,  they can now pick European foliage to go with desert terrain (click for a larger image):

Maybe handy for some islands in the med?

Hopefully – this change should allow for a greater variety of maps.

What else have I been up to?

Well, it seemed that I had a bug claiming that there were issues with unit shadows on water. So I placed a unit on some water and this is what I got (click for a larger image):

At first I couldn’t see anything wrong. Then I noticed what looked like a shadow issue on the top left hand corner of the unit.

See it?

It’s like a little bit of shadow sticking out of nowhere!

Rotating the unit around showed me that it wasn’t in fact a shadow issue as previously thought…

It was a reflection issue!

What I was seeing in the screenshot above was part of the unit being reflected off of the water incorrectly.

After a lot more experimentation I got a further clue when I moved the unit over deeper water (click for a larger image):

Now the problem was really showing itself.

It seems that on the render pass for the unit reflection the whole of the unit was being rendered even the underwater part of it! So what we are seeing here is a reflection of the underwater part of the unit, which in real life would be impossible!

After a lot of playing around trying many solutions I came to the conclusion that due to the way that origins were now calculated for unit models the only real solution would be to limit the reflection render pass to only render the part of the unit above the water, whilst the other render passes would render the whole unit.

In theory this solution would work, however there is one flaw – performance!

Alas, to implement the above solution any unit on water would have to have its vertex buffers recalculated twice every frame if it hadn’t moved, otherwise it would need recalculating three times every frame. As the game is running at 60 frames a second, if it had many units in it that were on water the calculations would be crippling.

I needed another solution.

After a bit of lateral thinking I decided to get around the problem simply by making units ‘float’ on water (click for a larger image):

This neatly circumvents the above technical limitation.  This is as a result of the unit now being set to float on water - its vertex buffer can now remain unchanged on every frame, unless it has been moved, in which case it may only be altered at a maximum of once – a vast improvement.

I also think that from an aesthetic point of view the units look a lot better when they are floating. So  fixing this issue has turned out to be an overall winner all around!

That’s it for this week.

Laters

RobP

I’m not normally political – but these proposed US laws are so poorly defined that there is a rather large chance that they will be used and abused by the rich and powerful to censor anything they so please – all in the name of copyright.

I won’t say anymore on this – and don’t get me started on software patents….

Laters

RobP

This week I’ve been able to put in a few hours here and there. Luckily with my new issues tracking system I now know exactly how many hours I have put in and how bad my estimates are

After reviewing my outstanding issues and filtering them out to show only bugs it became apparent that my system had 6 known bugs – some of which were quite serious. So I decided to start tackling some of these. My eventual aim is to reduce the count to zero before adding any new functionality to the game itself.

I’m a great believer that home developers should nail bugs as soon as is practically possible – if they don’t the bugs will build up to a point where they are unmanageable for one person. I don’t want to be in that position, so I’m taking a fairly aggressive stance to eliminate them before they get out of hand.

Of the six known bugs three got fixed, so I’m now down to three – but be rest assured I will be pointing the gaze of my mind in their direction pretty soon…

What else have I been up to?

Quite a lot as it happens!

Firstly I have been looking at my game installer. I have always had a major technical issue where I could never get the installer to install Managed Direct-X. Installing Direct-X in your own installer is a bit of a minefield both technically and legally. In the latter case Microsoft have some very strict rules on what you can distribute and how you distribute it.

After some research, lots of tweaking and lots of trial installs in completely clean XP Pro installations I eventually cracked the problem. To be honest, Microsoft have made a great job of their DXSetup installer, it just took me a little effort to find the packages I needed for Managed Direct-X and to get the whole thing incorporated into my own installer. The screenshot below shows the updated installer in action:

I’m now quite happy as this is one issue that had been dogging me for a long time. The only other thing I needed to do to the installer at this stage was add a licensing screen which can be seen below:

Why bother with licensing and why concentrate on getting the installer working properly at this stage?

Simple.

I want to start handing out bits of the game to various people so that they can test and start playing with them. This is not a beta or alpha test, more like an iterative testing of a product in development. That said my code is very stable and at least up to beta standards – I simply wouldn’t have it any other way!

By continuously sending out components to people I trust, I expect to get a lot more feedback and pick up any issues a lot earlier than would otherwise be possible. After all I’m only one person and there is a limit to what I can achieve within a given timescale!

Whilst working on the installer I also decided to try to incorporate obfuscation into my release builds. I spent a good four hours or so on this and have come to the following conclusion: It isn’t worth it!

Why? I must be mad? Surely?

Nope!

I made many discoveries during my obfuscation adventure.

First up was the discovery that files saved by my game, such as armies and maps are not compatible between obfuscated and non-obfuscated versions! For me that is a real pain in the rear!

What’s more obfuscation seems to affect different file types in different ways. For instance map files seemed to work across obfuscated and non-obfuscated versions – right up to the point that I had a play in the scenario editor and noticed that my units doing weird things when they were moved around (click for a larger version):

Armies on the other hand simply failed to load across versions and crashed the Army Editor! What is more, trying to fix bugs in an obfuscated environment is quite tricky too!

For me, having obfuscated release binaries that bore no resemblance to non-obfuscated debug binaries is a big no no and a huge source of potential risk.

At this point I then decided to have a look at decompiled obfuscated code and whilst it was a little scary in places, I think I could easily make use of it.

In the end I decided that the risks were simply too high for very little benefit. I firmly believe that if someone wants to hack your .net code they will do it and there is nothing you can do to stop them, regardless of whether you choose to obfuscate or not. In other words if they want your .net source badly enough they will get it!

Also, by the time Ancient Armies is released it will be out of date in terms of the technology I will be capable of. For example, my underlying graphics engine called Ionian has already been superseded by a shader based engine that I have written called Dorian. Dorian won’t be used in Ancient Armies because the way it works is very alien – but it is a very powerful engine.

I suspect that the only people that do obfuscate their products are very paranoid – especially if they are targeting a niche market like myself.

Hopefully my decision not to obfuscate should now be very clear to everyone – that is unless someone can convince me otherwise…

That’s it for this week.

Laters

RobP

Apart from working on fixes and enhancements, I have spent a bit of time this weekend taking my development environment up to the next level. This involved a number of enhancements.

The first enhancement was to configure my configuration management tool called Perforce to fully integrate my laptop with the environment. As a result if I am now sent anywhere professionally, I retain the ability to continue with my software development. What is more this remote working will be on the same code base repositories that I’m using at home! This should hopefully prevent the lack of productivity experienced last year when I got sent away from home on business.

In addition to remote working I decided to take my issue management up to a professional level. I felt this was required as the Ancient Armies system  is rapidly maturing and I need a means of keeping track of issues and any zany ideas that I get!

Before I get any further I should define what I mean by ‘issues’. Many people think of just the negative connotations when they think of issues. However, when I refer to them they can mean anything including: New Features, Enhancements, Bugs and Tasks.

Previously I had been using the built in ‘Jobs’ system within Perforce, which whilst good was quite limited. This is to be expected given that Perforce is primarily a configuration management tool.

To manage my issues I decided to employ a piece of software called JIRA.  I chose JIRA for four reasons:

1. Exposure to it in a professional environment was very positive.
2. Cost – At only $10 usd for a perpetual license – who is arguing?
3. It’s browser based – ie portable.
4. Integration – Perforce has built in plug-ins that can directly integrate with JIRA.

The latter was particularly compelling as it would mean that issues would be able to be tracked from end to end with full integration with Visual Studio via Perforce and of course Perforce itself. For example I can now create an issue in Perforce or JIRA and have it appear across all my systems, whether they be Visual Studio, Perforce or JIRA. Code can also be checked in against the issues in JIRA/Perforce too! And to top it all off, every system remains in sync with each other, regardless of where the changes are made!

A screen shot of my customized JIRA issue tracking tool can be seen below (click for a larger image):

I have to say that the tool has already proved to be very useful and dramatically helps with my work-flow and keeping focus on what’s going on in the project as a whole. With this system in place there will be nowhere for issues to hide and after prolonged usage I should have access to project metrics too!

Whilst purchasing JIRA I also purchased another browser based application called Fisheye. Once again Fisheye is fully integrated into my development environment - it can talk to both JIRA and Perforce directly. This tool specialises in source code change forensics. For me it is a very handy tool as it provides many powerful tools for analysing code changes and for locating any problematic areas within the code. It also allows one to check code related to specific JIRA/Perforce issues and even run differences between differing versions.

A typical Ancient Armies Fisheye screen looks like (click for a larger image): 

Many of the metrics I have already obtained from Fisheye have been quite enlightening.

 One set of illuminating metrics that I’m willing to share is shown below (click for a larger image):

What I like about this graph is it shows me when I’m most productive!

It seems that I do most of my work on Saturday and Sunday afternoons and have the results committed to Perforce by around 5 in the evening – just in time for some food!

I’m now very happy with my development environment. It is now at a point where it can be transitioned for use in a professional company with multiple employees. In addition it can now track issues to code and back again, create code from UML and back again, produce metrics and allow for working at remote locations.

I think you will agree with me that my development environment has most definitely matured!

Laters

RobP

Whilst putting the Scenario Editor through its paces various things started to grate on me. One of which was my algorithm for creating broken units from fixed units.

Consider the image below that shows my original breaking algorithm at work (click for a larger version):

On the left are two fully formed units. On the right are their broken equivalents as calculated by my breaking algorithm. Whilst I used to be pleased with the result, I’m not anymore!

For me the two biggest issues were that the overall shape and the allocation of colours were not being calculated accurately enough.

If one looks at the above image one can see that the broken unit’s footprints are a little way off their originators. To make matters worse, when one looks at the colours they seem to be a little bit messed up and don’t seem to follow the colour boundaries of their originating units.

In the end I thought enough is enough – I will recreate a newer algorithm to do this – especially as I now know a lot more about 3d Meshes than I used to!

I tested the new algorithm on a Persian Calvary unit and this is what I got (again – click for a larger image):

As one can see, the new algorithm is much improved. The footprints of both units are now practically identical and the calculated colours now appear within their correct boundaries. Woot!

Coming up with an algorithm to do this and work properly with all the supported formation shapes was quite hard work. The reason being, is that behind the scenes, everything is in reality a triangle with three sets of 3 dimensional coordinates! Not only do the coordinates have to be calculated but so do their surface normals. These are angles that are always perpendicular to a triangle’s surface, they are used by Direct-X to calculate lighting so they are very important. The screenshot below shows the above formation in all its naked glory (click for a larger version):

The reddish lines are my calculated surface normals. Note that I have set my algorithm to place all edges of the broken unit’s surface normals so that they point downward. This is because I didn’t want the lighting engine to give a too strong impression of the originating shape.

In addition I also had to calculate the contents of both the Index Buffer and the Attribute Buffer. The former optimizes what can be stored in the Vertex Buffer, whilst the latter allocates material colours to each triangle face. Of the two, the attribute buffer was the biggest pain as I had to check each of the triangle’s 3 coordinates against the angles used to define the colour boundaries of the original unit.

For my implementation each of the triangle’s coordinates were fetched from the vertex buffer via the index buffer one triangle at a time. Next I would get each of the three triangle coordinates to vote on where they stood in terms of colour boundary. The colour with the highest vote gets elected for that triangle! The beauty of this system is that you never get a hung vote because there are always three voters! Cool eh?

Who says I don’t do my bit for Democracy and the British way of life?

I’ll leave you with a screenshot of many broken and non-broken units. Hopefully you will instantly be able to see the relationship between the two types of units, especially now that both the shape and colours are now more tightly calculated! (Click for a bigger version of the image)

Laters

RobP

After reading and playing around with Lost Battles I can now confirm that in terms of expected results there doesn’t seem to be anything untoward in my system!

As a result of this I have chosen today to start off my next development cycle.

The first port of call was to test the scenario editor and fix any bugs found. There were two new bugs – one of which embarrassingly showed itself during a demo to a friend last year -  both of these bugs have now been firmly squashed

I was going to continue with more work on the scenario editor but I had one burning issue that needed resolving:  Realism vs Fun.

Up until now my game had been a compromise in that it offered two gameplay modes. One that was very realistic with full command and control, whilst the other dropped command and control to allow players to directly manipulate all their units – ie more fun.

This compromise always annoyed the hell out of me – it was poking fun at my inability to design a system that was both realistic and fun – that is until now…

After a lot of thought I have come up with a system that provides command and control whilst retaining that all important fun element – this is a game after all!

The design I have come up with is very innovative and as far as I’m aware has never been used in a game before. I’m very happy with the design as it now means I only need to support one gaming mode - a mode that is both fun and realistic. I feel this is especially important for product identity in that it gives the game its own coherent feel – something that would have been substationally diluted had I gone with the two gaming modes option.

So what is my new innovation?

I’m not going to tell you! So there!

Yes, I’m afraid, as mentioned before, that many of the systems being put in place at this stage of development are unique – a situation that I wish to preserve on product launch!

That said I can provide some clues…

It involved code changes to the army component and to the army editor.

The outward signs of change look like (click for a larger image):

Yup – there are the outward changes – and yup – those changes are obfuscated – but at least you can see the area of impact!

On to a totally different topic – tomorrow I start a new job. Something I’m really looking forward to.  As a result most of this week will be spent getting up to speed with new software and a new team.

Laters

RobP

For the eagle eyed amongst you, you might have spotted that the above game isn’t Ancient Armies

This is true, but it’s here for a reason…

There is a method behind my madness – at least most of the time!

Why am I featuring a boardgame here?

Well, it’s all down to research!

The above boardgame is unique in that it comes with a 300 page book by Professor Philip Sabin – the same author of the above game system. This book describes in detail the design decisions he made to produce the Lost Battles game with regard to the Professor’s deep historical research. It is for this reason that I bought this game.

By reading the book I want to provide some kind of validation to my own design decisions. It will also help to ensure that the assumptions I made in my historical research are at least similar to those that the Professor has made. The good news is that so far, for the most part, we agree on the interpretation of historical data.

The one big departure between the two game systems is that the Professor’s system is set at a Grand Tactical level with much abstraction. My system is set at a tactical level with a lot of attention to the detail. I suspect that part of the reason for the two divergent views is that my system is designed to run on a computer – this enables me to process a lot of low level detail in the background without the player needing to know such mundane trivia. On the other hand the Professor’s system has to be played by humans, so must be abstracted enough to make the rules more manageable.

However – the above isn’t the only reason.

The Professor makes a point that data on actual ancient battles is scant and as such this should limit the detail that one can model within their system. Whilst I do agree with this approach, my system takes the opposite standpoint and instead delves into the detail.

The reason why I chose to do this is that my game is provided with an Army Editor that will allow players to tweak just about everything if they so wish. This means that potential players can try out many ‘What Ifs’ by altering various parameters and seeing how this affects the outcome of their simulated battles. Hopefully with player feedback my system should converge toward higher realism.

After I have read the Professor’s book my intention will be to run a few battles using his system to check those results against results from my system. Such validation will help give me a warm feeling inside that my system is progressing in the right direction.

Some might say that I’m loafing and playing games! It has to be said that there is an element of truth here

However, the primary purpose is to validate my own system against a well respected benchmark in ancient battle simulation and hopefully to get some further insights into the mechanics of what really went on during those days gone by.

Laters

RobP

Before gearing up for the next phase of development – I have decided to post a quick article covering how the project started and to provide some indicators as to where it will go.

Back in ye-olde days in the late 1970’s and early 1980’s I was using the Micro Ancient rules system to play many historical battles.

A photo of some of the original Micro Ancient units can be seen below (click to see a larger version):

As can be seen in the photo above, the units were essentially made of cardboard. This made the armies themselves very cheap to buy. Cheap enough for a child on a small allowance to purchase!

For me I had no real option as there was no way I could afford the historical figurines at the time – especially in the quantities required to model a whole army.

This is what made the Micro Ancient system so great – one could purchase just about any army of the Ancient world for what amounted to pennies! More to the point, these armies were ‘whole armies’ not just small sections of an army. The upshot of this is that practically any battle could be simulated without any real compromises. I simulated many historical battles using the above card units on top of an old up-turned Subbuteo pitch with books underneath to define the contours of the hills.

Whilst very crude, Ancient Armies did enable me to play out many historical battles with the minimum of outlay – I guess my outlook on life as a child could best be described as unconventional!

So what was it that spurred me to start writing the computer game?

It all started when out of the blue I decided that I needed to learn how to program 3d applications. I don’t know why I decided to do this – I guess it was because it was an area of technology that I knew absolutely nothing about.

The results of my first foray into 3d were a prototype version of my current Ionian graphics engine and a mapping system that could take any height data via plug-ins and render them. These initial maps looked like (click to see a larger version):

Further work was carried out on the engine to allow it to calculate and draw contours (click to see a larger version):

I was impressed but I now had a bit of a problem…

I now had a crude graphics engine that possessed many unique characteristics and I had a mapping tool that would allow me to map anything. The big problem was what could I use this code for? As nice as the mapping tool was I wanted something more, something a bit more challenging. It seemed like I had a graphics engine and a mapping tool that were just waiting around looking for a use!

After some thought I realised that I wanted to do a wargame. I wasn’t sure on the subject matter yet, but I thought that the mapping system and graphics engine would be perfect for such an enterprise.

I realised that whatever I chose to do, the art content would have to be able to be something that I could do – it should be noted that I have the artistic talent that would fall short of that of an average house brick. I knew that the wargame I was going to write had to be abstract enough that my lack of artistic skill would not compromise it.

After a lot of thinking I remembered the good times I had with the Micro Ancient system in my childhood. I thought that this system would be perfect – the units were all abstract blocks – even I could design and draw those!

I set about thinking how I was going to implement the game. I quickly came to the conclusion that it would be highly modular and would be built from the lowest levels upward. My original design called for a map editor, army editor, scenario editor and the game itself. My first task was to look at my current mapping system and determine how I was going to integrate it. That’s when the first big problems began to surface….

The first issue was scale. Whilst the above mapping system is highly configurable with regard to its data sources, I was limited to what was easily and cheaply available on the Internet. This in practice meant limited access to maps with a scale of 1 sample point equalling 90 metres – far too crude for my needs. An example of this can be seen below where I have rendered Southern Spain. Visible in the image is Gibraltar lower right – this should give you an idea of the scale of map that we are dealing with (click to see a larger version):

These maps are just too small a scale to be useful. Experiments to turn these maps into large scale maps with interpolation techniques proved fruitless.

A further nail in the coffin was Artificial Intelligence (AI). The above maps are simply so detailed that to program an AI that could take advantage of the undulations of land properly would be too daunting a task.

In the end I decided that I would need to create another new mapping system from scratch. The new mapping system would need to suit the scale better, be AI friendly and also be highly configurable. It would have to allow a user to create any battle map that they could imagine – within reason. To point me the right direction I studied many historical maps – an example of one is shown below (click to see a larger version):

Here one can see that such a map is much simplified. Hills are shown as simple contours and units are shown in much the same way that they are represented in Micro Ancient. Given that most historical references provided their maps in this format it meant that the obvious thing to do would be to copy it. This way a user could read about a battle then be able to easily create the map with my system based on their text-book map.

My first attempt at a mapping system to model the above maps looked like (click to see a larger version):

As can be seen most of the required characteristics are there – contours, water etc. Plus my system was designed in such a way that a user could simply ‘draw’ maps within my mapping application. This meant that making new maps would be trivially easy. The mapping system was designed to be a top-down 2d map, though in reality it was really rendered in 3d with the camera’s movement being limited. This was done because at the time Direct-3d had no real 2d interface – everything had to be rendered as a 3d – even where only 2d was required!

After a bit of thought I decided that if my underlying code is 3d anyway, why not make the game 3d? This I decided to do. This decision had major ramifications with regard to the complexity of the project – but I do not have any regrets – I’m glad I did it. The switch to 3d, plus numerous enhancements to my Ionian graphics engine meant that I could now produce maps like this (click to see a larger version):

Pretty good eh? And what’s more the simplicity of the original mapping system is retained in that maps are simply designed by painting them in my map editor! The system also supports map overlays that allow one to overlay the 3d map with an actual historical map! This provides many advantages including the ability to completely customise the look of the map as well as providing a guide to allow a user to create very accurate maps. The screenshot below shows the above Issus map loaded into the Map Editor ready to create a map (click for a larger version):

From this point the project had essentially taken on a life of its own. I’d get an idea, then try it out. If it worked it was in, if not it was discarded. This approach to software development is entirely non-commercial, but does have many advantages – it allows one to take more risks and potentially end up with a better product. Of course such an approach would fail commercially because the additional time required would make the project non-viable financially.

The approach I chose suited my business model, in that the hard work would be done as a hobby – essentially for free. Then once everything is completed it would go on sale with no real additional costs. It should be said that there has been a lot of interest in this project – so there will be no difficulty getting a publisher

Things were going well until I started having issues with the underlying Micro Ancient system.

The first issue was that the system only worked with the units provided. The combat tables were all geared toward providing accurate results for these units. Designing new units with differing strengths would markedly upset the historical balance of the system. This meant that if one wanted to simulate historical battles with the actual numbers involved, the Micro Ancient system would fail!

A much bigger problem also surfaced with regard of getting hold of the original copyright owners. This proved to be a fruitless exercise and a big source of worry. The last thing I wanted to do was release a game only to be sued for using someone else’s work without permission.

These two issues forced me to drop the Micro Ancient ruleset. As decisions go, this wasn’t an easy one to make as it meant a fair bit of rework. It also meant that I would have to create my own simulation system – no easy task. However, I stuck with my decision.

Ancient Armies now supports one of the most realistic ancient battle simulations available. Units are now modelled with an unparalleled fidelity based on historical research. Units are no longer defined as having a weapon type, armour type and a morale level like every other wargame system. Instead many other factors are modelled – the fidelity is so high that even the differences in formation have an impact! So an Alexandrian Phalanx will behave differently to a Greek Phalanx, which would in turn behave differently to a Roman Maniple, which would in turn behave differently to a Roman Cohort! No other system that I’m aware of does this!

Overall I’m quite proud of the simulation system that I have designed and implemented.

To highlight some of the differences between Micro Ancient and my system take a look at a sample of units from both systems. The top row shows Micro Ancient Units, whilst the lower row shows units using my new system (click to see a larger version):

As can be seen, the units from both the rulesets are significantly different – the Micro Ancient ones appear to be a lot simpler. My units have shapes that dynamically model where every man is – my system also supports all of the standard formation shapes that the ancients really used – Micro Ancient units are fixed with an arbitrary size set by the designer. This means that in battle my units will change their shape and size dynamically dependent on what’s happening to them – unlike Micro Ancient’s which are essentially static shapes.

Another major difference between the two systems are the strength numbers. My system’s unit strengths are measured in actual men, Micro Ancient’s strengths are an arbitrary factor, designed to work with the existing combat tables. The upshot of this is that it is easier to model historical battles with my system as the strengths in the historical texts can be directly applied to my game system.

Other apparent differences are that my units have formation types, weapon types and armour – in the latter’s case Micro Ancient doesn’t model armour directly! To provide an indication of the number of variables being modelled in Ancient Armies consider the following screenshot from my battle test application. Although the fields are obfuscated, one can quite easily see that the system models a lot of variables (click for a larger version):

Overall my system is much more flexible. There was a cost in putting it into the game and that cost was time. It took approximately an additional year to implement my new system – a fairly large cost, but one that I know will pay dividends in the future.

Speaking of the future what’s next?

Well, at this moment of time the Scenario Editor is nearly complete. Once this is done work will start on the game proper. Although I haven’t started on the game itself, I’m a lot further ahead than this might indicate. Each of the various editors are connected to API libraries that provide a lot of functionality covering such things as maps, armies and battles. This functionality is already there buried deep in these API libraries! All the game has to do is access them!

The biggest risk to the project is my lack of free time. It seems that I have way too many hobbies. These combined with professional commitments and even a social life, do limit the time I have available. For me the project is primarily a ‘fun’ project – something to keep me amused in my spare time. If it’s not fun I will not do it – don’t worry I still find it fun!

Once completed the project will go commercial. Once commercial, time will start to cost. This is no bad thing as at that point the engine will be done…….

Note that I use the term ‘engine’ here.

Why?

Quite simply, the underlying mechanics are very generic and can be applied to practically any historical period up to about the time of the Zulu wars. The upshot of this is that I can invest profits in producing games that will simulate the American Civil War or the Napoleonic Wars – all using the same underlying engine. Such a business is a relatively low risk proposition  as the hard part – the engine – is already done!

Hopefully this article provides some insight as to how this project started and provides a peep at where I intend to take it next.

Laters

RobP