2023-08-24
I’ve been thinking about this topic on and off for some time, leaving notes scattered around all over the place. It’s time to compile them into one cohesive post, so that my future-self can look at and rethink the idea if he’s about to do it again.
(Hey future-self, go back to work. I know you’re slacking off right now reading this.)
Yes you’ve read that right. I don’t think it makes sense for me to do that.
This is a matter of discussion on the internet to this day, probably every game developer out there as an idea, but let me preface this: The conclusions you’re about to go through are for me and my personal situation. I work full-time as a software engineer in the games industry, and this is about the games I make in my free time, i.e. in addition to (at least) 8 hours of thinking-intensive work where the best of my efforts must go.
So first of all, I must put forward the reason why this is something I keep coming back to from time to time. I think this is because of the two distinct types of drivers wanting to drive the car: The Creative and The Engineer. The Creative wants to make the game, ship it and watch people enjoy the experience. On the other hand, The Engineer wants to solve problems while using the least amount of computer resources while having full control. I guess without me telling, you can see the conflict here. The ways they choose to reach the goals are different. Even the goals themselves might differ. In order to reach somewhere though, I need to designate one as the main driver and reserve the other for the event that the main one collapses of exhaustion. I chose The Creative.
You’re probably interested in reasons why.
Making games with a custom engine would make sense for me if I’d be able to say:
I’m in the ride for the process of engineering primarily, and shipping games isn’t as interesting to me. I’m fine with working on the same game possibly for a decade.
The primary reason why I went into the games industry is to see the players have fun with the games I worked on. This has been the main source of motivation from the very beginning. Putting this into the backseat is something I can do only temporary. Even if I want to go low level and get my hands dirty with memory bugs, after a while (could be weeks or months, but not years), I’ll feel the stagnation of working on the same project. I’ll ask “yeah cool but what is this for? it doesn’t seem to go anywhere.”
A couple of years ago, I was thinkering with this idea of making “the one game” that has been eating me inside
for a long time. It was meant to be in the exact way I imagined it to be. Everything has to be built from ground
up, so that I could fine tune every part of the game in the precise way I want to. What I didn’t take into account
is the amount of infrastructure required to be there, which isn’t directly related to the game itself (like
loading an .obj file, or making point shadows work). I had to spent so much time and sanity in these
parts that the game itself didn’t even take the backseat, but went directly into the trunk. It has other
additional reasons which I’ll come to in a moment, but it’s clear to me that if I kept working on it for like
multiple years, I would’ve definitely lose the sight of the shore and get stuck in development hell.
I’m fine with not having another serious project in the foreseeable future.
This is a commitment I shouldn’t make, if I want to ship anything. We don’t know what the future will bring, and it feels a bit too restricting to say something like this. I mean, sure, you can take a break and work on something else for a while, but I know myself; the reason why I would do such a thing is because I’d be already burnt out, and wouldn’t come back to the said project.
I have enough experience solving game programming problems without using an engine.
In hindsight, I think one of the biggest reasons why I gave up on the idea. I don’t have that kind of experience that allows me to be productive. I end up spending a good amount of time (and sanity) to get (for example) the renderer work, and then make the code look nice to have at least the minimum amount of self-respect. These sort of tasks become the main quest for a few months and, like mentioned above, I forget what the big picture looks like, which made me start doing this in the first place. This time frame ends up being long enough that The Creative lifts head then sees The Engineer is trying to make sense of a RenderDoc snapshot in 6.00AM (before the day job), and asks “why are we even doing this”. I see people come up with playable (and good looking) stuff in Twitter/Reddit/Twitch/Discord, and the more I see them the more I realize I have to go through that process, i.e. just keep solving problems so that it becomes easier for me. Since I’m at the very beginning of this journey (of going handmade), and since it’s a spare-time gig, it’ll take a good chunk of time until I’m as productive as I’m with Unity.
(Although, I hear you asking “this is how you become proficient at virtually anything. how else would you get the experience if you won’t push through?” and you would be correct. I don’t have that kind of time, however, which needs it's own place of elaboration)
I’m planning to make certain kinds of games, and my own tech will make me productive in that genre in the long run.
This won’t fly either. I don’t have a certain kind of genre/type/perspective I’ll dream myself building. I find myself taking my shot at card games, horror games, first-persons, puzzles… It’s all over the place really. Sticking with a general purpose engine (which I’m proficient at) has a lower time (and sanity) cost for me, at this point in time.
I have the perfect vision of what I want to build, and I won’t need quick iterations and prototypes that much.
Putting aside the fact that game development usually doesn’t work well with this sort of waterfall style, there was a project in my past that kind of fell into this category (actually there still is, but it has to wait). In that, I had a pretty good idea about how the game should make the player feel, i.e. what sort of experience to get across, but I didn’t have a clear outlook on how the game should look and play like. This bleakness caused a good amount of production-related problems, where the time/sanity cost of wrong decisions was a bit too much.
The problems I’ll tackle wouldn’t fit into the workflows of off-the-shelf engines. Instead of pushing the boundaries and fighting with the limitations of Unreal/Unity/etc. it’ll be easier to build my own custom solution.
While being a perfectly valid reason to pick that route, my current and possibly future projects won’t have this aspect. The experiences I deem worthy of getting across usually aren’t that technically ambitious.
I’m not happy with where the software engineering in general is headed. I don’t want to contribute to the problem by producing bloated&inefficient software with bloated&inefficient tools.
This is the only argument I don’t have much against, and it’s not a new idea either. If we want to see a change, we should start with ourselves. I was going back-and-forth between this and just picking Unity and rolling with it. After some experimentation and giving it a good amount of thought, the conclusion I arrived was that the other reasons outshine this one for me and my particular situation.
With that, I kind of accept the fact that the tech I’m using (Unity) might evaporate in the future, like Flash. I’ll take the bet, and in the case I lose, do the necessary damage control by rebuild the affected games with my own solution.
As you might have noticed, I avoided to imply that this isn’t set in stone. We don’t know what life will throw at us (postscriptum: for example the Unity distaster in Sep 2023) and we will have to adapt. In the end, everything depends on what we want to achieve and we need to determine the destination wisely and pick the correct tools carefully. Here, at this point in time, my goal is in the general direction of shipping stuff, so in order to prevent myself from getting caught in that spiral again, I needed to write these down. If I decide to pick this path again in the future, I'll have a concrete set of arguments to test myself against.
Even if we use an existing engine, we still have a lot of work to do.