Opening doors with a Modular Design Process

As I get further along in Floppy/Write’s development, I’m seeing more and more value in building actors and objects in a modular way. This week, I created a more advanced event system that spawns dynamic event objects with a wide range of properties. Sometimes these act as patrol points, other times they trigger animations, UI events, aggression, dialogue, or physics interactions.

The system is built from two core pieces: a utility/controller object that gets added as a component to all characters, and the dynamic event points themselves, which can be placed or spawned in the world to make things happen. These event points communicate with the character components to trigger gameplay actions. It’s nothing revolutionary, but for me, this shift from a single-script system using persistent map assets to a modular, runtime-spawned setup has made iteration feel way more accessible — especially as I write the story.

Narrative is going to be a huge part of Floppy/Write, and having this system (plus a simple breadcrumb object — a lightweight marker used to guide narrative progression or trigger specific events) frees me up from constantly worrying about technical constraints while writing questlines. I originally built this just to clean up and reuse code, which it definitely does, but I didn’t expect the modularity to actually expand the scope of what I can do without sacrificing manageability.

Next, I’m planning to apply this same modular approach to refactor the NPC code. Right now, my enemy.gd script is 793 lines — not even including weapon or behavior logic. My plan is to break NPCs down into several components: movement, pathfinding, state tree, dialogue and identity parser, weapon system, and a few utility scripts to hook everything into the player’s notebook (which also just got a modular rework).

This should make it way easier to tweak the controller logic without getting bogged down in data sorting or syncing unrelated processes. I’m still pretty new to GDScript, but I like it a lot for what Floppy/Write needs.

The notebook rework has probably benefitted the most from going modular. I’ve built a proper desktop interface for the in-game laptop, complete with draggable icons that save their positions, interactive word processing windows, and some basic organizational tools. All string data is stored in a CSV, split by app and character ID, which is then parsed in the DialogueManager to trigger events.

The real reason I did this? Typing on the Steam Deck is annoying — and I want to play Floppy/Write on my Steam Deck. So the word processor app will always be there, but thanks to some ideas from my brother, I’m adding more controller-friendly apps: Contacts, Calendar, Chat History, and a Xen Server. These will mostly use fill-in-the-blank or button-driven interfaces so controller input isn’t a chore.

This has some serious gameplay implications. I now have several interfaces for generating player hints and notes. For example, I can unlock options in the Contacts app only after an NPC spawns their “contact card” event. Or, if a player knows an NPC’s name but not their address, I can reveal their house number later — maybe in a future map app (if I build one).

All of this opens the door to big quality-of-life improvements. I had kind of resigned myself to the idea that the controller interface might always feel clunky, and that I’d just make the narrative really, really good — and maybe that would be enough for a few people to love it. But now, removing the tedium is actually possible, and suddenly this feels like it can be something far more accessible.