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.
5 comments
Trackbacks/Pingbacks
- Towards meaningfully gamifying Bayesian Networks, or, just what can you do with them | Kaj Sotala - […] Next post in series: Bayesian academy game – constraints. […]
Leave a Reply
This work by Kaj Sotala is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
In addition to making a public comment, you may also send me anonymous feedback.
While there are certainly practical arguments in terms of ease-of-creation for a shorter game, I tend to favor longer games myself, and I think there are viable methods for preventing players from save scumming to get the best results from choices which don’t necessarily demand a short game.
Here are a couple potential measures which come to mind.
* Make game saves available only at certain points (such as at the end of each in-game day,) and implement a large enough number of choices or actions in each day that it’s impractical for the player to test all the options by save scumming.
* Present the player with a set of events after each save interval drawn randomly from a pool generated by existing character variables. For instance, when the main character has certain variables for their reputation, character relationships and so on, at a certain point in the game, there might be, say, a pool of seventy possible character events, each of which presents its own set of choices, and only, say, six might be drawn on a single day, with selection being randomized with each reload.
* Delay feedback on the player’s choices. The player must be able to receive feedback eventually, to learn from the consequences of their actions, but if the feedback comes long enough after the choices, it will take an impractical amount of time for the player to reload back and test all the options on each choice. Here’s a possible implementation; you save at the end of every gameplay day. Afterwards, at the beginning of the next gameplay day, you receive feedback on the results of your choices from the previous day. The length of the gameplay day should be short enough that the player should reliably have time to get through at least one in a play session, so we don’t force a high minimum time commitment each time someone wants to play, but long enough that playing through one many times to get the best possible results raises a high hassle barrier.
There are probably other mechanisms I haven’t thought of yet. I wouldn’t get too attached to any solution until the problem has been examined thoroughly.
Yeah, there are several approaches that could be tried, and I agree that it’s better not to commit ourselves into any particular one quite yet. Another that came to mind was to have the roguelike saving system, but simply don’t have any loss condition: if things start drifting in an unfavorable direction, start giving the player more favorable random events so that they can always recover. That way, bad luck in the end part of the game wouldn’t necessarily require a restart. Anyone could win any game if they just kept playing long enough, but more skilled players could do it more quickly.
I like your suggested second idea: it reminds me of King of Dragon Pass, which had multiple-choice random events, and reloading an earlier save would usually give you different events. Though it has the drawback that it requires a design where the player is relatively passive, mostly only reacting to events that the game throws at them: it doesn’t work as well if the player can take actions of their own, outside any random event.
WRT the third option, I would prefer the player to always receive some feedback on their decision right away… but of course, if the choices have both short- and long-term consequences, one could conceivably present the short-term feedback right away and the long-term only later on. It’d take some careful designing, though.
“I like your suggested second idea: it reminds me of King of Dragon Pass, which had multiple-choice random events, and reloading an earlier save would usually give you different events. Though it has the drawback that it requires a design where the player is relatively passive, mostly only reacting to events that the game throws at them: it doesn’t work as well if the player can take actions of their own, outside any random event.”
Here’s one way that we might be able to implement it while giving the player opportunity to be proactive: randomize the population that appears to interact with on each day. Let’s say that the student body consists of a thousand students, maybe with all of them having personalities determined by the computer by mixing and matching variables at the start of each game. On each day, one tenth of those are randomly selected to appear around the school for your character to interact with.
That would make the characters a lot less distinct, though. If the player is only interacting with a small number of characters, it’s difficult but doable to create the illusion of them being real people that you’re influencing and bonding with. If you have a thousand students, you can’t really give each of them unique content anymore (or if you can, it’ll be something pretty superficial) and it becomes a lot more obvious that you’re not actually dealing with real people.
You can give computer generated characters enough content to make them seem fairly unique (I would accomplish this by dividing their personalities into axes, with each character having randomly assigned values on each axis, and writing up distinct responses for each interaction given the character’s values on the relevant axis, and on your relationship/reputation.
This is the sort of thing that would require a huge number of man hours though, probably involving a committed team of writers, because you’re facing something of a combinatorial explosion.
I think it might be worthwhile to have randomly generated NPCs for each game, who have randomly generated values and create a different factional balance for each playthrough, but have a set of pre-written characters with hard coded values who play set roles in various factions, who you deal with in every playthrough.
Randomly loading a hundred out of a thousand characters for each day would be *impressive*, and might be fun to try with enough resources, but you can accomplish the same anti-save scumming incentive by randomly loading, say, a dozen characters out of thirty, which should be within practical constraints for a deliberately written cast.