First of all, since I haven’t done so elsewhere, I’d like to thank all those who played my Spring Thing entry and commented on it in public and in private. I have a few remarks to make on what they criticised and what they liked and also on a few things that went unmentioned.
1. The parser as user interface
I had for some time been getting the feeling that much of what I had been doing with Inform was amateurish dabbling, my use of the parser, rules and world model a mere shadow of what was actually possible. In a way, this is how Inform 7 is meant to be used. Use a few of the more frequent verbs like they should be and add strange exceptions by hand. Its a Potemkin village but that’s all right. Taking the parser interface paradigm to it’s logical conclusion, is, after all, impossible and undesirable.
Or is it? For me, the intriguing thing about the command line is how its so ridiculously powerful. I think anyone with just a little knowledge of the Unix shell will be able to relate. With so many more user-friendly interface solutions around, why bother with the parser if you plan to take away the one thing that makes it interesting? How about we try and make a game that actually makes use of some of the potential of the parser. Critics will point out that players won’t even notice the difference. Very well, so it was going to have to be an experimental piece.
2. Experimental functionality
Dead Man’s Hill has a rather extensive system of newly implemented verbs, which can all be used on the player character himself as well as to command NPCs, who also act on their own. This necessitates automatically handing off more general actions to more specific ones. So its possible to order „Peter, shoot enemy with rifle“ as well as „Peter, kill enemy“, which may or may not achieve the same result, depending on what Peter carries in his hands.
Since I was already having the NPCs make these decisions on their own, I figured it wasn’t much of a stretch to go for some more agency and foresight, which means that the game now features quite a bit of artificial intelligence (Peter might decide to pick up a rifle and try to fire it at the enemy, then notice it wasn’t loaded so, provided he is still alive, pick up some ammunition etc.). Much of the AI is only enabled for the enemy NPCs so that the player still has someone to order around.
Then there is the tactical combat. Contrary to popular opinion, this is almost entirely deterministic. It fiddles with the turn sequence in a similar way to Kerkerkruip and that is where the problems start. To get the game to recognize commands to several characters at the same time, I used an extension by Daniel Stelzer that modifies the parser itself. The weird interactions of the different systems and the truly bizarre bugs that arise from them would have been reason enough to drop the project. Amongst the unresolved issues is the possibility to form-shift the player into one of the NPCs present by giving the wrong orders at the right time. But apparently this hasn’t come up in actual play. Players instead pointed out pronoun issues.
Procedural world generation was the next step. Unfortunately, this caused me to run into performance problems. So I had to keep the game world rather smaller than I would have liked. Turns out the AI opponents are smart enough to usually prevent the player from noticing how small it is before the protagonist gets killed.
2. Narrative vs. emergence
When designing a game, one is essentially trying to bring an aesthetic experience of some kind or another to the player. To do this, it is necessary to rely for the most part on the dynamics of play, which in turn are controlled by the game mechanics. That’s two levels of abstraction between the intentions of the designer and the experience of the player. Chances are, the designer will be misunderstood. Authors generally try to somehow skew this picture in their favour by introducing artificial story elements. Artificial in the sense that they are not emerging from the dynamics of play alone. It has been recently noted by Emily Short that to get the various story snippets to the player in the correct order, the game play elements have to be arranged accordingly (https://emshort.wordpress.com/2016/05/18/plot-shaped-level-design/). If we are talking about conventional parser IF, that means the geography of the game world has to be laid out to allow progression only in such a way as will not skip too much of the story. Since I was working with a procedurally generated world, this was not an easy task. The problem is not impossible to solve (see, for example, Dwarf Fortress), but I decided not to make much of an attempt. Instead I really wanted to rely on the dynamics to convey my aesthetics, the story of each playthrough standing on its own. I admit I didn’t take this to its logical conclusion since in my perception that would have meant an abstract game.
3. Thematic content
There is a lot that could be said about the first world war and the lessons that were not learned from it. It would have been a bit of a stretch to get all of this across in a single game. I tried to hint at some of it in the description and of course I was criticised for it because it doesn’t all show up in the actual game play. Still, I gather from the various comments that were made that some of what I wanted to transpire is actually getting noticed. Many people felt repulsed to perform the actions the game seemingly requires of them. That’s a great success for me, considering the callous indifference players feel towards commanding their protagonists to do what they do in most games.
The downside to this is that Dead Man’s Hill hasn’t seen the kind of attention I would have liked people to pay to it (I am not entirely immune to vanity). The game actually has a bunch of different endings and some seriously involved tactical game play. As one of my beta testers put it: It offers so many different ways to yet another stupid death.