The Ancient Armies Blog

This week I have spent quite a bit of time coding more of the orders engine. The new code is around 80% complete, but before it could be finished I would have to make a little coding diversion…

Some of the order code I have been working on involves user interaction with the maps and units. For it to work well I would need some means of marking up the maps.

As an example I wanted to be able to plot the path of a unit. In most 3d wargames, they take the ‘cheap’ approach and have some very boring tubular lines connecting the unit to its destination – I didn’t want this – I wanted proper markings – like arrows!

So off to work on the latest diversion. The result (click for a larger version):

Quite impressive – or at least I thought so – I’m easily pleased!

The arrows class I designed is very flexible. It allows one to define, colour, opacity and even the shape of the arrows. This can be seen in the screenshot above where the arrows exhibit different shapes, colours and opacity settings.

Coding the above wasn’t too bad. I guess my experience with creating dynamic unit meshes helped me out here.  However, there was one issue I had to address and that is terrain. Terrain, alas, can be quite hilly, so my arrows class would need to be able to follow this terrain! So back to do some more coding – I guess I can use the odd challenge to keep me amused!

After a further period of coding I created a hilly map and ran the application. This is what I got (click for larger image):

Terrain following looks good!  But wait, there was something that was bugging me….

Here is the same terrain from two other angles (again click for larger images):

Can you see what might have been bugging me?

Basically, the problem was – at least in my eyes – that the arrows were following the terrain a little too perfectly for my liking. The last image really highlights what I mean. Here the arrow end has ended up tilted on its side, which I thought was a little unsightly. Technically, it’s a marvel of terrain following technology, but aesthetically, at least in my eyes, it’s a bit of a failure.

Back to the code….

I decided to code in an option to allow the user of the arrow class to specify whether they wanted the arrow’s terrain following stabilized at all. With stabilization selected, the above three images now look like (click for larger images):

Can you see the difference yet?

How about now?

In terms of the last image, the stabilisation system ensured that the arrowhead bends at the horizontal and not at a diagonal, which looks far better in my opinion. In fact I think all the stabilised screenshots look better than their non-stabilised brethren. That said, I didn’t want to restrict future use of the arrow class, so whilst it defaults to stabilised, one can easily turn this off on a case by case basis (Click for larger image):

In the above screenshot I have stabilised the red and blue arrows, but have switched off stabilisation for the yellow arrow.

Now that I have these arrows in place, I can finish off the orders system, which I will show off next week. In many ways this bit of coding is a milestone, as it is the first time that map markers have been used in the game and its inclusion provides a firm foundation for any other marker types I wish to include in the future. I think these markers a light years ahead of the rather dull tubes that one sees in other 3d wargame systems.

I’ll leave you with one last arrows screenshot – not that I’m arrows mad!   Honest! (click for larger image) 

Laters

RobP

Been another busy week on the Ancient Armies front. Managed to achieve quite a lot!

A further ‘aspect’ of the orders system has now been put into place. Again – and I’m sorry – I can’t go into too many details but I can show some censored screenshots:

Programming the above was a bit of a pain as the grid component used to display the data is possibly one of the most complex components that Microsoft make! The display shown above has been coded as a standalone component as it is reused in several places within the system.

Also noticeable in the window above is the ‘Task Completed’ checkbox. Originally, the scenario editor would mark a task as complete once the relevant dialog has been visited. However, I have now decided that this is not really practical in real use and have instead provided the user with a checkbox on all scenario tasks so that the user can manually decide whether or not to mark off a task as complete.

The new functionality above has also been fully integrated with the parts of the orders system talked about in the last post, resulting in an updated user interface:

The orders system now takes into account the max initial orders setting that is customizable for each army as discussed in the Army Editor video. As various parts of the orders system are used the ‘Orders Left’ value will change. When it reaches zero no new changes can be issued – except the removal of existing changes.

Other work has included a tweak to the camera code in the generic display component, so that when a new scene is opened the camera defaults to a much better start position. Prior to this change the camera always started above the terrain pointing straight down – not too useful. Now a typical starting position looks like (click for a larger image):

I think the above is a much better starting position than just looking straight down.

People with hawk like vision will notice that the above screenshot also includes some new functionality for the scenario editor:

Yes – we now have a realtime continuous feed on what is currently under the cursor. This displays elevation, terrain and any units that the cursor is currently mousing over. This is handy to ensure that a particular unit is positioned correctly in terrain.

Anything else get done?

Yes – Overlays. These have now been enabled for the scenario editor (click for a larger image):

It should be pointed out that the overlays system will be getting modified to make it sensitive to transparency. This way a scenario designer can have the original terrain showing with overlays displayed on top.

Whilst the overlays shown above were used by myself as a guide for building the map, they were also designed to allow scenario designers to substantially alter the look of the default terrain. With a bit of artistic skill I suspect that one will be able to achieve quite a lot with this system. Alas I lack any real artistic skill, but as an example, in the screenshot below I have used the overlays system to drape a satellite image over the map (click for larger image):

This seems to be fairly effective, even though the terrain engine is not designed for satellite data. I suspect the above could be improved further by balancing the colour and making other modifications. In this case however, I just got a random satellite image and just placed it over the top of some terrain without any real thought to the aesthetics.

Anymore changes? Surely not?

Oh Yes!

I also found the time to provide a further optimization to the graphics engine. Every unit in the game consists of a number of triangles. The unit shapes themselves have a very low triangle count so aren’t a problem. However, the text on these units have many triangles within them. I decided to alter the engine to cull text output where a unit is further than a certain distance from the camera. The result is a much more scaleable engine and one with an increased framerate.

In terms of looks, I think the majority of people will not notice that this culling is happening. For example (click for larger image):

In the above image I have highlighted where the text has been culled to direct your attention to it. However, during normal game play, I suspect that this won’t be noticeable.

Well that’s it for this post. I hope to get more done next week!

Laters

RobP

Just a quick update! Still coding the orders system. There is a lot to this system – especially of the internal code variety – so there isn’t much to show.

The editing of a ‘certain’ aspect of the orders is now complete resulting in two new dialog windows – I seem to be collecting a lot of these:

As you can see most of the details have been obscured as these dialogs represent a very unique part of the orders system. I guess I’m posting these as evidence that work on the project never stands still!

Programming the orders side of the engine is quite interesting and a little slow going. The reason for this is that although the high level design is sorted and indeed most of the details – when one comes to implement these ideas there are always things to tweak or change based on how I envision the system working. Its kind of the old classic software requirements issue. I have my requirements, I know what I’m going to build, but once its built I want it changed!

The above is quite common in programming because the solution to a problem is imaginary, right up to the point that it is implemented. At this stage one can go over the functionality with a critical eye. It is here that new ideas evolve to make the overall solution even better, or conversely some things that were thought to be a good idea, turn out to be not to be so good once that finctionality is brought into being.

So, for the above reasons, the coding is slow, but steady. It needs to be this way so that I can put into place the best possible systems for the game.

Other work that has taken up a bit of time is bug fixing. As an example when moving the units around the map I noticed that every now and then the shadow volumes would go out of sync with the units themselves (click for a larger version):

Can you see the issue? Perhaps if we turn the camera around it will be more apparent (click for larger version):

In both of the above images it can be seen that the generated shadow volumes don’t quite match the unit that has created them, resulting in weird shadows floating in mid air.

Issues and bugs such as this are annoying because they take me ‘off task’. However, I’m a believer on getting these bugs sorted as soon as possible, otherwise one is in danger of producing a complete but buggy game, which could adversely affect its perceived quality.

I have seen many commercial systems in the past produced where the bugs weren’t squashed right away in order to conform to a tight schedule – the result being a system that has so many bugs and issues that it is almost impossible to stay on top of. Systems of these types very rarely recover to become high quality systems because it costs too much.

The shadow volumes bug shown above  took a bit of time to track down because it only happened rarely and intermittently.

In the end, the bug was traced to my shadow optimizer code. This is a special algorithm that kind of ‘knows’ when it should recalculate shadow volumes and when it shouldn’t. The idea being, that it only recalculates them when it absolutely has to. Alas, the routine was being a little bit too aggressive and was actually not recalculating the shadow volumes in some rare instances where it should!

A small tweak later and all is good with the world again! Woot!

That’s it for this week. Back to working on the orders system and fixing any other bugs or issues that come out of the woodwork!

Laters

RobP

Been quite a busy week on the project. I have been working on the orders system putting in place the low level architecture to support it. I’m at a point now where some of it is getting surfaced to user interface level, but there is not too much to see yet.

I have to say, that on completion of the design phase last week I felt genuinely excited. The kind of excitement one gets when one knows that something is instinctively right.

Adding the orders, isn’t just about orders. It’s also about artificial intelligence (AI) and how that will fit in. Its also about many other good things, which I’m not at liberty to discuss here.

The last sentence raises an issue that’s going to become more and more apparent as this project moves on.

Basically, I’m at a point where the stuff I’m working on directly affects how the game will play. Its the actual game mechanics as it were. The thing is that my game mechanics contain much that is unique. This leads me to a bit of a quandary.

Do I release information on this blog about the intimate details of the mechanics that will affect the final game-play? Or do I keep them under wraps until release? The creative side of me says ‘Yes – talk about it’, the business side of me says “No – Not on your Nellie’.

After much pondering I have decided not to publish any details related to the final game-play – that is until the game is ready. There will still be things to see and show in the blog, but for the core game-play elements, like for example the Orders System,  I have decided not to reveal them right now.

I’m sure that there are some people that will be disappointed, but I sincerely believe that my decision is for the good of the project. As already mentioned, there are/will be a lot of new and unique features going into the core game-play elements. I think it would be naive of me to publish details of these at too early a time. Rest assured, like the elements that you have already seen, many of these features are very innovative and will make Ancient Armies stand out from the crowd.

In many ways I’m disappointed that I cannot share my excitement with you over the way orders are modelled or the way the AI will be implemented. I hope that many of you will understand the reasoning for my decision and will stick around to see these features unveiled on final release.

Laters

RobP

The title pretty much says it all! Yes – Reinforcements have now been finished!

Achieving this involved integrating the reinforcement options with the 3d graphics. This is needed, as once a unit is selected to be a reinforcement, it should no longer be deployable on the map.

Initially I just programmed the scenario editor to hide units that have been made as reinforcements, but in the end I decided to ditch this solution and instead replaced it with one whereby a reinforcement unit goes transparent and becomes undeployable. Units already deployed will be moved back to the unit selection area off map.

The only problem at this point is that the current version of the graphics engine doesn’t support this! As a result part of my week was taken up with updating the graphics engine to allow it to support multiple levels of transparency for any object in the scene.

I decided that this was needed because the final game will support ‘Line-Of-Sight’ (LOS). The LOS system will ‘age’ a unit’s position information by making it more and more transparent depending on how recent the last report of its position was.

After the engine upgrade I decided to randomly alter various units opacity to see what it would look like in game. Here are the results (Click for a bigger image):

There are 5 units in the above image, each with different opacity settings.

With the transparency code in place I then incorporated it into the scenario editor’s reinforcement code. The result can be seen in the two images below. The first image shows the default setup of units when the scenario editor is started (click for larger image):

Next I allocate a number of units to be reinforcements. As a result of this the 3d view now looks like (click for larger image):

In the above image the units selected to be reinforcements are now made transparent. In addition to this, these units are no longer selectable.

Waving a mouse cursor over one of these units will update the status bar with additional information showing some of that unit’s reinforcement details.

That’s it for this week. My next task is to look at orders. This is a big task that I anticipate will take at least 3 weeks. As soon as I have something to show, I post up the next blog entry!

Laters

RobP

Work has continued this week on reinforcements. I’m not finished with them just yet – but I’m near!

The classes representing the reinforcements have been completed and the user interface stuff is around 80% complete. I suspect – unless I run into issues – that reinforcements will be finished by the end of next week.

For the rest of this blog entry I’ll take you through the current user interface design. As you will see, it is very different from the original. Bear in mind that all these screenshots are work in progress, so they may change as I finish off reinforcements.

To edit reinforcements one must either click the reinforcements section of the status-bar or click the relevant toolbar button or menu item. The first window that appears looks like:

As can be seen, reinforcements have been simplified somewhat! 

The dialog window now follows the design of the dialog windows in the Army Editor where one can Add, Edit and Delete from the top half and view the currently selected reinforcement in the bottom half.

Each side in the battle will have its own tab that is named with that sides army. The units list within the tabbed page will be colour coded to match the current side so as to ensure the user is in no doubt whose reinforcements they are looking at.

A game can have zero to many reinforcements and they are selected from the ‘Reinforcement’ drop down list.  There are currently no reinforcements which is why the window doesn’t show much. We are going to rectify this now by adding some reinforcements to the Persian side by clicking the ‘Add’ button on the Persian tab to reveal a new dialog window:

The above window allows one to define their reinforcement’s properties. Most of the settings are obvious. One of the changes instigated is that a user can now select one or more directions or ‘random’ (you will be prevented from selecting both) – this allows one to select a number of appropriate sides of a map that the reinforcements might appear on.

On the right of the window is a tree view showing the units that will be part of these reinforcements. Some of you may have noticed that this tree view looks like the one on the previous window – and you would be right! Both use the same custom control created especially for the purpose.

Editing the units that are part of a reinforcement is done by clicking the Edit Units… button which will display the ‘Select Reinforcements’ dialog window:

This window actually uses another custom control I have created called the Order Of Battle (OOB) control. I did this as the control has a lot of logic in it and I know that I will need to display a side’s OOB elsewhere in the application. Why write code more than once if you don’t need to?

On this filtered list, one simply selects the units that one wishes to include in ones reinforcements and then one just clicks Ok. This will update the ‘New Reinforcements’ dialog window to look like:

In the above screenshot one can see that the units list is now updated based on our selections in the previous dialog window. The display is a little different from an OOB display in that leaders are only shown – and named – as part of the unit they are in. This is partly done because it is very possible that a unit’s leader is already on the map, thus excluding the leader from being part of the reinforcements.

Now that I have filled out all the other fields as needed, I simply click Ok to take me back to the original ‘Reinforcements’ window that will now look like:

And that’s it! We have now defined a set of reinforcements for one of the sides! That simple!

There is still some more work to go on reinforcements as previously mentioned. I hope to get an update out next week to cover this.

Before I go, I’d like to thank the Spanish readers of this blog. I took a look at what sites had been visiting my blog and it seems that a particular Spanish Wargames Forum has been visiting it very extensively.

I’m guessing most of these hits have come from this forum post:

http://www.puntadelanza.net/Foro/phpBB3/viewtopic.php?f=37&t=10915

Alas, I can’t read Spanish(! – sorry), but the translation suggests that they like it but have concerns as to when the project will be finished. The game will be finished, as there are too many people both commercial and otherwise waiting for this game and I don’t want to let anyone down! Just bear with me on this as my programming team consists of just me and this is very much part time due to my real life job.

Anyways – See you all on the next blog post!

Laters

RobP

In the limited time I have available I have been chipping away at both Preferences and Reinforcements. The former is now complete, whilst the latter is still work in progress.

As usual with most things of a coding nature, what originally seemed like a trivial task – updating the preferences system – turned out to be a little bit more involved.

Not only would the new preferences have to take into account the graphics engine and army engine enhancements, it would also have to take into account that the Army and Scenario code now reside in library DLL files rather than Exes. This is done to allow for max reuse of functionality between all the applications in the suite.

In the end I produced a new class to handle all of this, but alas, come the test run there were a few issues. Some were down to simple bugs – eg ‘Why isn’t shadows switching off when I ask it to?’ , whilst other issues were a lot more complex, such as the graphics fixed function pipeline (FFP) not working quite as it should anymore. 

What is the FFP and why should I care?

The FFP is simply the default 3d graphics algorithms and pipeline that come with Direct-X. My graphics engine was originally designed primarily to use FFP for simplicity. However, recent graphics engine innovations have now led to the engine producing a lot of the scene graphics through custom shaders that do not use the FFP. One of the rendering tasks these shaders do for us, is that they draw the units themselves complete with reflections of the sky. Hence why I care!

However, I wanted to give the user the oportunity to disable unit reflections to get a higher FPS on low end systems or simply for personal preference. The easiest technical way to disable reflections, given the current code, is simply to switch to the FFP. I did this and got the following (click for a bigger version):

Can you see the problem?

Yes – All of the materials used in the construction of the units are tinged with blue.

But it’s a little more complex than that. Look carefully at the white writing on the Companion 2 unit – this is actually white – yet the ‘white’ body of the same unit is tinged with blue even though both use the same material!

Next I decided to alter the colour of the sun to deep red to see what materials are affected. I got this (click for a bigger version):

Again, rather weirdly, the lettering was dealing with the lighting correctly, but the unit bodies weren’t – despite both using the same materials!

Puzzling.

This one took quite a lot of thinking to sort out, but in the end the fix was very simple….

Basically, when I introduced shaders to the application I created my own custom vertex structure which unlike the old version now included a colour property. For some bizarre reason I had elected to default this property to full blue!  – I suspect something distracted me at the time – but who knows?! The reason why the units don’t appear as all out blue on the screen is that these blue vertex colours are mixed with both the material colours and any lighting colours – the end result being a pale blue wash.

The writing on the units still use the original vertex structures rather than the new custom one, so were unaffected by the above bug.

I changed the default vertex colour to something more neutral and dare I say more suitable and behold – the problem was fixed (click for larger image):

Excellent!

So now the user has the option to turn off unit reflections if they want to gain some FPS or if they just prefer matte units.

What other graphics options were added?

These can be seen in the screenshot below of the preferences window:

The preferences window is similar to the old one but has more options. In fact some of the additional options are not shown here as they are map editor specific and this screenshot was taken from the scenario editor.

Most of the settings are very straightforward and easy to understand. The only option that might need explaining is the ‘No of Tree Types’ option.

During testing it was discovered that it wasn’t the number of trees that slowed the frame-rate down. It was actually the number of tree types that caused potential frame-rate issues for low end systems.

This is because every tree type requires an additional render pass. So if one picks all 5 tree types the system is performing 5 render passes for the trees! Ouch!

That said, on most systems, on the majority of maps, the user will not notice any performance hit whatsoever. The hit only occurs on large maps with near 100% tree coverage on systems lacking a decent graphics card.

To show how the ‘No of  Tree Types’ setting affects the graphical quality I have taken 5 screenshots of the same woods from the same map – nothing altered except the graphics settings. The results are (click to see full-size image):

As you can see, changing the number of tree types doesn’t affect the number of trees displayed, just their diversity. This allows very low end systems to still sample the delights of big dense forests, but with a sacrifice of tree variation. This seems a much better compromise than just thinning out the trees.

I’ll finish this blog post with a composite image of how the game looks with both the lowest graphics settings and the current best graphics settings. Bear in mind that this image shows the two extremes, a user can tweak all of the options shown above to also get anything in-between. One should also consider that as the project proceeds other new graphical enhancements may well be added.

Click the image below to see the full-sized version:

As one can see, even on their lowest settings the graphics don’t look too bad – at least in my opinion!

I’m now off to finish the reinforcements coding, which should be the subject of my next blog update.

Laters

RobP

After a few weeks off - due in part to a lack of available time – work is now commencing again.

The first port of call was a project review. For the first time a schedule complete with estimates has been produced for the whole project. I decided to do this for several reasons. Firstly it would give me an indication when project completion will be and secondly it will enable me to prioritise work and make better decisions as to what is in and what is out for the first release.

Currently work is commencing on the ‘preferences’ subsystem and in the area of reinforcements – both of which need attention due to the updated graphics engine and the updated Army engine.

Much of the work at this point comes under the category of ‘under-the-bonnet’ stuff. As a result there isn’t much to show.

I fully expect that the majority of work from here on in to be under the hood – at least for the scenario editor, so blog posts will be less frequent to reflect this.

Once I get to the point where there is interesting stuff to show, I’ll post a new blog update.

Laters

RobP

A quick update on the tree front! Hopefully this will be the last tree update as I concentrate on another aspect of my mapping engine

Remember in the previous blog that I said that I couldn’t put trees on slopes? Not any more!

Here are two screenshots of the trees on slopes (click for a bigger images):

The routines will even work when hills or depressions are suddenly superimposed on existing forests.

Another feature of the tree allocation routine is that it can figure out the steepness of the slope. If its too steep, the trees will simply refuse to grow there. See the image below for an example (click for larger image):

Here we can see that the trees have refused to grow on the steep hill sides at the edges of the map!

Finally I have incorporated routines to prevent trees appearing in water. If water is drawn over an existing forest the forest will disappear. However, this part of the system is designed so that if the water is replaced with terrain, the woods that were at that location will make a reappearance!

An example of the tree water detection routines (click for a larger image):

Here I created a small woods and hill, then arbitrarily ran a river through it. As you can see the trees performed admirably, by not being where the water is!

My intention is to knock trees on the bark now and start work on the next of 3 features that I have also wanted on the map. You will have to tune in next week to find out what these are!

Laters

RobP

I wasn’t originally going to post again this week but here goes!

Before we start, I will run a spot the difference competition. Have a look at the image below and tell me if you can see any differences between that one and the similar ambush image in the previous post (click for larger version):

See the difference?

What if I zoom out a little?…

To use a famous Rolf Harris quotation: ‘Do you see it yet?’

Hint – look closely at the trees…..

Yes! – the engine now supports multiple tree types. I decided to do this to make the forests less uniform and a little bit more like forests.

The current system supports up to five different tree types in one scene. The downside to all this is that the frame-rate can take a bit of a hit when you have as many trees as the above map has. However, this won’t be an issue as the majority of maps will not be impacted and the map library provides a means to alter the number of tree types rendered from one to five and will populate the map accordingly.

This will allow players and the designers to tweak the tree type count to a level that is appropriate for their machines and the current scenario being played.

The differences in visual quality can be seen by looking at the next four screen shots from the Granicus map. The first screenshot is with the original singular tree type forests (click for larger image):

This next shot is the same map, at roughly the same view with all five tree types activated (click for larger image):

Hopefully you will be able to see the difference. I personally think the multi-tree image looks better.

Up close at soldier level this forest looks like the image below for the original singular tree types (click for larger image):

The same forest with multi-tree types enabled (click for larger image):

Again, I prefer the lower multi-tree image. That said if a user preferred the single-tree type forests, they can just turn down the detail settings to one tree type only.

Finally, I also managed to include localised trees based on the terrain type. The screenshot below shows what they look like for a desert terrain (click for larger image):

Much more in keeping with the terrain!

Well, that is definitely it for this week as I’m going to be chilling tomorrow. See you next week!

Laters

RobP