When I wrote an update on my 2023 resolutions, I included a little tidbit about being burned out on web development.
It's still true, but I want to write down what I've been learning about Godot before I forget.
It's so easy to get started with Godot by just following their "Your first 2D game" tutorial. I'm not even worrying about 3D at the moment, since it dramatically increases the complexity of any given thing.
Maybe more than anything, what I appreciate the most about this tutorial is that I feel like I've learned many of the basics that I'll carry through with me as I do many more things. That is: I didn't learn how to make the Godot 2D tutorial, I learned how to make any 2D game in Godot.
I immediately took what I learned from the tutorial "Dodge" game and made a "Catch" game (you are a bucket, catch falling objects, score goes up). While the main principles are essentially the same (read: it didn't require much to switch the gameplay), the key is that with just a brief couple of hours with Godot, I felt like I had a decent grasp of the fundamentals. That's pretty amazing for any tutorial, much less a game engine.
The next game I made was a little side-scroller with cute graphics that I bought from Cup Nooble on Itch.io. To be clear here, I'm not trying to make games to make a game, I'm making games to learn concepts - which I'm self-assigning.
In this case, I wanted mostly to learn the tile system and cameras plus a bunch of stuff all related to collisions (like hitboxes, item pickups, etc.).
This was the first time I felt really lost, and it wasn't with anything you'd probably expect. Spawning a mob in and picking up a weapon and particle effects and hitting enemies and moving the camera to follow the player and so much more was really quite easy. Granted, the code is a bit of a mess, but if I've learned anything from my decades in dev, it's to not focus too much on code quality during the "dabbling" phase.
No, the part that stumped me is Godot's tile system and editor. I cannot - no matter how much I try to understand it - figure out how the hell to get it to automatically paint reasonable maps.
Ah well, I learned a lot of other stuff in this little dabble, and - while it's unbounded and monotonous - I think the resulting little toy game is actually pretty neat! (It's fun, too, but only for about 3 minutes)
Once I had something "game-like" under my belt, I wanted to start learning more science-y things. On the roster is stuff like procedural generation and shaders (which I hear are the secret behind many visual effects).
I decided to start with procedural generation because I saw this video and HOW HARD COULD IT POSSIBLY BE, IT'S JUST MOORE NEIGHBORHOODS AND CONWAY'S GAME OF LIFE!
So it turns out that parsing a fixed region using Conway's Game of Life rules to cellular-automata my way to a reasonable map is not very hard. It's quite easy. The problem is procedurally generating new regions as the camera moves and making the new regions merge with the old regions in a sensible, imperceptibly seamless way. That's the hard part, and while it's not an impossible problem to solve, it's where I'm currently stuck.
I suppose "stuck" isn't exactly the right phrase. I've stopped working on this for the moment, mostly because I wasn't getting really fast feedback on my code any more, and I had other things I needed to get to. I've built code* that takes a region and generates a map for it, and it seems to work pretty well in combination with existing regions (it uses a physical buffer to load in any possible existing tiles around the region to be generated, using them as seeds for the cellular automata, but not modifying them).
The next thing to tackle is computing a new region to generate based on the camera location: it needs at least 8 points spread around the camera that trigger a region generation when they encounter blank space, but the regions have to be anchored in the original grid dimensions otherwise they'll randomly overlap, creating absolute mayhem. That means I'll need to work backward from "a trigger point" to "what's the least number of originally-sized regions starting from the original spawn point that will get me to a point that will cover this point?" I imagine this is very inefficient and I have no idea how this is done in other games.
Which leads me to probably my two largest take-aways from my time learning game development so far:
As an example of the latter, I was trying to "mask" the pop-in of a sprite (that's a game dev-specific word for "image") and was basically searching for "create temporary sparkle effect [in Godot 4]." By some miracle, I did stumble upon some tutorials for creating magic spell effects, which led me to particle effects and particle generators. But, I probably wouldn't have just discovered that on my own, and it didn't feel like I organically got to that result based on my search results. It just so happened that I specifically wanted a "sparkle" and that took me to "magic wands" which eventually got me to particles.
It feels like game dev is begging for someone to make some content optimized for beginners to come in and ask beginner questions and get useful answers right away. Here's a search that feels even a little advanced for a total beginner to type in and literally none of the results look even remotely useful.
To be clear, here's more or less what I was trying to accomplish:
I'm still incredibly excited about game development, but as with most new things, the instant dopamine hit and ultra-fast feedback loop has slowed dramatically. I still enjoy the challenge of solving a game dev problem, but I'm not as obsessively pulled into it when I have other things to do (like sleep).
I'm still itching to get back to finishing my procedural generation (I'll probably call it done once it's infinite; doing different biomes based on smaller slices of the noisemap sounds interesting, but it's too far into the weeds for me†.), and I'm very amped to learn about and play with shaders, so when I have time, I'm going to continue forging ahead!
I've been building up some ideas in my head for a game I'd like to make, and I feel like once I have the skills to actually get it out into a program, I'll be able to refine the "mechanics" and "gameplay loop" and "goals" part of game development.
*: I may open-source this code at some point, but with the current ecosystem of web scrapers masquerading as artifical "intelligence" stealing code and handing it to untalented hacks as if it created it, I'm not sure how I feel about my code being available for free any more.
†: Infinite procedural map generation is cool, but a game really needs to be begging for an infinite map and have real story reasons to include it. Well-crafted maps / levels are almost always superior, so getting far down the rabbit trail of procedurally generated biomes feels like a waste of my time at this moment.