Bayesian academy game: Constraints

My work on my Master’s thesis and the Bayesian academy game was temporarily interrupted when I had to focus on finishing the work I had piled up for another course. Now I’m slowly trying to get back into the flow, so here’s a post on some of the things that I’ll be trying to keep in mind while creating the game, and which should help shape its design. This post is still somewhat abstract: more concrete material should hopefully follow in the next post.

I’ve also started on the actual programming, putting together what should hopefully be a flexible Bayes net framework. (I looked at some existing libraries, but it seemed easier to just put together my own implementation.) Mostly model level stuff so far, though, so not much to show yet. I’ll probably put a copy up on Github or somewhere eventually, once it stops looking terribly embarrassing.

Constraints

“Design is the successive application of constraints until only a unique product is left.” — Donald Norman, The Design of Everyday Things

Having some constraints is nice. They help narrow down the space of possible designs and give an idea for what you need to do. So let’s establish some constraints for our game design.

Has to teach useful things about Bayesian networks / probabilistic reasoning. Kinda obvious, but still worth stating explicitly. At the same time, the game has to be fun even if you had no intrinsic interest in Bayesian networks. Balancing these two gets tough, since you can attract gamers by various story elements and interesting game mechanics, but then these elements might easily become ones that do nothing to teach the actual subject matter. My general approach for solving this is to build the mechanics so that they are all tied to various pieces of hidden information, with Bayes nets being your tool for uncovering that hidden information. More on that later.

Every choice should be interesting. Even if you manage to figure out exactly who knows what, that shouldn’t dictate the right option to pick, just as in XCOM, correctly figuring out the probability of killing your opponent given a certain tactic isn’t enough to dictate the choice of the best tactic. Rather, correctly using the skills that the game tries to teach you should be something that better informs you of the benefits and drawbacks of the different choices you make. If there’s only one obvious option to pick, that’s not interesting.

Of course, eventually somebody will figure out some optimal strategy for playing the game which dictates an ideal decision for various situations, but that’s fine. If we design the game right, figuring out the perfect strategy should take a while.

Must not be ruined by “save-scumming”. In my previous article, I gave an example of a choice involving Bayesian networks: you are given several options for how to act, with the best option depending on exactly which character knew what. Now, what does your average video game player do when they need to make a choice based on incomplete information, and they find out the truth state of affairs soon afterwards? They reload an earlier save and choose differently, that’s what.

Constantly reloading an earlier save in order to pick a better decision isn’t much fun, and really ruins the point of the whole game. But if that’s the optimal way to play, people will feel the temptation to do it, even if they know that it will ruin their fun. I would like to give people the freedom to play the game the way they like the most, but I’m worried that in this case, too much freedom would make the experience unfun.

Other games that rely on randomness try to combat save-scumming by saving the random seed, so reloading an earlier save doesn’t change the outcome of any die rolls. We could try doing the opposite: re-randomizing any hidden states once the player reloads the game. But this could turn out to be tricky. After all, if we have a large network of characters whose states we keep track of and who influence each other, setting up the game in such a way that their states can be re-randomized at will seems rather challenging. So I’m inclined to go for the roguelike approach, with only a single, constantly updating save slot per game, with no ability to go back to earlier saves. That gives us a new constraint:

Each individual game should be short. A constantly updating save means that if you lose the game, you have to start all over. This is fine with a game like Faster Than Light, where a single pass through the game only takes a couple of hours. It would be less fine in an huge epic game that took 50 hours to beat. Based on my own gut feel, I’m guessing that FTL’s couple of hours is quite close to the sweet spot – long enough that you get depth to a single game, short enough that your reaction to failure will be to start a new game rather than to quit the whole thing in disgust. So I will be aiming for a game that can be finished in, say, three hours.

This constraint is probably also a good one since my natural inclination would be to make a huge epic sprawling game. Better to go for something easier to handle at first – a limited-duration game is also easier to extensively playtest and debug. I can always expand this after finishing my thesis, making the game so far the first chapter or whatever.

One could also allow reloading, but restricting where you are allowed to save. Recently I have been playing Desktop Dungeons, where your kingdom grows as you go out on quests that are about 10 minutes long each. You can’t save your progress while on a quest, but you can save it between quests, and the temptation to try just one more quest makes for an addictive experience in the same way that FTL’s short length also makes for an addictive experience. But I’m not sure of whether my current design allows for any natural “units” that could be made into no-save regions in the same way as the quests in Desktop Dungeons can.

Another consequence of having constant saves is that

Failures should be interesting.

Always make failure entertaining. In fact, failure should be more entertaining than success. Success is its own reward. If you succeed at solving a puzzle, you feel good, you barely need any confirmation from the game. Just a simple ding will be satisfying. But if you’re struggling, if the game sort of is in on the joke with you and laughs about it, and gives you a funny animation, it’s actually sort of saying, yeah we want — it’s okay to be here. You can have fun while you’re here. You’ll get there eventually — you’ll get to the other end eventually, but while you’re here you can enjoy yourself; you can relax. And that’s really something I learned sort of from doing the game, but that’s really become an ongoing principal of ours in design is to make the failure — keep failure interesting. — Scot Osterwald

Even a game being short doesn’t help if a couple of bad decisions mean that you’re stuck and would be better off restarting rather than playing to the end. FTL solves this by quickly killing you off when you’re starting to do badly: this is interesting, since you can almost always trace your failure back to some specific decision you made, and can restart with the intention not to make that mistake again. I’m not sure how well this would work in this game, though I have been thinking about splitting it into a number of substages, each with a limit on the number of actions that you are allowed to do. (First stage: become elected as the Student Council representative of the first year students by winning them over before the elections. Etc.) Failing to achieve the objective before the time limit would lead to a game over, thus killing you quickly once you started doing too badly to recover. Possibly each stage could also be made into a single no-save unit, allowing saves between them.

Another option would be to take the Princess Maker approach: in these games, you are trying to raise your daughter to become a princess, but even if you fail in that goal, there are a variety of other interesting endings based on the choices that you made in the game. A third option would be to ensure that even a sub-optimal choice opens some new paths through the game – but it could be difficult to ensure that you never ended up in a hopelessly unwinnable state.

Still not entirely sure of the exact form of this constraint and the previous one: will just have to try things out and see what seems to be the most fun.

The next update should either be about some concrete game mechanics (finally!) and the ways that relationships are handled in this game, or about the way that the information is represented to the player.

Originally published at Kaj Sotala. You can comment here or there.