
Create your own Game Engine but don't use it - majikarp
http://www.zeroequalsfalse.press/2017/07/12/engine/
======
thomascgalvin
This can be said about plenty of things. Encryption is probably the most
obvious; there's a lot of benefit from reading about and implementing various
encryption methods, and absolutely foolish to use any of that work in a
setting where it might actually be attacked.

The article is pointing out something that should be obvious; if you're making
a widget as part of a larger task, your implementation will probably be
lacking compared to one developed by a team solely focused on making the best
widget they can. I could write an HTTP server or a threadpool or a database
connection layer if I really wanted to, but thousands of talented people have
invested millions of hours in those tasks already, and I'm not likely to do
better than them on my own.

Getting over the "not invented here" mentality allows us to focus on doing
things that are novel, or things that are custom. In my day job, I'm working
on a (relatively) trivial problem that's never been done before, because there
are about ten people in the world that need it. As a hobby I work on a text
editor that is completely customized to my personal workflow, and which will
probably never be used by anyone else.

~~~
aphextron
>Getting over the "not invented here" mentality allows us to focus on doing
things that are novel, or things that are custom.

I remember gradually coming to accept this as an intermediate programmer. Once
you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna
write SOOO much complex code to solve this problem!" to "I bet I can pipe
together 5 different CLI programs and not write a single line of code".

You learn that it's all about layers of abstraction, and understanding that
the human brain is far more useful and efficient at problem sets higher and
higher on that scale of abstraction than it is at twiddling bits.

~~~
brianwawok
Except for some of us, it isn't actually that fun to spend 5 minutes gluing
together 6 libraries with no documentation, and 4 hours figuring out an
undocumented bug deep in the source code. We would rather write someone from
scratch :)

Not that you can really afford to do that in a paid position, but for a side
hobby like making a game? Absolutely. If you are making a game for fun, do
what is fun to you.

~~~
Bartweiss
> 4 hours figuring out an undocumented bug deep in the source code

For me at least, this is the real issue. Gluing together random libraries
isn't fun, but it's fast and productive and lets me spend my energy and
attention building something bigger than I could have solo.

Gluing together _broken_ libraries, though... Well, I thought encapsulation
and black boxing were genius from the day I learned about them until the day I
actually tried to build something nontrivial. Now I just think of Douglas
Adams: "The major difference between a thing that might go wrong and a thing
that cannot possibly go wrong is that when a thing that cannot possibly go
wrong goes wrong it usually turns out to be impossible to get at or repair."

Finding myself 5 pages deep in Google trying to fix a fundamentally broken
Android API is way less pleasant, and ultimately slower, than working around
the API altogether. It's also why all the people I know maintaining long-
standing Rails projects have heartburn - using someone else's tools only saves
time when those tools are trustworthy.

~~~
brianwawok
Everything is broken at some level. Your own code will have bugs just like the
lib you import will.

Usually what is nice is your own code has a lot less lines of code, so you
SHOULD be able to find the bug sooner.

~~~
Bartweiss
Yep, I certainly don't mean to imply my code is right. But it's usually
shorter, and it's _mine_. So when I find the bug, I can make the sane fix on
the schedule I need.

For particularly good OSS libraries, I guess providing a PR would only be a
little slower than fixing internal code. But for anything poorly maintained,
or with closed development, discovering those bugs often means writing an
enormous workaround or switching libraries entirely - they just won't be fixed
any time soon.

------
crucini
There's no absolute answer to the "build vs buy" conundrum. A lot of us are
biased towards "build" and its useful to recognize that bias in our decision
making. But the "buy" side often has hidden costs. In the author's case, which
involves targeting multiple platforms, the "buy" side gets more attractive. In
general you are deciding whether to code on platform X or on platform Y built
on top of X.

Fashions come and go, and if you invest heavily on top of Y it may become
"obsolete". Will you be willing to stay on Y when the developer/community has
abandoned it? You may have to reinvest to port onto Y', while X remained
somewhat stable.

The higher level the platform, the more likely you are to hit surprising
limitations late in the process. Your role gradually transitions from
technology producer to technology consumer.

Programming an AVR chip in C gives you a great feeling of space and power
because the platform is so clean, while using Arduino you rapidly hit
limitations and spend your time getting around them. Higher level platforms
tend to make the easy things easier and the hard things very hard.

I wouldn't rule out the subjective factors. For many of us building is more
fun than sorting through what others have built. The brain works a lot better
when having fun, which is why MBA-style decisions about programming don't
always work.

------
steeleduncan
This blogpost gives the other point of view:

[http://www.spacesofplay.com/blog/why-we-built-our-own-
tech-f...](http://www.spacesofplay.com/blog/why-we-built-our-own-tech-for-
future-unfolding/)

Essentially that the engine you use can constrain what you create, so write
your own.

~~~
thehardsphere
I've considered a stack like that myself for less exotic looking games. It's
nice to know someone who actually has gotten farther than I have is making
similar choices and that those choices are working for them.

I think the choice boils down to project scope and the relative size and skill
of the team. If a game of your scope is already well served by an existing
engine, it makes sense to use it. If you have a large team with a particular
skill set, it makes sense to cater to their skill set by picking the engine
they know. For any other case, rolling your own makes sense, provided you know
what the scope of the project is in advance.

The common mistake (that maybe the guys in the parent article also made) is
that they assume "game engine" is some necessary prerequisite to making games,
so they spend time working on all of these technical problems that are not
actually their game they want to make.

------
karmadog
There's two big hindrances for success right off the bat:

1\. Refusing to just use C/C++

2\. Attempting to support most of the platforms

Both problems compound each other.

All platforms (even Android at this point) have C APIs for everything you
need. Creating another layer of abstraction here causes more work and
overhead.

Trying to get Java running on iOS with 3D APIs is a huge task in and of
itself. The same goes for C# (a task which Unity does for you). Languages that
require JIT for performance don't work on mobile (unless supplied by the OS,
e.g. JavaScriptCore). Debugging becomes extra-difficult.

C/C++ are not convenient to use, but not _hard_ to use either. It causes
discomfort at first, but you get used to it. Being forced to do memory
management manually also helps with learning how to structure programs, with a
bonus of not having to wrestle GC pauses.

Having said all that, using a commercial engine is totally fine, of course.

~~~
davexunit
I refuse to use C/C++. If that's what I _have_ to use to make games, I just
won't make games. Fortunately, there are other languages available with a C
FFI.

I don't think forced memory management teaches anyone much of anything besides
how to manage memory manually. It doesn't make programs better. I'm very
grateful for garbage collection so that I can spend my cycles thinking about
the problem I'm actually trying to solve.

edit: I think this came off a bit too dismissive, but I guess what I was after
is that what technology you choose depends on what you value. Personally, I
value using programming languages that are pleasant to work with, and I don't
personally find C/C++ to be pleasant. I enjoy dabbling in game development,
but it's not so important to me that I would use tools that I don't like to do
it.

~~~
karmadog
First of all, I'm talking about game _engines_ , not games. Both Unity and the
earlier Unreal Engine (afaik) used GC-ed languages for scripting.

However, if you want to make a quality game, you _can not_ afford long GC
pauses. I know that lots of people make games with GC pauses in them anyway.
It is a value judgement, for sure.

It's certainly possible to work around GC pauses, but that effectively means
you are manually managing your memory manager (instead of the memory), which
can be surprisingly difficult.

It's also possible that whatever you do is so "small" that GC pauses never
affect you. Enjoy your free lunch then.

~~~
TeMPOraL
Some of the work done to work around GC feels similar to the work you'd do in
C/C++ to work around memory fragmentation issues. Also, depending on the
language/runtime, you might be able to influence the GC algorithm, or at least
the frequency with which it runs. If you can e.g. run a GC every second for
not longer than ~1 frame, then pauses won't be noticeable.

~~~
karmadog
A dropped frame is always noticable. What you can do is keep a budget for GC
and then force-collect every frame.

------
thefoxbard
I really don't think the issue was with "creating x from scratch", but from
the purpose it was built for.

Game engines like Unity are general-purpose engines, they are not made for a
specific type of game, and can be used for basically anything. The trade-off
is flexibility and performance.

What they tried to do was to basically create a "clone" of Unity, that is,
they tried to create a general purpose engine, and that does not make any
sense at all for an indie developer.

If you're going to create a game engine + editor, then do it for a specific
genre of games (e.g. FPS), and do it only if you're planning to create a
series of games that belong to that genre only.

Unless you want to create a business out of selling game engines, then have a
specific game in mind before creating a game engine, and tweak it for that
purpose only.

------
alol
Having a broader understanding of your domain at a different level of
abstraction is always extremely valuable.

For anyone interested in the detail of _how_ to create a game engine from
scratch, I'd recommend checking out Handmade Hero
[https://handmadehero.org/](https://handmadehero.org/)

~~~
fellellor
Handmade Hero is over 380, hour or two long videos last i saw. How far are you
into it?

Regardless, it's an amazing effort.

~~~
nbm
I've watched pretty much every episode, mostly live. It is pretty amazing. It
also pretty much single-handedly reinvigorated my love of programming.

But there are definitely entire weeks (or weekends these days) of video that
aren't all that useful unless you're trying to build exactly what Casey is
trying to build.

[https://hero.handmade.network/episodes](https://hero.handmade.network/episodes)
is a must if you want to cut some corners on what you watch.

Off the top of my head, here's my suggestions:

* Weeks 1-15 are all useful - it's really a great introduction and kool-aid provisioning system

* Week 20 and 21 has some introductory lighting stuff.

* Week 23 and 24 has some good performance profiling stuff.

* Week 25 and 26 has some multithreading job queue stuff.

* Week 28 and 29 has SIMD/SSE sound mixing implementation

* Weeks 36-38 has debug/performance infrastructure

* Day 235 and weeks 48 and 49 are the start of OpenGL initialization.

* Week 74 discusses particle systems

* Weekend 3 discusses compression

* Weekends 6-14 are the core software-renderer-to-OpenGL days

* Weekend 23 is a re-implementation of lighting

The other stuff is exploration of concepts that are either specific to
Handmade Hero, or are much deeper implementation detail type stuff - not
entirely necessary if you're skimming.

~~~
krapp
>But there are definitely entire weeks (or weekends these days) of video that
aren't all that useful unless you're trying to build exactly what Casey is
trying to build.

That's been one of my biggest problems with Handmade Hero - Casey isn't
teaching people how to write C/C++ and build a game engine, he's teaching them
how he builds _one specific game_ and mixing his personal habits (and
idiosyncratic prejudices) along with some very useful programming knowledge.

And he also shut down comments on the Youtube feed at some point, which I find
very unfortunate. The commenters helped me gauge the BS factor for any
particular episode before jumping in.

~~~
RugnirViking
'he's teaching them how he builds one specific game '

While I would agree that there may perhaps exist a better alternative, most of
us have learned a difficult concept or two by finding a working example. This
is that, but taken up to 11. Assuming you actually follow on and try to make
-small- variations to ensure you understand whats going on, you will probably
be in a great position

------
CJefferson
On the other hand, I find my game engines, particularly (unfortunately) open
source ones, are in a terrible state.

They often try to support many platforms, then it turns out they usually
support one platform well, and the others are various degrees of broken. Then,
when you want to get your game working on Android, the engine is too massive
and complex for me to have any chance of figuring out how to fix it.

~~~
oneZergArmy
This is why i prefer frameworks like LÖVE 2d. it's so simple that I can keep
everything I need in my head. I like just staying in the text editor.

~~~
CJefferson
I really wanted to like love 2d, but I found the community very unfriendly,
and there were some fairly simple old bugs that have been around a long time.

Also, I was looking for something to teach children, and they seem to like
"hilarious" library names like anal. (This is not one of the problems I asked
about, I knew better than to ask someone to rename something).

~~~
striking
They recently (about a year ago at least) changed nearly all of the library
names.

They also had the friendliest community I had ever been in on IRC, besides
maybe #haskell. Sorry to hear you had a poor experience, I'm shocked to hear
things had changed on that front.

~~~
CJefferson
I'll have a look, because I am still on the lookout for something after
scratch -- I currently use pygame but I love the idea of love2d.

Maybe I just caught the IRC channel on a really bad day, or asked some
particularly offensive question, without knowing what I was doing.

------
avaer
Interesting contrast to the Carmack school of thought: _do_ build your own
game engine and don't even reuse anything you made before, because you'll know
better this time.

~~~
sclangdon
Also remember that id Software wrote an engine specific to the game they were
creating (it's debatable whether you can call them engines at all, really).
Things are a lot more streamlined if you take this approach because you
rarely, if ever, have to answer the question "would this work for some other
title?". Or worse, "would this work for any future title that may not even be
in the same genre?"!

That, I think, is the mistake many game devs (who write their own engines)
make. They make an engine for all possible games, then try to use it for their
2D match-3 puzzler, which uses about 5% of the code they've written, and even
then they have to cludge some bits.

~~~
FRex
They (id tech 2-4+) definitely are considered full on world class engines, FPS
specific but still. They each have a renderer, physics, scripting, asset
pipeline, map and data formats, tooling, etc. and were used to make other
games. They are too big, unified, oppressive (as in - they control the main
loop, their elements are all together, you can't mix and match easily, your
game code is on a level of a plugin for the engine code to call, not the other
way around) and multi domain to be considered libraries/frameworks.

------
ganoushoreilly
I think a lot can be said for someone trying to go their way, and learning the
value of a prebuilt solution. A lot of people would stubbornly keep trying to
build their own "because they could build better" rather than focusing on the
end outcome of a playable product.

------
thehardsphere
The mistake that most people make is thinking about whether or not they should
make a "game engine" when what they really want to do is _make a game._

If you want to make a game, make it. If it makes sense to use somebody else's
engine to make it, then by all means do so. If you aren't going use someone
else's game engine (which is a perfectly valid choice), skip straight to
making your game. After you've made a game or two, you'll know whether making
a "game engine" out of what you've written previously is a worthwhile effort
for your next game.

------
golergka
I've worked with Unity from the beginning of my career as a developer. (Used
to be a game designer and producer before that). I haven't quite understood
what's so special about it before I tried other solutions, including open-
source (Cocos) and in-house ones; turns out, a LOT of things that Unity devs
take for granted (like asset pipeline and management) are lacking elsewhere.

Sure, a senior developer should be able to write his own game engine from the
lowest level - but he almost never should actually do it on a real project.

------
kbenson
This is good knowledge for whatever your field is. I've created a few ORMs. I
don't use any of the ones I wrote, but I learned a lot in doing so. I've
created a few web routing systems. Again, you can learn a lot, but unless you
actually want to spend a lot of time writing and extending one, just use what
you learned to help you pick a good one.

------
mherrmann
Developing indie games is hard enough. Starting off by building your own
engine is crazy (unless there are _very_ good reasons). They unnecessarily and
gravely harmed their chances of success in a very competitive niche.

------
advice_giver
This blog post and the comments here are amazing. In no other software field
but indie game dev does spending a year trying to build your own toolset
instead of $ACTUAL_PRODUCT_THAT_MAKES_MONEY draw praise.

~~~
thehardsphere
It's cargo-cult word-thinking. "Game engine" is associated with "game" because
of the success of id Software, Epic Games, Valve, CryTek, et al. So people who
don't think the way programmers do, have the impression that a game engine is
a required step in the software development process to have a successful game.

------
krapp
This is apparently what I've been doing for about two years.

Except I still haven't gotten to the "engine" part, it's more "a bunch of
wrappers around Lua and SDL2 and some random stuff that seems useful, and
probably the worst ECS ever."

I actually did almost get to an actual game, though. But I was so disgusted
with it that I gave up and started everything over from scratch. Mind you,
everything _worked fine,_ I just hated every thing about the code.

And _this_ is why I am an amateur programmer and a professional box-pusher.

~~~
tisdy
I'm interested in pushing boxes. It sounds relaxing. Well, relatively. Have
you heard of webpack?

~~~
krapp
I have heard of it, but I've never used it. I'm far, far behind the curve when
it comes to anything involving web development. It's on my list of things to
look at.

------
sbov
It seems like you can learn a lot of that by building a game without using a
game engine at all.

------
psyc
Working on low level engine things for 15+ years lets me wield Unity like a
sword now. It's a mid-level sword, but my technique makes up for that.

------
aphextron
I think a lot of developers who come into game dev have a mistaken view of
Unity as the "budget" choice based on the poor quality of many of the indie
titles shovleled out with it. But Unity is probably the most advanced game
engine in existence today. Far beyond Unreal 4 in terms of both performance
and tooling.

The reason the average quality is so low with Unity titles is because of just
how _easy_ the technical aspect of making a video game has become with modern
engines. The barrier to entry for creating a game with AAA graphics is now a
$20 shader pack and the ability to hack together some C# scripts.

~~~
emodendroket
I have pretty much no experience with game development, but why is UE4 such a
popular choice for commercial games if that's the case?

~~~
aphextron
Most big studios are still on UE as a matter of momentum and the
aforementioned biases. Unity really only became viable in the past 3 years,
which is shorter than the average AAA game development cycle. Also certain
games such as FPS are still better off with UE, as that's what it was designed
for.

~~~
mnarayan01
> Also certain games such as FPS are still better off with UE, as that's what
> it was designed for.

What game types would you consider Unity to have better performance and/or
tooling for? Also, if you're feeling generous, why?

~~~
aphextron
>What game types would you consider Unity to have better performance and/or
tooling for? Also, if you're feeling generous, why?

The main difference IMO is that Unity has become the de facto standard for
anything VR related. UE is doing a good job with their VR support too, but
it's really clear which engine is favored by SteamVR, the Oculus SDK, and the
community at large.

Unity also has a first class asset store which can save you months of
development time when it comes to things like networking or doing complex
shaders.

Other than that it really comes down to personal preference. Scripting with
Unity vs. Blueprints with UE, C++ vs C#, etc.

------
aaron-lebo
A year is nothing in the grand scheme of things. If you can't invest a year
into building tools that could be your foundation for the next 3 decades, then
what you are building is just a quick-rich scheme that doesn't matter. Use
whatever you want because it doesn't matter...and your game probably isn't
going to sell anyway. Those are the odds.

But as they've pointed out, you kind of need to know that stuff anyway, so
it's time well spent.

I don't have a ton of gamedev experience, but at least graphically that game
isn't doing anything you can't do in a few hundred lines of C++. Maybe that's
part of their problem. Why use Java if you want to make a mobile game and it
isn't well supported on one of your primary platforms? That sounds like a bad
fit.

Unity and Unreal are super cool but they are also bloated with features that
you don't need and lacking in others you do. For the longest Unity required
you to use 3rd party modules for a camera. A camera....something that takes a
few lines of code for a basic implementation. Why didn't that come standard?

If you really want to hurry to market yet another game by all means use one of
the existing engines. It might even work really well. But if you want to do
anything interesting, you're gonna be doing custom stuff anyway.

~~~
kevindqc
>For the longest Unity required you to use 3rd party modules for a camera.

What do you mean? How can there not be cameras? How then can you view a scene
without that 3rd party module?

~~~
aaron-lebo
Google "unity camera scripts" for an idea of the kind of functionality that
people were grafting onto Unity a few years back.

