Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I observed that most of the most, big and well-known game titles developers oftenly develop their own engines - like Valve has their engine, Crytek has their own, Ubisoft has their own, Epic games has their own, Square-Enix has their own, ..., the list can be continued endlessly.

Why is that so?

Like, they do that, because they simply can, or possibilities of existing engines is not enough so they develop their own? I can hardly imagine a game which can require some specific engine, I think, possibilities of Unity3D or Unreal is just 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.

So what's the reason behind this?

share|improve this question
1  
1  
They don't want to license other companies' game engines and paying them. –  János Turánszki May 2 '14 at 20:30
    
I guess that's what you do when you have 9K+ employees laying around... –  glampert May 3 '14 at 2:42
3  
There are several counter-examples of big studios which create AAA titles using 3rd party engines like Unreal or the CryEngine. –  Philipp May 3 '14 at 10:07
3  
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. –  Nairou May 3 '14 at 16:03

9 Answers 9

up vote 39 down vote accepted

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.

share|improve this answer
12  
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. –  Skrylar May 3 '14 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! –  jhocking Mar 18 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 at 18:43

as said by Josh Perrie above:

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

share|improve this answer
10  
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. –  Josh Petrie May 3 '14 at 15:49
1  
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. –  antont May 5 '14 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; –  Codie Morgan May 5 '14 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. –  Quonux Sep 26 '14 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 :) –  Maurycy Jan 12 at 12:13

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.

share|improve this answer
2  
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... –  joltmode Dec 29 '14 at 19:14

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.

share|improve this answer
1  
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.. –  antont May 5 '14 at 2:19
1  
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 '14 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? –  Trevor Powell May 6 '14 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 '14 at 5:50
1  
@Tim RE: "Middleware makes things easier", I have had very different experiences than you, apparently. –  Trevor Powell May 7 '14 at 3:40

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.

share|improve this answer
1  
I wouldn't call Havok "heavily modified." –  Josh Petrie May 3 '14 at 15:50
    
Isn't Havok just a physics engine? –  Philipp May 3 '14 at 16:27
    
It is, and GW2 didn't do much of note to it that I can recall. –  Josh Petrie May 3 '14 at 17:07
    
Don't you mean (ie.: you want UE, not UDK only.)? –  Keavon May 4 '14 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! –  Shiki May 4 '14 at 9:28

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)

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

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
1  
-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. –  concept3d Dec 28 '14 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 ;-) –  Krom Stern Dec 28 '14 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 –  hop joppe5 Mar 16 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. –  concept3d Mar 16 at 7:17

protected by Byte56 Mar 18 at 14:24

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.