Why would a game developer write their own engine instead of using existing ones?

Question

I have observed that many big and well-known game developers often develop their own engines. Examples include Valve, Crytek, Ubisoft, Epic Games and Square-Enix.

Could it simply be because they can, or is it likely that existing engines do not meet enough requirements, so we would develop our own? I can hardly imagine a game that requires a specific engine. The likes of of Unity or Unreal are simply enough to make any kind of game; even if not, they have source code, which can be modified to satisfy even some extraordinary needs.

Why would a game developer write their own engine instead of using existing ones?

Answer 1

There are several reasons a studio may choose to "build" instead of "buy" their technology:

• Legacy technology; a studio may have started building their own toolchain before there was existing, viable middleware for it.
• Specific requirements; a studio may have a particular collection of requirements that is not well-suited to existing middleware or
• Budget concerns; a studio may not be able to afford the expense or contractual obligations of existing middleware.
• "Not built here syndrome;" the studios technical leadership may be wary (reasonably or unreasonably so) of technology they did not build and therefore do not fully understand.

In general, it does make good sense to own and control the things that are critical to the success of your business, and to outsource those that aren't.

For some studios, the design or storytelling aspect of their games may be the critical resource they expect to capitalize on for success. For those studios, it makes sense to simply buy technology that will allow their designers to realize the appropriate vision.

For others, technology may be the foundation for success. Studios that build MMOs, for example, generally will need to build that infrastructure themselves because it is critical to their success (and existing middleware is generally inappropriate, at least for larger, "AAA" titles).

Note that some of the studios you listed (Crytek and Epic in particular) have basically stopped trying to be dominating forces in the games market directly, and almost certainly make far more as middleware vendors than they do as game developers.

Answer 2

as said by Josh Petrie:

"Not built here syndrome;"

I am also writing my own engine, and I suppose the reason will be different for every developer out there, but in fact - I generally don't like working in other peoples code. I am compulsive in the sense that If I feel I could build it myself, then there's no point in settling for anything else.

I tested out various types of game engines, rendering API and such, notably Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre, etc.. many more... I wanted to start writing games - I downloaded a lot looking for a good comfortable and well documented entry point...

My problem however, was at the time I had no idea what was happening below the engine. I wanted good control, and I wanted a framework I know like the back of my hand. I came up with the idea "HEY! I think the only way I'm gonna learn how the thing works and understand it is to try building my own engine entirely and completely from scratch. Most of my programming history was with web and processing solutions - this was a whole new ball game for me.

Which is what I ended up doing.

So I chose to set up XNA since I already knew C#, and started thinking about how or where I should start. I needed an idea.

I decided that, no matter what, I would go straight into 3D.

Getting the basics down was cool - the sprite batch stuff, but as I progressed I ended up discovering new barriers and obstacles - my first real one being the batch limit. My goal was to build a game that could at render at least 10000 entities in the view frustum at any time.

I embarked on a new journey of implementing Shader Based Instancing (and learned HLSL while I was at it) , I ditched XNA's built in Model and Effect objects to write my own replacements instead. I had trouble understanding the VBO streams at first; I broke things - I went online asking questions about the instancing stuff and kept at it until I finally understood what the GPU was doing. It paid off; now I had over twenty thousand test entities zooming around in my viewport after a couple days of debugging my VBO with PIX (dxsdk).

Now I had "some" idea of how rendering pipelines worked, but wasn't done yet - I ended up creating my own game-state, camera, post effects, and entity objects, moved away from the XNA Content Pipeline by building my own loaders (personal dislike towards the XNB thing ), created a complicated depth sorted and blend-state separated geometry chain and also had instanced sprites and text all being projected into the game scene.

I kept adding on, fixing, changing and experimenting with this continuously for almost an entire year. In the end, it came out pretty good. I now had an understanding of what is going on under the hood, because I created it - my baby.

Now my engine was mostly stable and just about finished. It isn't perfect: the scripting is honky and the GUI wasn't great at all. But I still loved it. Thousands of lines of code, assets and media - holed up in a private 2GB git repository, and all the headaches I had to go through trying to do a type of development I never did before. Every obstacle I overcame was a lesson learned - and a relief.

I pulled off almost everything I wanted in it.

But in the end - I decided it was time to put her down. As much as I satisfied myself writing such a huge engine by myself, with advice from the net, and other gamedev buddies, I decided that I'm gonna do it all over again - and do it better - because now this time I mostly know what I'm doing.

That project still sits tucked away in my GIT repo.

My second pass at writing a new engine (this time on MonoGame), is progressing well. When something breaks, it's easier to fix. Less mess. I hope to publicly show off my game sometime this year, because I tend to be a bit 'too' attached to my code.

In the end writing my own engine is how I learned 'how' to do it, while being able to say that I know and understand exactly what every component does, and how they are supposed to work. I actually HATE reading other people's code, especially for large undocumented projects. I want everything I use to be built by me.

This is just me though. I doubt I'll ever use a pre-made engine, probably because I think it's just more fun for me to write my own frameworks than to sit and deal with someone else's code - full control.

Answer 3

The absolute key reason to write your own engine (and it surprises me that nobody has called this out yet) is for debugging.

If you've written a big, complicated game, and there's a crash bug in it, and you have the source code (and are intimately familiar with that source code by virtue of having written it), then you can simply attach a debugger to the process and find what's causing the crash. Done.

If you're using somebody else's commercially-available engine, and you don't have the source code for that engine (you normally don't), then debugging any problems that come up -- even inside your own code -- is going to be monumentally more difficult. And if you run into a bug inside the engine itself, you won't be able to solve them yourself. How would you like to be a week out from your release date and have someone discover a crash bug in the engine you're using -- a crash bug which you can't fix because it's inside a proprietary engine to which you don't have the source code? I've seen this happen -- you've got no choice but to lodge an urgent support call with the vendor and hope that they can (and are interested in) fixing the problem for you, while you scrabble around, trying to guess at a workaround which will avoid hitting the bug in the engine which you don't know what it is.

Game development is hard, but debugging is orders of magnitude harder. In my book, anything which makes game development harder but debugging easier is a huge net win.

Answer 4

There are very good answers here but they're missing one important additional point.

Many of today's licensable engines started out as dedicated engines.

Let's take Unreal as an example because it's so ubiquitous.

Today when you think of Unreal you tend to think of an engine that you license and can use instead of having to build your own, but that wasn't always the case, and once upon a time the Unreal engine didn't even exist as a separate entity.

Once upon a time there was a game called Unreal. The developers of it decided to build their own engine rather than license an existing one. Fast forward through several iterations and that engine becomes the Unreal engine we know today.

The point is that this is a chicken-and-egg problem. Every bit of middleware you can license started somewhere, and it often didn't start out as middleware at all (sometimes it wasn't even written with the intention of becoming middleware and it's current status is effectively an accident). People write their own engines because ultimately somebody has to write the engine, and today's dedicated engine might become tomorrows licensable middleware.

Answer 5

There are others reasons a studio may choose to "build" instead of "buy" their technology:

• New platforms: new mobile OS, console or controlers. Think about leapmotion, google glass, etc. The cross-plataform support is hard
• New game mechanics and/or in-game editors: Think about FEZ, some years ago (2D vs 3D)
• Lack of good free open-source game editors. Lack of good documentation on existing source of old games
• Evolution of the tools in the studio toolchain (or add new ones)
• Engine pricing and license wars

I also agree with specific requests/needs and engine pricing and license wars force some studios to roll out some engines.

The good motives to "buy" or "use" other engines are:

• Code Reuse: a engine already used in other games is more tested, more stable and mayhave most of the features needed, starting from day one.
• Extend: you can extend some open source engines.
• Free: or almost free, since even free open source engines, need some developer time to learn.

Answer 6

Historical reason (mostly).
Which is related to pricing.

Every game you saw running Unreal or CryEngine in the past years had to pay a huge amount of money. Especially if you want to get the source code (ie.: you wanted UE, not UDK only.)

But this changed. Now everyone can afford even bigger engines, as the price race started.
What that means...

• You will see much more games using both UE4 and CryEngine.
  Though, they won't be AAA games like they've been.
• Custom requirements and needs for each projects won't go away.
  See the Warhammer40k/COH engine at Relic, or the one that Generals used at EA.
  So even if anyone can afford the bigger engines, they don't neccesarily offer a better choice.
• There are others on the market. Like Unity.
  People love it for it's ease-of-use, fast performance, and the huge asset store.
  Of course, Unity is able to deploy to almost any platform.

So yeah. Needs, pricing in the past and such.

Answer 7

My answer differs from the existing ones, so I add it although it's late:

If you take the Valve example from the question, or the Witcher series the process was:

• License an engine
• Modify/adapt engine to your purpose
• Release game and generate money
• Create own engine for next game

The same approach is taken by almost all financially reasonable developers who develop their own engine. By modifying an engine they build up knowledge how an engine works, and run into design constraints which result from a licensed engine. At the end they have the in-house knowledge necessary to create an engine, the cash to fund the creation of an engine, and a project which will benefit from a dedicated engine. At that point the reason for building an engine is: Because it's the smart thing to do.

Answer 8

What about the team organization?

Behind the debug stuff are the documentation & support, no the code, because at the end I didn't want that my building group will touch the code of my own engine. That could be a mess.

So, I need a support group to do that. But that raises the costs: more people, more places, more line phone, more administration...

One solution to this may be outsource... to a middleware company, releasing resources to my business of making games, i.e. to the creative group and writers.

For an starting up company it's not a bad option to use and not build. And, after getting a critical mass of incomes, may be, just may be, you will want to build your own engine...

Answer 9

well. for most games that use their own engine created by their developers. often. they can't do things with 3rd party engine. so they make their own to make the development of their own game easier to do. or possible at least.

and many games that use their own engine just generally. work better. because they're more custom and 100% fit their task. and the game itself feels differently. its really easy to play a game and say thats made by. unreal engine or whatever. more custom engine generally and should result in a game that feels unique. looks unique and works uniquely and it should perform better than a game that was created on a pre-made engine.

Answer 10

my programming teacher told us, only use API's/methods/classes/functions which you know how to build

because if you dont know how to build it and are using somebody else's work chances are you dont know how it works and when you dont know how something works then you are alot more prone to error and problems and hitting walls of confusion

learning simple things can when compounded result in strange problems, let alone something complex like a game engine especially when you are supposed to use that game engine to run your game which can lead ot many unexpected results and problems

and game engine dont follow logical code or any other logic when they are built , sure there is some things which can be expected but in reality everything is going to be built based on somebody elses understanding and knowledge of some programming language or how some system works

for example if i choose to write a mathematical equation i can write it so many ways i can represent it with polynomials, or differential calculus or basic geometry or algebra or whatever suits me but sometimes i would write in a certain form/format because i want to be able to manipulate what is easily available , such as if i planed to do alot of vertex manipulation i might write this mathematical model using basic geometry, however if i wanted to change the curve using gradients i might focus on differential calculus to be able to easily manipulate the gradients etc and same goes for whatever it is i plan to have easier access to

and sometimes the current game engine might not give me the flexibility of what i intend to do or even maybe it gives you that option but its very hard to do so because the game engine focuses on physics forces as its main source of motion and manipulation of objects in the game

anyway i hope i made it clear what i was trying to point out