Just going to use this as an example to show how just because another engine has a similar feature, it doesn’t make them on par with each other. Have you tried both Mecanim and Persona? Go look at the tutorials and the lengths of them to get a character up and moving and you will see why I say that Unity is much easier. Mecanim is sooo much easier to use, and yes I use both. But I get so anxious because of the difference in ease of use.
I’ve not found it too bad, but then again I used CryEngine for a couple of years. Pulling your own leg off with tweezers is far simpler.
1 Like
And you know this from experience? 
haha Very interesting analogy that made me laugh. So have you tried Mecanim also? If so, which did you find it easier to use? Thanks.
My vote for favorite engine is: ROM 2.4
teary eyed The graphics were insane.
Of course I have, used Unity for a long while too. Well there is some advantages to animation as a whole, I like how you can just block out animations and Unity separates them for you. The T-pose and joint setup system is cool, making blend trees were quite simple. On the flip side when I used Mecanim initially were a lot of strange bugs so I dropped it in favour of the legacy system until Mecanim had reached more maturity.
1 Like
I think this is because you already put a lot of time into learning Mecanim. I ran through the Persona tutorials and I didn’t see anything there that was uber complex, just lots of little details that had rational defaults but the ability to tweak later on when you need that level of control.
If you had no experience with either Unity or UE4 and were a brand new CS grad who had taken some C++ in college it’s going to be a no-brainer. If you’ve used Unity for years as many of us have it’s a hard decision because now it’s not just feature comparisons but the cost of learning a new complex tool which is what annoys me. That being said I’ve been working my way through it since day one and I feel like the investment is going to be worth it longterm even if I am burning months now. (edit: also while blueprint is a great feature, I don’t find it particularly useful to me and I think it gets too much hype)
1 Like
What are you impressions of Blueprint? So far it feels to me, both from my own experience and reading up on what others have done, that it can be used the majority of the time. Dropping to C++ seems to only really be necessary when speed or extra functionality is needed.
I wouldn’t want to create complex subsystems in Blueprint. So depends on the complexity of your game. I have seen ridiculously complex blueprints, where I think the same thing in C++ would be much simpler and much better manageable and understandable. I would use Blueprints for simple systems and to glue everything together.
But that people create these huge Blueprints shows that it would work in theory, but how smart that is? I understand that if you miss the C++ or programming skills, but it asks for trouble above a certain complexity level.
2 Likes
BP makes perfect sense if you think about it being used so designers and programmers have a common interface to communicate with. Ie. programmers go make this complex system then expose some simple hooks via BP for designers to play with in the scene. As a single developer I’ve found no real use for it so far aside from tweaking constructor variables in the scene, which is roughly equivalent to the property inspector in Unity.
Blueprint macros can help a bit on this front. Making good use of them is essentially no different from dividing your C++ code into multiple functions.
Essentially the same for me.
About the same as using any scripting language. Blueprint is merely a scripting language that exists in visual form rather than text.
Well, except that it is visual, which is rather a huge difference. It makes sense for modelling a relatively simple domain specific language (a la ShaderForge, the UE4 material editor, World Machine…) - as long as the problem you’re solving in that language is limited. But even in the case of something like World Machine, just a slight move beyond simple graphs (and that includes making use of WM’s macros) makes everything a rather huge, unmaintainable mess. This in spite of WM not even being close to attempting any real flow constructs - it’s a DSL, not a full-fledged scripting language. Unlike Blueprint.
No need to even try it out (which I have) in UE to have that point come across. Just look at the UE4 tools demonstration video and listen to the presenter himself basically admitting how “fairly expansive” just a simple AI script for a butterfly becomes in Blueprint. In code, you could display the entire script with a generous amount of whitespace and indentation on… hmm… around half a screen - and read through and understand it all (I’ve actually tested that on a few people who have a couple of weeks of superficial programming experience) in less than a minute or two…
Blueprint is really nicely designed in terms of visuals - but it’s still a fairly bad idea for anything slightly more complex than “if distance between character and door is less than 4 feet, open door”.
Well I wouldn’t go that far, I’ve used it for all the GUI stuff and it was simple. All the character controller stuff, also very simple I’m coding the AI but apart from that I’ve found Blueprints very simple and handy.
I still use Blitz3D to knock out little projects and especially for prototypes.
I can take the same project and knock it out in Blitz at least 3 times faster than I can with Unity.
The Unity architecture, although very flexible and powerful, makes many things more difficult.
Just simple things like changing a font and presenting text. In things like Allegro and Blitz this is simple and easy.
In Unity we get GUIStyles and GUISkins. I get that it makes for a more flexible and powerful system overall but at the same time it just adds yet another thing, another layer, that has to be done before you can actually accomplish anything. It just all seems a bit over-engineered to me.
That all being said I am still working with it. I think once I get some decent wrappers around all of this stuff it will become an easy to use game development platform.
1 Like
I actually wound up writing some wrappers that I wind up copying into all of my projects (The Asvarduil GUI System.) It really helps me build GUIs much more quickly (usually about 2 hours per GUI, and most of that is dominated by creating the artwork.)
1 Like
Good thing guistyle and guiskin is a thing of the past, right?
Well, that is just an example of what I see as “bloat” and over-engineering.
Basically, I just want to be able to get in there, use the minimum functionality necessary, and get things done.
So, for example, I made a little prototype platform game in Blitz a couple weeks ago. I am converting that to Unity. To display the relevant scoring information I decided to just do the kind of thing I have done in the past… old school style.
Launch Paint Shop Pro. Draw the font characters. Import into unity and just use sprites to display that stuff on top of the game playfield. The kind of thing we did with bitmapped fonts many moons ago.
In before the lock? Technology is like religion, and someone is going to want to die on them there swords.
Gigi
@visual scripting and blueprint: Personally, as a developer, visual scripting is harder for me than scripting in C#. It’s a completely different experience than linecoding. It might be easier to learn if you’re starting with nothing, but nothing is easier to learn than what you already know how to do. So for me, Unity is still the right choice, at least until I hit the limitations of the Free version (which I don’t expect to happen anytime soon, personally)
, you’re a funny guy.
1 Like