Whew, I haven’t written one of these in a while! I’ve been doing some weird back-end programming for a bit, but a few things that I’ve been working on is finally ready for an experiment, so let’s talk about them.
We’re rolling out a new, more robust alert framework.
The old alerts were good for a few things, but not great for most. They began their life out of a need for a system for opt-in decision making, since we didn’t want to be pushing major choices to the middle of the main screen every time a player needed to make a choice (e.g. what to do about bandits), but the initial implementation of icons down the left side of the screen caused problems: icons alone aren’t enough to get across specific information, and there was still important information in the “ticker” (aka dialogue) box at the top of the screen because of this. Some news like “you got some planks” just didn’t make sense in a dismissable icon with the same weight as “pick your bandit foreign policy”.
The new alert system has three levels of alerts and two distinct visual styles which are roughly the size and shape that we want (but the art will likely be updated when we’re convinced we don’t want to alter them), and are broken into what we call “stubs”, “FYIs”, and “choices”. Alerts that can be dismissed (all but choices) can be dismissed by right clicking them. Alerts that contain more information will show this information when left clicked, so for instance choice alerts will expand the choice dialog upon a left click, and FYIs will expand a larger text window upon left click. Hooray standardized interactions! (And I’m sorry I trained everyone to right click to close, then swapped it halfway, and now it’s different again. I always hate it when designers change these things too.)
Things still to come with this system: general polish, and persistent events, which are one of the few things we still need to complete in order to get some of our eldritch/occult stuff back.
The existing ticker text is being moved to a “History” button, and will persist across load/save now (finally). There will also probably be vestigial cases where something important shows up there and not in the alerts somehow, but we will be doing our best to catch these cases.
There is, I think, a lesson in designing simulation games – or likely even all games – that I’ve learned recently in the only fashion that anyone ever really learns a lesson: the more often a player interacts with a game system, the more clear the state of the system need to be.
Our game has two systems that players are intended to interact with on a very frequent basis: the economy of widget production, and to a slightly less frequent extent, keeping their characters happy. The widget economy has some basic UI issues and maybe a couple structural issues that are getting in the way of this lesson, but it’s steadily getting better (and is the subject of a bunch of past and future blog posts). The character simulation, however, has been failing this pretty badly, and mostly due to design.
Initially the character simulation was developing character personalities out of a composite of dozens or hundreds of different memories of events, each with different importance to the character, each fading at different rates, in a way that seems to somewhat resemble reality, at least insomuch as any simulation of human behavior can. We had to trash that months ago when we realized that players had no real idea of why the characters were acting a specific way because they had no access to real data about how their moods were being decided. I dropped the number of memories that the characters could draw from down to seven and displayed the data in as much detail as possible without actually showing the numbers themselves. But I didn’t realize that this simplification was dooming the system entirely. With fewer memories to draw their composites from, the characters became more unstable. Unless they were constantly flooded with extremely positive memories, one bad memory could flip their state entirely. These systems are impossible to balance, so we’re not doing it any more.
- Characters now have what we’re terming an “emotional baseline” which for now is standard across all characters. Characters’ mental states are now determined by the baseline, as well as two other sets of things.
- Some things (such as quality of their workplace) will provide persistent adjustments to their emotional baseline, freeing up a lot of design space which the memory system wasn’t equipped to handle in the first place.
- Then the memories themselves will provide flat numerical increases or decreases to each emotion value. The baseline values, the persistent effect values, and the memory values will all be visible on the characters.
We’re losing a couple of things from this. The first is that the memories aren’t going to fade anymore, they’ll either be on or off. This isn’t great but it isn’t terrible, and while it’s technically still possible, we’re sacrificing a little bit of simulation fidelity here to gain more clarity (see lesson above). And we’re also losing the “mystery” of how the character states are calculated. If you wanted that, I’m sorry. There will be other mysteries, but what event has caused your character to go mad and attack their friends will no longer be one of them.
What we’re gaining is clarity (the opposite of mystery): now you’ll know what has caused a character to go mad and attack their friends! We’re also gaining the ability to hook things like building quality to the character state in a way that isn’t janky as hell (aka it’s balance-able), as well as the tools to balance memory effects. These things will allow us to give the character state more importance in the game, since we couldn’t do this due to the whole wildly unstable thing.
Oh, and also we’ve rolled madness into the sadness state and it is now called “Despair”. There wasn’t a compelling design for connecting sadness to the gameplay systems, it was just, well, sad. Also this just themed thematically correct. This is one of the few other things that eldritch/occult stuff was waiting on.
Lastly I feel it’s worth emphasizing a point which doesn’t make itself apparent in the rest of this post. Simulation complexity, randomness, and mystery are not inherently bad. In their time and place they’re awesome and often even necessary to a game. And we will have both of these, and they will exist in thematically important systems, just not the ones that you’re interacting with several times each minute.