Never Again Unity.

News & General Discussion
1

Coming back with flooding tears, begging to be accepted back within the ranks of Unity Community, is how I finish my story.

A story about a curious young lad, poet at heart, and a programmer with a swag, leaving Unity behind in search of more powerful, more perfect, more complete game engine. Treading the valleys of uncertainty, I thought I saw the crown jewel. A game engine (which I wont reveal its name) rumored to be as powerful as a German washing machine, and as versatile as a Japanese bathroom, producing games on a whole different level. I thought I have finally found the one truly perfect engine, that only the best of the best have achieved.

This is a story of how wrong I was.

Not long after compiling the first line of code did I receive 23 errors. And my “Perfected” engine crashed. Leaving behind a peculiar taste of what was to come. Engine crashing, Code unreasonably disgusting, Editor unintuitive, Documentation misleading. My perception crippled, as with each task more doubt has flooded my mind. “What is this shit?” was uttered at every corner, and button press.

And then I have Understood.

That whats more important then efficient code, seamless graphics, and great renown. Is the fact the you are working on an engine that was crafted for you. A place where you can advance and learn. Feel safe, and surrounded by commoners like yourself.

I plead before you,
Unity Community,
Never Again,
Shall I Doubt,

Never Again,
Shall I waver.

And Remain With Your,
Forever

12 Likes
2

Awwwww!

Now get to work.

4 Likes
3

Now you know what dangers lurk out there, awaiting the naive travelers who think “pffft… I got thiz”.

Making games is not a game.

1 Like
4

If you program with C# in Unreal your game crash, try again with C++.

2 Likes
5

The marginal performance gains of my crappy C & SDL game is insignificant to the speed at which I can produce very efficient content in Unity. If you write code yourself, you narrow the performance gap even more!

GameObject.Find(“”); BAD
GameObject.FindObjectWithTag(“”); better… but still BAD

referencing a variable in your “things I know I’m going to need to refer to” array… GOOD

6

Booooooo

7

Haven’t noticed any problems with using these liberally. I had to start using these for gui 4.6 interactions in a program I was writing, and I realized they work for everything. So, I decided to ditch this “they are BAD!!!” stuff and have begun throwing these calls in loops and everything.

I’ll find out first hand where the limit is where it affects performance.

8

Let the rest of us know where they are. This authoritative rhetoric is straining my critical thinking skills.

1 Like
9

Welcome back to Unity XD Most of us are quite nice here, and the buglist isn’t too bad at all

10

The community gods welcome you back with open arms.

17 Likes
11

I almost only ever use these in one block per class, to populate local copies of references, and then basically never again.

2 Likes
12

And so it begins, the reverse exodus. The grass was greener on the other side of the fence, but it was radioactive green!

6 Likes
13

You’re talking about Unreal engine, right?
i’d like to honestly hear criticisms of it.

ive found misleading documentation in unity many times, that’s hardly an isolated thing

14

Although that said, i’m ASSUMING that UT are smart guys, and they compile all instances of each tag into an array for each, so unless you heavily use one tag, it’s probably only got a tiny dataset to search and should be very fast

15

Pretty sure it’s still a string compare, so it’s good to use a dictionary in cases like this which use script, object - where object is transform, gameobject or collider etc, and the script holds references to everything else, if you don’t know what you’ll encounter in future at game time.

Find with tag, or find in general will always be a terrible thing. Good for Start() or editor setup.

16

we could do with a non string version. Each tag already has a place in an array, finding them by their tag array value seems like an easy enough thing for UT to implement.

yes finding things is slow, but it can still be faster than it is

17

Wouldn’t it be better for each enemy to, on Start, add themselves to a list / array in a gamedata singleton? Everyone knows where the singleton is :smile:

I like string compares. it’s like…

“a” compared to “b”
97 compared to 98
1100001 & 1100010 == 1100010

It may be false, but the hamming distance is only 2 :smile:

18

I’ve used UDK and bought UE4, and I can say that Unity is easier for the fact that importing assets. UDK/UE4 is more difficult, as you can’t use just any 3d mesh. It has to be in a specific format!!

Unity’s major weakness is that it’s script intensive. What UDK/UE4 does well is making tools that anyone other than a programmer can create a game. To my knowledge, there was a game created in UDK completely in kismet(I can’t remember it though). Kismet/Blueprint are the built in equivalent to PlayMaker, but better. Since they are built in-engine, they have modules that are specifically detailed to UDK/UE4. PlayMaker is very general at times.

UDK/UE4 has great graphics, but Unity can have somewhat similar look. However, UE3 games ALWAYS looked similar graphically, while Unity games don’t look similar at all. Most times, I cannot tell.

UDK/UE4 controller support is EPIC. :expressionless: Unity could learn a thing or two.

19

If i could bring one thing to a deserted island it would be Unity! :smile:

1 Like
20

You have to be careful, some compares in unity actually allocate a new string.