DEVLOG 2023-09-23

We made some slow progress this past 2 weeks and had a lot of thoughts, obviously.

Last week we had a gamedev stream and some progress, this week I had to cancel the stream but we continue next week. (as a reminder: I’m working on prototypes checking some technical aspects of the game I’m working on, MEGASTRUCTURES) Basically I have been adding some basic features to the prototype like ultra basic combat (width dodging). As mentionned in previous devlogs, this is to stress and observe the experience of adding features to the game when most of the game logic is in C++ and the rest is in Godot through GDExtension. So far adding new features based on the current setup have been a breeze, with separate passes on the “model” and the “view” sides of the game. I think in the real game I will setup something like an “default placeholder” for actions and events so that something generic happens visually if I add new actions and events in the model but not yet in the view. Currently they will be executed as expected but the view will not be updated at all if I dont add specific code. In the case of defaulting the view update, the idea would be to at least rebuild the whole view because we didnt have the code to just update it yet. That way I can implement a lot of things just with adding features in the model and still see visual feedback in the view, then I can focus on adding the handling of events on the view-side. That will be useful in the real project.

Meanwhile, you have probably seen and continue to see the debacl of Unity doing it’s thing starting last week. This have been a very noisy and entertaining and stressful time and continues to be. As someone with a bit of experience with Godot (and Unity but I stopped using it few years ago), I helped some people get aware of the advantages and disadvantages of Godot from my POV, what I think works well, what doesnt etc. There has been a lot of discussions about how (and why) to start working with Godot.

When I read the thread from the Caves Of Qud main author about his attempt at making Caves Of Qud build on Godot, I was glad to observe live a succesful project that followed a similar architectural logic of having a clear and (somewhat) hard separation between the view and the model of the game. That’s what I’ve been advocating here from the beginning, however there are several ways to do it. Apparently, in the case of Caves of Qud the separation layer was actually higher than I expected, because at the end of the transition he could display the game as asciiart. Most of the api conversions he had to do were on the few calls to the Unity engine that were sparse compared to most games. This means that the whole game, more than the model of it, except the direct layer of display and audio and input, were isolated (somewhat). The state machine of screens, like the main menu, charadcter creatoin etc. were abstracted away too. I guess the asccii art served as the communication layer with the display.

This is closer to the separation layer I was describing before there is a “director” layer which tells in high-abstractions what is happening, drives both the ui and screens and state of the game, but doesnt implement everything directly. While I made some diagram explaining this, I didnt yet took the time to attempt to do that in the prototypes and it’s kind of hard to set the exact separation in the context of GDExtension, but it’s still interesting to pursue. I’m not sure if I will have the time to try that in the context of the prototype, I might just focus on it in the real game, but at least I am now even more confident that it’s a good idea to do so.

It’s a good idea because for long-term game development, it means we have, at worser, a way forward if we find the tools problematic. While helping others consider other engines than Unity, there was also discussions about the possibility to just make their own thing, glueing libraries they want to use together to make a game. This is something I have experimented with in the past and could give my experience with that. I think if you have the time and budget to do so, it’s always the best approach for a long-term development EXCEPT if you’re doing something in a 3D space (it’s fine if your render in 3D but your world space is a grid for example). This is because if the space is continuous and in 3D, you want to be able to easilly move things around and that means you would have to have an editor more complex (although feasable) than if it’s a grid. So for 3D games I tend to prefer going with a full-featured editor-based game engine. This is why I took an hybrid approach with MEGASTRUCTURES. However there is still issues with my hybrid approach which are removed if I was doing the game-specific-glued-engine approach and this situation made me reconsider things.

As long as the real game is made with all the separation layer well defined, I should be fine either way for MEGASTRUCTURES. Meanwhile, I started to prepare the work of packaging Magnum for my build-system-and-package-manager build2 to open the possibility in the future. Dear IMGUI is already packaged and usable so making a game-specific editor is a possibility, although requires some time to setup. I might not go with that game-specific-glued-engine approach ever for this project but we never know. After all, Godot 4 clearly isnt perfect and I always am scared of it’s issues preventing me from releasing a version of the game, like Godot 3 did for my first game made with it. I might also not go with Magnum specifically, if I find too many flaws, but it would then be easy to switch to other solutions for specific needs, or to build my own if I feel like it’s the right way.

On another note for people who are interested specifically with my experimentation of GDExtension: I didnt try it yet but have been following the developpement for GDExtension hot-reloading feature which is currently targetted to be provided as experimental in Godot 4.2 (not sure it will make it though). So far some people pointed some issues but the general thing seems to work from the feedback you can read in the pull request discussion. I noted to attempt to try it and help debug if I can find the time but dont count on it as I’m kind of overloaded with work already.

I’ll continue adding basic features as planned to the prototype so we get something realistic, a super basic roguelike, and can start the next prototype from that soon… or maybe I’ll start the game directly as the next prototype is less important technically. I’ll keep you up to date on that.