Once you know how to do something, it’s easy to forget how much time and effort it took to get there. Making your own engine comes at a cost, and if you’re an artist or new to development, it’s a pretty high barrier of entry.

Unity initially presented a good value proposition. You lose some control, but the engine will do a lot for you. Even for experienced devs this meant saving time. And I think Unity got this popular because they largely delivered on that promise. It seems the problem is that they’re butchering the evolution of the platform. Judging by the comments here, if Unity we’re doing a better job of rolling out and documenting changes, and stabilizing the product I think people would be happy choosing it.

For context, it took me about a year of learning in my spare time to get to place where I could do my own cross-platform game engine, and some of that time was spent doing the code for the game itself.

What exactly is the expectation here? Would it have taken that much less time to learn the little nuances of Unity that folks here are complaining about?

Also for context, my full-time job is demanding, and I have a lot of outdoor hobbies like snowboarding and mountain biking. I bet if I were even more focused, I would have learned it faster.

It's not a big deal. You're already expending effort learning Unity/Unreal. It's only a little more effort to do your own thing. You might enjoy it

big difference is teams. If you're fine working by yourself, then an engine where you have 100% knowledge scope is great.

The moment you introduce another dev or artist or any individual that needs source access to work on your game, you'll probably have them hitting every pain point mentioned in the article and more. Why's your UI buggy (or does it even exist?), why's rendering this thing slow? So time is spent teaching them (and there's likely zero help on the internet unlike Unity/Unreal), or making tools/bugfixes to accomadate for them. i.e. less time on the actual game.

Hence the mantra: make games, not engines. If you like making engines, that's a good reason in and of itself to ignore that mantra. But if your goal is to make a game, then you shouldn't have to worry about the nitty gritty until it needs to be addressed.

It's funny because I have the same mantra. Make games not engines.

I focus on making the game, and the engine is the thing left over at the end.

But in so many ways, I have learned that a really productive game engine programmer should be spending his/her time building tools for the team. That's kind of the point.

You're making these tools that unlock the creativity of others, so they can help you with the team's creative vision.

I would expect any programmer I hire to be a problem solver, first and foremost, the kind of person who wouldn't need hand holding to modify the engine. I would hire people who I expect to make sensible decisions.

That's going to rule out a lot of people, and that's fine. When it comes to hiring, I select. I don't instruct.

I've made a bunch of half-finished engines in C++ and Common Lisp over the years, my problem is that I always end up bikeshedding the architecture instead of writing a game. And since I do it in my time off, life eventually intervenes.

E.g. this time around, between a new job and a pandemic, I don't have the headspace to think about my little experimental Roguelike I've been developing over the past year (which BTW. mostly took the form it has from me bikeshedding the ECS pattern).

So when the other day I thought it's time to test out the few things I wanted to test about VR, I eventually decided to screw writing my own code, and now I'm just poking around UE4 and doing everything in blueprints.

I definitely relate to the bikeshedding thing. I like what someone from Nintendo once said.

"You're making a game. The engine is what's leftover when you're done."

I like to think that way as well.

Sure, I have a laundry list of things to do, but it all starts with a gameplay idea that I want to explore. I force myself to justify all development efforts by way of serving the gameplay ideas.

That way, you're making a game first and foremost and the "engine" is the tool you make to make the game.

Building your own thing is fine if you're solo. When you start having to collaborate with e.g. artists who expect their assets to render the same way they do in their editor, or a game designer who needs to edit levels in the engine, etc., then you introduce a bottleneck due to the fact that some people are working on the engine, and others on the game that depends on the engine.

I've found that making a custom engine is more amenable to teamwork, not less.

I can build a simpler level editor that I can give to a totally nontechnical person (a.k.a. my spouse), and they can go to town making levels.

They don't need to know anything about Unity/Unreal. They just need to know about my game.

My game already includes levels my friends have designed using tools I made for them.

This is the big bottleneck, plus, for shipping jobs (say <2 month timespans), writing some of the basic stuff eats up more time than you want.

I've been doing an engine on the side (c++ underneath, javascript on top) for pc,Hololens,magic leap,Mac, android, we , pi/Linux (finally) for about 4 years now. I can churn out tools (editors, daemons that run for months, hot-reloading remote-assets, vr apps&overlays, ML tools, streaming point clouds) and demos, but it's still missing rigid body physics and a lighting engine (outside ray marching)

I still have to resort to unity or unreal to get jobs out, because there's too much to do for one person. (Although this is finally starting to change :)

I can't agree more. Unity was a good way to do games because it provided visual editor and unified API between all platforms including mobile if you use unity only as a renderer, it's pretty good and stable.

The only problem, to use unity with comfort, you need to code some base for networking, asset loading, bundle management, caching, localization, visual scripting, and UI (using NGUI and happy with it). It's the way how large companies work with unity (blizzard for example)

Getting rid of all those layers of abstraction stacked over the generation and writing code using modern C/C++ much more satisfying. Especially now, when we have a nice minimalistic cross-platform layer SDL, not to mess with video card/sound directly.

For those who want a slightly higher level OOP API, I want to recommend to try out https://oxygine.org/. It's using modern C++ to provide API similar to MonoGame.

For those who like unity like editor experience I recommend trying https://www.duality2d.net/. It's free, stable, and extremely fast engine width C# scripting similar to the unity MonoBehaiours system.

I definitely support making your own game engine if you enjoy it as a programmer.

But it shouldn't be a surprise that it's not the best choice for the most developers. Every moment you're debugging and improving the engine is another moment you could have been working on the game itself, because almost all engine improvements are orthogonal to improving the game experience.

So given a limited amount of time, you will always end up with a better and more complete game if you start with a batteries-included engine than if you roll your own.

Also the fact is most peoples' game ideas are very derivative and it would be overkill to reinvent the wheel by implementing your own engine for, say, a game that'd easily be made in Game Maker Studio

In my experience, it was easy... until I got to the part of my game that makes it unique. Then it went from easy to very very hard.

That's the thing about engines. They'll get you up and running quickly for basic stuff, but you'll be tearing out your hair when you need to do anything non-basic.

The way I put it is, "the engine isn't really done until the game is." So many polish features in games lead to new categories of assets, which in turn need new methods of rendering.

This is one of the multitude of reasons that so many older game devs reach for the C++ compiler; they don't know what the game will need, but they do know they can make the necessary modifications to ship if they approach it bottom-up.

Making your own game engine requires experience as well. If you've already used other engines, you'll have some idea of the "shape" that a UI library or texture loading system should take.

I had pretty much no experience when I started mine. "Shape" is an arbitrary thing. The shape of the tool should match the shape of your problem, and if you don't know what your problem is yet, you don't know what the best tool for it will look like.

> I'm not really sure why more people don't do their own thing.

I've certainly considered it, but one thing holds me back: cross-platform targeting. I'd love for my game to eventually run on the Switch, to say nothing of more basic targets like MacOS, Windows and Linux. Targeting those platforms would be a herculean effort.

I don't actually think it's that hard once you know how to do it. You basically make a cross-platform C library that generates the GPU commands and sounds per frame, then you just plug that into whatever platform you're running on.

My Mac Platform code is only like 1500 lines or so. Pretty small considering that it runs a 2D game full-screen on my iMac.

Not sure what is meant by 'Herculean'. Once you know how to do it, you don't lose that knowledge. You literally have the code to use on the next project. No big deal

> Not sure what is meant by 'Herculean'. Once you know how to do it, you don't lose that knowledge. You literally have the code to use on the next project. No big deal

The problem with this is that even if your code is 100% bug free and works perfectly, new platforms are created all the time. The PS5 is coming out in a couple of months - does your crossplatform code target that? Unity does. How about the Switch? How about VR? How about Webassembly?

I would encourage you to check out Casey Muratori's Handmade Hero. I believe he does a nice job of separating platform-specific code from non-platform specific code.

My engine is based on his. It has a cross-platform library that only handles the game logic itself. Each platform has its own thing called a platform layer that handles the platform specific aspects of the game (things like setting up a window, setting up a sound buffer, getting a basic communication channel to the GPU on that platform, etc)

Once you've got a few basic platform layers for each platform you intend to target, you just update them every now and again as needed.

Also, you don't need to make your thing cross-platform right away. Just do a basic separation, knowing you will come back later and make it work for various other platforms.

At the current stage of my project, I'm just exploring the space and nowhere near shipping. All of the platform porting will come later, once I know I've got a unique product that will sell

I have watched quite a bit of handmade hero. As a fun hobby, it looks great, but using that strategy to make an actual game... well, let's just say it doesn't surprise me he's multiple years in and hasn't even gotten to gameplay yet.

He hasn't gotten to gameplay because it is meant to be an educational series, which means skipping the parts that don't serve the educational purpose.

I've followed Casey's approach but taken a different path. Instead of focusing on covering anything an engine could do, I started making my own game.

And I discovered that once you get the basics of a platform layer and some GPU communication down, it's pretty easy to start throwing together a real game.

I'm doing it. I've got a real game with real gameplay, actual levels, real things you can do. All of this after a year or learning.

Yeah the cross-platform ease and great VR support is what keeps me there. I've done my own game engines in the past and really enjoyed it, but that was when I was purely focused on PC gaming.