03 / Video game
Job Hunt Simulator
A room, a résumé, and a clock that keeps moving.
- Role
- Cesar Delgado · game direction & development
- Status
- Godot prototype · demo in progress
- Technology / medium
- Godot · GDScript · data-driven simulation
- Focus
- Systems design, simulation architecture, validation
- 60 seconds
- Per in-game week at normal speed
- 15
- Authored general events
- 3–4
- Scheduled general events per run
Turn the job search into a system
Job Hunt Simulator is an in-development Godot game about applying for work while managing time, money, energy, confidence and composure. The player improves their résumé, navigates assessments and interviews, takes restorative activities and decides whether to sell belongings.
The playable prototype centers on an apartment and the tasks reachable from it. Its audience is players interested in management games and social simulations: ordinary actions become difficult because resources, hiring delays and personal capacity interact.
Scope the demo around one complete loop
The current loop joins the job board, application stages, delayed hiring responses and consequences inside one simulation. A separate catalog contains 15 general events, with a target of three or four scheduled per run. These are implemented prototype boundaries, not a claim of a public release.
Let uncertainty land before time resumes
Separate arrival from revelation
A hiring response first appears as a neutral notification. Its outcome is revealed when the player opens the email, so the interface does not spoil a pass, rejection or offer before that action.
Pause consequences coherently
Pending responses hold the simulation. An interrupted activity keeps its progress while the player reads and acknowledges the queue; normal time resumes once the hold is cleared.
Use events with conditions
Events can require a working laptop, an earlier rejection, portfolio work or rest. Eligibility rules connect narrative incidents to the actual run instead of selecting text without context.
Make the apartment meaningful
The room is the interface to activities and belongings. Selling an object affects the available state, so the visual environment and the resource simulation need to stay consistent.
One clock, several interacting systems
The GDScript implementation separates the continuous game clock, player state, activities, applications, hiring responses, contacts and general-event scheduling. UI scripts consume these systems rather than using independent real-time timers for each incident.
The clock converts real seconds into game days using one balance value: 60 seconds per in-game week at normal speed. The simulation owns event boundaries. General events use their own random-number generator, eligible pools and in-game deadlines, which makes seeded scheduling checks possible.
- 01Take an actionStart work, rest or an application
- 02Advance game timeResolve scheduled boundaries
- 03Response arrivesHold the simulation; show a neutral notice
- 04Open & acknowledgeReveal the outcome; resume safely
State that must not change twice
Application performance is captured at submission, so later study or contact changes cannot rewrite a result already awaiting review. Response handling also needs to reject repeated callbacks, retain manual pause and speed settings, and prevent an object sale from completing twice.
Keeping that behavior in the simulation makes it possible to test the same rules without relying on the visual apartment. The tradeoff is more explicit coordination between systems, in exchange for a single account of what happened and when.
Test the boundaries between systems
Simulation and event checks
The repository includes headless checks for event eligibility, scheduling, seeded campaigns, time boundaries and resource effects. The event catalog and its three-to-four-per-run target are present in the current implementation.
Response-flow checks
Dedicated tests cover queued notifications, hidden outcomes, pause and resume behavior, interrupted tasks, delayed scoring, stale callbacks and the ordering of expenses versus hiring responses.
Interface checks
The response-flow tests also exercise the actual email controls, viewport fit, keyboard focus and the prevention of clicks passing through a modal into the room. These are prototype test assets, not reported player research.
From integrated prototype to reviewable demo
The next useful milestone is a bounded demo pass: verify that a new player can understand the room, submit an application, respond to an interruption and reach an outcome without developer guidance.
Pacing and difficulty still need observation with players. A reproducible seed and the existing automated checks can help distinguish a balance problem from a timing or state-management bug during that review.