“Alea iacta est.”
“The die is cast.”
— Julius Caesar, crossing the Rubicon. It’s possible Caesar actually spoke it in Greek: ἀνερρίφθω κύβος, transliterated as anerrhiphtho kybos. Which sadly doesn't have the same ring to it, in my opinion!
Hello, Lucas here! We're taking a detour from the previous diaries on war to talk about the Action System.
The very first diary posted here was about the Action System. I’ve decided to revisit it, now that I know more about the game. Making a game is a process of discovery, and I've learned a lot since then.
I made a prototype for this purpose. It’s free and you can play it here! If you do, please use this form to send me your feedback!
This prototype will only be up for about a week in order to collect feedback. However, you can still access it afterwards if you're a paid subscriber on Substack.
The Action System is my replacement to the event system seen in many strategy games: Paradox games, Total War, Civilization, Old World and many others. People commonly just call them “events”.
Events are very popular for a reason. They allow the developers to showcase a wide variety of content, and they give the player some interaction. But they also have their drawbacks, mainly the repetition: “I’ve seen this event 100 times”.
Actions hopefully address some of the issues with events. Actions are always character-initiated rather than randomly generated; they have a bigger context by being part of an endeavor; and they have a more interesting resolution system than “pick one of these 2-3 outcomes”. By resolution system I mean the term as it is used in tabletop RPG design: a way to resolve whether you succeed or fail in what you’re trying to do.
In this diary, I’m going to mostly talk about the resolution interactions of the Action System, putting them in the context of the game as a whole (because that’s the context they have to exist in, after all).
One important contextualization is that this prototype was made with Private Actions in mind, in which characters go mostly solo. There are also Social Actions, which involve other characters. The mechanics will be a bit different with multiple characters. But I figured that, if I can make 1-character play fun, it will be even easier to make multiple character interactions fun.
Another important detail is that the prototype has no content, it's pure mechanics. In the game, my intention is for any Action to represent something specific you do. Drink at the Tavern, Watch a Play, Study Philosophy, Train Swordfighting, Practice Horse Riding, etc. None of that content is implemented (yet).
What follows is a long read, but hopefully interesting if you care about game design. If you just want to see the prototype in action, watch the video below. That’s actually the only place to really learn the mechanics, since I don’t describe them in this diary, preferring to write about why I made this prototype in this way rather than what it is. To find out what it is, you can also just play it here (and please remember to give feedback if you do!).
Randomness
I’ve experimented with various ways to resolve actions. This newest iteration features a system inspired by Roman dice games.
The Romans loved dice games and were big believers in luck. They had a goddess for it: Fortuna. This was so important to them that Sulla had the nickname Felix, “lucky”, and believed himself to be blessed by the gods with good luck. And this mattered to those around him: you don’t want to go against a lucky person. They have the favor of the gods.
There were two types of Roman dice: Tesserae and Tali.
The tesserae were our common 6-sided dice. The tali were 4-sided dice, usually made from ankle bones of sheep. This second option sounded more unique to me, so I decided to use them in my design, partly to signal to the player that this is an unusual mechanic that they haven’t played yet.
Tali (4-sided dice) had four numbers inscribed in each side: 1, 3, 4 and 6. Those numbers were the results you could get when rolling them.
We don’t know very much about Roman Tali games. It seems you would usually roll four Tali, and that would give you your result. The best result was called Venus, and it happened when you rolled one of each side. So, for example, rolling 4, 6, 1 and 3.
The worst result was called Canis (dog), and was when you rolled 1, 1, 1, 1. That was the “critical failure” of Roman games. It’s actually very rare when rolling four 4-sided dice, with about a 0.4% chance. The Venus result, in contrast, has about a 9% chance.
As a game designer, playing with dice is dangerous. A common complaint of players is simply RNG. Those three letters alone can send shivers down a player’s spine as they have flashbacks of that missed shot in XCOM with 95% chance to hit.
Of course, RNG by itself is not the problem, it’s how you use it.
I decided to give the player as much control over the RNG as possible while still keeping the game fun. The problem with giving this control is that it requires interaction, and the necessity of interaction can negatively affect the pace of the game.
Roman Tali dice had four faces, with values 1, 3, 4 and 6 (2 and 5 were omitted, those sides were rounded and the die wouldn't land on them). Each side looked quite different because they were different sides of a rectangular ankle bone of sheep and goats (yes). In the illustration above, they are ordered as 3, 4, 1 and 6. From: Michael J Speakman - Ancient Roman and Greek Tali Games & Roman and Greek themed Games that use Tali. Link to the pdf in the bottom of this wonderful late 90s/early 2000s style website.
Rolling 4 Tali in the prototype. That's how the Romans rolled, too.
Gameplay Pacing
In order to gain some clarity about the pacing of the game, I made this (overly busy) chart:
My chart. Please note that this is a sketch, it’s not precise, and everything is up to be changed. Many of these mechanics might never be implemented at all, as I discover that they’re just not fun, or they might be transformed into other things, be merged, split, etc.
The chart divides some possible mechanics in Historia Realis into four quadrants:
ANNOYING ZONE (top right): Mechanics that are both Frequent and Demanding.
OPTIONAL ZONE (top left): Frequent but Undemanding.
BACKGROUND ZONE (bottom left): Infrequent and Undemanding.
SEASONAL ZONE (bottom right): Infrequent but Demanding.
Any mechanic in the game will be somewhere in this 2D spectrum. But they should never be in the Annoying Zone.
Some game genres actually thrive in the Annoying Zone. They’re all about it. It’s not annoying at all for them. It’s just the Zone. Some examples are:
RTS games.
FPS games.
Action games in general.
Racing, sports, fighting…
Even puzzle games, which have to constantly present you with new and demanding challenges.
The reason why they get away with it is because those genres are expected to keep you focused and locked in.
But, in complex simulation games, there are so many interconnected systems that no specific mechanic can demand the player’s unilateral attention, or it quickly becomes annoying.
Other genres, like turn-based strategy and RPGs, also operate very well in the Annoying Zone, as long as they drift in and out of it. With turn-based games, you’re able to take a break from its demands at any time, while RPGs often drift from more demanding moments of combat to other less demanding moments: moving around, talking to NPCs, etc. Most genres use this “dual pace” of times of intensity and then some peace. The Minecraft day/night cycle is a classic example. Or Raids in RimWorld. Any cutscene also fits this pattern.
But that pattern doesn’t really work here.
I think that “real time with pause” grand strategy/simulation games are in a unique position because, while you can pause at any time, you mostly want to pause as little as possible, and for as little time as possible. This keeps the gameplay and the emergent narrative flowing. Pausing too much (or for too long) gets in the way and breaks flow and immersion.
Chart zoom-in. The Annoying Zone. Nothing should ever go there.
Big Danger: The Annoying Zone
Actions in Historia Realis are frequent. They happen every few in-game months or so. At the fastest speed, that can go by very quickly.
One motto that’s been on my mind lately is: “don’t #%@ the player”. That’s obviously not enough for good game design, but it’s certainly crucial in order to not have a bad design.
What does it mean to not #%@ the player? It means always allowing you to at least try doing what you want to do, even if you fail. It also means not demanding too much, too often.
Here are some words and terms that I see players use when a mechanic is in the Annoying Zone:
Micro (too much micro)
Babysitting
Clickfest, too much clicking, clicker game
Popup spam
Manual labor
“It’s a chore”
“Feels like work”
So ok, avoid the Annoying Zone at all costs. You do that by making your frequent mechanics less demanding, and your demanding mechanics less frequent.
Now let’s talk about the opposite problem.
Smaller Danger: The Boring Zone
If too many things are in the Background Zone, then that becomes the Boring Zone. Everything is automated or too simple and you don’t get to do anything fun. You don’t get to use your stuff, to play with your toys. The descriptors “map staring” and “waiting simulator” might be symptoms of the Boring Zone.
I don’t believe this is as big a problem as the Annoying Zone, but it can be! The solution should be simple: move things out from the Background Zone and into the Seasonal and Optional zones. In other words, make things either more demanding or more frequent.
To fix this issue, I’d lean towards adding more demanding features, because boredom is usually due to lack of challenge. But always be careful that making something more demanding doesn’t put it in the Annoying Zone. So don’t make more demanding things that are already frequent.
Chart zoom-in. Too many things exclusively (and deeply) in the Background Zone can turn it into the Boring Zone.
Minimal Mechanics
Grand strategy games are maximalist games, in some sense. They have complex interconnected systems, intricate mechanics and so on.
But individual mechanics should still be minimal and play only their role really well, not overextending themselves. At least in my opinion, individual mechanics should be minimal, and come together to form a “maximal” experience.
NOTE: One might think that the minimal interaction is a choice between two things. Not so. The most minimal choice isn’t “choose between these two things”, but “choose whether to do something or nothing”. Choosing between two options means always changing the current state, always evaluating two possibilities. The cognitive load is much lighter when you consider whether to even change the current state or not. You likely already know the current state, or a good part of it, and you might be perfectly happy with it. In the choice between “nothing” and “something”, the cognitive load is just to say “I’m good” and decide to do nothing, or to say “maybe I could do better” and evaluate a single option (rather than two). This matters when you’re trying to make minimal interactions. Instead of two options that change the state, consider a “single option” instead: to do nothing (maintain the current state) or something (change the state).
Specifically for Actions in Historia Realis, they have to steer clear of the Annoying Zone, but still do their job.
So what does it mean for a mechanic to do its job? How do you measure if a mechanic is successful? You can use three measuring sticks for each player interaction in the mechanic:
The interaction is always impactful
The cost of interaction scales according to its payoff
The interaction is meaningful; it holds a metaphor; it tells a story
I’ll go into each one now.
The prototype, with a very non-minimal tooltip. The interactions themselves are pretty minimal, though!
1. The interaction is always impactful
The player wants to make impactful change through their interaction. An interaction that doesn’t have a deep enough impact feels pointless, useless, underappreciated. The player asks themselves: “Why did you make me click this button if it changes nothing? What am I here for, anyway? Am I not valued? Is my time and effort not respected?”
Early on, I experimented with an interaction that allowed you to replace one of your tali with a challenge one. It sounded cool, but it led to situations where interaction was possible, but not big enough to change the outcome of the action. For instance, you could, instead of losing 10 to 20, lose 15 to 17. It made no difference, you still lost.
So those possibilities added a lot of noise to the mechanic, and bad noise. They made a large chunk of the possibility space not impactful enough. This meant the player would have to scan the possibility space for those unimpactful possibilities, and discard them.
So I removed that, and made sure the interactions were always impactful.
Now the player soon learns one thing: if you click a button, something will happen. You will change the outcome meaningfully. And that becomes the contract between you and the game. If you want to have an impact, then the game will let you. The question goes from “can I make an impact or not?” to “what is the impact?” and “do I really want it?”
"Choose your action" screen of the prototype. You select between actions with various difficulties and rewards.
2. The cost of interaction scales according to its payoff
I could talk about balance here, but that’s not what I mean.
By cost I mean in terms of what it demands from the player as a human being: time, attention, effort, brain juice.
By payoff I mean an emotional payoff, ideally. Not just “you gain +10 this”, but what actually happens. The situations (and player interpretations) created by the interaction. The player’s emotional reaction.
For example, when you use one of the Tali in your hand, you can get a really good bonus. But it takes some mental effort (and time) to make the right choice.
If you can get large emotional payoffs for low interaction costs, that sounds ideal. But I think that the largest payoffs are created precisely by demanding more interaction. In other words, you need higher interaction for higher payoffs. As the player interacts more, they impart their personal investment into the mechanic. You just have to make sure their effort wasn’t all in vain. You have to make the mechanic build up to something.
Which is why I like the mechanic of collecting tokens and then using them, preferably in harder actions. You invest, you build up to it, then you get a payoff: you win very hard actions that you otherwise wouldn’t. And you use your previous choices to do it!
Also, the cost of this big payoff is spread over many smaller interactions. When you get that final payoff of adding the token you needed to make your roll go brrr, it’s the culmination of your past interactions in a single click.
NOTE: A common problem is that, while it’s hard to increase the payoff, it’s actually extremely easy to increase the cost of interaction (without increasing the payoff). You just give busywork to the player. More menus, more buttons, more stats. It can even feel like you’re doing something productive as a game designer, because you’re adding mechanics, right? You might even fool the player in your screenshots, because it looks like there’s a lot of stuff! But if you’re just adding to the cost of interaction, you’re making the game worse, not better. So look at the actual payoff and scale the cost of interaction down accordingly. You can make the game better by removing stuff, not just adding!
Action screen of the prototype. Here you try to get a success, or get more out of your success.
3. The interaction is meaningful; it holds a metaphor; it tells a story
Games are a form of communication. Mechanics are the sentences, and each player interaction is a word. Every time the player interacts, they should advance an understanding, a story. They should build upon the meaning they’ve been creating in their minds.
This is probably the hardest layer to get right, especially for abstracted simulation games. When you're playing a less abstracted game, like when you're bashing goblins on the head, the story is clear: you bashed, the goblin died, you won, and you probably looted the poor goblin's corpse. You see those things happen. In a UI-heavy simulation, meaning gets fuzzier. And unfortunately you can't "just make it more realistic". There's no such thing. The truth is that a simulation is always a lie.
What I can say is that, in my simulation, I tried to use both the aesthetics of Roman dice games and the view of the Romans themselves of how things happened, how it was that some people got what they wanted while others didn't. Sometimes people had the favor of the gods, and sometimes not, and they had to navigate this.
This is also the layer to consider the place of the interaction in the overall system and the game as a whole. Does it fit? Is it in the right place? Does it say what it intends?
This is probably the point where this prototype fails the most at. My hope is that content will help with that, but perhaps there are other things I can do as well. I feel like there's more to say about this, but for now this is all I have.
End screen of the prototype. Shows your final results.
That’s it!
If a mechanic is doing those 3 things well, and not doing their opposite, then it’s hitting its requirements. And that’s the best we can hope for. To discover what the sins to avoid are, just invert the points above:
The interaction is not impactful enough.
The cost of interaction is too high, the payoff too low.
The interaction is not meaningful, not understandable, not story-generating.
Avoid those as a designer and you’re fine.
NOTE: There is something mysterious and that can’t be put into words about what it means for a mechanic to do the above things really well. I think that what it takes to accomplish that is simply intuitive design + playtesting/prototyping. In other words, adding good stuff and then taking bad stuff out or changing it. In yet other words, good iteration; having good ideas and then having good ideas about where to take those. Unfortunately, the recipe doesn’t get any clearer than that, in my view. It’s something that one has to simply do and hope that the gods favor them in their endeavor.
Final Words
Lastly, I want to say that words are very weak when it comes to game design. What really matters is how the game plays. Luckily, this write-up is at least backed by a prototype. So anyone can compare the ideals written up here with the reality of how the prototype actually plays. No doubt it falls short of everything I want it to accomplish, but hopefully it can be improved.
Next, I will be adding another ingredient to this process: time. I think it’s important to give a prototype some space to breathe, like baking a cake and then leaving it out to cool.
The other important ingredient is feedback. And this is where you come in! You’re welcome to play the prototype and then send me your feedback through this form. You can also join our Discord to discuss it directly with me and other players. That would be truly incredible. Your thoughts and feedback are super important and help me make a great game for everyone.
Then, with time and feedback, I will consider how to integrate these mechanics into the game; or decide to scrap them completely, if they turn out to be bad for the game after all (such as if they exist too much in the Annoying Zone!).
I will talk more about Endeavors in a future diary.
That’s all for now, I hope you enjoyed!
Shorter video of me just playing the prototype, rather than explaining the mechanics.
Thanks!
Join our Discord to stay in touch! I'm there, you can ask me questions or give me suggestions!
If you want to support the project further, you can join our Substack.
Thank you very much.
— Lucas
Remember to wishlist Historia Realis! Oh, and follow it too! Then you get cool diaries like this delivered to you!