About RobP

Got into backpacking in the spring of 2012. I started as a couch potato then made my way through walker, hiker and now backpacker! As you can see from below I have far too many hobbies! :)

A Wee Bit of Engineering!

Warning! Engineering Construction!

Warning! Under Construction!

Over the past two weeks I have been conducting a great deal of engineering work on Ancient Armies to get it ready for the implementation of column movement.

It all started when I was looking at a bug with the fatigue system. This is the bug that my new telematics system picked up a few posts ago where fatigued units were not regaining their freshness after exertions.

Whilst probing around the fatigue system I was horrified by the fact that the code for it seemed to be literally everywhere! Having the code for a single subsystem littering an entire game can make it very difficult to understand, debug and can of itself cause many other engineering problems further down the line.

An inspection of the cohesion subsystem revealed a similar issue. :/

I was mortified. I’m typically very hot on software coupling and cohesion. I guess it was just the way these two subsystems had evolved over time.

In the interests of simplification and maintainability, I decided to completely refactor both of these subsystems so that they are both located in one place within their own respective classes.

Doing this was a non-trivial affair, it involved grabbing bits of code from all over the system and moulding them into a singular coherent class.

It took a fair bit of time but the rewards have more than made up for it.

For a start, it made fixing the fatigue system incredibly easy:

Fatigue goes up, fatigue goes down! (click for larger version)

Fatigue goes up,  fatigue goes down! (finally!) (click for larger version)

For the first time, fatigue in the game is now being recovered properly after a unit’s exertions. The screenshot above shows the game providing real-time data to my telematics application on the right. This shows two units exerting and then resting with their fatigue levels doing exactly what I expected them to!

The telematics application has been a God-Send. For a start it originally discovered this issue, something that would have been very difficult to spot with standard tools. But more importantly, it also easily verified that my fix was working!

To try and prove this code fix was working from within the code editor would have been a tedious and time consuming affair. But with telematics, it is as easy as running the game and viewing the results!

The telematics system also came to the rescue with cohesion too:

The telematics application lending a hand in diagnosing a cohesion issue. (click for larger version)

The telematics application lending a hand in diagnosing a cohesion issue. (click for larger version)

After the refactor of the cohesion subsystem, the graphics weren’t showing a unit’s cohesion levels properly. A quick run up of the telematics application proved that there was nothing wrong with the underlying modelling and that it was in fact an update issue to the graphical subsystem!

Again, without telematics, this would have taken much longer to determine as it would have been difficult proving that the cohesion system was working properly over time.

The other tooling to provide great assistance was my new automated build process – as introduced in the previous blog entry. Seeing the installers magically appear on my NAS drive after committing code never grows old. Nor does being able to tell exactly which version of Ancient Armies I’m running! Both of these seemingly small details, go a long way to making the job of cracking bugs a lot easier.

Although the refactoring of the fatigue and cohesion subsystems took two weeks, it leaves the software in a much better state.

For a start, all the complexities of cohesion and fatigue modelling are encapsulated and hidden away within their respective classes. None of the rest of the system needs to know how they work. Even when I’m calling these sub-systems, I no longer need to memorise how they work as it is all nicely tucked away.

When other systems within Ancient Armies call fatigue and cohesion, they can now ask simple questions like, is a unit fatigued? or exhausted? and they can do so without having to do any of the sums themselves. This helps to simplify the code and to ensure that one achieves consistent results throughout the game.

The other big bonus from the refactor, is that if either sub-system needs tweaking in the future, I know exactly where to go – they are both housed in their own files. More importantly, I only need to learn what the code is doing in that one file to fully understand the subsystem. This is far easier than traipsing through the entire game’s codebase trying to work out what’s going on!

Finally, in what seems like a long journey, I am now in a position to start work on column based movement. So tune into the next post to see some of the early results from my efforts.

Laters

RobP

 

Welease Wodewick!!!

Things have appeared quiet over the last few weeks, but in reality I have been hard at work in a special kind of hell normally reserved for Dev-Ops type people.

I was going to be using my time fixing bugs and getting Ancient Armies ready for the next stage of development. However, I kind of got myself side-tracked….

I had always known that my development environment lacked one very crucial piece of functionality…

The ability to create reproducible and traceable builds along with their associated releases.

Up until now, if I wanted a release, I would fire up Visual Studio and hit build. Next I would run the installer for Ancient Armies, then away I went.

However, this process had a number of issues:

  • I could not reliably reproduce an exact build or release from the past.
  • I didn’t really know what code changes were in my releases.
  • Ancient Armies itself lacked any formal version numbering – which exacerbated point number 2 above.

All of these issues are critical. If one does not know which code changes are in a particular version of the game, then one cannot test the game.

To resolve the above, I decided that I would create an automated build and release management process. After a little research and a personal recommendation, I decided to integrate a tool called TeamCity into my development environment.

What does TeamCity actually do?

A build from within the TeamCity tool.

A build from within the TeamCity tool.

It allows me to configure and manage the build and release process. With it, I can build a particular version of Ancient Armies, automatically obfuscate the binaries, create installers, run automated tests and then deploy the installers to my NAS system!

That’s a bit of a mouthful!

The best part is that it all happens automatically the minute I commit anything to my remote master. It’s like magic! Write some code, commit it, wait around a minute or two, then miraculously I have a new build directory created on my NAS drive complete with an obfuscated and unobfuscated installer – all this without lifting a finger! 😎

Having the ability to be able to instantly recreate any version of Ancient Armies cannot be underestimated and will be especially useful during the Beta phase of development.

TeamCity also integrates exceedingly well with my JIRA issue tracking system:

The TeamCity dashboard in JIRA.

The TeamCity dashboard in JIRA.

In the above screenshot I can instantly see that I have built 20 versions of Ancient Armies, of which the last two builds went well. I can even click on the individual blocks to get detailed information with regard to each build.

The key principal with these builds and releases is that they are versioned. In the above screenshot, the current version is build number 20. This allows traceability through issues, code and the final finished components.

TeamCity also integrates tightly with JIRA issues:

The new Team City fields in Ancient Armies' JIRA issues.

The new Team City fields within Ancient Armies’ JIRA issues.

In this case, I can see that this fix (AA-230) went into build number versions 10 or later. This means that I now know precisely which versions of Ancient Armies have this fix in! And more importantly, which versions do not!

The new functionality also allows me to kick off a build from here, or to initiate one when the issue is closed or resolved.

All of this was simply not possible before.

I can even view the specific builds that incorporate code changes from the issue being viewed:

The TeamCity tab shows all the builds that incorporate changes from the parent issue.

The TeamCity tab of the JIRA issue shows all the builds that incorporate changes for that issue.

The versioning created by the build process automatically flows through to the installers and then on to the final components. The screenshot below shows the file properties for the Ancient Armies game executable:

File properties now display the file version number from the build.

File properties of the game components now display the file version number from the build.

From the screenshot above I can instantly see that this version of the game was created by build number 20!

Prior to the introduction of this release system, I would have had no idea which version this executable was, or which fixes were incorporated into it – all versions of the game were statically fixed to version 1.0.0!

In addition, the game itself is now aware of its new auto-generated version number:

The about window from the Ancient Armies game.

The about window from the Ancient Armies game.

Just by viewing the About Window for any part of Ancient Armies I can immediately see the dynamic version number for that component. In this case it originated from build number 20.

When it comes to testing, any issues found can now be reported against a very specific version number. This number can then be used to determine which changes went into that release so as to target any diagnostic work.

This all sounds like really good stuff, but there was a rather large fly in the ointment…

It turned out that the installer technology that I was using for my game could not be built by MSBuild. As a result it could not be incorporated into the build and release process. This is a huge flaw. It’s fine having an automated build and release process, but if you cannot build and release the installers for the game, you are pretty much wasting your time!

I was a little shocked. I was using Microsoft technology in my installer, so the last thing I expected to be doing was re-writing it due to future incompatibilities.

There was a hint of trouble ahead from within Visual Studio 2015 itself. Its complete lack of native support for the installer technology that I was using should have rang a few alarm bells…

I searched high and low for a replacement technology. I had found that most commercial installers can cost upwards of £500 and were usually priced in the thousands! Far too rich for my pocket.

In the end I did find an open source technology, one that is even used by Microsoft itself: The WiX Toolset.

This toolset is a double edged sword. It is exceedingly powerful – much more powerful than the technology that I was using, but alas very complex and lacking any kind of wizard or UI design tools. Everything is done by creating low level XML code  – not exactly very friendly!

I found myself continuously banging my head on the wall trying to bend the WiX Toolset to my needs. Even the simplest of tasks devoured a disproportionate amount of my time. In addition, the whole toolset follows a multitude of hidden and non-obvious rules, all of which are set to trip-up the unwary.

I think it would be fair to say that the WiX learning curve was exceedingly steep and incredibly precipitous. In retrospect I might have picked a simpler toolset like Inno, but alas, we are where we are…

With much persistence and having written nearly 400 lines of XML code, I now have a world class installer for Ancient Armies. More importantly, this installer can now be built from the command line, which means that it can be incorporated into the automated build process.

Over the next few screenshots I will take you through the differences between the old and the new installers. The old one is on the left, whilst the new one is on the right.

First up, the introduction page:

The introduction page from both installers.

The introduction page from both installers. (Click for larger version)

Straight away one can see that the new installer on the right looks much more like a standard installer. In addition, and rather importantly, it automatically picks up the build version number from the build process. Here we can see that it is the installer for version 1.0.0.20 of Ancient Armies. This build labelling was simply not possible with the older installer on the left.

Incidentally, the rather alarming legalese text at the bottom of the old installer is not mine, it’s automatically incorporated by the installer itself with no option to turn it off.

Next up is the licensing page:

The licensing page from both installers.

The licensing page from both installers. (Click for a larger version)

There isn’t much of a difference here other than the ability to print the license agreement on the new one. The new one’s title bar also indicates the specific version of Ancient Armies that is to be installed.

Clicking the next button results in the options screen:

The options page from both installers.

The options page from both installers. (Click for a larger version)

Here the differences are very pronounced. The new installer on the right is much more advanced in that it allows one to pick exactly which components are to be installed. In this case, the Main Game (not optional), the Editors and/or Telematics.

The older installer is an all or nothing affair – you cannot choose your components.

Clicking the next button takes you to the pre-install screen:

The confirm installation page from both installers.

The confirm installation page from both installers. (Click for a larger version)

Here, both installers are very similar, though the new one on the right makes it absolutely clear that you are about to perform an install and it warns you that Admin privileges will be requested by the icon shown on the button.

Clicking next takes one to the installation itself:

The progress page of both installers.

The progress page of both installers. (Click for a larger version)

The new installer on the right wins again. Its progress information not only shows a progress bar (not currently visible), but it will also tell you what it is doing at any particular time. Alas, it runs so quickly that I couldn’t capture this. In addition, its progress bar takes third party installations like Direct-X into account.

The old installer on the left provides no real feedback other than progress and even this is flawed as it always hangs at the end whilst Direct-X and other third party software is being installed.

Once the installations are completed one is taken to the final screen:

The final page from both installers.

The final page from both installers.

Note that the new installer on the right tells you precisely which version of Ancient Armies you have just installed. This is simply not possible with the older one on the left.

In addition, if one looks at the Windows Applications Management Window, one is now presented with the version number there too:

Windows Applications now shows the correct and dynamic version number of the game.

Windows Applications now show the correct and dynamic version number of the game.

As a result one is never in doubt as to precisely which version of the game is installed.

Writing the new installer using the WiX toolset took an inordinate amount of time and effort. Despite the frustrations, I think the end result was worth it.

I now have a modern contemporary installer that can pretty much do anything.

However, the real story here is that I can now produce automated builds and releases from end to end with dynamic version numbers incorporated into all the finished components. This new capability should not be underestimated!

Had the old installer technology worked with the build process, the whole build and release process would have been configured in a matter of hours. Instead it took me around two weeks of continuous tweaking, two weeks that could have been spent coding.

This is the one downside of home development, one has to wear many hats and be multi-skilled. These additional hats can and often do take one away from the core software development effort. The only silver lining, is that from a professional standpoint it does make me a well rounded developer.

Whilst I’ll look back at this period of development work as not particularly pleasant, at least it is now done and dusted. Time to look forward to some real game development!

Laters

RobP

Telematics – Done!

It's Magic!

It’s Magic!

This is a relatively short update post.

The photo above shows the end result of my work on telematics. Here I have a game running on my Surface Book laptop on the left, whilst my Surface Pro on the right is picking up that game’s internal data in real-time! 🙂

As a result I’m a very happy chappy!

I can now run with two machines, with one of them configured to show me realtime data feeds directly from within the game itself. This will reduce by a significant order of magnitude the amount of time that I will need to invest in future debugging endeavours.

The finished application.

The finished application.

The finished application has had a lot of additional functionality added to it to allow one to pan and zoom around the data – hence all the additional buttons.

It’s underlying protocol has also been switched from Named-Pipes to TCP/IP. This change proved to be remarkably trivial thanks to the way I architected both Hermes (the communications layer) and the Telematics solution itself.

In terms of project time, I pretty much hit the nail on the head too:

Not bad.... Only an hour out...

Not bad…. Only an hour out…

The original estimate was for 1 week of development, the actual time taken was one week plus 57 minutes. As estimates go, that was a good one!

I’m now in a good place with regard to communications. I quite literally have the technology to code the multiplayer functionality that I want to add.

So where now?

The next phase is bug fixing. This will be a few weeks of relatively-boring-but-has-to-be-done-fixing and architectural tweaks.

Once complete I will make a start on the mythical column movement.

I will see you then!

Laters

RobP

Telematics – Courtesy of Hermes!

Telematics Baby! (Click for full size)

Telematics Baby! (Click for full size)

Last week I alluded to having to write a new telematics system for Ancient Armies.

Well, it’s now here, mostly….

The screenshot above was taken from the new telematics application. It can connect to any game running on any networked machine and provide real-time graphical detail with regards to the multitude of hidden variables within the game.

Below is a screenshot of the game that was sending its data:

The scenario that's sending its data.

The scenario that’s sending its data. (Click for full-sized image)

You will need the eyes of an eagle-hawk, but the only noticeable difference between this game window and the older ones is the new telematics button on the far right of the main toolbar.

This button is normally hidden by default. To show it and gain the use of telematics one must first go to the options screen and pop across to the new Telematics tab:

The new telematics tab!

The new telematics tab!

This tab allows one to enable telematics and to pick the machine that the telematics application resides on. I have greyed out my machine names as I don’t want the internet to know the names of my local computers.

Once enabled, the telematics button becomes available on the main menu. Simply click this to allow the automatic sending of data.

If the telematics application is not running whilst the game is sending data, this is not an issue. The system will simply wait for the telematics application to start then automatically send the backlog of telematics data. In the meantime, one can carry on playing!

This new feature brings a lot to the table. Firstly, I can now see what’s happing in every unit on the battlefield, all in realtime! Being able to see their variables changing over time allows me to spot bugs easily and to check that the modelling is working as expected.

In fact this system has already found its first issue. If you look at the first screenshot at the top of this post you will see the cohesion (orange) and fatigue (blue) levels for all the units in the scenario over the first turn.

One thing I noticed is that for some orders, the units were not recovering from their exertions. Such an issue would have been very difficult to spot without this tool and may well have gone unnoticed whilst introducing many subtle issues.

The other thing that this system brings to the table is Hermes.

What’s Hermes?

Hermes is my new communications layer for the game. In fact, like Chronos and Atlas before it, it has been made generic enough that it can be used for any game or program.

The best thing about Hermes is that it hides the complexities of low level communications thus making it very easy to use. It also allows one to use a variety of low level protocols (simply inject them in), all whilst presenting developers with the same simple to use interface.

As expected, Hermes also handles all the other issues normally associated with communications, such as multi-threading and queuing. All in all, a very powerful system. 😎

In terms of the game itself, having Hermes in place means that multiplayer gaming is now a possibility – I just need make use of the technology that is now there!

However, there is still more work to do on the telematics system. My expectation is that I will be finished by the end of next week.

Time on Telematics!

Time on Telematics!

In fact my JIRA system says that I have just over a day’s worth of additional development to do – assuming my estimating was good. That’s after having invested nearly 4 days of effort into this system – 4 days well spent in my book.

I’ll leave you with a video showing how this new system works. Enjoy!

Laters

RobP

Chasing the Bugs!

A lot of bugs have been squashed - but a lot of them have also been discovered...

A lot of bugs have been squashed – but a lot of them have also been discovered…

As mentioned last week, my primary aim is to get the system into a relatively bug-free state prior to adding new functionality. The graph above shows that I fixed quite a few this week, but I have also discovered quite a few too.

Although no closer to starting the column movement code, it is still a good position to be in as I now have a system that has 13 fewer issues in it. Alas, not all coding can be glorious and exciting new functionality!

Most of the work that took place this week occurred in the Armies module – the module that models all aspects of units and armies.

The first ‘issue’ was this one…

Issues orders to cavalry units…

Starting positions for the default cavalry units.

Starting positions for the default cavalry units.

Runs a 30 second turn and ends up with:

Errr.... What happened?

Errr…. What happened?

The units didn’t exactly move very far…

These kind of bugs can be quite hard to find as the system keeps track of a multitude of variables for each unit. These variables can be hard to follow because the system runs multi-threaded.

Luckily, one of the pieces of work that I also did this week was to update the formation classification system to bring it up to date with the current modelling.

The classification system puts a symbol on a unit to tell the user whether it is Open Order (OO), Order (O), Close Order (CO) or Dense (D). The idea being that a player can instantly see how tightly packed a formation is – something that would be impossible to tell just by looking at the unit.

This subsystem was very old and didn’t reflect what was really happening. However, this was rectified, resulting in units being properly classified.

That said, I should probably point out that the game does not use this classification – it knows a unit’s precise measurements – the classification is solely a player aid only.

In my case, the classification helped track the issue above…

Ah... That would be it...

Ah… That would be it…

When I zoomed in onto one of the cavalry units I saw that its density classification is ‘D’ or dense. That would explain why the units were having problems moving!

These units were created very quickly using default unit sizes, formations, frontages and densities. However, it would appear that these defaults don’t give you units that function well…

This defined my next task:

‘Update the defaults to generate units that function correctly when created!’

The result:

Starting positions with the new unit default sizes...

Starting positions with the new unit default sizes…

Note the defaults have made the cavalry units a lot larger. Ok, lets run a turn and see how they perform…

That's more like it - there was actually some movement!

That’s more like it – there was actually some movement!

Bingo! All sorted….

Well almost….

The problem with the new defaults is that they highlight just how large the unit size variations can be. Alas, the Army Editor’s display window just couldn’t cope with some of these new sizes:

Oh - that doesn't look right...

Oh – that doesn’t look right…

Damn! I’m missing a fair bit of the unit. Creating a Chariot unit results in the whole screen being filled by part of that unit! Not good at all.

Conversely, small units like a Roman Maniple became very small and difficult to see.

To fix this, I altered the code in that pane to automatically zoom the camera to properly show off the chosen unit. This code was not trivial as one has to work out apparent sizes in metres based on the camera distance.

Nevertheless it got fixed:

Much Better!

Much Better!

Perfectly zoomed!

Even small units are now zoomed correctly:

Even the tiny Maniple is now scaled appropriately!

Even the tiny Maniple is now scaled appropriately!

The eagle eyed amongst you will have noticed that the window also gets a new scale in the bottom left so that users can more easily determine the size of a unit.

Fixes to tooling might seem a waste of time, but these tools are used to create the game assets – they will also be distributed with the game to allow players to create their own maps, units, armies and scenarios too….

Going back to the loaded scenario, I noticed another potential issue:

Classification 'O' (Order) - Really? A Macedonian Phalangite?

Classification ‘O’ (Order) – Really? A Macedonian Phalangite? You are kidding?

I thought ‘Oh No – the new classification system is broken already.’

Based on general wargamer bias and expectation, the Macedonian unit seemed to have an incorrect classification. Such a unit would at least be close order, if not dense!

However, after doing my research, I have discovered that this is in fact correct!

This is the default phalanx formation at 16 deep. The Macedonians didn’t even give it a name, because it was the ‘standard’ formation. However, some texts do refer to this formation as the Open formation!!! Woot! My system seems to have classified correctly!

If the above unit closes down to the 8 deep Pyknosis formation, as used prior to contact, the result is:

Pyknosis - classified as CO (Close Order) - Breaths a sigh of relief!

Pyknosis – classified as CO (Close Order) – Breaths a sigh of relief!

CO!!! Perfect. Closing the formation down further to the 4 deep Synaspismos results in the system correctly classifying it as ‘D’ or dense.

Of course, when I did my first formation change, I noticed a bug where the visible model’s density classification was not being updated. But this was a trivial issue and easily fixed.

So what’s planned for next week?

Well, I now have two big issues I need to look at.

First up is the text on the units. These don’t seem to be created at the correct sizes anymore. The font is either too small on large units, or too large on small units. I suspect that this is due to Windows 10 DPI scaling – most machines seem to be set to around 150%.

Fixing this issue will be difficult, but it is one that will need addressing as the unit text is the system’s primary way of communicating unit information to the player.

The next issue is related to the potential ‘bug’ described at the top of this blog entry….

It seems that Ancient Armies has got to the point where there are many subsystems acting on each unit. These affect a multitude of hidden variables with results that sometimes seem counter-intuitive – like in our example above.

However, debugging these issues is difficult as one really needs to see these variables changing over time to fully appreciate what is happening and why. This is made all the harder by the game being multi-threaded.

Luckily, Ancient Armies already records everything, all thanks to Chronos that was fitted last year. So the information is available, I just need a way to display it.

So one of my next tasks will be to create a debug monitor application. One that I can run on a separate computer that will monitor the game running and display graphs and debug information for each unit.

This will be a non-trivial task that will take a fair bit of time to complete. At first, this might seem to be a frivolous thing to do, but it will save a lot of time in the long run. This is because with such a tool I will be able to see what’s happening inside the units in realtime so that I can assess whether what I’m seeing is intended behaviour or not.

Going forward, the system will only get more complex, so a monitoring tool like this one will become critical to speeding up development.

So that’s my tasks fixed for the next few weeks! Sorry column movement, I will visit you eventually! Honest!

Laters

RobP

 

Back on the Horse!

The new workplace!

The new workplace!

I’m now back coding and designing Ancient Armies!

To aid with the ongoing development I bought myself a new development machine – A Microsoft Surface Book. This replaces my now deceased Apple Mac Pro.

I chose this machine because I was very impressed with them at my workplace. Plus having the ability to draw directly on the screen is essential for visualising the many geometrical problems that I have to overcome.

The fact that the screen also detaches from the keyboard to form a tablet is a bonus! All in all a very flexible machine!

So what have I been up to so far?

Firstly I spent 2 days designing how I was going to implement column based movement – both on road and off road. I also took additional time to design how movement orders will work for indirect orders – ie the orders you send by herald as opposed to direct command.

This is now all documented and safely stashed away in my Confluence system.

During the code research for the design work, I noticed that a few classes had got a little too big for their boots – yes Game I’m looking at you! As a result I invested some time to refactoring these so as to maintain a high level of code cohesion.

Refactoring is a perfectly normal activity and generally happens as a system evolves and takes shape. You can ignore the need to refactor, but you do so at your peril! The result can be an unmaintainable mess of code.

Although the design work for column based movement is now done, I will not start this new functionality until I have cleared down the backlog of bugs and issues that are still outstanding.

One issue I wanted to sort out straight away, is that I didn’t like the way the system automatically let the user side-slip a formation left or right. So I have modified the system so that the player must now make a conscious decision to side slip. This is achieved by simply holding down the side-slip key (currently mapped to left-shift), whilst issuing the orders.

If the side-slip key is not held down, the system will prevent the unit from side slipping.

In terms of bugs, the first one I ran into was this one:

Where did the overlay go?

Loads Desert Map…. Where did the overlay go?

Believe it or not this is the desert test map, which should normally look something like this:

A unit side slipping to the right...

Desert overlay in place!

It turned out that my overall approach to map overlays was way too simplistic. It failed to adequately accommodate the movement of files from system to system.

This bug only got discovered because Windows 10 on my new development machine gave me a different username from my other machines.

On the plus side, the system did fail gracefully – it loaded the map, but sans overlay. It was close, but no cigar!

The new overlay system is now much more robust.

When overlays are added to a map they are now imported into the system as opposed to merely loaded. Of course this in itself is complex as you need to be able to differentiate between images that are new and those that are already imported. Plus the system also needs to deal with the possibility that two different overlays may well have the same filename…

However, don’t fear! This has now all been taken into account and the system has been thoroughly tested.

So what’s next?

As mentioned above, I want to clear down the backlog before starting on the column movement functionality. There is a fair bit of work in there and I can see it potentially occupying a fair bit of my time.

If the bugs I’m fixing are relatively interesting, I will put up blog posts up about them. If not, you will probably hear from me in a few weeks time when I will declare that the backlog is empty!

Laters

RobP

 

Spot the Difference!

Things have been a little quiet around here.

The following photos may provide a clue as to why….

After...

The now…

Notice anything odd in the photo above?

No?

Then check out the one below:

Before...

The long gone past…

If you haven’t got it yet, I’ll spill the beans.

Basically, my development machine has finally stopped working. It was a 2009 Apple Mac Pro. This is an expensive machine and one that’s completely uneconomical to repair.

I had a love-hate relationship with that machine. It suffered from many issues including overheating and a display that could best be described as temperamental. But I did enjoy the earlier editions of OSX, that is until Apple dropped the ball with the most recent releases.

It gave around 7 years of sterling service before finally succumbing to its fate.

In terms of Ancient Armies, no source code was lost as this is stored on a separate RAID NAS drive system. In retrospect this was probably one of the smartest moves I ever made. If I hadn’t moved the source code, we would be in a bit of a pickle right now.

The only real issue is that my JIRA, Confluence and Fisheye servers were located on the Apple Mac. These are the primary management tools that help keep track of the project and its documentation.

My original intent was to wait until I got a replacement machine as I didn’t want to develop on my games machine. However, I have now decided that the games machine will just have to do!

The hard part of getting JIRA, Confluence and Fisheye transferred from the old hard-drives to the games machine took a little imagination and a not inconsiderable amount of time. However, I can now declare that these systems are all safely running on the games machine with no loss of data. 😎

So where does this leave the project?

With Christmas coming up, I have decided to schedule a restart in early January. So have a Merry Christmas and a Happy New Year everyone. I’ll see you all, bright and bushy tailed in the New Year!

Laters

RobP