Devlog #2: Systems, systems, systems
I'm still going! Motivation has waned very slightly while Kate and I find ourselves obsessively playing Blue Prince in the evenings...and maybe a bit too much on the weekends...but a project like a whole-ass video game is a marathon, not a sprint, so I'm not too worried.
I ended up switching from GDScript to C# shortly after my previous devlog. The way GDScript is integrated directly into the Godot workflow is cool, but the language itself simply felt clumsy to work with. The tradeoff cost of having to wait a few seconds for the .NET project to build before I can test changes has been negligible at worst, so I haven't looked back.
Most of the work I've done so far comprises various data-driven systems:
- Scene management and transition (loading and swapping scenes, moving between different rooms, etc.)
- Robust, configurable dialog, conversation, and cutscene systems
- Very decoupled movement, animation, and camera systems
- A natural-feeling "follow the leader" algorithm for non-controlled party members
- Game-state management
- Interactivity (opening chests, starting conversations, etc.)
- Localization support from minute one
The plan is to be able to get to a point (relatively) early on where much of the work of making the game becomes simply...data generation. There will always be more code to write, of course, but after a certain point, it should be minimal.
I'd upload a video of some of this stuff in action with my sweet Chrono Trigger placeholder assets, but I am currently refactoring my solution to move a lot of data models into a shared library with the intention of building a YAML-to-Godot-resource tool that slots into my build pipeline, so I'm not in a runnable state.
Although Godot's built-in inspector is pretty sweet, trying to use it to configure anything other than very simple objects quickly becomes a nightmare of nesting:
This is disgusting. The overwhelming majority of the time, I will not need to configure most of these options. I don't need to or want to set speaker name overrides or non-default positioning/advance configurations for every chat bubble. Almost every chat line will be a static chat line. And so on.
So the plan is to be able to script things like cutscenes and conversations in very lean YAML files that, during the build process, automatically provide sensible defaults for all that stuff unless explicitly provided, so that I can just write the YAML equivalent of "Bill says 'Hi'" and be done with it.
Once that converter's done, I have three more fundamental systems to work on: persistence, UI, and combat. I'm saving combat for last, because I expect it to be far and away the meatiest system in the game. But I'll get there eventually! Until next time.