The screenshot above shows a number of semi-historical units in a mock battle to test how the system can deal with many units. It’s not the largest battle in the world, but it is a lot bigger than the ones that I have been testing up until now.
With this many units in play and moving about, there was a negative effect on framerates.
I can probably perform more optimizations to make things liquid smooth again, but I now think that the time is right to implement my fall-back plan *Muhahaha* 😈
Many of you know that the system runs using 30 second real-time turns. Some of you might have been wondering why I had gone down this design route instead of making the game fully real-time?
Well here are the answers:
- I wanted a game that could easily be played by email – a popular means of playing wargames on the internet.
- I also wanted to provide a back-up plan for potential future performance issues…
Answer 2 probably needs a little more elaboration.
Real-time games have one technical disadvantage, they are constrained by the fact that all the game calculations have to be performed at least 60 times every second. As a result each set of calculations must be finished before its 16 millisecond slot elapses.
Calculations can take longer, but at that point they will start to negatively impact the game’s frame-rate. Either that or the calculations will start to introduce significant lag to the gameplay.
Another obvious side-effect of this technical limitation is that it will ultimately restrict the maximum size of the battles that you can run before the system starts slowing down to a crawl. More units always equate to more calculations…
By designing the game with 30 second game turns, it has provided me with a fallback option of performing all the calculations for a turn up front. This will however result in a progress bar appearing with the words ‘Thinking…’, just before each turn starts.
I believe that this is a small price to play to enable one to have battles of any size and to allow one to have more leeway with regard to the calculation timings.
In fact, it will allow me to add complex Artificial Intelligence (AI) routines to the game without having to run into the 16 millisecond constraint. Of course, I can’t go completely nuts, as no one wants to wait for an hour whilst the computer works out the next turn! 😛
Having a progress bar between turns also has the advantage that it provides a cue to the user that they are about to switch from planning to operations – something that’s not readily apparent right now.
To implement the above system properly will be technically challenging, especially as I see it as an opportunity to add replay functionality to the system. Replays would essentially be leveraging very similar functionality to that used for a pre-processed game turn, so I might as well code the system so that it does both.
The upshot of this is that the next tranche of work is going to take longer than usual, as a result the next update on this blog may end up being some time away. But do not fear, I will be beavering away!
Before I go I’d like to thank ‘roaming111’ who has been submitting these blog posts to reddit, where they have been reaching number 1 on numerous occasions 😎
I will leave you with a few more screenshots of the semi-historical units that were used for the current round of testing: