I recently released my game Dispelling Bee on Itch about a week back. While the game isn’t anything mind-blowing or even particularly enjoyable for most people (unless you enjoy typing), it was a great learning experience, and I’d like to kind of hit on some of the key things I learned from working on it, mainly for my own future reference. I made Dispelling Bee in Godot, but I think a lot of the core concepts I learned can carry over to most any set of tools.
Disclaimer: This is mostly for my own edification. You’re welcome to read it, but I’m not quite sure what you’ll get from it.
When I began work on Dispelling Bee, I was intimately familiar with many basic core game engine design philosophies, having made a (very minimalistic) engine myself. However, something that’s a lot more difficult to teach or learn is the actual organizational structure of the game and what design philosophies you inhabit when crafting systems for scene changes, entity instancing, and the like. While there are a great number of examples for simple applications of such features, not a lot of references online seem to go into a lot of depth in how these features should be designed to work in tandem. Aren’t these systems the very core of what games are built upon? Who’s teaching this stuff? Am I a moron, and this stuff is just rudimentary? I don’t know.
Here’s what I took away from what I did:
- Create a dynamic scene class to inherit from that has unspecified member functions that your individual scenes can override for their specific needs.
This may be a little esoteric. I found that I tend to want more control than what the engine intrinsically gives you for switching scenes. Specifically for Godot, I had a number of pre-loaded scenes that I wanted to quickly switch between, but needed a way to grab focus on the switch. They were already ‘ready’ as far as the engine was concerned, so I needed to pull control focus between the scenes without the use of the _ready functions. Adding a prototypical way I could generically reference scene functions through my director class was super useful and prevented me from bogging down my director with scene-specific code; well, mostly.
- Hierarchy and data access go hand in hand and you gotta respect the hell out of it. Children should have no idea what their parents are doing.
This is general advice, but is very prevalent in Godot. Additionally, this is idealistic; something that you should generally strive for, but not prevent yourself from subverting if logic or simplicity outweighs the safety and cleanliness. As a counter-example, if I made an effects system that allowed me to drop in effects as objects under my player class, the child containing a reference to the parent would be preferable to the parent referencing the child, as the simplicity of the drag-and-drop nature of the former would be lost.
- Figure out how to want to handle general architecture early on in development. The longer you wait the more baked in the interim systems you have been relying on will become.
- Conversely, if you spend too much time planning things, you’ll never get anything done. Finishing something roughly is better than never finishing at all.
This is a push and pull I suffer from when making pretty much everything, and it’s probably one of the main reasons I struggle with game jams; too many times when I’ve been making games have I run into debilitating issues because of a lack of architectural foresight, so I’ve become somewhat fearful of getting things wrong the first time around. This leads to a lot of choice paralysis. At this point I really don’t have a solution for this, but becoming more aware of my tendencies is part of that battle, I guess. Main advice: no extremes one way or the other.
- Keep explicit tabs on asynchronous functions. They can get out of hand quickly.
Like, keep a notebook or something. This could be yields in Godot based on signals, events in C#, whatever. You will lose track of things. They will bite you in the ass as you desperately try to debug them. Beware. If you make an event system, or are using something similar to Godot’s signals, remember that while they are generally “safe”, as in they reduce coupling, they can also be the cause of very silent bugs.
- Art and animation takes forever and I suck at it.
Holy moly am I inefficient at art. When I’m programming, I can usually hit a ‘flow’ state eventually, where I can figure out where I’m going with my code efficiently. Not with art. I found myself questioning every artistic decision, redrawing lines over and over, cycling in and out assets, and eventually settling for things I was less than satisfied with. I would say thinking about and making the art for Dispelling Bee took most of my time working on it, even though there’s really not much there. Heck.
- Realize when something is a turd. Cut it off quickly, polish it, be done with it, and move on.
Alright, that’s a little harsh. I don’t think my game is a turd. What I really mean is try to realize what the level of scope and appeal your game should have as soon as you can. Sometimes you start working on something that sounds interesting on paper, but is really rather limiting, or becomes less interesting over time, or isn’t intuitive to your players, and so on. Decide how much time you want to spend extending a game that’s probably going to fall short of your expectations, stop dreaming up new features, and just finish it. I could have come up with a billion and one new enemies and abilities to throw into my game, each of which would have drastically increased the time I would be working on it and polishing it. All for a mediocre payoff. No amount of extra content is going to fill the hole at the center of Dispelling Bee: it’s built on a gimmick, and not much else.
Again, this sounds very negative, but I’m just attempting to be honest with myself. There are a lot of things I did with the game that I’m proud of, mostly that I actually ended up finishing it and it didn’t enter my massive graveyard of incomplete games. I’m going to try and make a post about things that went right/wrong, and a bit about focusing on gimmicks over design.
Thanks for reading my ramblings. You’re a champ.
