Progress on Barren Planet and the Wargame Library

Saturday, 26th September 2020

I've made quite a lot of progress on the wargame library since I last posted about it. The four basic modules are complete and tested: unit types, terrain, individual units and the map. Each module has all the code to manipulate, load and save the associated data. The capabilities are the same as the old Psion game, with a few exceptions. Previously I discussed the removal of hard limits on unit and terrain types, and a more fluid treatment of battlefield map dimensions.

I've also changed how terrain protection worked; that is the amount of protection terrain can give to units. On the Psion games, it was a blanket figure for each terrain type. This led to some unrealistic effects. Forest, for instance, had a high defence bonus for units stationed there. But this also meant that two aircraft flying above would also benefit from that protection. I've changed the system so that each terrain type has a terrain bonus for each unit type (which could be none).

The module I'm working on at the time of writing is the battle module. This holds information about the current state of the scenario: what resources each player has for production, what units can be produced, and the current state of the map. More may be added to this. The Psion games also stored this information, but I've made quite a few changes here.

Firstly, starting resources and turn-by-turn income are not handled by the library. These will be the responsibility of the host game. Only the current resources of each player are counted, and the host game may initialise these and optionally increase them during the battle according to the game's campaign model.

Secondly, the Psion games had a simplistic approach to production in each scenario. Either you could create units or you couldn't. Either you could restore units or you couldn't. The new library will have a list of units that can be created during the battle. You will still have to have a unit on the battlefield that creates these units. Restoring units won't depend on this list, so you'll still be able to repair units that were given to you at the start of the battle, even if you can't build new ones.

This will allow unit types to be introduced at an appropriate point in the game. Players (human or computer-controled) can be prevented from creating and deploying those units before the proper time, which is especially useful for story-driven content. Because the host game is in control of the economy, rather than the library, it also gives more possibilities for income generation. For example, a game might just dump all the income on the players at the start of a scenario. Or it may have income during the battle based on occupation of key resource-generating locations.

I'm developing a demonstration game for the library. It doesn't look like much, but it does allow the capabilities to be tested. The library is designed for use with any operating system, so the demonstration game lacks any graphics. It resembles an old teletype game, where maps and stats are printed on a scrolling text display, and the game is played with simple text commands.

As as occasional break from coding I've been mocking up a screenshot for the jam game, which I present at the top of this post. Things may still be tweaked when I begin development next month, but the screenshot gives you the overall look of the game. The colour palette is quite conservative but I think it suits the theme of the game very well; had the CGA hardware allowed me a free choice of any four colours then I might well have chosen these very colours!