[2024/09] Dev Blog: The Life of a Government Clerk
The Life of a Government Clerk is a single player, turn-based, coffee break Roguelike game made with Godot engine. The game title comes from Chekhov’s short story, The Death of a Government Clerk, while the core mechanics are inspired by Kafka’s novel, The Castle, in which K witnessed two clerks delivering document by cart in a hotel.
The game is under early development. Its current version is 0.0.2, which is not ready for play yet. In this article, I’d like to share my initial design ideas and current progress.
An Inspiration Pool & Some Meta Rules
My brain has an inspiration pool which is similar to, if I may say so, Illithids’ salty brain pool. Inspirations stay dormant most of the time. Occasionally, when my brain feels itchy and I happen to have enough free time to scratch it, I will make a new game. This time, the image of K standing in a narrow corridor emerges to the surface.
Now comes to the meta rules. I stick to three rules based on personal taste. They are neither rational nor reasonable.
- It is a single player, turn-based Roguelike game.
- There are no meta progressions, because I strongly dislike them.
- A player may lose the game in 1 minute, or if being tactical, beat the game in 5 to 15 minutes.
There is a optional fourth rule. I prefer to create a game that is not heavily combat-focused. I can write a long list of combat skills, or spend days talking about buff/debuff mechanics. However, to distinguish them from its counterparts is a challenging job. On the other hand, by building a peaceful world that diverges from Rogue’s hostile dungeon, everything (at least) looks different and makes me less worried about uniqueness.
By combining the initial idea, four meta rules and two worlds from my previous game (One More Level, Snowrunner and Desert), I have formed a vague picture of the new game.
- A player controls not one, but a line of ASCII characters, including PC and file-delivering carts.
- PC has three sets of abilities based on the number of carts.
- There are three feedback loops. Whenever PC uses ability, the environment adapts so that using the same set of abilities will become easier, while using other sets will be less rewarding.
Describe Game Scenes
Next step is to describe possible scenes for a clearer view of the game. This idea comes from Jason Grinblat, one of the developers of Caves of Qud. Quote from Procedural Generation in Game Design:
Look to envision gestalts across the spectrum of your rule systems, from common interactions to rare ones. Think about a story one of your players might excitedly tell their friends about how they took advantage of a rare confluence of events to narrowly escape a deadly situation. Now think about a more common occurrence, say, a particular strategy a savvy player might repeat over and over again for some minor benefit. Once we have a number of desirable gestalts, we can interpolate between them to develop modules and an appropriate assembly mechanism.
I don’t want to elaborate the interactions here. They are outlined as Q & A below.
- In the middle of a game, how many choices do PC have? Load an item, offload an item, or change the number of carts.
- How to reach a destination? Passively avoid obstacles, or use ability.
- How to beat the game? Deliver enough documents.
- How to lose the game? Maybe a clerk waits too long and becomes impatient?
Another approach is describing valid keyboard inputs.
- How many key strokes are required to load/offload an item?
- Suppose one cart can hold only one time, when load an item, can PC choose the exact cart?
- When offload an item, can PC choose the exact item?
- Can PC and carts go backwards?
- How to select and use ability?
- How to inspect carts and items?
The more I think, the less confident I become. In a world without fantasy elements and combat encounters, I find it hard to design obstacles and protagonist abilities. Both of them are critical to a story and a game. Therefore, I have to loosen the restriction and summon another mind worm from my brain: Planescape: Torment.
Everything suddenly clicks. A dustman delivers corpses in the smoke-filled Mortuary. He chews blood flies to empower himself. He rings a bell to open a portal. He swings a femur to drive away shadows. In addition to corpses, he also needs to deliver needles and threads. I translate the world from Sigil back to Kafka’s Castle simply because there are already too many fantasy-based games, but not so many fiction-based ones.
Resource Flow
Resource management is one of the key elements of a Roguelike game. It is also the main topic of Game Mechanics: Advanced Game Design. In this book, the author introduced a design language, and a list of design patterns (in Appendix B), to describe resource flow, which I find quite useful. I write down the flow diagram on paper first, then reproduce it in computer with draw.io.
Figure 1: Resource flow diagram.
The main feedback loop is a converter engine. Three types of primary products (an Atlas, a Book and a Cup of tea) are converted by Clerk and Officer in turn. The final product (Progress) stimulates the production of raw materials. A stopping mechanism controls the output of Atlas, Book and Cup. A Clerk will not start working until he has received two materials of different types, which is controlled by Desk gate. An Officer triggers multiple feedback loops, in which Progress and Account are positive, while Servant is negative.
PC travels around with his carts to load/offload items and cash payroll check. As shown in the bottom right diagram, his Carts are drained in two ways: either by actively loading an item, or by passively collecting drafts. If all Carts are fully loaded with drafts and there is no way to unload them, player loses the game. Two mechanics worsen the situation. The fewer Carts PC has, the more drafts will be loaded, which is a dynamic friction. Servants, if not driven away by Stick, also result in more drafts. PC can pay to clean a Cart, that is, reset a Cart’s load factor to 0. Deliver an item to Clerk or Office leaves an unloaded Cart.
PC has three abilities: Stick, new Cart and Order. They are provided randomly by Service in the bottom left diagram. Stick neutralizes Servant‘s effect. Cart ability grants PC a few temporary Carts. Both services cost a small fee. Order, on the contrary, pays PC in cash and reduce the remaining Document deliveries by 1. Since player wins the game by delivering 10 Documents, what prevents Order from becoming the dominant strategy? A successful Document delivery pays PC $3, while an Order is only worth $1. The accumulated cash when game ends acts as a score to evaluate player’s skill and luck.
You may have noticed that PC ablities do not vary with the number of Carts. Besides, using ability has no impact on environment. It is because I have not found a way to fulfill two of my initial ideas yet.
Game Demo
In the current version 0.0.2, I have added basic functions to PC and carts. The video demo at the beginning of this article shows current progress and is marked with tags. I will explain it in detail below.
Day 1
I imported code from my previous project Godot 4 Roguelike Tutorial. After just one day’s work, I already have a Roguelike game with movable PC, field of view and pathfinding AI, help and debug menus, and a rich library of helper functions. Here is the lesson I learnt. The best way to make one game is making two games.
Extend
New carts are added when PC moves around. Note that the number of remaining hidden carts is shown in sidebar.
Load Item 1/2
Loading should be triggered by interacting with an NPC, but is activated by a wizard key instead at the moment. Wizard keys are also used for offloading items, adding or cleaning carts.
An item is automatically loaded in the last unoccupied cart. If a cart is fully loaded with drafts, it is occupied and shown as three dashes. A cart may also be occupied by one and only one item, which is shown as a lower case letter. The item closest to PC (along with the holding cart’s load factor) is printed in sidebar and updated dynamically.
Examine Mode 1/2
In examine mode, player can move PC sprite to inspect the content and load factor of every cart. The result is visible in sidebar.
Unload Item
Items are dropped starting from the one closest to PC. The load/offload order is similar to, but not the same as, “last in, first out” (LIFO). A cart’s load factor is not affected by loading/offloading.
Load Item 2/2
When loading an item, the game only takes visible carts into account. If your cart line is not fully extended, a new item might not appear in the last cart. It does not violate the LIFO rule above.
Examine Mode 2/2
In examine mode, PC sprite can jump between the first and last cart, move forward or backward.
Clean
The first 6 carts are different from additional temporary ones. They are available for free when game starts. Their load factors can be reset to 0 by cleaning. When cleaning, a temporary cart’s load factor cannot be reduced. However, if its load factor has reached the maximum value, the cart is marked as DETACHED.
Remove Cart
A DETACHED cart will be removed when PC moves. The carts that follows fill in the hole automatically.
Trapped
The game ends if PC cannot move in any direction.
Figure 2: Go backward.
I have considered two ways to go backward.
- I: Record PC’s every step. Replay it in reverse when required.
- II: Move PC sprite to a specific cart first. Then turn to a different direction.
Technically, both ways are feasible. However, UI and key inputs could be more confusing. From gameplay’s view, turning around makes PC more agile, so there should be some punishment, but how to balance the benefit and drawback? My answer to this question is a few more questions. Does it make sense to put a resource node (Atlas, for example) in a hard to reach corner? Yes. Does PC have to turn around after arriving at such a node? Perhaps yes. Does it make sense to punish PC for achieving a goal? Definitely no. Can we distinguish turning-around-before-a-node from turning-around-in-the-middle-of-nowhere? Yes, but inadvisable, because inconsistent mechanics is evil.
Leave a comment
Log in with itch.io to leave a comment.