DEVLOG 2023-09-09


Last week I was having power outtage issues in my appartment which forced me to cancel the stream (after having a total blackout in the 10 first minutes of streaming). I found it was the old fridge and had to replace it, RIP my bank account.

This week I was thinking about what we found so far relative to Godot + GDExtension-view + model-in-C++ and revisited the issue threads related to these foundings. Turns out that Godot 4.2, which currently is in it’s 4th dev release (basically alphas) introduces the fundations to allow hot-reloading of GDExtension! Also there is a PR already implementing that functionality, not working for every GDExtensions but it’s designed to let the dev decide and check that it’s actually possible without issues. That’s excellent news for me as hot-reloading would have quickly become an issue in my limited hours of game development (which is financed by my dayjob income of course).

Also I’m also working on another project with a friend to check some stuffs related to Godot 4 (4.1.1 inour case, the last stable version) and make a small game together etc. One thing I realized is that there is less weird bugs so far. There are, but less.

I was thinking and checking all this because I’m getting frustrated to have to check other engines. I would love to be starting the work on the actual game soon. That made me try to see what I should do to get a bit faster on the prototyping and cutting stuffs is the easiest way. So as discussed in the livestream, I decided to not try to build the view of the prototype with Unreal (also because it’s clunky in may ways and probably overkill for my case), Magnum (because it would take a massive amount of time and there is no pre-made 3D editor) which I considered to use because they can be used directly in C++. Instead, I will continue with Godot, but I will focus on making the GDExtension layer the less problematic possible, the more hermetic possible make easy to change engine if I hit a major issue in the future. While Godot seems good enough for this project, I’m still having suspicions. Partially because of the transfer of value-data (like “structs”) between Godot and C++ being quite bad IMO, but also because I’ve seen surprising bugs in Godot 3 that started to show themselves about halfway in a 6-month development time of my first Godot game (which was also in 3D). My current theory is that most of theses bugs were due to the Godot Physics Engine but I’m not an expert in Godot unfortunately and although I did build a custom version to see if I could dive in Godot’s code, I just didnt have the time to do so in the last 6 months. So let’s go with Godot, but carefully.

With that in mind, I proceeded with completing prototype-2 but it’s not done yet. Basically I’m checking the experience of adding new Actions, Events and a basic rule system (simpler than in my previous roguelike but also too limited for MEGASTRUCTURE, it’s just for prototyping) so that we see how much work it is. I added a basic damage system, with death, in the model then wired the view so that I can attack. It worked well without much trouble and was not long to implement. The only missing thing is an animation and removal of a character-view when they die and animation that they do. The attack action targets a position, not a character, so it can potentially target nothing, which is handled. I also implemented a 50/50 chance of evasion if there is a character in the attack range, just to get a feel of it. I didnt have time to do more this week so progressing on that and adding some other basic actions and events and I had a lot of familly events ongoing this week so progress will have to wait next week.

As we approach the end of prototype-2 I’m thinking about prototype-3 whihc is about the action-turn system with fine-grain time to enable high-speed action but perceived in slow-motion. I discussed the idea with some game-designer friends, see if they have some inspirations on the subject, some references etc. The heart of the agreement design-wise is that I will have to either setup an actually continuous time system, or a turn system which is very very fine in granularity and the difference is not actually clear. We now have a lot of examples of the continous time system, using pausing to select actions, like the famous Baldur’s Gate 3 (or Divinity series) and there are smaller games showing combat in slow-motion. Checking all that helps a lot (although I didnt start a game of BG3 for lack of time and focus, just checked a bit how it is played in combat in streamers playthrhough). There are several additional things to take into account for MEGASTRUCTURES however:

  • you can control more than one character (or just bodies - similar to Hard glitch), which kind of matches what’s happenign in BG3;
  • the action system in MEGASTRUCTURES will allow one who have the resources in their body to launch multiple actions in parallel (like hacking while evading bullets), which I didnt find an example of so far;

Anyway all that to say that I’m not sure if prototype-3 and 4 might happen because I’m doing something that could be modular enough to be changed on the fly in the real game. I’ll decide if I’ll switch directly to starting the real game or spend some time playing with the action-turn system before that once prototype-2 is done.

Leave a comment

Log in with itch.io to leave a comment.