Is Unity or Unreal fit my needs? Veterans only

Started by
25 comments, last by kop0113 6 years, 1 month ago

Hello there. It's a bad topic, but I'm asking particular things which bother me, so hope to get real help here. First of all, I'm interested in opinion of very experienced users/programmers of Unity (and even better if you have long time Unreal experience as potential alternative). Have no experience with both engines and not very interested to spent half year deep learning one of them to find out that just wasted time. The game will be similar to classic first/third person 3d games (like Alice Madness Returns, Hellblade or something like that) with me as the only one programmer and developer who hire 3d artists to make things faster or to make something I cant do myself as fast as they do. Because of my specialisation, want to make game look as much realistic as I can with not much content, no stunning physics or other fancy stuff.

My skills: 

Mostly wasted time as graphics programmer last two decades, helped indies to improve graphics or modify existing games as hobby, but also have big experience with coding engines (c++) and feel okay with any parts of them (but prefer to avoid because of complexity learning and working someones code). I dont know C#, but guess will be fine with it. Have experience with visual scripting in engines (Virtools and Quest3D) and like it.

What is required and what bother me: 

Working with visual scripting (blueprints) most likely slower process compared to native programming, even with C# which I dont know, so Im not sure if complex project will not become way more time consuming when using Unreal instead of Unity. Also from what I can see in tutorials, Blueprints of Unreal are not perfect and intuitive at first sight, they are mostly very tiny ops, so to make something serious you need to build hell many elements. So, how is this on practice for big projects, can it be that using blueprints be equal or faster development process over C# scripts? My friend told me that Unreal developers cant normally share their code and use screenshots for that, so I fear maybe there is no internal ways to copy-paste some blueprints from one object script to another and require do the same things again and again, right?

I know that most engines with access to sources can be improved a lot by graphics, but its all about time, is it worth such investiment or not. Unreal have good prebuild graphics, but not okay for me, need to write my own screen space ao, change its blending code to much more complicated, better implement some other realtime ambient and indirect lighting features, make other tonemapping and eye adaptation, change temporal aa or disable it. In Unity not just these things, but some other need to be done from scratch and as I understood from googling, you basically define render pipeline flow there, if want to make any good changes, but without source code to do this in C# make me feel it cant work fast if you try to handle more than thousand visible objects on screen. Am I correct about this and Unity have very negative performance impact when trying to customize renderer (without making own .dll of course)?

Texture streaming in Unity do not exist, so is this possible to develop in good way with no noticable stuttering using only included C# code? Is that easy and will work globally or something very tricky and add huge amount of time to game making? To bother with splitting up levels to small scenes and load them is much more work to do when no good streaming is available. In Unreal (not sure, but from what I can see in games), streaming is very weird, it preload low level mips slowly to make framerate smooth and its often much worse than get some delay and display full resolution, so Im not happy with that, but at least by memory requirements its way better than default Unity.

Is Unreal have any simplifications for utilizing save/load game feature or like in Unity, it must be done entirely by programmer hands?

Is it really true that projects in Unity rarely broke when migrating to new version, while Unreal can destroy all the job you have done, so for safety reasons you should stick to some build? if so, Unreal sounds not very good thing, unless you have army of coders who can fix all the bugs in huge engine.

In general, is Unity for complex projects is good enough out of the box by features or require to program too many things which bring up when you start to work on game? Excluding purchasable assets with .dll files in them (prefer to avoid this for multiplatform). I already have bad experience of starting development using other engines and spending half year for each to try write missing, but required code for making game and its not acceptable for me, few months is okay, but no more. So how is it in Unity for usual complex 3d first/third person single player games like shooters or action rpg?

Thanks

Advertisement

You might want to just try out both and evaluate for yourself first hand.

1) Unreal allows you to also use C++ rather than blueprints. There are some differences but it can work in a very similar way to Unity. I have used UE4 for many projects now (including work on a port of the engine to FreeBSD) and I probably still couldn't even make a door open in pure blueprints haha.

2) UE4 as a developer can be used entirely without the editor. You basically generate the build scripts via a command-line tool (or the editor) and then use your favorite Editor or IDE to modify the code and then initiate a build via "gmake" or "msbuild". This almost eliminates any chance that UE4's editor will trash your project on a version bump.

As an artist or designer (who needs to use the editor), yes the version bump can sometimes disconnect assets and the scene but this is also true for Unity. I actually find that UE4 using C MACROS rather than Unity's C# reflection to be a little bit more robust when connecting scripts to the scene but yep, they both can break.

3) I find UE4 to be a nicer choice for build systems such as jenkins or bamboo and version control. For example in Unity, the build script (written in C#) needs to be compiled by the editor before it can run, this gets messy. In UE4, the Unreal Build Tool can do much of the work, such as initiating a bake or a module can be made that doesn't need the editor to actually load. This makes build VMs more feasible.

http://tinyurl.com/shewonyay - Thanks so much for those who voted on my GF's Competition Cosplay Entry for Cosplayzine. She won! I owe you all beers :)

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.
  • Unreal is C++ not C#, if you can even use C# to any real degree in it I couldn't tell you since I've only ever see C++ used with it.
  • Blueprints are certainly not a replacement for code, they're okay for logic and things and have the benefit of being easy to add and remove due to not needing to go through the horrendous process of adding C++ files. They fail horribly when math is involved, since literally every operator is usually a blueprint node.
  • Blueprints nodes copy between things, between different projects is a little different and would require you to migrate the entire blueprint object generally and then copy and paste parts out of it that you want.
  • The texture streaming system on ue4 has options for customization, you can probably fine tune the way it works, or you know, modify it in the engine code.
  • UE4 is nice but like any thing of scale it has a lot of stuff in it you may never use, it also is tuned for very specific types of games, a serious RTS for example would find much to hate in Unreal with the way ticking and the AI behavior trees are set up, they definitely favor more complex characters you would find in an FPS and the entire architecture with game modes and each level being its own world are definitely symptoms of the UT focus. Other options exist but it is quite obvious they were added later on to try and accommodate different game types and thus often feature rather obtuse behavior or restrictions on design, the level streaming in UE4 can be a bit weird to work with, as an example.

Couldn't tell you as much about Unity since I've only used it briefly but frankly given your responses about UE4 I think you need to go investigate more and actually try them both rather than reading and creating these misconceived notions.

This is going to be long. You have a lot of misconceptions of both engines. Spoilers will explain in more detail.

5 hours ago, Boris-ka said:

Working with visual scripting (blueprints) most likely slower process compared to native programming

Faster. Because you are linking code directly with game objects it saves a lot of code work.

Spoiler

 

Where Unreal is slow is at the start of the project. It's like rolling a giant boulder downhill, slow at the start and once it's moving it rolls on it's own.

A example would be materials, you have to make material nodes to set it in the material editor, then each has to connect to there right slot; that is slow work. Once that is done a artist can use the material editor and material functions to build shaders, this reduces workload on graphics programmer.

 

 

5 hours ago, Boris-ka said:

Blueprints of Unreal are not perfect and intuitive at first sight

Blueprints are a tool, think of it as a third party software if you must. Like @kop0113 explained C++ is the coding language for unreal. They also have deliberate limits, like you can't read pixels on a texture without making your own blueprint node for it, these limits are to prevent non-programmers on the team from destroying the game.

C++ can be used to expand blueprints.

Spoiler

Blueprints are a tool for linking code with assets and a tool that allows non C++ programmers to help make game content. For example a artist can use a trigger volume and some rotation code to make a door that opens when clicked on.

 

5 hours ago, Boris-ka said:

My friend told me that Unreal developers cant normally share their code and use screenshots for that

It is safe to say your friend isn't a Unreal user. Blueprints need to copy and paste like any code as such it has a text form that goes to the clipboard. It's just a very long text so it isn't easy to read.

Spoiler

Images are used to explain things. The Unreal documents often provide a copy and paste version of the blueprint it's explaining.

*Removed example- It's too long for post. 

 

 

5 hours ago, Boris-ka said:

Texture streaming in Unity do not exist,

Unity has streaming and it's a constant part of the engine, so much that people often forget that it is streaming.

Spoiler

Unity's scene takes care of the streaming. Any time you try to load in a Unity scene it streams by default. Loading assets from packages at runtime streams them. You can stream scenes in a additive manner that allows you to make larger worlds.

Unity's problems with large open worlds is not the result of their streaming but instead is limited by there rendering pipeline.

 

 

5 hours ago, Boris-ka said:

In Unreal (not sure, but from what I can see in games), streaming is very weird, it preload low level mips slowly to make framerate smooth and its often much worse than get some delay and display full resolution

That is what the developers decide to use, you can pick how you want it. Same for how things are LOD in and all of Unreal's scalability options.

5 hours ago, Boris-ka said:

Is Unreal have any simplifications for utilizing save/load game feature or like in Unity, it must be done entirely by programmer hands?

Unreal has pre-build save tools. Some for saving simple text like score and others will save everything. Unity also has some of these.

Spoiler

Every game has different things it considers "Progress" and so every game has different things to save. Engines like Unity and Unreal gives you tools for the best and worst case, only score or everything; for any other save system there is no way for them to know what you need.

 

5 hours ago, Boris-ka said:

Is it really true that projects in Unity rarely broke when migrating to new version, while Unreal can destroy all the job you have done, so for safety reasons you should stick to some build?

Ha ha, no. Both suck at updating. Unity is known for making unneeded changes to their function names, breaking all the previous code you had. both can have a lot of instability when upgrading.

Spoiler

Often when working with engines you download the same one as the rest of the team. Stick with it and only update if there is a fix important to your game. Updating often involves fixing bugs and is a waste of time if not needed.

When working with a custom engine you don't make changes willy-nilly to the core engine, this is the same concept.

Most large publishers don't update their engine at al during production and keep using the old version till the game is published.

 

 

5 hours ago, Boris-ka said:

Unreal sounds not very good thing, unless you have army of coders who can fix all the bugs in huge engine.

Unless you have a army of developers you won't notice many of the bugs, The ones you do notice will often be shrugged at and moved past. You can only use a small portion of the engine as indie developers.

Spoiler

For example say there is a bug that is causing textures to take 1mb more memory, you won't mind because it's only a problem for games larger than what you can make.

A bug that really stops your development can be fixed by you, both engines allow for this.

 

 

5 hours ago, Boris-ka said:

is Unity for complex projects is good enough out of the box by features or require to program too many things which bring up when you start to work on game?

Unity out of the box can't make a AAA game, but you can make something like Alice Madness Returns. 

Alice Madness Returns has aged well and a lot of the stuff used back then is standard in engines today. Unity can easily make a game like this, Unreal will be even better at it.

Hellblade is a bit too much for Unity out of the box but as a graphics programmer you could make it happen. Hellblade is too much for the average small indie team. Something of this scale should only be attempted with a budget of >$160K and with at least one professional for every part.

5 hours ago, Boris-ka said:

Because of my specialisation, want to make game look as much realistic as I can with not much content,

Unreal then, it's literally what the engine was made for. Unity is practical but ugly.

 

5 hours ago, Boris-ka said:

Have no experience with both engines and not very interested to spent half year deep learning one of them to find out that just wasted time.

This makes it seem like you are disposition against engines and have very little experience making games.  Not saying you never worked on a game, it just reads like you haven't made many games yet.

If engines where as bad as you claimed, no one in there right mind would use them. Engines are very effective and using a pre-build saves a lot of time. There are problems but both Unity and Unreal allow you to edit the engine without editing the source code.

The time spend learning a engine is not wasted. Game development is a skill on it's own and no matter what tools you use the principles remain the same.

40 minutes ago, Scouting Ninja said:

Hellblade is a bit too much for Unity out of the box but as a graphics programmer you could make it happen. Hellblade is too much for the average small indie team. Something of this scale should only be attempted with a budget of >$160K and with at least one professional for every part.

I'd say quite more than $160k. If this source is right (https://www.gamesindustry.biz/articles/2014-10-29-ninja-theory-can-recoup-hellblade-budget-with-300-000-sales), there were 12 core team members, so I'd say it's ballpark one million, and they had a quite experienced crew, I believe. Still, possible to aim for such a thing of course, but a very ambitious goal nonetheless.

If you want to gauge the potential of each engine, take a look at what games were made with each one and with what team size. If the point is only graphics, look at tech demos that appear every now and then made using each one.

Other than this, each one has its own idiosyncrasies, but at the moment and wouldn't say that any of then are inherently better than the other (I'm not a veteran though, so that's only my baseless opinion).

 

 

12 minutes ago, Thiago Monteiro said:

I'd say quite more than $160k. If this source is right (https://www.gamesindustry.biz/articles/2014-10-29-ninja-theory-can-recoup-hellblade-budget-with-300-000-sales), there were 12 core team members, so I'd say it's ballpark one million, and they had a quite experienced crew, I believe. Still, possible to aim for such a thing of course, but a very ambitious goal nonetheless.

Where I live that would barely cover two programmers of low to moderate experience for a year, forget "professional." Making games is crazy expensive if you aren't doing it as a hobby or as slave labor, especially with how costs of everything seem to just be going up. That said that whole we need to raise prices on games because they are so expensive to make is just publisher nonsense, GTA 5 cost less than 300 million to make and made about 2 billion in its first week of sales.

Thanks for the answers folks, appreciate that. But could somebody please answer on my questions about making changes to renderer pipeline in Unity, is that have huge negative impact on performance cause of C# and something done in weird way with many potential troubles? For example, if I decide to replace shadows for point lights to draw them to render target of specific format and custom filtering between transitions of cascades, do I need to make everything from scratch, including build list of shadow casters in area covered by light, so performance will be degraded a lot on C# script? Or if I replace deferred buffers with my custom to have more or less data (as I understood, Unity have prepass draw of scene wasting dips)? I fear such kind of things are made just to have them and nobody care how fast they work.

PS: I really want to avoid trying to learn both engines for making decision, somewhere at 2000-2001 did this mistake, was dissapointed and started to work on my own engine, wasted lot of time. Then around 2007 made another attempt and wasted around 7 months learning, fixing, adding missing things. And then abandoned this idea after finding out how much things must be done first to make engines to be complete for game development and stable, not just for some demos. Some engine can be good at first sight, but would take too much time to polish it for one programmer, while another may suck by learning curve, while summary development time will be way shorter.

4 hours ago, Boris-ka said:

about making changes to renderer pipeline in Unity

Unity knows it's rendering pipeline is awful and a huge turn down for large developers, so they made a Scriptable render pipeline. https://docs.unity3d.com/Manual/ScriptableRenderPipeline.html It's not part of the default engine and you need to go download it.

Unreal exposes it's render pipeline and has composing tools to help with it. You can also download the full source code. For example the AO you want to do can be done with a composer.

5 hours ago, Boris-ka said:

I really want to avoid trying to learn both engines for making decision

Unreal is the one that best fits your needs.

They both work very similar, as do most engines I have ever worked on. Trying each for a week won't do you any harm, but if you need to start now then Unreal is a good choice.

7 hours ago, Thiago Monteiro said:

I'd say quite more than $160k. If this source is right

You are correct, a game like that takes much more than $160K it's just that 160K looks like the boundary between Indie and Big Indie.

A average trained person is worth $45 000 a year. So a team of 4-5 people can make a Indie game of +/- $160K.

 

Hellblade had a good setup, each person on that team of 12 was worth more than $80 000 a year. It took 3 Years to make so saying the game cost $3 000 000 to produce is not a stretch at all.

In fact it looks accurate because it would mean they made about $10 on every game sold at $30 to make their money back at 300 000 sales.

Did they ever say how much it cost to make, like a actual number?

I couldn't find one, only interviews stating that they needed to sell roughly 300k units to recoup investment. Adding overall company costs, typical UK salaries for senior staff (which I think they are), software licensing, distribution costs (they were not getting $30 per unit sold on Steam for instance), marketing, and some odds and ends, you can easily double or triple this estimate.

 

In relation to the topic, this might be a relevant read: https://blogs.unity3d.com/2018/01/18/2018-and-graphics/

 

10 hours ago, Scouting Ninja said:

Unity knows it's rendering pipeline is awful and a huge turn down for large developers, so they made a Scriptable render pipeline. https://docs.unity3d.com/Manual/ScriptableRenderPipeline.html It's not part of the default engine and you need to go download it.

Do you mean horrible in terms of performance, quality or ability to customize? Where do you see the limitations, graphically speaking, of the default render pipeline?

9 hours ago, Thiago Monteiro said:

Do you mean horrible in terms of performance, quality or ability to customize?

For the render pipeline it was all of the above, although in general Unity is easy to customize. 

9 hours ago, Thiago Monteiro said:

Where do you see the limitations, graphically speaking, of the default render pipeline?

Reflections and normal maps is the two that I always have to fight with when working in Unity. In short Unity's realtime render and baking system work completely different resulting in twice the work for artist. Shadows would be third on the list but where you need really good shadows you can use stencils.

Unity users like to use The Blacksmith as a example of how good Unity is, however if you read up on The Blacksmith you quickly discover that to get there look they had to change very fundamental parts of Unity to get it.

This topic is closed to new replies.

Advertisement