DEVLOG 2023-06-24

Not much progress this week: I had to cancel the livestream unfortunately, but I still manage to progress in some aspects.

I’m mainly thinking about how to write most of the general behavior of the game in a visual-independant way, without adding too many abstractions layers. This is a juggler’s performance to do so really and definitely requires some experience with the techs you’re using.

Right now I’m mainly considering what if it was Hard Glitch, how hard would it be to separate the general graphic and i/o behavior of the game from actual visuals and audio etc.? It seems not that hard actually, but the difficulty is how precise that code is compared to the real representation. For example, it’s easy to have the code that decides which screen to show the player when. It’s less easy to decide which part of the UI they should be displayed because maybe that’s dependent on how the UI is displayed. It might be easier to just expose the model of the game to the visual code (here GodotScript scripts) and then rely on these scripts for all representations. However it would mean having to rewrite the logic of these screens again if I decide that Godot is not ready yet for this game.

As pointed last week, while Godot is very very promising when working with C++, it’s also not really ready today. I didnt decide yet if it’s a big issue for this game. But a better strategy is to just make boundaries where they are best for enabling an easy transition to another engine or implementation of the “view”. In my experience, it’s very easy to find too late a fundamental limitation in a tool, and then decide to change that tool and realise that it’s too much work. I want to avoid that (because I’ve been there and it can kill projects), which is why I spend so much time just thinking about this aspect of it, where to put these boundaries so that I can handle change of such a fondamental piece of the game without a demolishing cost.

There is also the issue of easilly expose raw data (like enums, ints, tables, etc.) to Godot without having to know that it’s for Godot. This is useful also for being able to do serialization of the state of the model. Big things to think about.

Another thing I was wondering about but didnt have time to try yet: Godot 4.x have a new grid/tile system which is supposed to work even in 3D. I have no experience with it but I noted to take a serious look at that as it is quite important for me to know if I can, as I expect to, be able to edit levels inside Godot and make it work in sync with the internal model. It might not be simple because it means being able to edit the tilemap in a way that modifies the model’s world, so maybe I will not be able to benefit from the editor itself. I think I can because you can add code that’s workable at editor-time so it should work, but it needs some experimentation.

Lots of prorotyping again coming next week!