5 ms·

I'm gonna offer you another angle. Custom engine. You CAN almost always beat these general solutions if you specialize with your engine. Question is, should you

I'm gonna offer you another angle. Custom engine. You CAN almost always beat these general solutions if you specialize with your engine. Question is, should you? Would that specialization offer an advantage vs developing something with a general solution like that?

georgemcbay 7y ago
The biggest problem with custom engines is really the tools -- it isn't that hard (relatively) to build a modern feature-rich 3D gaming engine. OTOH, it is very difficult to build a full tool pipeline that supports that engine. Most of the value of Unreal or Unity is that the tools are already there and they more or less Just Work and a lot of people know how to use them.
- Keyframe 7y ago
  Is the format of those tools open? One could, in theory, use their tools, but with custom engine.
  - gridspy 7y ago
    Just go and use Godot if you want an open / custom engine and good tools. https://godotengine.org/ https://godotengine.org/
    - fartcannon 7y ago
      Godot is a fantastic engine. And it's fully open source so if you want to have a hack at it, you definitely can. And the guys who dev it are cool as.
  - gmueckl 7y ago
    The format is somewhat open. Unity stores a lot in plain YAML files. Unreal has a wild serialization framework that is part of the freely accessible source cide (but tons of strings attached - so be careful!). So you might get some reuse out of these editors, but the catch is that they are extremely engine specific (with UE, I can't quite tell if the editor is built for the engine or the engine for the editor). So you'd just set yourself up to replicate the same engine design because it makes handling the output of these editors easier.
  - Bootwizard 7y ago
    Yes. The tools source code is here: https://github.com/Unity-Technologies/UnityCsReference?files=1 https://github.com/Unity-Technologies/UnityCsReference?files...
  - Jasper_ 7y ago
    Formats tend to be tied in some strong nature to the way the engine works. Think of it this way: you could create your own engine, but then every difference between your engine and Unity is a bug from the artist's perspective (thing works correctly in Unity but does not in your engine). There's no sense in using the same format for your engine if you don't implement every single last checkbox and dropdown.
- appstorelottery 7y ago
  >Most of the value of Unreal or Unity is that the tools are already there and they more or less Just Work and a lot of people know how to use them This is a very good point I missed above - people - the fact that lots of developers and artists are already experts with the tools lets you hit the ground running and focus on the game. With a custom engine you've got all the training involved to use your custom toolset.
- gmueckl 7y ago
  This is something I generally miss in game engine discussions. Good tooling for an engine feature is two or three times the effort of the feature itself on average. So ypu can probably bould an amazing engine runtime in your spare time, but doing anything interesting with it is painful because creating the tools is incredibly fiddly.
Crinus 7y ago
From personal experience custom engines offer more flexibility, assuming they're not 20 year old monolithic behemoths that tens (or hundreds!) of developers added their little piece and nobody bothered to remove much over the years. IF they're not that, it becomes easier to mold them to what your game(s) need (especially if you focus on similar genres, at least from a gameplay/engine requirements perspective). Also from a tools perspective, big generic engines like Unreal and Unity have their established ways of working internally that may make writing good tools either hard or suboptimal (meaning that you can do something but since it isn't how the engine likes things it would not be fast). It is usually good enough for most uses, but if you want to make something very specialized you'll have a better time doing it with an engine you have control over, otherwise it'll be an uphill battle (there are cases with Unity for example of people having tools outside the engine and just import the final data, using Unity as little more than a scriptable renderer with asset manager and physics). On the other hand, custom engines mean custom tools and more often than not tools get the short end of the stick in custom engines. It is a double edged sword, on one side you can make some simple and great tools that focus exactly on what your game is all about (something like Unreal is similar to C++: there is a lot of stuff that you can ignore but they still provide mental overhead even when you ignore them), but on the other side you have to make tools (and just in case, using Blender or 3ds max or whatever as your level editor is the perfect road to inflict pain on everyone involved, often leads to low performance with little visibility on why - and unless you have a vendetta against level designers do not even consider using dummy objects for level scripting, the only thing worse than that is asking people to paint triggers on a grayscale terrain texture using Photoshop). (note that i'm assuming you have access to source code here which rules out Unity for the majority of developers using it - and of course i also assume that you have the know-how for working on custom engines)
appstorelottery 7y ago
I think it comes down to budget and what you're trying to develop. Developing your own full-blown engine with all the bells and whistles; scene management, physics, animation, ik solving, audio, video, asset importing, networking, scripting, UI, VR and so on is what used to be one of the biggest investments a game developer would make. ID software's engine generated a lot of revenue for for them back in the day - because was cheaper to pay 250k than do it yourself. At the end of the day as a gaming company you're trying to provide a unique experience - and as you say - a custom engine can be a way of doing that - but after you've created the engine, then you've got to create the game on top of that. So I think these generalised engines have satisfied a market need that wants to focus on the game itself rather than engine development. As mentioned below in the comments - tools are also extremely important. If you're going to support standard tools (e.g. Maya etc.) for asset generation there's more work involved. The entire art pipeline has to be considered. It's a huge job. Making your own editors etc. again lots of work. If you have your own engine - you've probably got your own GUI and asset management system at this point for artists. So this is a long way of coming around to "should you develop your own game engine?" If your use-case means that it's cheaper to do that than extend Unity or Unreal - and you've got the capital and talent - I guess it makes sense. But if you look at the majority of really successful games these days - they're using 3rd party engines. Even rockstar started with using Renderware - and now they have their internal engine with probably really good reason (super deep pockets and use case). But I guess if you're not Rockstar - and you're trying to make something AAA - it's expensive enough without trying for your own engine. Let's not even get started on making the engine cross-platform. Of course, if you're making space invaders and know how to talk to the graphics API directly - none of this is required ;-) Just my IMHO.
- Crinus 7y ago
  Something that i haven't seen mentioned much is that some people just prefer to work on custom engines (i'm willing to bet that the main reason John Carmack made his own engines was because he liked working on his own engines rather than the costs of licensing). I know of at least a case (i wasn't part of it myself) where after a developer decided to switch from their custom engine to Unreal, almost the entire engine team quit. FWIW personally when judging potential workplaces i bias towards those using custom engines since there is way more room for having an actual impact on the project and i am more likely to learn something new from a custom codebase than the 482th Unreal fork. The fact that people often feel the need to justify working (almost always in a defensive stance) with a custom engine shows that they simply prefer to work with a custom engine despite other concerns. Also there isn't really a clear cut distinction between AAA and smaller studios using custom and generic engines - while indies are more likely to use something like Unity, that is mainly because there are way more indies than big teams and many indies do not have the knowledge for a custom engine. But there have been many successful indie and small studio games with custom engines and AAA studios with licensed engines to say that if you're Rockstar go with custom, if you're small go with 3rd party engine. Honestly i think the people involved are way more important (and likely to affect the choice of an engine) than any budget or size concerns (i'm not even considering the game type as most custom engines are used to make games that could also be made with 3rd party engines and the game type is rarely the driving factor for that choice).
soulofmischief 7y ago
I think Unreal wins there because the engine is open source and modifiable whereas Unity's is not.
- cpv 7y ago
  I would say modifiable and available. Create Epic account, link to Github, receive access to UE4 repository. Probably can be revoked easily. Or get it via launcher, after log in into your account. Also, you cannot post online more than 30 lines of engine code (forums, stackoverflow,etc). I'm not a lawyer. Edit: launcher part.
  - soulofmischief 7y ago
    I see, thanks for the distinction.
    - cpv 7y ago
      Nonetheless, having access to the source gives you insights how things work, build by yourself. With more experience, you can customize it, or suggest PRs. This can be a game changer.
- echelon 7y ago
  Open source or available source? Open source means you can use it and redistribute it freely.
Will_Parker 7y ago
It depends on whether you have the technical prowess of Jonathan Blow or not? He was able to create game aspects in custom engines that would have been impossible otherwise. E.g. low level sound control in Braid, some amazing use of lighting and reflection in The Witness.

georgemcbay 7y ago

The biggest problem with custom engines is really the tools -- it isn't that hard (relatively) to build a modern feature-rich 3D gaming engine. OTOH, it is very difficult to build a full tool pipeline that supports that engine. Most of the value of Unreal or Unity is that the tools are already there and they more or less Just Work and a lot of people know how to use them.

Keyframe 7y ago
Is the format of those tools open? One could, in theory, use their tools, but with custom engine.
- gridspy 7y ago
  Just go and use Godot if you want an open / custom engine and good tools. https://godotengine.org/ https://godotengine.org/
  - fartcannon 7y ago
    Godot is a fantastic engine. And it's fully open source so if you want to have a hack at it, you definitely can. And the guys who dev it are cool as.
- gmueckl 7y ago
  The format is somewhat open. Unity stores a lot in plain YAML files. Unreal has a wild serialization framework that is part of the freely accessible source cide (but tons of strings attached - so be careful!). So you might get some reuse out of these editors, but the catch is that they are extremely engine specific (with UE, I can't quite tell if the editor is built for the engine or the engine for the editor). So you'd just set yourself up to replicate the same engine design because it makes handling the output of these editors easier.
- Bootwizard 7y ago
  Yes. The tools source code is here: https://github.com/Unity-Technologies/UnityCsReference?files=1 https://github.com/Unity-Technologies/UnityCsReference?files...
- Jasper_ 7y ago
  Formats tend to be tied in some strong nature to the way the engine works. Think of it this way: you could create your own engine, but then every difference between your engine and Unity is a bug from the artist's perspective (thing works correctly in Unity but does not in your engine). There's no sense in using the same format for your engine if you don't implement every single last checkbox and dropdown.
appstorelottery 7y ago
>Most of the value of Unreal or Unity is that the tools are already there and they more or less Just Work and a lot of people know how to use them This is a very good point I missed above - people - the fact that lots of developers and artists are already experts with the tools lets you hit the ground running and focus on the game. With a custom engine you've got all the training involved to use your custom toolset.
gmueckl 7y ago
This is something I generally miss in game engine discussions. Good tooling for an engine feature is two or three times the effort of the feature itself on average. So ypu can probably bould an amazing engine runtime in your spare time, but doing anything interesting with it is painful because creating the tools is incredibly fiddly.

Crinus 7y ago

From personal experience custom engines offer more flexibility, assuming they're not 20 year old monolithic behemoths that tens (or hundreds!) of developers added their little piece and nobody bothered to remove much over the years. IF they're not that, it becomes easier to mold them to what your game(s) need (especially if you focus on similar genres, at least from a gameplay/engine requirements perspective). Also from a tools perspective, big generic engines like Unreal and Unity have their established ways of working internally that may make writing good tools either hard or suboptimal (meaning that you can do something but since it isn't how the engine likes things it would not be fast). It is usually good enough for most uses, but if you want to make something very specialized you'll have a better time doing it with an engine you have control over, otherwise it'll be an uphill battle (there are cases with Unity for example of people having tools outside the engine and just import the final data, using Unity as little more than a scriptable renderer with asset manager and physics). On the other hand, custom engines mean custom tools and more often than not tools get the short end of the stick in custom engines. It is a double edged sword, on one side you can make some simple and great tools that focus exactly on what your game is all about (something like Unreal is similar to C++: there is a lot of stuff that you can ignore but they still provide mental overhead even when you ignore them), but on the other side you have to make tools (and just in case, using Blender or 3ds max or whatever as your level editor is the perfect road to inflict pain on everyone involved, often leads to low performance with little visibility on why - and unless you have a vendetta against level designers do not even consider using dummy objects for level scripting, the only thing worse than that is asking people to paint triggers on a grayscale terrain texture using Photoshop). (note that i'm assuming you have access to source code here which rules out Unity for the majority of developers using it - and of course i also assume that you have the know-how for working on custom engines)

appstorelottery 7y ago

I think it comes down to budget and what you're trying to develop. Developing your own full-blown engine with all the bells and whistles; scene management, physics, animation, ik solving, audio, video, asset importing, networking, scripting, UI, VR and so on is what used to be one of the biggest investments a game developer would make. ID software's engine generated a lot of revenue for for them back in the day - because was cheaper to pay 250k than do it yourself. At the end of the day as a gaming company you're trying to provide a unique experience - and as you say - a custom engine can be a way of doing that - but after you've created the engine, then you've got to create the game on top of that. So I think these generalised engines have satisfied a market need that wants to focus on the game itself rather than engine development. As mentioned below in the comments - tools are also extremely important. If you're going to support standard tools (e.g. Maya etc.) for asset generation there's more work involved. The entire art pipeline has to be considered. It's a huge job. Making your own editors etc. again lots of work. If you have your own engine - you've probably got your own GUI and asset management system at this point for artists. So this is a long way of coming around to "should you develop your own game engine?" If your use-case means that it's cheaper to do that than extend Unity or Unreal - and you've got the capital and talent - I guess it makes sense. But if you look at the majority of really successful games these days - they're using 3rd party engines. Even rockstar started with using Renderware - and now they have their internal engine with probably really good reason (super deep pockets and use case). But I guess if you're not Rockstar - and you're trying to make something AAA - it's expensive enough without trying for your own engine. Let's not even get started on making the engine cross-platform. Of course, if you're making space invaders and know how to talk to the graphics API directly - none of this is required ;-) Just my IMHO.

Crinus 7y ago
Something that i haven't seen mentioned much is that some people just prefer to work on custom engines (i'm willing to bet that the main reason John Carmack made his own engines was because he liked working on his own engines rather than the costs of licensing). I know of at least a case (i wasn't part of it myself) where after a developer decided to switch from their custom engine to Unreal, almost the entire engine team quit. FWIW personally when judging potential workplaces i bias towards those using custom engines since there is way more room for having an actual impact on the project and i am more likely to learn something new from a custom codebase than the 482th Unreal fork. The fact that people often feel the need to justify working (almost always in a defensive stance) with a custom engine shows that they simply prefer to work with a custom engine despite other concerns. Also there isn't really a clear cut distinction between AAA and smaller studios using custom and generic engines - while indies are more likely to use something like Unity, that is mainly because there are way more indies than big teams and many indies do not have the knowledge for a custom engine. But there have been many successful indie and small studio games with custom engines and AAA studios with licensed engines to say that if you're Rockstar go with custom, if you're small go with 3rd party engine. Honestly i think the people involved are way more important (and likely to affect the choice of an engine) than any budget or size concerns (i'm not even considering the game type as most custom engines are used to make games that could also be made with 3rd party engines and the game type is rarely the driving factor for that choice).

soulofmischief 7y ago

I think Unreal wins there because the engine is open source and modifiable whereas Unity's is not.

cpv 7y ago
I would say modifiable and available. Create Epic account, link to Github, receive access to UE4 repository. Probably can be revoked easily. Or get it via launcher, after log in into your account. Also, you cannot post online more than 30 lines of engine code (forums, stackoverflow,etc). I'm not a lawyer. Edit: launcher part.
- soulofmischief 7y ago
  I see, thanks for the distinction.
  - cpv 7y ago
    Nonetheless, having access to the source gives you insights how things work, build by yourself. With more experience, you can customize it, or suggest PRs. This can be a game changer.
echelon 7y ago
Open source or available source? Open source means you can use it and redistribute it freely.

Will_Parker 7y ago

It depends on whether you have the technical prowess of Jonathan Blow or not? He was able to create game aspects in custom engines that would have been impossible otherwise. E.g. low level sound control in Braid, some amazing use of lighting and reflection in The Witness.