GODOT DEVLOG #1: Laying the Foundation
first Godot project, nodes, the foundation
I’ve embarked on a new game project this month that I’m calling my February Project. A little bit about my game dev history: I grew up using the stone-cold classic engine Game Maker (my finest creation was a 2 player fighting game called Kirby vs. Yoda). A couple of years ago I started tooling around with Unity and Blender and managed to get a couple projects out (Poem Simulator and SXSWSXSWSXSWSX). The former debuted at an exhibit at Austin’s DadaGeek labs, and the second was supposed to debut at a SXSW showcase show, which was cancelled due to the first emergence of COVID.
Since then, I’ve prototyped a number of projects, but each one fizzled out during the move from prototype to actual game. I worked really hard on a six-degrees-of-freedom flying shape matching game (My First Memory). I worked on a first-person game where you wield your facial expression to solve social puzzles (Face Wizard), that one was tough. There were a few others too; each had moments of inspiration but hit a wall of frustration before being relegated to the towering dumpster heap of my unfinished ideas.
Will this project be different? I’m unemployed right now, which gives me ample time to flesh it out. And maybe the reflection and organization required to maintain a devblog, along with the public nature of it, will push me to finish this project. If not, that’s okay; I’m not going to beat myself up about it. A big element of solo game design, from what I can tell, is the abandonment of projects, sometimes after years of work. Luckily I find the process along the way to be challenging, satisfying, and exciting. And the process is always more important than the end “product.” If you don’t love the process, how can you enjoy the act of creation? And if you’re not enjoying creating it, no one is going to enjoy playing it. Theoretically.
Godot vs Unity
I’m using a new engine for this project. In the past, I’ve used Unity, which has become an industry standard especially with regards to indie/solo dev games. Unity is capable of so much, from simple little 2D mobile games all the way up to sprawling open world 3D adventures like Subnautica. That is to say, it’s powerful and full-featured. Dare I say… too full-featured?
Unity is a bloated piece of software. There are so many bells and whistles, so many add-ons and plug-ins and menus and filetypes involved, that it is unbelievably overwhelming for a beginner. I made Poem Simulator and SXSWSXSWSX by trudging through all that feature-muck, watching countless tutorials, copying other people’s codes, begging for help on Unity forums, etc., and it was a total slog! I never had a good grasp on the fundamentals of the engine, and whenever I took an extended break from it, I had to relearn all the weird little details and workarounds. Though I blame only myself for the state of my decaying projects, Unity certainly didn’t make those initial steps easier.
A few months ago, I took a live Godot tutorial hosted by Babycastles that really spoke to these frustrations. The fellow running the tutorial talked about switching to Godot for the very same reasons outlined above. By the end of the tutorial, I was ready to make the jump, and in fact wished I had done so earlier.
Godot has a lot going for it! It’s completely free and open source. It’s much more friendly to beginners like myself. It’s way easier to move 3D models between Godot and Blender (free 3D modelling software). And on a fundamental/operational/workflow level, Godot just makes more sense. It feels like a natural refinement of Unity’s object-oriented structure.
Sure, it doesn’t have all the high-end 3D features or the wealth of plug-ins that Unity has, and there’s not as many tutorials available online; Godot is more than a decade younger than Unity and hasn’t had as much time to develop. But for my purposes (simple 3D, artistic aspirations, don’t really understand shaders) it’s perfect. Thus, my first Godot project.
The Game Idea
A year or two ago I stumbled upon this forum thread where game developer Lucas Pope (known for Papers, Please) detailed in real-time the development of his mystery game, the incredible Return of the Obra Dinn. The thread is both instructive and honest, and I liked how he continued to update the thread for months without ever revealing what the game really was going to be. So, taking a page from him, I’m not telling you what this game is about. You’ll just have to see!
Since this is the “prototyping stage” of the development process, I’m holding off on fleshing out the details to myself until I have a working prototype. I could spend hours gathering art inspiration, mapping out levels, fantasizing features and game-loops, but if the foundation fails, that’s all wasted time. So let’s get the prototype done first, then we can dive into the details. Suffice to say, I have ideas.
Jan. 31-Feb. 4, Week 1: Laying the Foundation
This first week is all about the basics.
On day 1, my goal was to implement the first-person “character controller.” This is the script that allows the player to move, look around with the mouse, and jump. You’d be surprised at how easy this is: with some tutorials, even a complete scripting beginner can have a guy moving around on a flat plane in about a half an hour or so of work. I used this tutorial for mine; the script looked clean and understandable. Here are the meatiest bits of the script, where I'm taking in the mouse motions to rotate the head, and detecting button pushes for the movement of the player character:
On day 2, I opened up Blender for the first time in more than a year and tried to remember how to make a low-polygon tree! For this game, I’m trying to keep the 3d graphics as simple as possible so I don’t get bogged down in the textures and models, which is a trap I’ve fallen into before. I got a nice tree going and then I designed a bird from a cube and put him on the branch. I used this video to remind me how to model a bird, but after following the first few steps, I went off in my own direction.
Because the game will have a lot to do with sound and audio, on day 3 I gave the bird a “sound node” and a beautiful little looping song (an mp3 of a robin chirping). I also modeled a little speaker, and gave it a sound node with a machine-whirring sound on loop (I think it’s the sound of a money-counting machine?).
Nodes are where we get into a real fundamental difference between Godot and Unity. In Unity, games are made up of Scenes, which are basically your “levels.” In Scenes you place your Objects, which can be Prefabs (reusable objects) or unique in themselves, and each Object can have limitless Components, which add to the Object’s functions. So for example, you could have a Scene with a bunch of tree Prefab Objects, and a single unique bird Object, which has a sound Component. And all of these things can have Scripts, which are communicating with each other and effecting Components in various ways. It’s a lot of moving parts to keep in mind.
In Godot, everything is a node. Your level is a node, your objects are nodes, and the equivalent of Unity’s components are just nodes. So for the bird, we have a spatial node (a base level 3D node, delineating a location in space), and attached to that spatial node, we have the 3D mesh/model node and a sound node. It’s nodes all the way down! That bird node is nested (ha) into a level node.
Groups of nodes are called scenes in Godot, which was a bit confusing at first. You’d think of a scene as a stage or space, but that’s not always the case. The bird and it’s two nodes altogether constitute a single scene, and that bird scene is instantiated into the level node, which makes it a scene. So it’s all nodes and groups of nodes called scenes, all cleverly organized in a hierarchical format that’s easy to read at a glance. Like I said, it’s a refinement of Unity’s approach. Instead of dealing with all these different classes of various elements, everything is a node, and they interact in predictable ways.
I had to refamiliarize myself with how to texture a model and how to get it into Godot. Thankfully, the process is easier here than in Unity, especially for the simple textures I plan on using. Feeling inspired!
Finally, I pushed myself to create an interaction system using this tutorial, which taught me some new techniques along the way (like extending one script with another script). With a little elbow grease, I turned the speaker into an interactable object that shuts off when you walk up it and push E. There's even some on-screen UI text for interactable items! So now you can shut that racket off to hear the bird’s song clearly.
All in all, week 1’s progress is excellent:
Next week, I’m going to hit the first real challenge. Adding an in-game sound recorder.