Unity/Unreal/Cry?
- Thread starter Injury
- Start date
Havok is middle-ware, rather than a game engine - it really doesn't belong in this poll.
I use Unity and Unreal for various things. I no longer deal with CryEngine, used to use it way back when at university for a couple of things.
CryEngine
Right now, CryEngine is crap. It's one of the worst programming code-bases I've seen and is riddled with very basic amateur bugs. It's my current opinion that the only reason to use CryEngine is for publicity and marketing (if on Kickstarter, it would be to get as many people as possible to throw money at my project) due to gamers believing it to have some kind of pedigree in the game technology world. I believe Star Citizen uses CryEngine solely for this reason. It's not a good engine for space-sims and they've had to modify a lot of the shitty aspects of it (and they hacked around the limitations) just to make it work for their needs. Cloud Imperium Games managed to turn this ridiculous need for hacks and modifications into marketing PR and get more gamers to throw cash at them, it's quite remarkable.
The move to 64bit floats is a symptom of a flaw, not a sign of genius technology, which the utter morons (who really enjoy sucking off Star Citizen's marketing team) seem to believe.
CryEngine was built for the excellent games FarCry & Crysis and it was built to show off specific graphical effects and do some really awesome stuff in that field. It was never designed to be any good as a general purpose game engine, that's the unfortunate truth.
I'm interested in what Lumberyard has done with the engine.
Unreal Engine
Unreal Engine, on the other-hand, is an absolutely wonderful code-base to work on. The community-contributed source code on github is excellent. Everything is clean and easy to navigate around and I'm able to make significant modifications to both the editor and the runtime engine. It is a really excellent engine.
If you want some story-time on this engine, in the early days of UE4 before it hit github the engine was actually pretty shitty. I know that the PlayStation UK R&D teams used it very early on and apparently it was a buggy mess that they had to abandon entirely. I have a sneaking suspicion that the move to github was an effort to let the community develop the engine further and improve its quality by having teams fix their issues themselves and contribute their fixes back to the main engine. This is good.
That being said, whilst I'm comfortable with the UE4 editor, it isn't entirely a blank canvas for developers to work on, unlike Unity. There are some issues I still have with Unreal, specifically their binary compilations for some assets being an absolute bitch with source management software (and build times). I believe they're moving these towards a human readable string IR format to solve these problems, so this complaint may already be solved.
Unity
Unity I'm not allowed to comment on the source code, I'd piss off a few people (I used to make a habit of pissing of Unity back in the days when count Helgason was the CEO, we had a few email conversations).
Since then, Unity has improved a heck of a lot. They got a new development team behind the engine, they're currently doing a fantastic job refactoring the very-shit code into a really excellent job-based graphics renderer.
Unity's marketing is set around realistic graphics, which is something I feel they don't have as good as Unreal (out of the box), its biggest strength is its editor, which is a blank canvas for making pretty much any level-based 3D game you want.
It's still shit for 2D games and it's shit when it comes to open-world or large-scale games. Against my instincts, it seems to be pretty good for RPGs (the multiplat ports of Final Fantasy IX and To The Moon use Unity).
C# is a win for Unity, but overall I think their scripting system is still rather shit, and I know Unity's scripting system inside-out. The way threads are divvied-up is not consistent and is flawed. I hope they resolve this for the refactoring. Basically on some platforms your scripting is initialised on a main thread, some times it's on the render thread and the callbacks can be on any old thread, you have no idea until you pick a platform and script for it.
Their refactoring has a much better way of handling the rendering thread, way, way better, so if you want to deal with that then things will be fine, but any other thread (including main) is a nightmare to handle.
The other thing I dislike about Unity is the blind fanboyism some of its users have. If you're making a game, personally I think Unity is a better choice than Unreal, but Unity is not the only choice and it is not perfect at all. I know people who love the engine so much that they refused to learn anything else and now their entire career is "Unity", and personally I think it's stupid to make your career depend on the existence of someone else's technology. The best Unity developers know that it is shit, but they've chosen it because of what it can do better than other engines.
Suffers from the same large-project crippling binary IR issue that Unreal Engine has. Unity needs to develop a string IR as well. Actually, overall Unity's editor is really crappy for large-scale team projects across source management. It's good for using, but after a long period of time it really doesn't play nice.
The other scripting languages Unity offers should not be used. I know that Yanadere Simulator has suffered massively from technical debt (absolutely massive) because it was all coded in Javascript. Apparently the developer is working with a studio (thank fuck for that, he desperately needed a producer for his project) and the first task the studio is doing is refactoring the code-base to C# for improved compile times and code-health/management.
One more thing with Unity, their road-map is specifically built around mobile. They love mobile, they've made a lot of money from it, that's where their main development is focused. Their priority hierarchy is basically:
Conclusion
For small projects, use Unity. No reason not to, it's very good. For large, long-term projects; use Unreal Engine. It won't start fucking over your team of 8+ developers or shitting its pants when updated or managed over git 18 months down the line - something Unity really does spectacularly.
Don't use CryEngine.
If you're developing a traditional game for mobile, then use Unity. The only reason to write a custom game engine for mobile is if your game is doing something revolutionary on the mobile platform that hasn't been done before. Unity will always be a few years behind the bleeding-edge of technology (depending on how high up that technology is on the list I posted above).
On other platforms, there's more room to argue for writing a custom engine. In some cases the Quake III engine would be a better choice than Unity (networking).
Unreal Engine wins the console space easily.
I use Unity and Unreal for various things. I no longer deal with CryEngine, used to use it way back when at university for a couple of things.
CryEngine
Right now, CryEngine is crap. It's one of the worst programming code-bases I've seen and is riddled with very basic amateur bugs. It's my current opinion that the only reason to use CryEngine is for publicity and marketing (if on Kickstarter, it would be to get as many people as possible to throw money at my project) due to gamers believing it to have some kind of pedigree in the game technology world. I believe Star Citizen uses CryEngine solely for this reason. It's not a good engine for space-sims and they've had to modify a lot of the shitty aspects of it (and they hacked around the limitations) just to make it work for their needs. Cloud Imperium Games managed to turn this ridiculous need for hacks and modifications into marketing PR and get more gamers to throw cash at them, it's quite remarkable.
The move to 64bit floats is a symptom of a flaw, not a sign of genius technology, which the utter morons (who really enjoy sucking off Star Citizen's marketing team) seem to believe.
CryEngine was built for the excellent games FarCry & Crysis and it was built to show off specific graphical effects and do some really awesome stuff in that field. It was never designed to be any good as a general purpose game engine, that's the unfortunate truth.
I'm interested in what Lumberyard has done with the engine.
Unreal Engine
Unreal Engine, on the other-hand, is an absolutely wonderful code-base to work on. The community-contributed source code on github is excellent. Everything is clean and easy to navigate around and I'm able to make significant modifications to both the editor and the runtime engine. It is a really excellent engine.
If you want some story-time on this engine, in the early days of UE4 before it hit github the engine was actually pretty shitty. I know that the PlayStation UK R&D teams used it very early on and apparently it was a buggy mess that they had to abandon entirely. I have a sneaking suspicion that the move to github was an effort to let the community develop the engine further and improve its quality by having teams fix their issues themselves and contribute their fixes back to the main engine. This is good.
That being said, whilst I'm comfortable with the UE4 editor, it isn't entirely a blank canvas for developers to work on, unlike Unity. There are some issues I still have with Unreal, specifically their binary compilations for some assets being an absolute bitch with source management software (and build times). I believe they're moving these towards a human readable string IR format to solve these problems, so this complaint may already be solved.
Unity
Unity I'm not allowed to comment on the source code, I'd piss off a few people (I used to make a habit of pissing of Unity back in the days when count Helgason was the CEO, we had a few email conversations).
Since then, Unity has improved a heck of a lot. They got a new development team behind the engine, they're currently doing a fantastic job refactoring the very-shit code into a really excellent job-based graphics renderer.
Unity's marketing is set around realistic graphics, which is something I feel they don't have as good as Unreal (out of the box), its biggest strength is its editor, which is a blank canvas for making pretty much any level-based 3D game you want.
It's still shit for 2D games and it's shit when it comes to open-world or large-scale games. Against my instincts, it seems to be pretty good for RPGs (the multiplat ports of Final Fantasy IX and To The Moon use Unity).
C# is a win for Unity, but overall I think their scripting system is still rather shit, and I know Unity's scripting system inside-out. The way threads are divvied-up is not consistent and is flawed. I hope they resolve this for the refactoring. Basically on some platforms your scripting is initialised on a main thread, some times it's on the render thread and the callbacks can be on any old thread, you have no idea until you pick a platform and script for it.
Their refactoring has a much better way of handling the rendering thread, way, way better, so if you want to deal with that then things will be fine, but any other thread (including main) is a nightmare to handle.
The other thing I dislike about Unity is the blind fanboyism some of its users have. If you're making a game, personally I think Unity is a better choice than Unreal, but Unity is not the only choice and it is not perfect at all. I know people who love the engine so much that they refused to learn anything else and now their entire career is "Unity", and personally I think it's stupid to make your career depend on the existence of someone else's technology. The best Unity developers know that it is shit, but they've chosen it because of what it can do better than other engines.
Suffers from the same large-project crippling binary IR issue that Unreal Engine has. Unity needs to develop a string IR as well. Actually, overall Unity's editor is really crappy for large-scale team projects across source management. It's good for using, but after a long period of time it really doesn't play nice.
The other scripting languages Unity offers should not be used. I know that Yanadere Simulator has suffered massively from technical debt (absolutely massive) because it was all coded in Javascript. Apparently the developer is working with a studio (thank fuck for that, he desperately needed a producer for his project) and the first task the studio is doing is refactoring the code-base to C# for improved compile times and code-health/management.
One more thing with Unity, their road-map is specifically built around mobile. They love mobile, they've made a lot of money from it, that's where their main development is focused. Their priority hierarchy is basically:
- Android & iOS
- Windows
- macOS
- Apple TV
- Nintendo Switch (has this been publicly announced? If it hasn't then I'm talking out of my butt so please don't believe me)
- Web Player <- this one is making a comeback
- Playstation 4 / XBone (I know their PS4 development used to be more focused than XBone, but that may have changed by now)
- Wii U
- Linux
- Blackberry, Wii, 360, PS3, 3DS, PSVita, Windows Phone (Windows Phone used to be a bigger focus, it's not now)
Conclusion
For small projects, use Unity. No reason not to, it's very good. For large, long-term projects; use Unreal Engine. It won't start fucking over your team of 8+ developers or shitting its pants when updated or managed over git 18 months down the line - something Unity really does spectacularly.
Don't use CryEngine.
If you're developing a traditional game for mobile, then use Unity. The only reason to write a custom game engine for mobile is if your game is doing something revolutionary on the mobile platform that hasn't been done before. Unity will always be a few years behind the bleeding-edge of technology (depending on how high up that technology is on the list I posted above).
On other platforms, there's more room to argue for writing a custom engine. In some cases the Quake III engine would be a better choice than Unity (networking).
Unreal Engine wins the console space easily.
I was hoping you'd reply!
Thank you for the in-depth response. The place I work at now uses a spin-off of Cry and Havok for it's MMO. There are a few engines floating around here. I'm glad you are giving me something decisive to go on as I'm just trying to spec out basic games right now and if the Unity pipeline is simple enough for what I'm doing, I'll go with that.
Unreal is pretty. Like really pretty, but therein lies the problem. I'm not good at making pretty things. I think for what I'm able to model, low poly BS that it is, it will fit better in Unity's look anyways.
Maybe I'll dip my toes with Unity on one genre and Unreal on another. I feel like I should stay agile at this point and learn both to stay balanced.
They are moving my office in a couple of years so I have to get on this or it's a no go.
What did you do for materials, models, etc when you started? I feel like I have to make my own stuff right now for the practice, but any thoughts for the non-artist model maker?
Thank you for the in-depth response. The place I work at now uses a spin-off of Cry and Havok for it's MMO. There are a few engines floating around here. I'm glad you are giving me something decisive to go on as I'm just trying to spec out basic games right now and if the Unity pipeline is simple enough for what I'm doing, I'll go with that.
Unreal is pretty. Like really pretty, but therein lies the problem. I'm not good at making pretty things. I think for what I'm able to model, low poly BS that it is, it will fit better in Unity's look anyways.
Maybe I'll dip my toes with Unity on one genre and Unreal on another. I feel like I should stay agile at this point and learn both to stay balanced.
They are moving my office in a couple of years so I have to get on this or it's a no go.
What did you do for materials, models, etc when you started? I feel like I have to make my own stuff right now for the practice, but any thoughts for the non-artist model maker?
Nathaniel3W
Member
Injury":3ofc4tct said:
Unity Asset Store. Even if you end up not using Unity, check the Asset Store. You might also try getting some assets from there and modifying them. It will help you learn the various content-creation tools you'll want to know your way around, and it will help your game look less generic.
Nathaniel3W
Member
Injury":3p8yo2p0 said:
We all have a tendency to conflate things that we usually see together. Like comics and superheroes. There's no reason why comics have to be about superheroes, but we all associate the two because we see them together.
Likewise, we associate a certain visual style with Unreal because that's how people have been using it. But there's no reason why you couldn't use Unreal with creative shaders and stylized art. That's basically what I'm doing.