Learning to Crush

First ever post about my first ever video game Bit Crusher, coming out…eventually. I literally started working on this last month so there is no concrete long term plan whatsoever. I've learned from the many many mistakes of other industry giants that any sort of promises made too early on will basically always come back to bite you in the ass, so I'm not setting any expectations here. At least, not yet. Additionally, I don't really want to put myself in any sort of box: maybe I work on this for a couple months and make something kind of neat, maybe I work on this for two or three years and make some straight heat. Either way, what I know for sure is that I want to document my progress and my work and potentially get some super valuable feedback. I have an idea for where I want to take the game genre/direction wise, and I'm currently planning to make it in Godot considering that it's free, open source, and not UE5. But all of this is very subject to change.

For those not super in the know, Godot is a video game engine. In the same way that you use Photoshop to edit pictures and CapCut to edit videos, you can use Godot to make video games. Emphasis on "can" here: coding everything is an option, but I'd rather work smarter not harder here. Much like the grand multitude of options there are for photo editing software and video editing software, there are more than a couple for making video games, called "game engines." Many different professional game studios have their own game engine made in house, but there are a couple that are publicly available. Examples include Unity, dog shit computer shredding unoptimized slop machine Unreal Engine 5, and Godot. Part of why Godot interests me is the fact that it is open source. I would consider myself quite an aspiring computer whiz, and frankly, I would love to one day build a game engine much like other studios have done, but on top of Godot. However, I would be pretty out of my depth if I tried that now, so first, I want to get familiar with using Godot. Starting out, I'm not exactly setting out to make anything crazy yet: I'm well aware of the rule of thumb of not making your dream game for your first game. Starting off, I'm just mostly trying to learn the tech. To reign in my scope a bit, I'm going to be rebuilding this old game I made a few years ago when I was learning how to code in Java. It wasn't anything crazy, but I think the foundation had some potential. Plus, maybe lightning will strike during the beginning stages?

So, I dove into Godot having watched maybe one YouTube video, like a complete idiot. I started with the version of Godot that supported C# because I thought it might give me some mobility—if Godot didn't do it for me, I'd at least have some C# experience if I ever wanted to move to Unity or…okay not Unreal Engine. No thanks. In hindsight though, choosing to use the Mono version was an… interesting choice.

At first, I hard coded nearly everything myself. I ignored Godot's built-in scenes, signals, and shaders. I could've learned how to use these things with some YouTube videos, but again: I'm an idiot. My character and enemy trails were made up of polygons created as children of the root scene so that their position wouldn't be relative to the originating entity. The only reason I did it like that was because I didn't know that the global_position variable existed, because I didn't watch any YouTube videos, because I am an idiot. For movement, I bypassed Godot's pre-built input system entirely and handled key presses within the script of the player, handling all the nuances of key-up and key-down logic myself. I even made a VHS-style overlay with a bunch of lines over the screen, not knowing that shaders could have done the same thing but way cooler.

On top of that, C# support in Godot was rough. There was no built-in autocomplete, documentation was scarce, and most of the editor's features were built for GDScript, not C# (particularly signals, which did not auto-generate methods for me). I did a small amount of research recently and it seems that there were solutions to a few of these issues, but at the time, the level of "newness" I was experiencing kind of overwhelmed me. Frustration was one thing, but then I realized something pretty crucial: games made with C# cannot be built for the web. This is probably something I should've known from the start, but again: idiot. Being able to share a simple demo online was very important to me, so once I realized that, I dropped C# almost immediately. Additionally, I took a step back a bit and looked into the parts of Godot that I should focus on learning. Knowing how to code is one thing, but that's only half of the battle here.

So once I shifted away from using the mono version of Godot and left C# behind, I really began to figure out how to work with Godot more as opposed to against it. I watched a few more YouTube videos, I read more of the documentation, and I became a genius, basically. I started working with GDScript instead and I learned very quickly how much of a nice shift that was going to be. It's a very simple programming language, and reminds me a lot of Python which I have a lot of experience in.

I also looked more into what scenes are and what they do. As expected, they weren't exactly a one-to-one replacement of object-oriented programming principles, but it's still similar enough to where I can utilize it in a way that I need to. (I would later realize that custom classes can in fact be made in Godot, but I haven't exactly utilized that knowledge quite yet.) In addition, I started working with the parent-child hierarchy more. I realized that I could just take the top level node that was my original game and place that inside of the new top level node of a different scene as a child of that new top level node and it would still work fine without any change in logic. I thought that was pretty neat and I was stoked once I realized that that was something I could do. It's actually inspired me a bit to shift away from having just the game idea I originally had and now I want a game on top of that game. I'm not sure if that makes sense, but hopefully in a future post I can elaborate a bit more.

In addition, despite scenes not exactly being the same as classes, scenes still allow programmatic creation of object prefabs; what that means is I can make a loop inside of the game within a game node that randomly generates a couple enemies from the enemy scene. Once I realized I could do that, I was very happy with where I was in the regular version of Godot and started getting a lot more comfortable.

Looking at the goals I set when I started working in Godot in regards to getting familiar with it, I'd say I'm close-ish. The old proof of concept is mostly rebuilt, but it's not finished. The original version had level variations and different enemy archetypes depending on the level, and that still needs to be implemented.

That said, while I don't fully "understand" Godot yet, I now understand what I don't understand—and more importantly, I can see the path towards understanding what I don't understand. Basically, I know what I need to learn and where to learn it.

I also think some of my original goals need reevaluating. Not because they're impossible, but because they might not be necessary — at least not right now. The mathematical complexity reduction idea with bit shifting is a good example. It's something I experimented with, and I still find it interesting, but I need to figure out whether it actually does what I think it could do for my game. I'll break that theoretical system down more in a future dev log.

Moving forward, the priorities are fairly clear: I need to lock down the core gameplay loop. I still want to implement the VHS-style overlay — I think it fits the tone I'm going for. And I also need to set up programmatic recreation of the gameplay loop. I want this to be a roguelike. I don't want to handcraft every level. Rooms, encounters, progression — all of that needs to be generated dynamically. Hopefully, I can make all of that happen in the next few months. Maybe.