Forum rules - please read before posting.

Unity or Unreal?

I'm a non programmer. I make 3D and 2D assets. I know there will probably be a bias for Unity here, but I'm willing to hear these opinions too. 

What is the best engine to start with? Are blueprints worth investing time in to learn? AC appeals to me because the essentials for adventure games is already provided. However, I hear Unity requires more coding. 

Comments

  • edited October 2017
    Both require coding. Blue prints are best for small tasks or giving logic to animation states/character controllers. If you make a game using only blueprints chances are the performance isn't going to be all that better than making it with c# in unity. Heaps of Unreal users will tell you the best is to write you own code that then interacts with the blueprints you've made. 

    But C++ is quite hard as a starting programming language, since you have to manage memory yourself. This makes it easier for novices to shoot themselves in the foot... a poorly written c++ is most likely not going to be any faster than a regular quality c# code, where memory is managed for you automatically. In C# all you need to do is learn what kind of things to avoid (like, if possible, to avoid using a foreach containing a lot of instructions inside a continiously looping method). 

    Unreal does have better visuals out of the box, period. And it allows you to use visual scripting to make your own shaders, which is closely related to why Unreal tends to look better (in Unity, if you want custom shaders, you have to write them yourself or buy a shader editor in the store, and shader coding is pretty hard if your math and trig is bad). Well, to be fair, there are very good VFX packages for Unity, like Unity's own free Post Processing stack, but they are all separate downloads and are not there out of the box. 

    On the other hand Unreal is more complex, tasks are more clearly separated (for different specialist), so it's harder to learn, and better suited for teams rather than solo devs (unless you have a lot of industry experience). Unity all in all is usually the best starting point to learn about game development or get into the industry (since it's easier, and c# is easier to learn too). You can always learn Unreal later too, lots of people tend to choose one or the other depending on the project's needs. You don't really have to stick to just Unity or just Unreal.

    But, seeing how you are interested in Adventure games, I'd say to stick to Unity and AC. AC has most of the functionality (if not all) to make an adventure game (be it, 2D, 3D or 2.5D). AC has it's own visual scripting based on Actions (ie: like switch scene, or play this audio/animation, swap cameras, etc), it allows you to do some pretty complex logic without programming anything (if you really need or want to). So, unless you have some pretty uncommon features planned I doubt you'd need to code all that much, if at all, since chances are you could implement some of the features using AC's visual scripting.

    One warning though, using AC or other game frameworks for Unity doesn't mean you should skip learning Unity basics. You'll end up creating walls for yourself (since, if you don't know how to do something you may end up thinking it's impossible or make up an unnecessary complex solution. Or you may end up missing a feature because you don't know it exists). If you want to make a good game you still need to know how to use Unity properly, period. The good thing is there are ton's of Unity tutorials or video courses out there. Unity has a good learning section in their site and recently added some interactive tutorials which can be accessed in the Launcher itself (in the learn tab). You'll just have to put the effort to watch them. Also Unity's community is huge and tends to be more helpful to the novice user (since many of them began in the same way). 

    Anyway, whatever you decide, best of luck!
  • Depending on how much ammount of time are you willing to spend.

    If we are just talking about the vainilla editors themselves, UE is just a better, more robust engine, and that is totally targeted at making games.

    That being said, I find C# better than blueprints, and haven't even delved into UE c++.

    The only thing I can say about unity is that has quite a better asset store, and you can find solutions to almost anything there, but like Alverik said, you'll rust if you rely only on them (I know it by first hand). Also Unity is getting quite a overhaul recently, and I can say that the cinemachine stuff they implemented is amazing.

    Also looking at the future, UE isn't looking good financially and unity is swimming in money.

    I really can't say, I have both editors and I'm mostly trying to learn Unreal, while developing in Unity. I also take this more like a hobby than anything.

    But if I would give advice to someone it would be: go with UE. It's just better, and even easier in a lot of ways. They're quite similar in a lot of ways, so it'll be easy to jump from one to another.
  • edited December 2017
    shredingskin I'd be interested to know why you think that UE is "just better." I don't agree at all. UE tends to have "better" graphics. If you are very very graphics-focused I suppose I could understand why you think UE is better. Other than that, I don't know why you would believe this.

    If I would give advice to someone, it would be to go with Unity, especially if they are an indie dev. Indie games don't live or die based on having next gen graphics anyway. It's been around longer and is more mature, the community is larger, the asset store is invaluable, coding in C# makes a hell of a lot more sense than using C++ (it's not like you're writing the low level engine code for christs sake!).
  • UE isn't just a graphics focused engine, hell, Unity lighting is more complex than UE's, the only thing I'd say that UE post processing is really useable out of the box (now unity is also working on post processing volumes like UE) and the AA is quite a step ahead.

    Things that UE has over unity:
    1- Better high end performance, just put a geometrically complex scene, both in defered, with post processing, look which one looks better.
    2- Terrain tools. Unreal is miles ahead here.
    3- Geometry edditing. This is pretty new, but it's like a probuilder lite out of the box (but it works without causing overhead).
    4- Blueprints (even if you don't like it, in Unity the most similar is notorus that costs 250 bucks).
    5- Unreal had what unity calls timeline (that still has some quirks) a long time ago.
    6- Shader editor with material instances/masters.
    7- Bake times.
    8- Pretty usable examples right out of the box.
    9- Particle system, shuriken is pretty bad performance-wise and isn't as good IMO.
    10- Occlusion/lod tools.
    11- better audio tools.

    But most importantly UE has"real" game making tools, player starts, gamemodes, level blueprint, behavior trees, saving, localization, pain triggers, pawns, splines, UE certainly has a workflow, and if that workflow doesn't work for you then you'll hate it, but it has a lot of features right out of the box that would cost a lot in unity, and it has a gamelike approach to the design while unity is a lot more DIY.

    But yes, UE has a lot more features than unity (and is more stable) right out of the box.
  • edited December 2017
    1. This is graphics
    2. This is also graphics
    3. This is inappropriate for a game making tool. It's feature bloat. This should be done in a modeling tool
    4. This is unnecessary and an incredibly inefficient way to write logic. Anyone who was halfway serious would just take a few months to learn how to write code (which is much easier in C# than C++)
    5. I use a 3rd party tool for cinematics so can't comment here.
    6. Material instances are admittedly a little tricky in Unity sometimes, but it's not that hard to get used to. and there are so many tools for making shaders on the Asset store there's no need to ever code a shader in Unity.
    7. Ok sure Unity takes a little too long to bake in my opinion as well, but oh well.
    8. Unity has probably a million usable examples right out of the box as long as you include free downloads from the asset store as part of the box (which you should). Unity is miles ahead on this point.
    9. This is also graphics. I use particle effects pretty sparingly and don't have an issue. If you're using lots of particle effects, then your game is in the high graphics category
    10. Unity has good Occlusion/lod tools. I assume you are saying that Unreal's are better somehow?
    11. Unity's audio tools are more than adequate. A game making tool is not an audio editor. Use the right tools for the right job.

    Through the asset store, you can find products that do all that and more far better than Unreal does it. Ok, so it costs a little money. But if you're not willing to pay only like a couple hundred bucks for tools that do exactly what you want them to do to make the game you want to make (rather than what Unreal wants them to do in order to make the kind of game they think you want to make), then you're really not that serious about making games. Part of the beauty of Unity is the mind-bogglingly enormous amount of choice you have through their asset store, from shaders to spline tools, to visual scriptors if you want them (but ew!), to whole systems like Adventure Creator. The possibilities are endless with Unity.

    Also, the cost of Unity is far better. If you are making free games or games that won't make very much money, both are free. However, if you want to actually make a reasonable amount of money, making your game with Unreal will have you paying Unreal a percentage of your profits for the rest of your game's life.

  • edited December 2017
    I agree c++, is a major pain in the ass... People who know and use a lot of programming languages tend to tell you the only pro about using c++ right now is performance (workflow is a mess). So, I do lean a bit towards @Hightreason 's opinion, but I still think both are good to learn and use depending on the project. UE4 is specially good for first person shooters, which is probably its main/original target genre anyway. Though, I don't do shooters much, so I do prefer Unity's DIY approach.... I guess, from a programmers standpoint, Unity's greatest characteristic is that you can make it whatever you want it to be. It's not hard to create you own workflows on top of it (a testament to all the tools in the asset store).

    Anyway, personally, I'd recommend Unity or Godot Engine for someone who is just planning to stay a hobbyist, since they have easier workflows. But, I guess If your objective is just to kill time then any Engine will do...
  • edited May 2018
    With Unity 2018 coming onto the scene I highly doubt there are any downsides visually. As for Blueprints, someone mentioned Nottorus which is not in development anymore. But there is a new asset in active development by Ludiq called Bolt which functions a lot like Blueprints would but in Unity. 
  • edited May 2018
    It looks like Unity is trying to address some of the things I said here, so I wasn't really far off.
    Have you tried their 3D game kit (Unity's) ? It uses the HDpipeline, it looks good (nothing mindblowing), and it runs terrible.
    I don't think unity 2018 will get that close to Unreal's graphics, but they are doing stuff they need that UE already have (light culling is a HDRP only feature...ok, why?).

    I think they kinda dropped the ball a little with the lightweight/HDpipeline, they did it because HD will be compute shader based and both will not work together, reasonable, but why do a separate branch that you will have to mantain when you already have the current pipeline (let's call it legacy, that's what it is) ? 

    When HDpipeline will get out of preview mode, it'll basically support most of the market and also the high end mobile, now you are stuck with two rendering pipelines to support that are not compatible between themselves... Why instead of that don't have one that can turn off settings? Isn't that basically the idea behind the scriptable pipeline ? If the project doesn't target X shader model, then use the legacy system, it makes more sense to me.

    The editor is their biggest problem now I think, the way it serializes things makes the editor crawl if you have a big ammount of assets in your project, Unity works like silk while it doesn't have much stuff, it starts to crawl in a big project or just try to move stuff.

    Hopefully unity is going on the right directions, the only reason I keep with it is mostly AC and the quality of some assets.

    EDIT: I'm using 2018.2b to test a couple of scenes (and see what will break and what not with the hdrp), and I'm fairly impressed with the progressive lightmapper, the baking times have dropped quite significantly and it doesn't turn the editor unusable. Good stuff.
  • edited May 2018
    @shredingskin You have a few unfair opinions...

    Why separate HDRP from LWRP? Because it would become a mess internally (like the old pipeline). I work on VR projects trying to aim for 3 types of Rigs at the same time and that alone becomes a pain in the ass when programming (simulator, rift, Vive, all do some things differently). It's no different when you try to make a system that does everything and WORST, when you have to make a nice intelligent Inspector for the users. Try to remember Unity has a frigging long list of supported platforms compared to most other engines, and they need to cater to all of them.

    You also seem to be forgetting that a whole ton of Unity users aim at mobile or VR mobile where the Lightweight pipeline totally makes sense. Not everyone aims at the high end mobile devices. 

    You are also forgetting that a lot of the more advance development teams tend to modify the Engine very, very often (it doesn't matter if it's Unreal, Unity, CryEngine or whatever). Triple A studios tend to shoot for effects or optimizations that the Engines they use often don't support, so they go out of their way to modify the source code and recompile the editor itself to achieve their goals. The SRP system allows advanced teams to modify the rendering pipeline without having to go through the trouble of modifying the Unity Editor directly.

    The new pipelines also addresses a lot of issues and limitations the older pipeline had. Only the people who knew well about the older artifacts and limitations can really see the difference. And using the 3D gamekit as an example of visuals is a bad idea, since that's stylized artwork. If you want to try to test Unity for realism you'll have to get AAA artwork or photogrammetry models (which are often used in AAA projects). 

    Regarding the 3D game kit. You understand that it's a project that barely got out of alpha like 1 or 2 days ago and the devs involved have accepted it's still poorly optimized? The intent for the project was to give non-programmers some pre-made game play to tinker with and get used to Unity workflows. It also provides a lot of bread and butter gameplay so that new teams making games in the same genre don't have to code everything from scratch.
  • edited May 2018
    By the way, now that I think about it, I remember reading in the Unity forums that the 3D game kit is still using the legacy pipeline, not the HDRP or the LWRP (which have rendering optimizations).
  • The thing I said about the LWRP is that it will be a chore to mantain it alonside the HDRP and the legacy one. The main difference is that is made for devices that don't support shader model 5, something that the legacy pipeline already supports by default, I think that having forking paths (that don't work with each other) is a bad step, and they should focus on the HDRP to be able to downscale instead of having a total different path (specially since SM 5.0 will not be something that far off when it comes out of preview).

    About the 3D kit, I just made it with the HDPL template, and it was using the HDmaterials (and even some custom shaders, that HDRP can't use the legacy ones, so I don't know), just saying it's not good publicity to have a fairly straightforward 3d platformer and run like it does (then doing movies like adam, the blacksmith or book of the dead).

    I think it's nice that they're trying to actually do games and not some cutscenes, that will make the engine stronger in the long run, but there's a long way to go.

    I do think that it's unfair, in the sense that unity is probably the 3rd best 3d free engine, but not that unfair when comparing it with UE.
  • edited May 2018
    (Quote from the 3D game kit's producer Aurore: This project is made to be used in Legacy at the moment, there is a way to get it working with Lightweight but we have not documented it. The next projects we release will be in a Render Pipeline though so it will be covered soon. )

    @shredingskin The whole point of SRP itself is to make modifying a Render pipeline easier using plain C# code (LWRP, HDRP are just examples of this, they're both using SRP's system in the background). The main components of the different SRP won't be hard to modify. It's only a problem for the Shader graph really. That's the only place where they have created an initial pain in the ass for them, I accept that. But people aiming for older hardware with limited power won't miss anything else all that much (and that includes people aiming at a ton of mobile devices and VR headsets right now).

    From a programmer's standpoint it's easier to work when S.O.L.I.D principles are enforced. Specially the Single Responsibility Principle (coincidentally called SRP). You get shorter, cleaner code, and less bugs. Modifying a script that follows the SRP principle doesn't have a risk of creating bugs elsewhere.

    Besides, I don't think focusing solely in HDRP is sensible. Tons of people in the world are still using older PCs or mobile phones and will keep using them even when new technologies arrive because they're cheaper (I tend to be on the poor side often so I can understand this well).
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.