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

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?

• Possible duplicate: gamedev.stackexchange.com/questions/12488/… and related: gamedev.stackexchange.com/questions/859/…
– House
May 2, 2014 at 20:19
• They don't want to license other companies' game engines and paying them. May 2, 2014 at 20:30
• There are several counter-examples of big studios which create AAA titles using 3rd party engines like Unreal or the CryEngine. May 3, 2014 at 10:07
• Valve started out using the Quake engine, then eventually wrote their own for later games. It's often a matter of learning to use what's available, then eventually wanting to achieve something more than what the existing engine offers. At which point you have to make heavy modifications or roll your own. May 3, 2014 at 16:03
• "When you have a hammer every problem you see is a nail". Just because you can write a certain game with a certain engine that doesn't mean it is the best solution. May 4, 2014 at 13:05

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.

• I would add that there are sometimes advantages to technologies which are "built here." One example is how Unity3D changes their EULAs each version and add strange restrictions, such as no "gambling games." When you license a tech you are at the mercy of the licensor not to turn around and revoke the license for no particular reason (such happens with the IP rights for making licensed games) or decide to charge you to fix their bugs for them. May 3, 2014 at 9:23
• seriously, Unity says "no gambling games"? They even used to have a specific page about gambling in the Community section of their website! Mar 18, 2015 at 18:43
• Unity's page here unity3d.com/industries/gambling says you can buy a "Unity Gambling license". I haven't found a price for it, but sounds like they still allow you to make the games for gambling provided you pay for special licensing.
– Alex
May 7, 2015 at 18:43
• In addition, it's easier to get started with what you already know and end up building an engine, not even knowing what an engine is. An engine is nothing but a collection of use cases; if you are trying to reduce redundancy, you end up writing an engine, and if you are trying to just build the game, you end up with a monolithic system. It's very very difficult to get a game engine and learn how to get it to display a pixel, then realize it can't do that because it sees everything as a texture. You don't have to deal with that when you write your own. May 1, 2016 at 5:58

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.

• This reads a lot more like a rambling personal anecdote; you could probably edit this to make it much more concise and it would make a better answer.
– user1430
May 3, 2014 at 15:49
• This is all certainly great for learning and also for making your game when you have the time for doing everything. When it indeed is just you. But what if you ever want to collaborate with someone? Or work in a company with also other programmers? If someone would like to join your project, isn't it a bit strange that they would be then supposed to read your code -- for them other people's code .. the very thing you HATE. I find that reading code is a very important skill too. No offence, I'm sure you've learned a lot and written a cool engine - just a note that it's not all there is to it. May 5, 2014 at 2:15
• I'm aware of that, just every job I have had involving any kind of code in any language, has always been solo for me D; May 5, 2014 at 21:33
• I must say, I know exactly for what reasons a person rolls out his own engine/tool/whatever. But it has a price (like all things)... I have the feeling that all bosses just plainly hate it when you can't read/understand the most crappiest code out there, so please go ahead and throw yourself in a s***ton of badly written baddly maintained code without documentation, just get a feel for it (the "real" world). No offense. Sep 26, 2014 at 3:33
• That's the reason we, programmers, can't have nice things. Because we always want to make everything ourselves instead of using working and trusted methods. I have compulsive need to write everything myself, but I am slowly learning to trust others and so far it does me more good than bad :) Jan 12, 2015 at 12:13

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.

• This is one big upside we've experienced with using an open source engine (cocos2d-iphone). We can debug it exactly the same way as the code we've written. I actually find that the way to think of open source is that it's your code. If there are bugs we'll have to fix them, like in any other part of our code.. May 5, 2014 at 2:19
• This can be said of any middleware. Debugging code is 80% of a programmer's job, and handling middleware is a common problem with the technology we sit on today with more middleware than we can count. Learning to overcome that is just part of the job. If the engine doesn't break, something else you don't have control over will. Less moving parts is a good idea, but when it gets complicated like game dev, then you'll have to deal with lots of them anyway.
– Tim
May 6, 2014 at 2:36
• @Tim I strongly disagree -- that one external thing might misbehave in a difficult-to-debug way does not imply that we ought to just shrug our shoulders and resign ourselves to letting everything misbehave in difficult-to-debug ways. One obviously needs to take things on a case-by-case basis, but an engine is a big system where tricky bugs often lurk. Why would you not want that under your control, if you can possibly afford to make it yourself? May 6, 2014 at 3:35
• @TrevorPowell It obviously comes down to the complexity of the project and as you say, a case-by-case basis, but simply reinventing a wheel (especially if it's a big wheel) needs to be seriously considered regarding the time saved by not doing it. Middleware makes things easier. As a developers we believe we can always reinvent a solution to make it better without considering how well that solution is put together. A few bumps > reinvention > The wrong solution entirely
– Tim
May 6, 2014 at 5:50
• @Tim RE: "Middleware makes things easier", I have had very different experiences than you, apparently. May 7, 2014 at 3:40

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.

• Worth noting, that back in the day, when the games such as Unreal were first built, there simply were no other choice as writing it all from scratch. It's only the past couple of years where we have a choice of N engines... Dec 29, 2014 at 19:14

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.

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.

• I wouldn't call Havok "heavily modified."
– user1430
May 3, 2014 at 15:50
• Isn't Havok just a physics engine? May 3, 2014 at 16:27
• It is, and GW2 didn't do much of note to it that I can recall.
– user1430
May 3, 2014 at 17:07
• Don't you mean (ie.: you want UE, not UDK only.)? May 4, 2014 at 3:58
• #JoshPetrie: Sorry, to be honest I am not experienced in Havok/never played with it. So I stumbled upon GW2's LICENSE file and then visited it's wiki page a few days ago and saw Havok. Then I had some old memory about seeing "Havok" at a game's start, where I thought that IS the engine. But then I also looked up Havok back then and I knew it's a physics engine. tl;dr: I mixed things up about Havok. || #Philipp: It's a bit more than that, but indeed it's not a game engine, my bad. || #Keavon: Right, fixed. Thanks! May 4, 2014 at 9:28

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:

• 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.

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...

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.

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

• -1 If you work on any respectably sized project, you are actually expected to use function/classes that you don't know how it was written, and you might not be able to write one yourself without having to study number of books on the topic. I am not talking about what every programmer should know, but a game engine is a huge project, and it is expected that programmer X specialized topic X doesn't have knowledge in topic Y and hence have to use the function, I am also not implying that you shouldn't know how to use the API you should but you might not have enough knowledge to write one. Dec 28, 2014 at 10:02
• Does your teacher know how to build a complete car up from chemical elements from scratch? Or does he drives it assuming it just works ;-) Dec 28, 2014 at 11:30
• @concept3d there is a difference between working on a project where somebody else designs those functions/classes you use, because usually if you don't understand something it can be easily explained , a programmer that goes to using code classes/functions/libraries he/she doesn't know is a foolish person, even classes and API's that are available publicly come with manuals and wiki's that explain what those API's or functions do, to just expect to use it without knowing what it does is like trying to swim in deep waters without knowing how to swim, and really ignorant and error prone Mar 16, 2015 at 2:28
• @hopjoppe5 If you check the accepted answer, these are the only reasons that people build their own tech. A lot of the libraries/code are outsourced in real world, and you have to use it. Reading the manuals is different from knowing the implementation, for some algorithms you are even discouraged to implement it yourself and should be implemented by experts in the subject, if you had any real world experience you will understand this. Knowing everything is impossible. Mar 16, 2015 at 7:17
• One of the main reasons for abstraction is to write code so that people who don't know how it works, can still use it. When working on a game any larger than pong, it's not likely that you're familiar with every piece of code. And in most cases that's a good thing, because it means you can focus your mind on what you're working on right now, rather than worry about how the input system might handle your request for an "On Action Key Down" event. Sep 23, 2015 at 14:43