• android (3)
• battle-for-the-solar-system (10)
• blob-wars (10)
• brexit (1)
• code (6)
• edgar (9)
• games (43)
• lasagne-monsters (1)
• making-of (5)
• match3 (1)
• numberblocksonline (1)
• orb (2)
• site (1)
• tanx (4)
• three-guys (3)
• three-guys-apocalypse (3)
• tutorials (17)
• water-closet (4)

While keeping myself busy with The Pandoran War, adding missions, features, and all kinds of other bits, it struck me that I currently have no idea how the game is actually flowing. When creating the missions, I tend to create the mission file, specify which mission is required to unlock it (the previous in the same star system or one entirely different), and then go from there. I then just play the mission separately, starting it directly from the command line. The nice thing about PW is that the player doesn't receive upgrades, etc., so nothing of the sort transfers between missions; the only persistent things in the save file are the stats and the missions that have been completed.

I've made games in the past that follow a non-linear structure: the missions in both Blob Wars : Metal Blob Solid and Blob Wars : Attrition unlock as the game moves on. However, the major difference is that in those games there were only a relatively small number of missions - about 18 or so, so it was easy to keep track of things. Already PW is up to 30 missions, and the list is growing constantly. I found myself in danger of breaking the game by not resolving the mission structure properly.

The solution was to create a visualisation of the mission structure. Yay, dependency graphs! I poked around on stackoverflow for a bit, to see what people suggested, and then knocked up some Java code to create the graphic (it actually creates HTML, with some CSS styling on lists).

It does the job, but exposes the very problem I'd wanted to avoid: it will be very easy to lose track of the flow, and will soon become quite complicated. The other issue with the v0.4 approach was that it was a little too restrictive on the order in which the missions were unlocked. The game isn't linear by any means, but I wanted it to be a little looser.

So, I overhauled the mission structure, telling missions that they were only playable once a certain number of other missions had been completed, and when the mission prior to it in the same system had been completed. The result is this (click to enlarge):

Reading from left to right, the numbers in the grey box represent the number of missions required to unlock the missions in the set, and the number of missions that could have potentially been completed up to that point, respectively. I feel this is better, and easier to understand. Not shown is that there are error messages if missions are detected to be out of order or conflicting. This will be very important as more missions are added.

So there you go. A little insight into what goes into making a non-linear, mission-based game..!