Only managed to squeeze in just over 4 hours of coding this week.

One of the rules I have is that I don’t code at home on the same day that I’ve been coding at work. If I did, I would be coding Ancient Armies whilst my brain was still fatigued from coding professionally – probably not a good thing.  

Also I don’t think it would be fair to the company that I work for, as I would be turning up the next day without giving my brain a sufficient rest period – again probably not a good thing.

In my previous job this didn’t matter too much because I was multi-skilled as a Systems Designer and a Software Engineer so I was never coding everyday. However in my new job this is no longer the case! For me this is a good thing, not a bad thing, after all doesn’t everybody want to do a job that’s also their hobby too?

Although I only did 4 hours I made the most of my time…

First up, I added my new optimized height finding system to the last two remaining shapes, namely rhomboids and circles. 

Here is a screenshot of my system’s calculated test points for the first Rhomboid under test (click for full-size):

As can be seen, my system appears to have calculated a good set of test points. One thing that can’t be seen from the above image, is that I have made an alteration to the system so that it adds an extra test point at the geometric centre of all shape types. Probably not really needed, but I’m just playing safe.

Next I chucked a super-huge rhomboid at my system with some 4000 chariots which resulted in (click for full-size):

Here we can clearly see the additional test points that the system has calculated. So far so good!

Now on to circles (click for full-size):

Again the system seems to have coped with that circle quite well! Next I gave the system a larger circular unit to play with (click for full-size):

Calculated test points are once more spot on!

That’s all the unit shapes accounted for using my new test-point system. I don’t have to worry about unformed units, because they inherit their test points from the shapes from which they originate.

Testing at this stage also proved that the unformed unit bug had already been resolved by just this singular optimization alone!

However, I was on a roll and decided to put a few more optimizations in…

When looking for further optimizations I realised that the one thing that could be optimized was the algorithm for automatically generating broken 3d shapes from a fixed shape. The original system used a kind of cheat to make calculations easier. Consider the broken Companion unit below (click for full-size):

Can you see where the ‘cheat’ is? No?

I’ll come clean, the ‘cheat’ only reveals itself when you take the unit off map to see what is hiding under the terrain (click for full-size):

Hopefully the ‘cheat’ should now be obvious!

Whilst this ‘cheat’ made the generation algorithm a lot simpler, it did mean that the unformed version of the unit had a lot more triangles in it than it really needed. In this case over double! Plus in terms of aesthetics it’s a bit of a failure.

So I hit the ‘On’ switch in my brain and came up with a more complex algorithm, an algorithm that only creates the triangles that are actually required (click for full-size):

Pretty Cool Eh?

Only managed to reduce the triangle count by more than half!

Any other optimizations?

A few more…

Whilst standing outside – yes I do go out! – I noticed my faint shadow on the pavement.

I then decided to do an experiment…

I took a few paces to the left and checked my shadow. Next I rotated my body by 45 degrees and again took note of the shadow. Then I took a few paces back and again looked at my shadow. At this point I decided to do one more final check and moved a few paces to the right and once again observed my shadow. I suspect that anybody looking must have thought I was missing a few marbles

While this wouldn’t be the first time(!), my experiment did yield a very valuable result. I had realised that when a light source is very far away, the rays of light that reach you are essentially travelling in parallel straight lines with the source appearing to be fixed in space even when you move. This is in direct contrast to a nearby light source!

I did the experiment because I wanted people to think that I was crazy remembered that I had modelled the sunlight in the game to replicate a very distant light source with parallel rays. As such, its rays always hit the map in a parallel way from a seemingly fixed point. I now smelt an optimization here!

I realised that if the direction of light was always the same regardless of where you are on the map, then shadows for a model need not be calculated for simple movements (translations) because the light incident angle would always be the same! The only time the shadow volume would need recalculating is if the nefarious unit decided to do something underhand… say like rotating itself!  

The system as it originally stood calculated shadow volumes every-time a unit so much as sneezed! A few code tweaks later resulted in the shadow volumes being calculated on unit rotations only. 

Woot! Another optimization added to the system. This optimization really made quite a big difference to the measured figures for moving units! So who says that standing around is a waste of time?

Next, I added further optimizations to all unit models to prevent them recalculating their vertices unless they are going up or down a slope. Small undulations in the ground would be ignored. Again another boost to performance!

For my performance tuning finale I was going to add a throttle to the main render loop within the control section. However, this made very little difference so I removed the test code and left things as they were.

Despite the last optimization not working, I’m a very happy bunny. Moving units have never had such a high frame rate! And the unformed unit issue is now well and truly solved!

What’s next?

Based on the feedback I have been getting from my testers I’m going to spending the next few weeks adding additional functionality to map editor. 

The map editor uses the maps library which is also used by the scenario editor. I figured that as some of these changes would be in the maps library, it would be a good idea to address these enhancement requests prior to continuing work with the scenario editor. Of course, thanks to my cunnng architecture the scenario editor will automatically get all the enhancements added to the map editor!

That’s it for this week – I’m off to make a Sunday Roast!

Laters

RobP

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 in order to fully 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 also 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

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

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 won’t say anymore on this – and don’t get me started on software patents….

Laters

RobP

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

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

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

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