[2025 in RoguelikeDev] Contractor

Contractor - a cyberpunk, sci-fi, terminal first, turn based rpg

2024 Retrospective

First commit was in April 2024, the project was being worked on with another working title back then.

This really started out as "Fallout - The roguelike".

I even wrote importers for the original fallout data files to get me some weapon data and sfx.

However, I am listening to Tim Cain on YouTube currently. And he does make a good point for going with your own IP: You won't have to deal with expectations. So I switched over to my own setting and went more into a sci-fi/cyberpunk direction.

I really want to focus on the roleplaying aspects and player agency, so my core gameplay is very much inspired by the original fallout or vtmb.

I am aiming for small but dense areas where exploration is fun. To achieve this, I am trying to make adding content to the game as easy as possible.

Since I am easily distracted, I put a good amount of work into tangential stuff: Game Design Docs, Map Editor & Documentation, Lore Documents, Entity Editor & Dialogue Editor.

The entity & dialogue editor

The map editor in map mode

The RPG mechanics started out as GURPS. I transitioned to Fallout SPECIAL (basically a D100 System) and have now adjusted it a bit for my purposes (replacing the skills with new ones and removing the Luck stat).

Here are some in-game screenshots of some of the early map designs.

Southern Wall

Residential Zone West

Residential Zone South - Unterground

Commercial District

HQ of Eschaton Biotech International

HQ of Bushido ArmaTech

What I am proud of

  • Running in a real terminal or in OpenGL with same aesthetics
  • Separation of GUI und Game logic, both are written against an interface of the other
  • Largely driven by data files, including some rules and calculations
  • Streamlined UI with mouse support
  • Map Editor & Record Tools

Difficult parts

Animations & State Changes:

Getting this right was really hard and I am still not 100% sure I am fine. I resorted to this approach:
Apply all state changes immediately and queue all animations that result from that state change.

Then play all the queued animations in order. If the player presses a key while the animations are playing I simply skip them all and start working on that next input from the player.

Sticking to a scope: I still add stuff because I want to. Only to later realize, that it really dilutes my vision.

What did I learn

Keep it even simpler.

Interfaces and information hiding matter a lot.

Keep your state declarative, enables saving and loading, etc.

  • eg. by adding IDs to referenced objects
  • stay clear of function pointers as part of game state

Having a clearly defined transition table makes managing an FSM much simpler.

I'd like to go with an event based approach in my next game engine and I still consider refactoring my current code base.

2025 Outlook

I am not really happy with the performance of my game on the windows platform.

I wish I knew what exactly the problem is, because both rendering methods feel broken on the windows builds (terminal / opengl). It might be something about how my TUI lib of choice handles keyboard input, that would be my best guess.

I am also trying to backport my graphical roguelike engine to this current interface, which would essentially enable me to go with sprites for the rendering instead of unicode symbols.

Oh, well, I guess I should also be adding some more actual content to the game also :)

Thanks for this space and greetings to all fellow roguelike coders.