[2024/11] Dev Blog: Rethink Game Design

• Demo: https://youtu.be/sufBq5gWVwE
• GitHub: https://github.com/Bozar/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.

I have been very busy in the past few weeks. I had little time in coding, but was still able to think about game design, which was exactly I needed. I will share my thoughts in this blog post.

Game Demo

First of all, let’s take a look at a game demo. The source code is hosted on GitHub and tagged as blog_3.

The demo shows three aspects of the game:

• Label 4, 7: The main resource flow: raw files -> files on desk -> Document.
• Label 1, 5, 6, 8: PC faces various obstacles when he moves around.
• Label 2, 3, 9, 10: PC can take a few ways to overcome the obstacles.

As mentioned in the first blog, the main resource flow involves three nodes.

• Raw files (Atlas, Book, Cup and Encyclopedia) are generated automatically.
• PC delivers raw files to a Clerk.
• A Clerk converts raw files to a Document after a few turns.
• PC delivers the Document to an Officer.
• When an Officer receives a Document, he stimulates the production of raw files.

Label 4 and 7 in the demo show two segments in the flow. Note that you can check cooldown or progress in Examine Mode. When a raw file node or a Clerk shows 3, it means the node or the Clerk is 30% ready to produce a new file, or a new Document. When a file on a desk shows 3, it means there are 30% pages remaining for the Clerk to read. The file disappears when all pages are read. Besides, you can see in label 7, even when a Document is ready, it will not show up until at least one desk is empty.

PC spends most of the time move around in dungeon. His Carts accumulate drafts along the way (label 1), which is the main obstacle of the game, because when a Cart is fully loaded with drafts, it cannot carry a file any longer. To make things worse, a raw file node’s cooldown time increases every time PC receives a file from it. And only one Officer will be available once the first Document is sent (label 8). A Servant becomes inactive if he is left alone for too long (label 5), which increase cooldown time for all raw file nodes. Pushing a Servant makes him active, but it also reduces a Clerk’s working progress (label 6).

In order to decrease a raw file node’s cooldown, PC can push a Servant away (label 3). Doing so also prevents Carts from loading drafts (label 2). PC can also earn salary from delivering a Document (label 9), and use cash to clean Carts (label 10).

You might have already noticed the Service symbol near the center of the screen. It changes every time a raw file is unloaded. But since I have already decided to redesign its function, let’s just ignore it for now.

Looks good, but …

There is quite a lot of coding behind the scene. You can even beat the game by delivering 10 Documents, which is not shown in the demo. However, after a few playthroughs, I found that the game was not challenging or interesting. A player can simply leave a thumb down on Steam and go on to his next game. A game designer and programmer, on the other hand, has to answer why and how.

This is not the first time I encounter such a situation. The game mechanics looks reasonable and fun on paper, but is flawed after being implemented with code. The dungeon layout of my previous game, Ghost in the Swamp, was rather banal initially. I dropped game development for a few months until I finally figured out a way to improve the design.

Based on my previous experience, I still don’t know how to avoid the problem beforehand. But when it occurs, I should stop coding right away. Analyze my game experience and discover pain points. Take the time to find out solutions.

What goes wrong?

Firstly, I noticed a user experience issue. A raw file node becomes a rectangle after it sends a file to PC (see label 3, for example), which indicates that the node is unavailable at the moment. Player can check its cooldown in Examine Mode, but there is no way to know which file it sends. A node’s file type should always be visible. If the node is inaccessible, it shows a out-of-service symbol in Normal Mode, and its cooldown time in Examine Mode. I can think of an easy fix for this problem, therefore it’s not worth mentioning here.

I cannot find any obvious issue in data balance. The real problem, I think, lies in game logic.

Resource Flow and Garbage Time

My first suspicion about flawed game logic is that the resource flow might be too simple. More specifically, I’m talking about the final step in the flow: from Document to raw file nodes. Currently, after an Officer receives a Document, all raw file nodes’ cooldown time are reduced automatically. What if PC has to deliver a few special files from an Officer to a raw file node, and improves its production rate manually? After further thought, I decided to keep the existing mechanics as is. Delivering a Document to an Officer is a hard task. Player needs a strong, immediate reward, rather than to save the princess in another castle.

I also noticed that I spent some time to move aimlessly in dungeon, because raw files were not ready, and all Clerks’ desks were occupied. Ideally, PC has one of five goals at any given time.

• Deliver a raw file to a Clerk.
• Deliver a Document to an Officer.
• Reduce a raw file node’s cooldown.
• Draw cash.
• Clean Carts.

The main issue here, I think, is that it is not so urgent to reduce cooldown as quickly as possible. My solution is to raise punishment. Previously, by game design, PC loses the game if all Carts are fully loaded with drafts and he cannot pay to clean Carts. If the game ends once all Carts are fully loaded, a player will be more motivated to stimulate raw file production.

With Great Power Comes Greater Challenge

Another problem is that PC’s ability, and the obstacles he faces, do not grow properly as Documents are delivered. PC earns salary by delivering Documents and draws cash from an Accountant. Money is power. But how to use it? After play testing, I find out that only two types of services are useful under any conditions: clean Carts and extend Carts. Therefore, there will be two service stations that is available when the game starts. PC will also be able to unlock more temporary stations when he becomes rich.

An inactive Servant (see the demo above, label 5) increases all raw file nodes’ cooldown. As more Documents are delivered, there will be more Servants in dungeon, which result in even longer cooldown time if not handled properly. Part of the challenge comes from data progression in this way.

In order to further increase difficulty, I’d like to introduce two new mechanics as time goes by. A Clerk will require a specific raw file. There will also be traps on the ground. When triggered, it forces PC to wait a few turns. PC can push a Servant into the trap to disarm it, or simply walk around to avoid it.

Another type of power comes from a longer line of Carts. Currently, Cart length does not matter much. I think more Carts should grant new abilities to interact with Servants. PC with 4 or more Carts will be able to load a Servant in addition to a raw file. The Cart with a Servant in it will no longer accumulate drafts. The Servant can be dropped at a raw file node to reduce its cooldown, or at a trap to disarm it.

I write down a TODO list as a summary.

• Add progress bars to raw file nodes.
• Implement the failure condition.
• Remove obsoleted service types.
• Add temporary service stations.
• Let Clerks be more demanding.
• Add traps.
• Grant more abilities to a long line of Carts.

With the list in hand, I will be more confident when I finally have time to sit down in front of my laptop and start coding.