Progress Update: Staying on Track and Avoiding Burnout
I spent some downtime on vacation deciding what to work on next—evaluating what was actually the best thing to focus on, being honest about what was scope creep, and figuring out what would be both fun and engaging to prevent burnout while still staying on pace.
Something I realized is that I’m actually pretty far ahead of schedule. Originally, when I got back from vacation, I had planned to work on the turn-based system. I even improved on the state machines I used to make (I’ll talk more about that later).
But ultimately, I decided to work on the UI for moving units instead.
Selection Cursor and Unit Movement
I had a really productive three-hour session working on a movement system that I’m really happy with. I think I could make it a bit more scalable by adding Signals, but for now, it’s working well.
Signals are something specific to Godot, and I can always resort to them if anything ever becomes too tightly coupled. I remember reading somewhere that Signals are best used when needing to communicate upwards in the hierarchy rather than downstream. Hopefully, it will be clear when and where to use them whenever I need to refactor.
I also got to show off what I built—the Selection Cursor—to my friends and cousins on Discord. It was great getting to share progress!
Man, I really need to figure out how to attach images and videos to this blog so I can properly showcase my work. But to be fair, this blog isn’t about showing off—it’s about accountability. I’m sure one day I’ll care enough to figure out media attachments, but for now, it’s not a priority.
Eventually, I’ll probably start a YouTube channel or other social media for marketing the game, but that will come later—probably after I have a fully playable demo. It might even be fun to do dev vlogs, and I’d be willing to restart the project and do some light refactoring for that. Even though that would take time, I think it could be fun and helpful for others trying to build something similar.
Struggles with Unit Tests
One thing I really need to decide on is what to do with my unit tests. Right now, most of them are broken, but that’s because development is still early, and things are constantly changing.
To be honest, I’d rather use my motivation to work on new and fun features instead of spending time fixing tests for features that are still evolving. I keep telling myself that once the vision for the game becomes clearer, I’ll go back and fix the tests—maybe even using AI to help generate them.
I’ve noticed my unit tests are blurring the lines between unit tests and integration tests, and every time I add a new feature, I have to constantly update them—which isn’t fun right now.
I’m sure I’ll get back to unit testing, especially since I want to improve my skills for work. But for now, I’ve been on vacation, thinking a lot about fun features and how to implement them. So I’d rather get those ideas out of my head and into the game while my motivation is high.
Speaking of which, I should really go back and update my GitHub project.
Next Steps: Turn System or Overworld?
The next thing I want to work on is either the turn system or a small overworld that transitions into the battle scene.
I had some time over vacation to think about this, and I’m realizing it might be better to delay the overworld for a while—maybe even until next quarter or later. I think it’s a really good idea to fully define the battle scene first—know how it looks, how it works, and what data it will need—before setting up an overworld to transition into it.
I’ll probably need some kind of singleton or manager to store player-related data, like party members and inventory items, since most of that information will need to transfer over between scenes. So I might push the overworld off until Q3 or Q4 to minimize rework.
Looking Ahead
Next week, I’ll let you know how implementing the turn system goes.
Thanks for the support!