A dumb question ....

hello guys,
As a newbie beginner /architecture student with 0 exp in coding. I got a chance this semester doing a project in unity. So this engine got my interest. After a lot of research here are my questions.
Ps. I don’t mean to say which one is better. I am just curiously asking these questions as I can not answer myself even with all of those research I did.

1. Comparing to UE4 why is Unity considered to be more beginner friendly? UE4 has a lot of built in artist friendly features like visual scripting, node based shader editor, particle system, 2d tile map editor etc. It seems like UE4 has a complete artist friendly system many years ago already while unity just rencently released shader graph, 2d editor (last year) and still doesn’t have official visual scripting. But why it’s still considered as more artist(coding newbies) friendly than UE4?

2. Why does it take so long for Unity to develope such user friendly system as shader graph, visual scripting etc... Aren’t these supposed to be fundamental features?

3. I am also planning to buy super tile map editor, Octave 3D. Do you think it’s still necessary ,considering unity has its own new 2d tilemap system and progrid and poly brush plugin?

 

As a new user, UE4 is probably a smidgen better than Unity but Unity has a far greater wealth of beginner resources than UE4 by a long shot. Even Unity's own Learn Section offers a great starting point. That said, I think it'd be prudent to download both and give them a week long test drive or so to figure out which one works best for you as both Unity and UE4 are pretty complex bits of kit.

Sort of yes, sort of no. When UE4 came out, it came out swinging, building on the foundation that UDK/UE3 had before it. The fact that it took so long for Unity to get a visual shader editor is personally a little mind boggling, because writing shaders by hand kinda sucks but UE4 was also the first engine of its scope to lean so hard into visual scripting, so I think that caught a lot of people off guard.

I'll leave this for other people to answer since I don't really use Unity's 2D tools.

 

Thank you for you reply! so the biggest reason for unity being more artist friendly is its compele beginner friendly community and tutorial session and superb asset store I guess? Is there any other reasons (like engine itself)?

 

One reason has already been touched on my @Murgilod, but there is another reason that you likely glossed over because you didn't realize that it would become an issue and that's having to work with C++. I know, Epic Games has node-based solutions for scripting, shaders, particle systems, etc, but you can only go so far with Blueprint.

Once you reach the point, and you will reach that point eventually regardless of how hard you try to stick with their visual systems, Blueprint is no longer sufficient for your needs you will have to work with C++ and while they've augmented it with a lot of support macros, the reality is it's still way harder than C# for non-programmers.

It's very possible that they've become fundamental features but it's only a relatively recent thing. When Unity first became available these were not fundamental features by any stretch of the imagination. At best these were features that you found in engines that were designed to hold your hand or were custom designed for in-house use.

Since they've taken off Unity has wanted to implement their own solutions, but there were simply far more pressing issues that needed to be solved. For starters, Unity's scripting framework (C# and Mono/.NET) was way out of date, the graphics needed serious overhauls, and so on. Visual node-based systems are way less important (because they're built on these).

 

Since UE4 and Unity solve the same problems in quite different ways, the choice of engine boils down to whichever one you make progress best in.

 

Thank u for u detailed reply!
So does the same thing apply to playmaker? What u mean is that playmaker, blueprint and all those node based editor have limits where those tools are no longer sufficient and eventually we have to work with the code. In that case, C# is way easier for non-professional programmer to pick up comparing to C++. Am I right?

Wow, then C# really makes unity popular then I guess.

 

Yes, it applies to every visual scripting language and is why the most popular of them have a way to create your own nodes when you inevitably run into a situation where you need a node that doesn't already come with the language. A handful of third party assets come with custom nodes for the asset but most of them don't.

 

I would argue also, The UI/UX of Unity was far more intuitive to me rather than UE4.

 

If you want to be a game developer generalist, and you're a beginner, I think Unity is far and away the best choice. The Learn section and millions of answered questions on the forums and Unity Answers puts UE to shame. I have never had an easier time learning a piece of software, by a large margin, than with Unity.

However I hear that artists have a fairly easy time just setting up scenes that look great in UE4, so I think if that's all you want to do then UE4 is probably the way to go. I can't vouch for the real utility of blueprints - they are not incredibly pleasant for my programmer brain to deal with, in my limited experience with them, but your mileage may vary.

In the long run, you should try both, and only your experience will tell you which to choose. The jury is still out as far as I'm concerned, and they may never be back.

 

Thank u all! So I can conclude that unity is more user friendly mainly because of simplicity / usability of C# coding language and a compelete active helpful forum assets store and community?
Well it’s just because sometimes it doesn’t make sense for me that UE4 has so many node based system and unity has just recnectly developed them. Hahahaha

 

When it comes to programming, the question is how useful blueprints have been in finishing and shipping games? I can see why they'd be fun to use as a beginner, but are they an alternative to programming? I think the answer is clearly no. They don't offer anywhere near the same level of control, they become difficult to manage when things get complex, and you depend on someone having created all the blueprints you need, someone who knows C++.

So Unity maybe skipped this one. I think they would have benefited from the Asset Store possibilities of blueprints, but maybe they had a better idea planned for the year 2050.

If you're creating a game of any complexity, and you want to be able to craft it the way you want to, I think the artistic side depends on the graphics tools, which UE4 has always been strong with, and the programming side depends on how easy it is to work with the language and API, as well as the documentation, which I think Unity wins in. So UE4 having blueprints, in my opinion, didn't really help them improve the programming side, since in most cases they only provide enough out of the box control for prototyping, and sooner or later you have to face the language itself. As for their graphics tools and workflow though, I think they put Unity to shame.

 

Try it out for a week.

 

This comes up in every thread and honest to god I have played multiple quality release games that were actually well polished that were made entirely in blueprints.

 

Fair enough, that's why I posed it as a question. But I would ask:

• Where did the blueprints come from?

• What happened when the dev wanted to add something that wasn't in the blueprint?

• How complex, at the design level, were the mechanics (I've seen a couple of very cool games made with blueprints, that came off as complex due to the artistic handiwork and amount of juice and visual/audio feedback, but really the games were not complicated in design). Not all games need to be complicated, of course, but some are.

I like the idea of blueprints, and I'm ready to be convinced, but I can't see a way to make it possible to create anything you want with them unless you happen to get exactly what you're looking for.

And I think it's a possibility that needs to be considered that although blueprints enabled these games to be made (which is important in itself of course) the process of creating the game was nonetheless quite inefficient.

 

I have programmed a lot in C, C++, and C# over the years. C# is the easiest. It does not bother the programmer with pointers, and the C# syntax is often more clear. C# is my favorite language. It is fantastic.

 

Yes thanks! now I got it. Seems like C# did make unity a sucess!

 

I would say that, and the simplicity of its interface, make it decidedly the more approachable of the two.

 

You seem to have conflated beginner friendly and artist friendly. Decent artists are anything but beginners. Getting your head around all of the features that Unreal throws at artists is anything but beginner friendly.

Unity's main advantage is that if offers a completely blank slate. The engine was built with no particular game structure in mind, and can be relatively easily manipulated to produce any structure.

The correct answer to why Unity is dominant today is pricing. Unity was the first engine to offer an indie tier. It was the first to offer free a free tier. And it still offers prices better then Unreal at every level.

The pricing means that every hobbyist, amateur and student for the past decade has gone to Unity as their first point of call. Then when these people moved into professional development, they brought their engine preference with them.

 

I've never really understood why UE4 is seen as making it significantly harder to produce certain types of games due to being geared toward FPS. Maybe there are some things that came from that, but are they really obstacles?

Really what turns me on with Unity is that the editor is so intuitive and straightforward, and dead simple (as well as the ability to customize it). The UE4 editor compared to Unity is like taking a game like Journey and adding scifi greebles, neon lights and ACES tonemapping with a contrast of 5.

 

I've only ever briefly played with Unreal. Spent a few weeks experimenting with it. During those weeks it certainly felt like it was pushing me into an FPS. Every default was geared towards an FPS. Things had to be turned off to to get it to a blank slate for other games.

Now if I had a few years experience with the engine, I have no doubt I could make games it it about as fast as I do in Unity. But getting those few years experience is rough.

 

It wasn't the first engine to offer an indie tier, but it was definitely the first engine with this feature set. I barely remember the engines I checked out prior to Unity and Unreal but I definitely remember Irrlicht which was open source. It had an attempt at an editor but it was more like a framework than what we call a game engine now.

https://en.wikipedia.org/wiki/Irrlicht_Engine

 

I haven't spent more than a few days altogether in it either, but I never found anything that railroaded me into something that didn't make sense for pretty much any kind of game. I haven't tried to do anything too crazy though, like make a pixel 2D game or something like that.

Anyway, I definitely agree with the idea that Unity presents itself as being much more of a blank slate, which I like.

 

The hardest roadblock for me about trying Learn Unreal back in the day, and periodically testing it out between projects is Unreal workflow is done through the vantage point of being inside the diorama, and flying around (Maya), and Unity is from the vantage point of outside the diorama looking at a legend.(Photoshop/Dreamweaver)

You have to have good viewport mechanics to make the best of Unreal, while you have to have good organizational structure foresight to make the best of Unity.

I fire it up, and get frustrated that the core way of workflow in Unreal is by flying around and clicking on things. You'll see if you watch any tutorials, the tutorial givers generally spend a lot of time when they are idle explaining something they are flying around in the viewport subconsciously at random.

It's because they've become accustomed to this workflow of visually flying to their objects, instead of click through an organized Hierarchy, and hitting F.

Because of this Unreals Viewport is naturally more developed than Unity's and can feel more intuitive for 3D artists who have taken the time to get used to that environment, and Unity can feel underdeveloped.
And since you are in Architecture. Unreal's more advanced 3d viewport workflow may actually be more intuitive for you.

Unity's workflow generally makes sense for most people who aren't from a 3d modeling background, and is often considered more newbie friendly because of this, and is drastically more intuitive for 2D games, because of how 2D layering works, having a very advanced Viewport doesn't really help Unreal much, since you want to always view things from a specific angle.

-

another thing that is very newbie friendly is Unity's UI tools.
It's very easy to just start making actions, and reactions, and testing them with a gui button when you first get started, and slowly building from there, and can feel rewarding almost instantly.
20 minutes in a Unity UI tutorial, and you'll already start having ideas of what kinds of things you could start doing.

-

Visual scripting is absolutely marvelous for learning, and can indeed be used in production, and offers a chance for everyone on the team to be able to work on something.
But if you are working in a small team, even remotely value your time, you will eventually crave the sheer speed, and control of manually coding things.

Creating complex systems that would take weeks in Blueprints or Playmaker can be done in a day, and once you figure out how, the sheer sluggishness of going back to visual scripting can be really hard.

-

Assets on the store will usually beat Unity's tools, because they are focused on a specific thing.
So Buying the assets will definitely jumpstart you, and get you motivated in the short term, I actually do recommend getting assets if you can afford them. If they are good, it's basically like having an extra team-member.
But the downsides are locking yourself into a workflow of that asset. Compatibility issues, and other random things.
So don't be unhappy if you have to eventually overhaul, or completely remove the asset.

 

Well, I would guess that the developers mostly make them themselves. That said, they also have a store much like the Unity one... though last time I checked it wasn't nearly as well populated.

They would make it. I think Blueprint gives you the ability to do that for just about anything in-engine. Just because it's visual doesn't make it limited in this regard.

I've only a little experience with Blueprint coding myself, mostly helping other people do stuff, but it seems like a complete programming language in its own right. You get all of the basic building blocks, including the ability to make your own functions / classes / nodes. So if it doesn't come with a node that does what you want you can make one. I don't know if it gives you access to stuff like system functions (eg: reading/writing files), and I would guess that you'd need to write some kind of plugin wrapper if you wanted to integrate 3rd party libraries.

A potentially confusing thing about Blueprint is that the same name is used for two things in Unreal. One of those things is basically what Unity calls "prefabs" - you can make an object and save it as a template to be re-used later, and that template is called a "blueprint". The other thing also called "Blueprint" is their node-based scripting language which, from what I could tell with a few brief sessions, is in fact a fully fledged scripting language.

Check out Dead Static Drive, and the developer's talks. I'm fairly certain he said all of the code is made in blueprints at the talk I saw.

I don't know how mechanically complex the game is. To me the more important stuff is how the developer is able to make a bunch of their own tools and systems in there, which has drastically increased the scope of the game they could have made if they did it from scratch. They could have done the same stuff in many other tools, so it's not as if it's magic or anything, but it is a good example of what can be done with that particular set of tools.

My main dislike about the system isn't what it is or isn't capable of doing, it's entirely that I can type waaaay faster than I can drag little blocks around and wire them up to each other.

I can imagine it having great utility from a level design or sequencing perspective. That kind of code is a) fiddly to write, b) messy and c) hard to visualise as a flow from the text alone (especially for non-coders). Being able to visually wire stuff up like "when this door opens spawn some enemies and then play this animation" or "when this trigger is entered check if the player has all of the keys and, if they do, open the door" is probably great.

Making complex systems or tools in there really isn't my idea of a good day, but that's no reflection on the system with regards to its design goals.

 

I have no doubt that any game can be made with blueprints. After all, blueprints is just code in a different format. The question is whether someone can make their game without writing code at all, either getting their blueprints from what Unreal provides out of the box, or off the marketplace, but without having to be a coder themselves. It seems like sooner or later, you or someone on your team has to face the code. And that's why Unity's C# trumps Unreal's C++ for beginners.

I might be wrong. Maybe, as you suggested might be the case, it's possible to do everything from the most primitive blueprints. But I wonder if that's really feasible for a mildly complex game, from the perspective of handling complexity, cleanly separating functionality, designing the architecture of various systems, and debugging. I have the notion that at the point where a dev can do that in blueprints, they are only a half-step from being able to code normally anyway, and that many of the difficulties with coding are not simply a question of text vs nodes in the way that it's often expressed.

Anyway, this is the point where my experience with blueprints is lacking, so maybe someone else can give a better idea of what it's like.

 

I linked a game which claims to be doing exactly this.

This notion is 100% correct.

Blueprints are coding. It's just another language, one which happens to be written with nodes and pins rather than words. Yes, if you understand how to do things in Blueprint then "coding normally" is only a matter of typing it rather than drag-and-dropping it.

As far as I'm concerned, anyone who claims that node-based systems let you do things "without coding" doesn't know what they're talking about.

 

Well then, if one knows how to code, C# should be a lot easier than creating everything from primitive blueprints.

My point is that since there is no way to avoid coding, C# is the most elegant of the lot, which makes Unity attractive.

 

My experience with Blueprint was really frustrating. It took me quite some time to do things which, in a text-based language, would have been a few seconds of typing. The idea of, say, implementing a sorting algorithm or a game AI in it makes me groan on the inside.

So, basically, personally I entirely agree with you. Text all the way for anything non-trivial. To put that into context, though, I've ~20 years of experience of typing code and only a few hours of experience in Blueprint. Maybe 20 years from now visual programming will be a far more normal thing, and experienced programmers will look like high-APM Starcraft players? I personally can't see how visual programming could become as efficient as text-based programming, but my perspective is biased and visual programming is pretty new. Text-based programming has had years of active research, advancement and tools development. Of course it's better... at the moment. In the future, who knows?

Visual systems do definitely have their up sides. Inability to make a syntax error is one. ("Why is there a red line here?" "Ah, you need an 'f' after that number.") Built-in visual prompts is another. ("Green pin to green pin" is far easier for a non-programmer to understand than "the second parameter has to be an int, so you have to use the name of a variable that is also an int".) They just cooperate better with how some peoples' brains work, which is a perfectly reasonable thing to take into account, especially for team members such as artists who just want to make some animations play or level designers who want to do stuff like hook up switches and doors or puzzles or spawn triggers and such.

Also, for anything that's a sequence with some simple timing and/or branching, visual languages can be great as you're basically able to flowcart out some high-level actions. I've written purpose-specific visual tools for this before. Blueprint means more members of the team can use a common tool for that kind of stuff, which is neat.

 

That's quite possible, although I haven't seen enough examples to convince me that it's the case. Language is a highly developed part of the human brain, and one might argue that it has the specific purpose of making it easier to play with and communicate complex conceptual systems in a way that maximally reduces unnecessary detail and maximizes efficiency.

But that's neither here nor there, since I think people will have to find out for themselves what works and what doesn't.

 

This.

I dabbled with Unity briefly but basically learned 3d modeling first before getting further into both Unreal and Unity. For me, an artist, working in Unity is a chore. It's not fast or intuitive. But, for the reasons mentioned (and some others), working in Unreal is a breeze. Very fast and intuitive. Everything is geared towards being in the game and moving around there.

To me, that is a better designed engine for making a game focused on visual immersion. You need to be in the game as early and often as possible. JMO, and that's all it is just an opinion, because obviously some really visually immersive and beautiful games have been made with Unity.

I think for the hobbyist developer, the most important question is which programming language will offer me the flexibility I need the fastest?

 

C# is easier to learn than C++. There are more and better tutorials available for virtually any feature of Unity, both official and 3rd party. There is a larger community available to offer free support.

Shader generation and visual scripting solutions have been available on the Unity Asset Store for years. Fundamentally though, Unity is a professional level development tool, not a toy for playing around with game development. Visual scripting is of dubious necessity, and you'll always get better performance writing your own shader code.

 

Visual scripting will be available in the next alpha release after 2019.1 which is out now.

 

Thanks to this discussion I'll make a necessary adjustment and start talking about formatting and visualization of logic rather than code, as it it's confusing and always oppose text format to node format instead of the core issue which is really interfacing with the logic. There is nothing inherently in text that make code run faster.

 

Other than the language and toolchain are designed for performance. I'm not aware of a single visual scripting solution that isn't implemented as one node equals one function. A coder would almost never write an application where one step of a program equals one function.

I haven't looked into the code generated by Blueprint when you ask it to spit out C++, but the fact that the performance still doesn't come close to C++ written by hand makes it a fair bet that it still continues to have one step as one function.

 

But that's an implementation detail. There is no reason it has to be implemented that way. @neoshaman didn't say that visual tools are built for speed, they just said that the performance difference isn't an inherent property of text vs. nodes.

 

Right. I'm not saying it can't be done. I'm just saying no one seems to care enough about performance to do it. I believe it's because the people who write these tools feel that those using them will never be tasked with writing high performance code. I can't wait to see Unity's implementation and if they decide to break this mold.

 

root cause of the problem

I meant not inherent to any "format" beyond node and text dichotomy.

But yeah it's a problem of the entire tools ecology rather that the "format".

Also there is a difference between command flow oriented visual language and data flow oriented node visual language

 

I suspect that this is because when someone makes a visual system the problems being solved aren't performance issues.

A game designer who wants a door to open when the player has a key and presses a switch doesn't care about performance. Ease of use and a clear flow are far more important to them. That's not a failing of the tools, or of anything. Execution performance just isn't always the goal.

And to be honest, optimising use cases like that would be a complete waste of time. And the cases where performance really are needed are generally already covered well by other tools, which happen to be text based.

 

Anyway there is also the case that visual node is basically a replacement for scripting language like lua, and scripting language too had "performance" problem. So this is a case of text having that same problem than visual.