Brief background of my game dev history.

Before September 2017, I couldn’t tell you the difference between Windows and Mac.

I had recently moved to the city and needed to find some job to do. I heard about some friend of my wife’s was trying to make a video game. I grew up playing video games, so I thought that sounded pretty cool. Make my own version of Halo or Ghost Recon.

I did some googling and learned that game development consists of digital art and programming.

I took interest in 3d art because in school I always liked to doodle. I won’t say I was a good artist, but I was always making art.

I took a look at programming too but it’s full of big words and math and I hate math.

I determined that my goal was to make games, but it seemed that the sensible approach was a long one - first become a 3d artist, get a job in a studio, make connections, and over the course of 10 to 15 years then I might be able to be in a position to start my own studio.

I spent about 3 years learning most disciplines in the 3d field. Then one day, I met a guy on the Unity forums who wanted some help making a game.

We had a talk about our goals. We both agreed that we would make a game in one month and publish to Steam. No matter what the game looked like, we would publish in one month.

This was all about simply getting the experience of publishing a game.

We didn’t market the game whatsoever, but nonetheless it did alright in the post-indie apocalypse world. It sold a couple thousand copies on Steam and got mostly positive reviews.

The biggest joy for me was that I got to watch strangers playing it on Youtube (see left).

In that game I made all of the art and designed the missions. Pretty much I did everything except write code. It was a lot of work, but I really enjoyed all of it. That experience made me realize making my own games didn’t need to wait 10-15 years. I could do it right now.

I did not feel proud of the product I was producing. I felt like I was losing a fight.

As I understood at the time, Unity is the engine of choice for indie developers. Unreal is another option, but it is difficult to learn and not as user friendly - especially to beginners.

That’s what the internet seemed to suggest.

I had already made one game in Unity, so it seemed logical to make my next game with the same tool. I was curious about Unreal because it does boast much more impressive rendering, but all of the most sensible people I could query made a strong case for Unity. So I started developing LANDNAV in Unity.

The first big task was to decide which render pipeline to use. I did a lot of research, and many weeks of exhaustive testing. For me the question was not, “what looks the best,” but rather, “which workflow is broadly compatible with other tools I’ll need to use?”

I am not the most technical person, but if an answer exists, I can discover it. To this day, I still couldn’t tell you which render pipeline in Unity best suits LANDNAV. Each one offered few solutions and many compromises.

Next, before I could prototype the game, I needed to be able to support a large terrain. In this case, conducting landnav exercises in a small space wouldn’t answer very much about the viability of the game, so there wasn’t a smaller, simpler way for me to get started.

The terrain was going to be big, and then we are also operating relatively small tools. This necessitated origin shifting operations and level streaming. To accomplish this, I had to hire an experienced programmer.

It took not insignificant time and effort to get the game to a playable state. Development felt like slogging through a marsh in an iron suit of armor. Exhausting, rigid…not conducive to creativity and adaptability.

The problem was most of this time and money was not spent making forward progress. Nearly all of it was spent developing tools to build the game, then developing work arounds because with a hodgepodge of tools - many third party - getting systems to work together becomes like herding cats…and later, once the game was built to scale, we ended up having to redesign the game in an attempt to conform to rendering shortcomings.

I did not feel proud of the product I was producing. I felt like I was losing a fight.

In the end we ran into game breaking bugs that caused memory leaks, crash to desktops, and overall bad performance. But never minding those development stopping issues, daily work had become onerous. Opening the project took up to 30 minutes. Entering play mode would take 20 seconds or longer…

if s**T is broke and you don’t know what to do, try the opposite.

My experience doing landnav training in the Army was a pivotal moment in the development of my character.

Being out in the woods alone, trying to do something that seems impossible…pushing my mind and body to the limit, and then going for another 100 kilometers…it makes one into a person that is hard to defeat.

So, this experience I was facing with the development of LANDNAV was nothing new to me. A challenge to be sure, but I know how to get around a challenge.

I didn’t know exactly what to do because I haven’t been a computer guy for very long, but I got a few techniques for handling a situation like that.

One thing I’ve learned that can get you out of a bad place: if shit is broke and you don’t know what to do, try the opposite of whatever you’ve been doing.

So, Unity was giving me a hard time. Everyone seemed to suggest that Unity was the right tool for the job, thus insinuating that if I couldn’t make it work with Unity - well that just meant that I must suck at game dev.

Maybe, but it would be better to actually know.

I downloaded Unreal 4.26. The first thing I learned was that I might not need to hire programmer help this time. Unreal has an in-built visual scripting system that makes programming like stacking Lego’s.

I can stack Legos.

Initially, I figured I might need several months or maybe a whole year to get fluent enough to even consider rebuilding LANDNAV in this new engine. After one week of doing beginner tutorials from Youtube and Udemy, I felt ready.

After one month, I had all the basic mechanics implemented. I had done the work myself this time, so I had complete control. I was able to experiment a lot and thus improve many systems.

I did hire occasional consulting help - basically if I hit a snag with some math problem, I just have somebody show me what to do.

Within another two weeks, I had the game rebuilt as completely as it had been in Unity. Most importantly, I was now able to stress test the new engine. I went overkill on the world size and density of the foliage. I left the art unoptimized. I built the project and played it for hours. Zero issues. Performance was good - no bugs, no crashes.

I accomplished this in just over a month. You can surmise then what the workflow was like, and how the in-built tools kept me productive without having to spend weeks verifying compliance among third party systems (read: herd cats.)

It’s a simple story. If you require a summary, this is it: for a project like LANDNAV, Unity gave me many problems. Unreal gave me productivity.

Could a more experienced developer make a game like LANDNAV in Unity? Sure. But in the time it takes an experienced developer to write the tools needed to make the game in Unity, I can write the entire actual game in Unreal. As a beginner. Consider that. I think it’s important.

In your own decision making process, there is big questions that must be answered first. Is target hardware supported? That’s the big one. If that is a go with either engine, then I think you need to test real-world workflow, and then stress test a vertical slice of your game.

Don’t let anybody sway your opinion without doing your own test. Nobody really knows anything. Every game project is so unique, nobody can speculate which approach is best for your project. Only reality can guide you, so you have to put in the leg work and test. You must validate your entire workflow and stress test on your target hardware.

Whatever your belief is - challenge it.

Workflow is king. If your mind is wasting energy on battles that don’t contribute to developing a player experience, you are fighting the wrong battles.

If you don’t already know, understand that prototyping a game is easy, but polishing an experience to a marketable degree of quality is 1000 times more work.

Here’s an analogy - try roofing with a cheap plastic handled hammer, rather than a wood one. In just a few hours, you’ll understand that details about the tools you use make a serious difference.

Digital work is not different just because you’re sitting on your ass. Your brain works not unlike skeletal muscles. It does work, then it suffers from fatigue and must rest. You must manage your energy and choosing the right tool for the job is an important part of that process.

I don’t think the general consensus that Unity is the engine of choice for beginners or tiny indie developers was necessarily wrong - I think it’s just outdated. Game development was very different 5-10 years ago, but based on the work I’ve done on this project, I think a strong case can be made to say, “Unreal is the more appropriate engine for beginners and tiny studios.”

In conclusion, if the shoe fits, wear it. Or not. I don’t care what you do, but I hope that whatever your belief is - challenge it. The question of which tool to use is not insignificant.