Devlog: Maintenance and refactoring

Nov 30

I spent one hour researching ways to export extra color channels for every mesh vertex from Blender to Godot through a GLB file, which is quite silly - both Blender and Godot can handle that kind of metadata, but they can't be communicated from one to the other, at least not with that format.

I debated ways to include both multiplicative and additive color in the same basic channels, but in the end it's really just not viable, not without losing a lot of basic properties I will also need, like simple vertex coloring.

And that will be important, as texture mixing is just too much for me to add to every level without a developer team to help me. So, studying old games, I noticed that they sometimes (when they did it at all) replaced texture mixing with vertex coloring. Use it correctly and you'll get a lot of mileage out of it.

So, in conclusion, I'm just going to keep two separate shaders, one for multiplicative color and one for (inverted) additive color. They're both simple enough to use and let me build levels quickly and efficiently.

Dec 1

Checkpoints are now fully functional, the player is automatically teleported to the last visited out upon death. These will simplify level design a lot, I no longer have to hard-code their positions manually, but place a few statues around and it'll all work just fine. I also fixed the animation of waving flags which, surprisingly, I had already fixed on Blender ages ago, I just kind of forgot to export them to Godot again.

And I added symbols to the boulders on the slide hill puzzle of the prairie level, to make it fairer (or not, depending on the chosen difficulty level). Those were a little tougher to add than I expected, as they are supposed to disappear along with the rocks when they're smashed, but I got the job done.

Dec 3

I spent one hour rubber-ducking some friends (which are therefore now entitled to a spot in the game credits, under "rubber ducks"), but I think I have a plan to reprogram the camera manager efficiently. First, having the camera parented to the focus was a dumb idea, I can very easily replicate it with just maths. And I love maths. Because of my 'tism.

By default, the camera focuses on (a point slightly ahead of) the player and is controlled manually with the joystick or the mouse; in battle, the camera focuses on a point midway between the targeted enemy and the player, and is controlled entirely by the camera manager so the player can focus on fighting.

In cutscenes, both the focus and the spherical coordinates of the camera and programmed and the camera pans towards them at the speed the scene requires (which may be just ∞ for teleporting). In levels where the camera must be fixed or on rails, the focus point behaves normally (ahead of player or between player and foe), but the euclidean coordinates of the camera are handled entirely by the level.

Camera rumbling is trivial in all cases, extremely easy to add, not an inconvenience at all. However, no camera tilting. We don't do Dutch angles in this house.

Dec 6

Happy Spanish Constitution Day!

I've been refactoring the code for the camera manager and, of course, that has broken everything because it was all coupled as all hell. Understandably so, since it was obviously one of the first classes I had to implement for the game to be functional.

I'll invest a few days to tidy it up, along with the global class handling most of the communication, since it contains a lot of junk that is either never used or can be done a lot more efficiently. It shouldn't cost much and it'll make future development a lot quicker.

I'm going to keep all camera movement lineal for the most part, although player control will still be spherical for simplicity. Surely I can afford a couple of extra float values in a singleton object, to store the yaw and pitch. Heck, I could even recycle part of the lineal data as spherical, if I really wanted to optimize the memory usage.