Summary
"ServOS" is a single-player simulation-puzzle game where you monitor robots and fix them. Through mini-games, it satirizes the relentless grind of productivity and how easily workers are replaced in oppressive systems.
"ServOS" is a single-player simulation-puzzle game where you monitor robots and fix them. Through mini-games, it satirizes the relentless grind of productivity and how easily workers are replaced in oppressive systems.
Genre: Work Simulation, Strategy
Engine: Godot
Team Size: 4
Platform: PC
Engine: Godot
Team Size: 4
Platform: PC
Contributions
Game Design
Designed quota/energy/overclock core loop
Balanced escalating quotas & failure states
Designed the Overclock for a risk and reward button
Programming
Implemented CCTV multi-camera system
Scripted quotas, dialogues, overclock & post-it events
Developed minigames & global state manager
Narrative Design
Collaborated developing dystopian story, boss messages & hacker group interjections
Embedded narrative through post-its & quotas
Embedded narrative through post-its & quotas
Research
Studied surveillance aesthetics & labor exploitation systems
Inside the Process
Designing the Loop
When I started building the quota, robot energy, and overclock loop I asked myself how to make players feel the grind. Quotas became the obvious choice, always hanging over the player as a number to reach. Energy was another simple minigame and a constant hurdle to keep robots working. Overclock was meant as a tempting risk and reward button. It feels powerful in the moment, but if used too much it consumes more energy, forcing more work.
Keeping the Loop Fresh
The minigames came from not wanting the loop to feel stale. After the first playtest with only the ability to recharge robots, the experience felt incomplete, even if repetition was part of the goal. An iteration was needed, and from that new minigames were made to keep the game more entertaining while still carrying the stress of time pressure. Having them on the main screen, while also watching cameras and robots malfunction, was meant to create pressure and stress as confirmed in later playtests.
Balancing Workstations and Robots
When I started balancing the game I kept coming back to the relationship between the number of workstations and the number of robots. Every new workstation meant more tasks piling up, and every robot added meant more things that could break down. That tension was the backbone of the balance.
Level Design as a Balancing Tool
But the numbers alone weren’t enough. I realized the level design itself had to carry part of that weight. The way rooms connected, the distances between them, and even choke points in the layout shaped how quickly players could react. If the pathing was too open or too short, the pressure disappeared. If it was too long, the game became frustrating. Finding that middle ground was where the real balancing happened.
Surveillance as Gameplay
The CCTV added another layer. Six cameras, one for each room, meant the player never had full information at once. They had to switch perspectives, monitor different areas, and constantly process partial information. That choice wasn’t just thematic but mechanical.
