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
That being said, I find C# better than blueprints, and haven't even delved into UE c++.
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!).
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.
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.
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.
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.
@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).