DEVLOG 2023-07-08

In the previous week I totally forgot to write a report, sorry about that. But in the same time not much happened that week other than I resumed the livestreams on Wednesday and we managed to see a C++ debugger break in the middle of a Godot game execution. That was interesting.

This week, I have been thinknig about various things related to the Godot/GDExtension usage and limitations. I feel the need to go a bit farther in my experimentation to see for real the impact of chosing Godot instead of some obvious alternatives (keeping the model in C++, so that reduces the number of alternativeS), and the idea of having the C++ side of the code “direct” the view implementation in whatever language needed. Because that last point might or not be a good idea, depending on the level of abstraction set in place.

I then decided and anounced, described and explained in last livestream that:

1. I will try to implement the “view” of the prototype into Unreal Engine too (and some other alternatives, see below);
2. but first I will attemtpt to setup that “director” layer of code that should be the same whatever the view implementation.
3. Finally, the basic roguelike game being used for prototyping needs to be a little more complex than it is now. This is mainly so that what we are trying matches a realisitc game design and constraints.

Once announced, we started the live by making a diagram showing what that “director” layer would look like in the general idea (it’s in the prototypes repository). Then we proceeded to insert a list of things to add to the game to make it more complex into the trello-like project thing on github.

I then proceeded to coding. The first thing was to start making the view get “events” instead of having to re-build the whole graphic scene based on the new state of the world after some turns passed. This pointed that so far I didnt really provide different events for each effects made by an action, so I set that up. It took some time in the livestream but we got it working (although it broke gcc build, but gcc misses some standard headers…).

So the work being done right now is continuing in that direction. After the stream, “Colin Bellino” contacted me on Mastodon to ask:

@klaim Hey there, i’ve been following your experiments to use Godot and now Unreal as a view layer, very interesting stuff :) I’ve been wondering, why chose fully featured engines for this, instead of just a renderer or framework? Thinking of things like The-Forge or sokol_gfx.

Which is a super legitimate and interesting question, so I answered:

I would actually prefer a renderer or framework but the core issue is will it make me spend more time on the engine glue than on the game or not? I’m considering full engines first because at least part of the visuals of the actual game would be “fast” to implement. However, I usually prefer frameworks of libs with custom clue, and that’s still an option, I might explore it if I decide it’s still worth the time The crux of the issue is that I want the game to be played in a 3D grid, which means you need to have proper 3D edition tooling specific to the game, and having a full engine helps with that. BTW I dont know The Forge or sokol_gfx, but I did listed Magnum as a potential framework (+Dear IMGUI). I rejected bgfx and some other similar libs. If it was 2D I would just slap SFML on it and proceed haha I guess things would be different (and go far faster) if I was full-time on this project, which is unfortunately not the case haha

I wanted to add: I’ve been using game-specific libraries-glued-together frameworks in the past, setup and that’s my go-to way to do things when I can. The thing that really scares me is the 3D aspect of it, which makes it longer to develop. If I was full-time on this project, I would totally go with a custom framework as it would mean total control over the details and ability to adapt. Actually, maybe one day I will ditch Godot or whatever solution I start the game with, after getting enough fund to be full-time on this game? One can dream XD

This exhange made me think that I should be able to add a few other frameworks to the prototyping plan for implementing the “view”, and that would help me figure out how to do the “director” layer at the right boundary of abstraction for this kind of game. So I added in the trello-like project on github a few frameworks I might use.

This is all part of the 2nd protoype project, the 3rd and 4th being more about the spatial structure and the action-turn system I’m planning. Lots of questions to look answers for!