On writing games from scratch7 februari 2016
Lately I have been writing some quite grumpy posts on Twitter regarding third-party game engines, so I felt it was time to do a write-up on the topic.
Every now and then people find out that some game which has been released recently was written from scratch, meaning it did not use any third-party game engine. Whenever this is found out about I often start hearing comments from game devs and gamers like "yeah well that game didn't need to have it's own engine" or "the cost of making the game could probably have been reduced a lot if they went with something like Unity". Sure, if you are a game developer that likes using something like Unity, then fine, use that engine as long as you like it and you're happy developing using it.
It's important to note that by making your own engine, or writing from scratch as I prefer to call it, you usually do not mean making a general-purpose engine before you start making the game. In most cases it means creating a specific-purpose monolithic program where the "engine part" and game is just one big program, created in tandem.
Please note that I usually work in small to medium-sized teams. I do not work in large teams (AAA etc), therefore I have no strong opinions on how I'd like to make games in such teams. This text is not going to be some "there is one correct ultimate way to make games"-thing. It all boils down to what a game developer likes and what makes them happy.
The joy of programming
I have been working for a while at a company where we use Unreal Engine 4 for our game. The game is looking great. I love the team. But I really don't enjoy the day-to-day work, all because of one thing: I do not find it fun to program in Unreal. And by "not finding it fun" I mean that actually typing the code and reasoning about how to transfer the problem in my head into lines of code just isn't fun.
There are some Unreal-specific and some non-Unreal-specific reasons for me feeling like this. I don't want to go into the details of the Unreal-specific reasons now, but let's say it's a combination of the following: Really really bad iteration times. Forcing you to use what I think is a bad sub-set of C++. The bad iteration times in combination with the bad sub-set of C++ makes you write more than you want in Unreal's visual scripting language Blueprint. Blueprint has pretty neat iteration times, but is near-impossible to refactor when shit hits the fan. I can literally count on my fingers the times I've found excitement and a general joy of programming while using Unreal.
All this lack of joy made me work slower. I think people underestimate how important the joy of programming is. I feel like I'm at 10% effectiveness whenever I'm unhappy writing code. Whenever I feel like I'm doing something slower than I can, I feel stressed. And when I feel like I do things slower than I can on daily basis, I get chronically stressed.
I've been working in Unreal for the whole summer and fall of 2015 and I really really tried to pull myself through it. I wanted to work on this great game with these great people. But it turned out to be the most stressful period of my life and I have not been feeling well because of it. Because of some piece of software. It may sound like I'm a spoiled kid for not having worse problems. Sure, I have had an otherwise very problem-free 2015. Any other big crisis would probably have overshadowed these problems. But still, it is what has been eating me, driving me nuts and stressing me out.
I'm simply put the wrong person to be working on a project using Unreal. My co-workers don't seem feel nearly as frustrated by Unreal and I'm glad that they are happy and continue working on our great game. But I have because of these issues resigned from my job. My last day will be February 29, 2016.
What about other engines?
At this point someone probably thinks that if I was working on a project which used Unity I would have none of the above problems. Yes, Unity has neater iteration times. It does few of the weird things with the programming that Unreal does. It is substantially more fun to code using it. I have used Unity for lots of game jams and I find it great for such purposes.
However, this text is more about my feelings working on longer projects. In a long project that uses Unity I still feel substantially less joy than if I had written the game from scratch. All developers have different tastes in how to create. Just like Bob Ross paints everything using primarily two big brushes and a paint knife, all game developers have their own personal style when creating games. Some don't want to be concerned with what happens under the hood, only writing gameplay scripts on top an opaque engine. Others are driven by knowing what the computer is actually doing, ultimately having to craft most of the program themselves. I know I am the latter but I think both ways are fine and it is in choosing what suits you that you stay happy and less stressed.
Changing stuff up
Ron Gilbert recently wrote a blog entry about engines on the Thimbleweed Park blog from which this quote comes: "I started to take a close look at engines that were suitable for a 2D point & click game. Lots of great choices, but deep down (if I'm honest with myself), I'm a game engine snob. Whenever I use an engine, I keep wanting to modify it and hack into it to do what I need. I guess I've found over the years that it's a lot easier (and less stressful) for me if I just create my own.". Something that really resonated with me was, for previously explained reasons, the "and less stressful" parenthesis, but also the part about modifying the engine to suit your needs.
Most complex third-party engines often need surgery. Some of them don't come with source, which is deal-breaker for me if I'm gonna do a longer project. But even if you manage to get source access you suddenly have a new set of problems. As you start hacking into the source and make your modifications you probably, unless it's late in the project, regularly update to newer versions of the engine. With enough modifications in your own version of the engine the merges with new versions get so time-consuming that you start restraining yourself from changing the engine in the first place.
You might also do engine surgery the Unreal-way where everything is super object-oriented and you create your own subclass of the vanilla engine class and completely override functions in the engine. But this is also a bad idea! Suddenly you're leaving dead code everywhere, making browsing through the engine source harder.
It's just a program!
When I code I strive for making tidy and lean solutions that gets the job done. Using a general-purpose game engine kind of takes you in the opposite direction. You probably only use a portion of the features in the engine, making a big chunk of your game's collective code into bloat. All of the unused features are just noise there to distract you as you find your way through the engine code, looking for that thing you wanted to change. When I write from scratch I feel at ease because I think of all the code usually found in general-purpose engines that I avoided having in my game.
I firmly believe that a program should be as clear as possible and contain only the stuff it actually needs. And as I see it, a game is just a program! For me it makes sense to have a single monolithic program where engine and game code live in symbiosis. It's a program where I can throw out whatever code I feel without remorse. It's a program where I know that most of the code is used. It's a program where I have a chance to understand how everything works. And most importantly, it's a program that was fun to create.