Barren Planet: The Process

Tuesday, 25th July 2023

Bringing all the features together for Barren Planet ended up taking over two years. This included breaks due to burnout, ill health, and the occasional break for short jam projects - projects that actually did turn out to be short, unlike Barren Planet!

The project began with a library for the game mechanics. On the Psion these were integrated tightly into the game, and reusing the mechanics in successive games meant deconstructing and reconstructing a game around them. With the compiler tools available to me on the PC I decided that keeping the game mechanics in their own library would make it easier to build varied games around them. The library would include no AI at this stage, but did include a simple 2-player demonstration battle played with a rudimentary scrolling text interface. The demo battle was enough to test the code during development.

Then came Barren Planet itself. I planned out a kind of storyboard of how the game would play, and what information and choices would be presented to the player at any particular time. That allowed me to draw the assets, starting with screen mockups and then extracting the various user interface components from these mockups. I adopted the units and terrain from the earlier Psion game, and drew the assets for those too. With the assets drawn I created a utility that packed them into a data file that could be loaded in the game. Then I started on the game proper, with routines to load in these assets and display the title screen.

With the planning and the assets in place I could start with some of the classes used in the game. Although written in C, a procedural language, I use an object-oriented approach, with classes and objects used for such things as a game in progress, a campaign, a scenario, a turn report. The code for handling these things was developed first. I then created a utility that allows me to define a campaign and its battles as a text file, and creates a campaign object from the text file.

Then I implemented a few of the user interface screens: the new game screen, briefings, player turn, debriefings, and the turn report. These screens brought everything together into a working 2-player game. I could finally play the game in me-vs-me and me-vs-friend battles to check that the game mechanics and user interface functioned properly. Around this time, the sound effects were created.

Then came the PBM feature, which I tackled before the computer player because I knew it would be the simpler of the two. It turned out to be a bit more complex than I had envisaged, especially in trying to make the process as foolproof as possible. But once done, the me-vs-friend battles became easier to test.

The biggest challenge was the computer player. A lot of logging was needed so I could analyse the decisions that the computer was making. First I implemented the identification and ranking of targets. Then came the allocation of computer units to those targets. Then, the mobilisation, where the computer's units moved and dealt with those targets. The interface for the computer player was minimal, because I decided to show the computer's moves using the turn report that's already used to show the enemy's turn in 2-player hotseat and PBM modes. This meant I didn't have to also display unit movements while the computer was playing.

Alongside all the program development, the First Landing campaign was gradually built up a scenario at a time. Once the whole campaign had been created, I write a utility to test the balance of the campaign. This utility plays a specified battle through ten times in a computer-vs-computer match, without showing the moves on the screen. At the end, it reports how many times each side won. Any figure close to 5/5 means the battle is balanced.

At the end of this two-year journey there was some tidying up to be done. The title screen was finished, and some music was added. The game was now ready for the beta testers.