Comments on: Built here? No, thanks [...] Built here? No, thanks. On why building your own internal game engine may not be a good idea. [...] [...] Built here? No, thanks. On why building your own internal game engine may not be a good idea. [...]

]]>
By: Daniel/2011/03/17/built-here-no-thanks/#comment-1727 Daniel Fri, 18 Mar 2011 20:03:58 +0000 I wonder, the 'great' games that are made with custom engines, do they always come from big companies who can afford them, or are there others? I wonder, the ‘great’ games that are made with custom engines, do they always come from big companies who can afford them, or are there others?

]]>
By: James Podesta/2011/03/17/built-here-no-thanks/#comment-1703 James Podesta Fri, 18 Mar 2011 13:36:12 +0000 It's not a xxx vs xxx thingie, it's a matter or making people think a bit about starting an in house engine. Some teams don't actually think about it. I've seen every single example I give in the post in real life, so it's not about stereotypes, but about what really happens. So little stereotyping there, get your facts straight. It’s not a xxx vs xxx thingie, it’s a matter or making people think a bit about starting an in house engine. Some teams don’t actually think about it.

I’ve seen every single example I give in the post in real life, so it’s not about stereotypes, but about what really happens. So little stereotyping there, get your facts straight.

]]>
By: Sepul/2011/03/17/built-here-no-thanks/#comment-1682 Sepul Thu, 17 Mar 2011 23:59:33 +0000 I must agree with this post. I think that there are not many cases where developing a custom engine pays off. It seems to me that taking an existing engine and adding a set of game exclusive features will indeed have all the aforementioned benefits. A mistake easily made is the 'adding' part. A third party engine is always developed with a certain design in mind, so when you choose one you have to make sure that the design fits the goals for your game, otherwise you end up changing huge chunks of code from your 3rd party engine to make it applicable for your game. In that case you either chose the wrong engine or you have such specific requirements that you should have written your own engine. Another problem with custom engines is that when your game has finally shipped, all that you have a left is an engine that is tailored purely for the game you just shipped. So what are you going to do? Create yet another sequel or similar game, or do you want to take a fresh start and make another type or original game? Chances aren't high that you'll be able to reuse your custom engine so you end up writing yet another one, with all risks and costs involved. Also, if you have multiple games in development, are you going to write an engine for every single one of them? Is it worth the cost? Maybe if you're Blizzard... I must agree with this post. I think that there are not many cases where developing a custom engine pays off. It seems to me that taking an existing engine and adding a set of game exclusive features will indeed have all the aforementioned benefits.

A mistake easily made is the ‘adding’ part. A third party engine is always developed with a certain design in mind, so when you choose one you have to make sure that the design fits the goals for your game, otherwise you end up changing huge chunks of code from your 3rd party engine to make it applicable for your game. In that case you either chose the wrong engine or you have such specific requirements that you should have written your own engine.

Another problem with custom engines is that when your game has finally shipped, all that you have a left is an engine that is tailored purely for the game you just shipped. So what are you going to do? Create yet another sequel or similar game, or do you want to take a fresh start and make another type or original game? Chances aren’t high that you’ll be able to reuse your custom engine so you end up writing yet another one, with all risks and costs involved.

Also, if you have multiple games in development, are you going to write an engine for every single one of them? Is it worth the cost? Maybe if you’re Blizzard…

]]>
By: Joe Hegarty/2011/03/17/built-here-no-thanks/#comment-1674 Joe Hegarty Thu, 17 Mar 2011 16:13:50 +0000 I agree. It should be ready for the artists to use as soon as possible. But I also think it's a matter of planning - if someone has just started learning how to build engines, it's obvious that he won't design anything near the engine the team would want to use. As a result, a lot of time is wasted for everyone. However, if the developers have the required engine building experience, training can be safely started in the pre-production phase. What I want to say with this is - those who want to make an engine for their games must learn to make them in a safe environment (no business, no hard deadlines etc.) first. And be really enthusiastic about it. I agree. It should be ready for the artists to use as soon as possible. But I also think it’s a matter of planning – if someone has just started learning how to build engines, it’s obvious that he won’t design anything near the engine the team would want to use. As a result, a lot of time is wasted for everyone. However, if the developers have the required engine building experience, training can be safely started in the pre-production phase.

What I want to say with this is – those who want to make an engine for their games must learn to make them in a safe environment (no business, no hard deadlines etc.) first. And be really enthusiastic about it.

]]>
By: Bernat Muñoz/2011/03/17/built-here-no-thanks/#comment-1669 Bernat Muñoz Thu, 17 Mar 2011 11:26:08 +0000 3. I don't assume artists and coders work on different parts of the world. It's just that you usually want to get some tech running before actually hiring artists, else they might have to wait until they can work on something valuable. Consider it "tech pre-production" phase. And during that pre-production, tech will change a lot, so even if you'd be training people during that period, it'd be quite a time losing investment. Also, as a note, my main concern is people hired AFTER the engine is developed (for example, after the first or second game is released, and the company starts growing). 3. I don’t assume artists and coders work on different parts of the world. It’s just that you usually want to get some tech running before actually hiring artists, else they might have to wait until they can work on something valuable. Consider it “tech pre-production” phase. And during that pre-production, tech will change a lot, so even if you’d be training people during that period, it’d be quite a time losing investment. Also, as a note, my main concern is people hired AFTER the engine is developed (for example, after the first or second game is released, and the company starts growing).

]]>
By: Kester Maddock/2011/03/17/built-here-no-thanks/#comment-1667 Kester Maddock Thu, 17 Mar 2011 10:57:39 +0000 That's true, I didn't really mention teamwork there. But I can do that now (just a bit out of order, I hope you don't mind): 7. If considerations of artists of the team are taken into account when developing the content pipeline, artists will know how to use it and they will most probably like it. If they have to work with something that is already done, it's a 50:50 chance that they won't like it. Besides, making a new content pipeline isn't hard. Using engines that require to use one of the more popular (and more useless) mesh formats is a lot harder - they lack almost everything a good format needs - compact binary representation, material description system, LOD/imposter info etc. Or they have crammed all that in the editor, different for each instance and that's just horrifying. 3. I think you have the assumption that artists and programmers work in different sides of the world. Well, even if they did, it would still be possible to take their ideas and preferences into account in the development of the engine. Also, training people is a job you can do as you're making the engine, not only after. 4. There's nothing to consider about the team - if something doesn't work, it will be programmer's fault. And he will spend months hacking a feature together. 1. In-house engine with an editor is better than another finished engine without an editor. I think everyone will agree. The other points I've made are about considerations of a certain programmer in the team and didn't seem relevant enough to update. Actually, most of those are about the work of a programmer. Only one or two - those who will use the feature. Those would also probably develop the part in a small team... I agree with you about the amount of time necessary to develop an engine though. It's always more than one thinks it would be. In my case, almost exactly two times more. But it's my first time with a 3D engine(weird, isn't it?). So, obviously - if I had the experience before, I would use the better decisions first and didn't have to update many parts of it. So it's all about experience... That’s true, I didn’t really mention teamwork there. But I can do that now (just a bit out of order, I hope you don’t mind):

7. If considerations of artists of the team are taken into account when developing the content pipeline, artists will know how to use it and they will most probably like it. If they have to work with something that is already done, it’s a 50:50 chance that they won’t like it. Besides, making a new content pipeline isn’t hard. Using engines that require to use one of the more popular (and more useless) mesh formats is a lot harder – they lack almost everything a good format needs – compact binary representation, material description system, LOD/imposter info etc. Or they have crammed all that in the editor, different for each instance and that’s just horrifying.

3. I think you have the assumption that artists and programmers work in different sides of the world. Well, even if they did, it would still be possible to take their ideas and preferences into account in the development of the engine. Also, training people is a job you can do as you’re making the engine, not only after.

4. There’s nothing to consider about the team – if something doesn’t work, it will be programmer’s fault. And he will spend months hacking a feature together.

1. In-house engine with an editor is better than another finished engine without an editor. I think everyone will agree.

The other points I’ve made are about considerations of a certain programmer in the team and didn’t seem relevant enough to update. Actually, most of those are about the work of a programmer. Only one or two – those who will use the feature. Those would also probably develop the part in a small team…

I agree with you about the amount of time necessary to develop an engine though. It’s always more than one thinks it would be. In my case, almost exactly two times more. But it’s my first time with a 3D engine(weird, isn’t it?). So, obviously – if I had the experience before, I would use the better decisions first and didn’t have to update many parts of it.

So it’s all about experience…

]]>
By: Bernat Muñoz/2011/03/17/built-here-no-thanks/#comment-1662 Bernat Muñoz Thu, 17 Mar 2011 08:26:34 +0000 By third parties? On consoles, as you know, you get a few first parties developing engines for the console they're exclusive to, but those not lucky enough, have to work with way less resources. Most of my favorite games on console have a custom engine, also, but that doesn't mean you have the resources to actually push one while creating a game. By third parties? On consoles, as you know, you get a few first parties developing engines for the console they’re exclusive to, but those not lucky enough, have to work with way less resources. Most of my favorite games on console have a custom engine, also, but that doesn’t mean you have the resources to actually push one while creating a game.

]]>
By: Tips on making your own game « kelthar/2011/03/17/built-here-no-thanks/#comment-1659 Tips on making your own game « kelthar Thu, 17 Mar 2011 07:52:41 +0000 Obviously if you don't have graphics as a high priority just buy the thing and get the hell on with what is unique about your game - same with any area. But let's say you do care about graphics. Look at the number of successful games that wrote their own engine. There's lots of them. Those people made an engine with unique features and showed off those unique features like crazy. Look at the number of successful games "based on" another engine. There's lots of them. Those people got great content on-screen quickly, then spent a ton of time rewriting the engine from the ground up - there's usually nothing left of the original engine by the time they've finished, but they paid the cost of grokking (and nuking) someone else's codebase on the way. Both paths require an in-house team of graphics ninjas. Which one you choose is largely down to temperament. Are you happy rewriting someone else's codebase but having pretty (but probably slow) stuff immediately, or will you go for maximum performance & features but have a painful start? Obviously if you don’t have graphics as a high priority just buy the thing and get the hell on with what is unique about your game – same with any area. But let’s say you do care about graphics.

Look at the number of successful games that wrote their own engine. There’s lots of them. Those people made an engine with unique features and showed off those unique features like crazy.

Look at the number of successful games “based on” another engine. There’s lots of them. Those people got great content on-screen quickly, then spent a ton of time rewriting the engine from the ground up – there’s usually nothing left of the original engine by the time they’ve finished, but they paid the cost of grokking (and nuking) someone else’s codebase on the way.

Both paths require an in-house team of graphics ninjas. Which one you choose is largely down to temperament. Are you happy rewriting someone else’s codebase but having pretty (but probably slow) stuff immediately, or will you go for maximum performance & features but have a painful start?

]]>
By: Szymon Swistun/2011/03/17/built-here-no-thanks/#comment-1654 Szymon Swistun Thu, 17 Mar 2011 03:55:17 +0000 <i>Severe rant warning: for those who don't support the idea of making an engine at all, you may be really angry after reading this. You have been warned!</i> :) I've tried working with another engines. Honestly, I have done that. Conclusion: most of them suck. And it's not because some features were not working - most of the time everything was working. It's because... 1. There are no good and easily extensible editors for engines and making them is like going through hell.. and back. 2. Most productions have special requirements - like unique shading, huge worlds, 4D data, action replays etc. Most engines are designed for the average case and thus just don't fit. If someone doesn't believe me, give me the name of an engine that can render 5000 objects, maintain rendering speed above 60 FPS, have an extensible entity framework, the ability to generate meshes procedurally and a very simple WYSIWYG editor. The one I have doesn't count here. :D I doubt that even Unreal could generate meshes for you (except CSG brushes, of course). 3. Working with your own engine is much faster than with any other engine. Obviously. 4. If there's something you need and the engine has that, chances are - it's not what you were hoping for. If you wanted a GUI - please, you have one. It's just locked to pixel coordinates... good luck using that for HUD. If you wanted an extensible material system - here you go! But please don't ask for more than 4 custom textures! And it continues to infinity. The result - you have to write lots of your own code anyway. Problems - of course! What you could write in a few lines if you had your own engine, you'll have to wrap around the existing interface until it chokes... need extensible LOD system? Write your own renderer on top of the old one with dynamic data insertion and removal! 5. You need scripting? Engines will push it to you until it's coming out of your ears. While it's good to have the ability to test ideas quickly, quite often scripting controls everything which means there's way too much of it. That amount of control is unmaintainable by the engine designer and doesn't work fast and doesn't help with debugging. 6. Most engines are "interfaced" - they're made in a way that users could use a designed interface which is often wrapped around everything unnecessarily just because there's a library/header/dll border between the engine and the game. I actually prefer working with framework-like engines. They're way more easy to develop and use because of the lack of clutter. Now many people are saying "make games, not engines" and if once I could totally agree, today I can't - the situation with game engines is awful (it's not like the situation was better once, I just grew up :D ). But I also don't fight the opinion - after all, there are lots of developers making their clones of whatever game they like and for those games, those engines are really great. But for productions that stand out - rarely - and even then engines aren't used without heavy modifications. And they're commercial... Severe rant warning: for those who don’t support the idea of making an engine at all, you may be really angry after reading this. You have been warned! :)

I’ve tried working with another engines. Honestly, I have done that. Conclusion: most of them suck.
And it’s not because some features were not working – most of the time everything was working.
It’s because…
1. There are no good and easily extensible editors for engines and making them is like going through hell.. and back.
2. Most productions have special requirements – like unique shading, huge worlds, 4D data, action replays etc. Most engines are designed for the average case and thus just don’t fit. If someone doesn’t believe me, give me the name of an engine that can render 5000 objects, maintain rendering speed above 60 FPS, have an extensible entity framework, the ability to generate meshes procedurally and a very simple WYSIWYG editor. The one I have doesn’t count here. :D I doubt that even Unreal could generate meshes for you (except CSG brushes, of course).
3. Working with your own engine is much faster than with any other engine. Obviously.
4. If there’s something you need and the engine has that, chances are – it’s not what you were hoping for. If you wanted a GUI – please, you have one. It’s just locked to pixel coordinates… good luck using that for HUD. If you wanted an extensible material system – here you go! But please don’t ask for more than 4 custom textures! And it continues to infinity. The result – you have to write lots of your own code anyway. Problems – of course! What you could write in a few lines if you had your own engine, you’ll have to wrap around the existing interface until it chokes… need extensible LOD system? Write your own renderer on top of the old one with dynamic data insertion and removal!
5. You need scripting? Engines will push it to you until it’s coming out of your ears. While it’s good to have the ability to test ideas quickly, quite often scripting controls everything which means there’s way too much of it. That amount of control is unmaintainable by the engine designer and doesn’t work fast and doesn’t help with debugging.
6. Most engines are “interfaced” – they’re made in a way that users could use a designed interface which is often wrapped around everything unnecessarily just because there’s a library/header/dll border between the engine and the game. I actually prefer working with framework-like engines. They’re way more easy to develop and use because of the lack of clutter.

Now many people are saying “make games, not engines” and if once I could totally agree, today I can’t – the situation with game engines is awful (it’s not like the situation was better once, I just grew up :D ). But I also don’t fight the opinion – after all, there are lots of developers making their clones of whatever game they like and for those games, those engines are really great. But for productions that stand out – rarely – and even then engines aren’t used without heavy modifications. And they’re commercial…

]]>
By: James Podesta/2011/03/17/built-here-no-thanks/#comment-1643 James Podesta Thu, 17 Mar 2011 01:15:58 +0000