Don’t worry, I’ve not dropped the project yet 😊

Actually, for past months I was working hard on something closing the gap between cool-looking static scenes with a rich but boring architectural modding foundations, and a real game having dynamics.

Accomplishments

  • ✅ Added sprites & prefabs: Guard, Stairs, Bunk, Toilet, Boiler.
  • ✅ Reworked rendering system: now entities from floors below the camera floor (or above if camera is underground) are dimmed properly and providing correct hitmap for mouse interaction.
  • ✅ Built foundation for HUD. Rewrote the Debug Overlay with the new API with Stack Panels and other rich UI capabilities.
  • ✅ Added mouse interaction: now the game knows what HUD element or entity on the map the mouse pointer is over! This is the hugest achievement to unblock further development!
  • ✅ Added game wallclock and aging systems: now the world and entities age with time. And it’s visible in Debug Overlay.

Flexing

Ground floor
Ground floor
First floor: the guard and concrete flooring/walls from beneath are properly dimmed
First floor: the guard and concrete flooring/walls from beneath are properly dimmed
Dungeon: entities from above the ground are properly dimmed, while dungeon-located prisoner & water boiler previously hid under ground appears
Dungeon: entities from above the ground are properly dimmed, while dungeon-located prisoner & water boiler previously hid under ground appears
Hovering entities: check their age in real time!

What’s next?

A lot of refactoring, sadly.

I had to rework the rendering system for better tracking of what’s being rendered per frame, so that the mouse interaction system would “know” which entity/tile the mouse pointer is over. This required me to build a transient RenderVisibilityContext holder. And I had no other place to glue the MonoGame part and the Core of the engine than the World. So, now the ECS World has knowledge of the rendering visibility context. This is dirty and would confuse modders, especially those who would dig into the World with Lua. I’ll need to bring up another layer of gluing things between the engine and the MonoGame renderer.

I’d also like to break down the current monolithic RenderSystem and make it as a… plugin. Same logic as with the TextureAtlasBuilder: the game would provide a reference implementation, but an advanced modder could alter it. Why one could ever want to replace the RenderSystem? For instance, because someone may disagree with the current multi-floor rendering logic, and to provide more customization for a user.

The mouse interaction system is now tightly coupled with the MonoGame lifecycle. I’d like to make it out to a plugin as well. Let a modder to decide whether they want a user to interact with entities mismatching the camera active floor.

Another issue is with keyboard handling. It’s also monolithic and tightly bound with the MonoGame lifecycle now. I’d like to decouple it and introduce a configurable keymap, so that a player could assign different keystrokes for actions. It’s what a lot of games lack of, nowadays. Mine wouldn’t suffer from that.