Probably the most difficult part of this projet to date has been definining the various game systems and AI states. Yes, it is a bit late in the day for this sort of thing. But at least I'm there and I'm doing it. Descriptively, tiring is an understatement. Much like concept art this process starts on paper, and then I transitioned it into a mind map. But conceptually it's way more taxing than anything I've done so far. It's just hard.
Initially it seemed like it would take two ticks to do actually, hence the up-beat nature of the previous blog entry. The autonomous AI for the vehicles were quick to define and implement. And also easy to test. But when you start fleshing out the 'greater force' that the player will be up against, things start spiraling out of control very easily. And like most software projects, when you start eyeballing the details there's nothing keeping an eye on the bigger picture. I've come to refer to this as the distilling process.
Piling on states and variables is no good thing, and it's hard to take all that and boil it away until the essentials remain. So what is essential then? That rather depends, but one non-negotiable requisite is to have a very clear idea of what your game is going to be about. And I'm not talking about your idea's premise. I'm talking about your game systems.
How are you going to achieve meaningfull player decisions? Variations in player engagement? Sure, some of the story elements or the underlying premise drive towards that, but that doesn't go deep enough.
In Stingray, the premise is corporate warfare. Part of the story is infrastructure. So, a tactic that would slowly disable intallations is on the cards because if you're on the full-stealth side of the tech-tree you can't bull-run an installation out right. Take out the power supply then, that'll shut it down. Oh wait, there's more than one. But now they know where you are. Was that a good decision? Because here they come to investigate. Will they repair it while I'm dodging?
And so the spiral continues...