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 at 20:30
    
I guess that's what you do when you have 9K+ employees laying around... –  glampert May 3 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 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 at 16:03

7 Answers 7

up vote 32 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
9  
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 at 9:23

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
8  
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 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. –  antont May 5 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 at 21:33

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

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
    
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 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 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 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 at 5:50
    
@Tim RE: "Middleware makes things easier", I have had very different experiences than you, apparently. –  Trevor Powell May 7 at 3:40

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

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

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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