Tuesday, February 16, 2021

Game structure oracle

Text parser adventure games, usually called interactive fiction, are video games which present you with the state of the virtual world, and expect you to type in commands which change this state, usually actions of a character which you play. Zork (playable online here) was a famous series of completely text-based parser adventure games, where the state was also presented as text. The early Quest games from Sierra (King's Quest, Space Quest, Quest for Glory, etc), while providing information in both textual and graphic form, still required you to type commands in.

Eventually most of these series culminated in games with more graphical interfaces, resulting in the genre of point and click adventure games, but there is a small community of designers who still create fully textual parser games, often using the Inform language, which is ultimately based on the language used to design the old Zork games and other Infocom interactive fictions. One of the skills you had to develop as a seasoned text parser gamer was expressing what you wanted in a way the parser would understand: which nouns must be acted upon by which verbs, based on possibilities gleaned from the textual descriptions, or from knowledge of the system itself, such as its inventory and combat features.

As a thought experiment, suppose that instead of developing these skills yourself, you had a professional parser gamer working for you: someone who knew exactly how to navigate the game and understand its description, who might even be able to peek at the video game's code or assets directly, although they'd only do so to make sure they were answering your questions correctly, rather than to give you information you shouldn't have. This person would take your descriptions of what you wanted your character to do in the virtual world, and translate them into commands that the mundane parser would be able to use; they'd then describe the new state of the world to you, using the result provided by the parser game. This person is starting to sound a little bit like a gamemaster, in the role of judge or referee, except that they wouldn't be enforcing rules, so much as translating back and forth between you, the player, and the parser game, which does the actual enforcement.

This professional parser interpreter would be acting as an oracle for the text parser adventure game. An oracle in this sense is the term used in theoretical computer science for a kind of black box which can be asked questions to which it provides answers, in ways that the questioning algorithm's designer does not have to understand. In this case, the parser sends the description of the current state to the professional parser gamer, who will eventually come back with instructions the parser can understand and act upon.

When we look at role-playing game structures like the hexcrawl, or the node-based scenario, their systems, taken at face value, could be implemented in software. You could write an Inform program to provide the backing to a hexcrawl, once you've populated it; you could change it whenever you added or removed anything. And then your job as a GM while running the game could move towards being an oracle for the program, and something role-playing-like would occur between you and the player, even if you don't go beyond that to riffing or improvising at the edges. This is an extreme version of constructive alienation, an almost complete distillation of all creative thought into the process of designing and implementing the external structure and its procedures, and then supporting the player in engaging with it as a mere interpreter.

If you limit yourself to being a game structure oracle GM, there are several ways in which you can improve. First of all, the better programmed or designed your game structures are, the more variety the players will encounter as they engage with them, and the less you will be pressured to improvise. This will make you a better systems designer - or adapter, if you decide to use an existing adventure module in this way. In fact, it may well make it easier for you to create an adventure for someone else to use - you could honestly provide them with an interesting experience to run for their players, without forcing them to improvise to cover gaps you might've otherwise left.

Another thing you can get better at is translating player intent into rules usage. If you want to better support the implied character sheet game of the RPG your system runs on, this can be very beneficial. Alternatively, you might come into conflict with player knowledge of the CSG if you're trying to hide the details from the players to improve immersion. There's a balance that's worth striking.

Since the system is limited, and we're excluding the possibility of improvisation or ad-hoc rulings, another thing you might have to get used to doing is either diplomatically saying no, rationalizing why an unsupported action won't work, or preemptively guiding the players to consider choices that are supported by the system. The latter can be done by making sure to emphasize the systematically relevant features of the environment when you're describing its state. In extreme cases, you'd be making sure that even if the system itself effectively requires pixel hunting, the players aren't required to perform it.

As I said when I was discussing the CSG, this limit of GMing isn't in line with my natural inclinations. I am far likelier to improvise, to make rulings in the moment, to run with what the players give me directly. The purpose of this exercise is to challenge myself to improve in the aspects of GMing that do not come naturally to me; hopefully, this will lead me to be more well-rounded.

No comments:

Post a Comment