I’ve often seen videos where people would explain in depth the inner workings of games and their engines, mainly to explain how a glitch is possible or an optimization technique. For some reason I have been unable to find a video such as that for Godot, while proprietary engines like the source engine and sm64 get plenty. I’m aware that such documentation does exist on the docs, but I find long videos a lot easier to digest when it comes to engine architecture and rendering techniques and the like. If anyone knows any videos providing such info, I would love to see them and learn how the engine i’m developing for is actually running my game.
Could you link an example of such a video, so we know what kind of information you are looking at/for?
Explaining a glitch in Godot could encourage someone to fix it, thus making the video outdated and incorrect, it wouldn’t be particularly helpful to make such videos when the github issues is a better place to report errors. Optimization techniques are written about in blogs, generally speaking it is better to discuss code in text, because code is text, not video.
I dont think he means that he wants to know about glitches, but more like “what automatic function calls happen every frame, in order” or “exactly what happens when a node gets instantiated and added to the scene tree”?
so mainly just seeing how godot is internally handling what it does in a video manner, the most interesting parts of those glitch videos to me was learning about how those games are actually handling everything.
Ive tried looking through the code, but its just been really hard for me to read despite having learned the c++ syntax. And the comments are too sparse to give me a good idea either
Those videos are based on docs and ‘research’ held by individuals.
I don’t think there are any videos that you are looking for. Godot is mostly community-driven, and I don’t think anyone has documented the whole core inner workings. Godot Contributors Chat may be able to give you a little info
I’d just add to what @tibaverus said - good to be curious about inner workings, but prior to diving into that, make sure that you’re sufficiently competent with “outer” workings. Otherwise, you’ll be putting the cart before the horse. Learn to use the engine before digging into optimizations based on inner workings.
These are great videos, some are more game-specific than others of course. I don’t think you will see videos like this on Godot for the same reason I mentioned with bug fixing; the engine is still updating rapidly, where the source engine and pac-man haven’t been updated in a decade or longer, so it’s pretty safe to poke around internally and post a video that will stand up to date for the next decade.
Some concepts do still apply, like the short video explaining a game “tick” differentiating from game time is similar to how Godot processes physics, your defined _physics_process will run 60 times per second (or as defined by project settings) but with a fixed delta time (with few exceptions), processing twice per-frame or more to “catch up” with the game’s frame rate.
RNG has developed a lot over the years and especially as 32-bit and then 64-bit computing became the norm new techniques could be used. Godot’s docs specify it uses the PCG family of RNG techniques for it’s random number generation.
I’m sure if you keep up checking what other engines do, even old ones, you can apply some of these findings to modern engines with little twists. But as @normalized said it’s better to take a top-down approach, make games in the engine and dive deeper from there. Personally I was very stubborn in my own studies, I learned to make games from the ground up starting with command line games, up to frameworks with SDL2, then moving up to Unreal engine. Once I started working with game engines I found it would’ve been a lot nicer to go the other way around, taking what I learn from game engines and applying it to lower level games, such as “visleaf” or octree graphs for collision and visibility, or even pack files for resources to reduce file i/o.
Fair enough, I guess it would make sense that any interesting “quirks” would be patched out of an active open source project and therefore not have videos about then unless some popular speedrunning game had used a specific build of godot that retained it. Just wish the docs would break down how certain classes like dpitextures work rather than having to look through the code to get a grasp of what’s happening. I’ll just focus on my game for now and then look into these when I better understand the use of them.
