A different perspective on Unity development.!

Someone posted this on another thread, found it quite an interesting read from an upper tier well know developer who works for many large outfits. I always thought Unity was better suited to 1-2 man teams anyway, so meh.! You might find it interesting though..

https://www.quora.com/Why-dont-big-...or-their-game-development/answer/Mark-Maratea

 

I agree. I find for every time saving thing Unity has, it is quickly lost under a pile of sketchy stability and questionable issues I feel could have been avoided, probably years ago. So I'm in complete agreement.

It does state it's cool for small / tiny games, and I agree with it. I'm currently trying to do a medium sized game and Unity is in a slow state of collapse, hoping things will turn around though.

 

I'm kind of surprised his reimport only takes 90 minutes.

I really need to pick up an ssd drive at minimum.

 

I had similar issues in both unity and UE4 at this point. Unreal nukes UDataAssets silently. Unity occasionally does the same. No matter what you pick, there will be some trouble somewhere.

This dude's offhand statement about double precision is very strange, though.

However, another statement in that thread is worth attention:

It is very close to the truth.

I've recently found out that I can make unity api behave in the way I like by slowly introducing replacements and improvements for portions of the framework via extension methods. That seems to be working well.

So, apparently the "close to the truth" way of working with the engine might be starting with prototype and then slowly replacing most of the functionality you had in prototype with your own, reducing the engine to scenegraph renderer/physics framework. I'm not entirely sure, though.

 

I had the impression that many large teams (certainly more than 2 to 3 people) are using Unity? Like @zombiegorilla's team for example and I seem to recall seeing mention of other 12 to 20 man teams some place.

Of course, it could be they actually are mainly using it as just an API to render graphics and play music and sounds. I seem to recall @zombiegorilla saying something along the lines of they built their own framework and don't actually use Unity in the traditional way. So maybe that is how they get around these kind of issues.

Actually does make sense to me because I basically just Unity to draw graphics and play music & sounds. Certainly don't use the physics system, collision events and all of that other Unity-specific stuff. That always caused me more grief than anything else. And you guys are working on projects way more complex than the stuff I am doing so I would think it has to be a necessity to sort of "roll your own" framework on top of Unity in that case, right?

At any rate 20% of their time per week is crazy. So they basically lose one full day per 5-day standard work week just on what they call "Unity issues".

 

Yeah that sounds quite accurate - 20%, it's not a dramatic figure. Unity saves around that time too, so it breaks even and the benefit of choosing Unity as a time saving thing is entirely lost in my view. It's great for prototyping or if you know your game falls inside the Unity feature set, it can be a good choice. But every game has problems so my feedback bears that in mind, I know clearly what is my problem and what is a problem I'm working around

My problem is I want things and Unity isn't there yet. I mean I needed instancing a long time ago. But 5.4 solves that. I need many other things fixed and I know it's eventually coming. But I can't plan for eventual things.

 

There were issues with hot reloading UDataAsset's that got fixed a while back (mid 2015), not sure if you're still having issues? I've not had any. But anyway I'm not exactly sure it was an offhand statement, it's not unheard of for games to use double precision physics, I could be wrong but didn't Star Citizen go down this path?

Also it sounds a bit of an odd way to work, you'd be better off with something like Xenko (or something like it) in which you can change whatever you want whenever.. That includes bare bone basics too..!

Although yes, when I used Unity I did pretty much only use the real barebones stuff then added my own..

@GarBenjamin

Hearthstone from what I've seen of it, looks like a well thought out great game made by a talented bunch of people. But in terms of actual complexity it ain't exactly Eve Online is it? It's a 2D card game that could of honestly been made in anything (sorry Zombie, don't hit me ARRRHH!))..

 

At first I thought he might be a certain someone who hangs around on the Unity forum but the name wasn't the same. Jokes aside though it's another aspect that you would have to work around and if I'm not mistaken the solution won't always be the same across all your projects.

Time spent working around limitations that the engine could have handled for you is time that could have been better spent.

 

Recently the forum kind of gives me the impression the overall mood is a bit down. I'm trying to remember if I've ever seen anyone here say "Man, I love working with Unity" or anything positive along those lines. I'm having no trouble remembering there being hundreds of posts complaining about this and that. Is the unreal forum any different? Or is everyone there also complaining about issues with their engine?

 

That's not a large team. By a lot of people's standards, it's not even a medium size team.


I do wonder how many of these project management issues are architectural issues specific to Unity, or if it's a case of not wanting to/knowing to plan out an explicit project management schema. If it's a large enough studio that could make it's own engine and would have to plan out workflows anyway, you would think they could devised systems that circumvent the worst of it (using separate dlls, scene checkout systems that only grab the assets in the scene).

 

Unreal has a dedicated feedback section. Unity has them too but everyone seems to use General Discussion instead.

 

@Martin_H For simple games, I still think Unity is pretty sweet and a class leader.

@RockoDyne, that requires time and money.. Why bother when solutions that fits their needs already cirumvent major issues?

@Ryiah Unity's feedback section might as well say error 404.

 

Ah. I've only recently paid attention to it because my launcher was crashing attempting to download 4.12.

 

Works like this. You make C++ UDataAsset derived class. You save it via project inspector (or whatever it is called). You add one field to it, rebuild and restart the editor.
And boom - upon restart you see "import failed", asset is gone and so are all references to it. Very easy to reproduce, I think I even reported it.

I honestly don't care if it is odd or not (no offense intended). The purpose of engine/tool/language is to complement my abilities, so whatever works for me is right, and whatever doesn't work for me is wrong.

I think working via extension methods might be a good approach, because essentially it is similar to idea where data must be decoupled from the methods. I think it is sorta similar to ideas that were present in lisp and to what I *heard* of smalltalk. Maya SDK had sorta similar approach in 2007 where they decoupled data from interfaces that process it, and used different prefixes. It worked, sorta made sense, but the process wasn't organic (Because you had to do that as some sort of "FSomeFunctionInterface.SomeMethod(someData)". Extension method wraps that into intuitive syntax, plus you can toggle them on/off via namespaces.

The funny thing is that extension methods and yield statement are one of the two features in C# I found interesting. Those aren't present in C++, although there were proposition for both yield and extension methods to be included into C++ at some point. There was a test implementation for yield in C++, and bjarne stroustroup himself proposed idea of syntax equivalence (where x.someMethod(y) may equal to someMethod(x, y), if X::someMethod(y) does not exist and vice versa).... and that sorta fixes that ancient problem where you had opportunity to declare two versions of equality comparison operators....

Spoiler

Yield:

Extension methods:
http://mariusbancila.ro/blog/2014/10/15/extension-methods-in-cpp/
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf

I also found interesting statement about C# extension methods on some blog.... basically a dude wrote something along the lines of "after writing the code using extension methods, I got a very clean and human readable code.... but it wasn't a true OOP, so I scrapped all of it ann decided to never use extension methods ever again"... which sounded very ridiculous to me, because guy valued using OOP approach more than maintaining code readability.

Anyway, I just found that topic interesting.

 

Wasn't there a "I love unity" thread just a while ago?

Basically, engine have flaws and people that hit those flaws complain about them in their spare time.

Spoiler

I found another gem a while ago:

http://forum.unity3d.com/threads/po...atedepthtexture-why-is-it-even-needed.197455/
Started in 2013, last post in 2016 arguably not fixed.

 

The article doesn't have very much meat too it. Basically it comes down to loosing data on prefabs in version control, and preferring doubles over floats.

I've had similar issues with loosing data on prefabs in a team version control environment. At the time we had an artist producing assets and dropping them directly into the assets folder, without opening Unity. Each person who downloaded the commit would then create their own meta data file for the asset, with its own GUID. This could then cascade into a bunch of issues if each person referenced the object in the inspector, and then tried to merge conflicts.

The doubles versus floats issue is probably moot. Unless you are working on an open world game, then it doesn't matter that much. And if you are building an open world game, then you have a ton of other things to worry about with Unity's general suitability anyway.

20% of the time dealing with Unity issues seems high to me. But I'd guess to roll your own engine you would be spending at least the same number of man hours on the engine, if not more.

I love working with Unity.

What you are picking up might be the result of the licensing change. Price increases tend to bring a lot of people out of the wood work to complain about the engine price or features, and then leave again. The mood should pick up once this settles down.

 

For the Unity Forum's standards that's bigger than f'n jupiter man.

Honestly, I like working with Unity. Except for the EventSystem and StandAloneInputModule which is total friggin trash! TRASH! Overall, Unity is easy as hell to work with.

I am kind of unhappy with the pricing changes though, and the competition from other engines in terms of ease of use is definitely catching up. But I would definitely recommend Unity to anyone who needed a recommendation.

 

True. I meant in contrast to the article talking about Unity only being good for 2 to 3 people. Not to mention compared to just myself or any of the rest of us sole developers around here even twelve people is a large team. If I had 11 others working on a project... wow I could just relax drink a beer or two and projects would be completed!

 

Doesn't seem to be working for Hello Games. How many times have they delayed No Man's Sky again?

 

Ah, I had to touch this one recently. It is... very weird, frankly.

Code (csharp):

1.  
2. ExecuteEvents.ExecuteHierarchy(currentHandler, currentEventData, ExecuteEvents.pointerClickHandler);
3.  

^^^ I mean, come on...

 

Wait until you try non trivial drag and drop where mouse out events are unreliable...

I don't care about syntax. I do care when systems suck because they don't work and hide the data I need to fix them under dumb visibility modifiers.

 

Last time I think I implemented this without event system. Or at least, without using it directly.

And the problem is not syntax but that the the code does not express (well enough) what it is doing.

 

Thing is, negi.. What we do isn't exactly what a single developer using a binary release engine or any other engine would use.. A lot of base frameworks and class derivatives we've modified and / or some sub systems we have upgraded.. So the issues you have, may not be the issues we have..

I've had all sorts of things to fix, from package cooking to issues with Lightmass shadow exponent / penumbra etc. etc.

It does cause issues with upgrading, in which we tend to only do that once in a big blue moon. We were recently on 4.5 and we're testing things on 4.12 now.. 4.5 was released a fair while ago..

Next time I'll be going more down the route of completely custom, I've already started investing time into a Unity alternative and if it's as advanced as I need it to be by the time all the ridiculous amounts of artwork is done. It'll be trivial to port the game (which is the easy bit) over.

You should care if it's an "odd" way to work, re-inventing the wheel for no gain doesn't seem like the most efficient route to take. Which I guess we were saying the same thing essentially, you use whatever saves you the most amount of time..

 

Good portion of your post is explaining the obvious/things I already know.

I might not be very good at explaining it, but this is not reinventing the wheel. It is building on top of it.

Meaning it does not matter if it is "odd" as long as it is efficient. You aren't going to argue against that, are you?

 

I'm starting to think we need to preface our posts with "You likely already know, but..."

 

Don't forget to add 3 paragraphs of a legal disclaimer while you're at it ^_^.
Just in case ^_^.

Spoiler

"The information of this post is provided as is, without warranty of any kind. In no event should the author of the post be held liable due to accidental damage, harm, loss of life, initiation of robot uprising, awakening of cthulhu as a result of application of any information obtained by interpreting or misinterpreting following statements as well as application and misapplication of said obtained information in areas including, but not limited to: operation of nuclear facilities, creation of ...." etc, etc, etc

 

I wasn't arguing in the first place .. This is just another thread where we chew the fat and say stuff. As obvious as it is, none of anything we really talk about on these forums actually matters that much.. You'll choose the right tools that works for you, you'll make your own type of game and learn from your own resources. It'll either work or it won't..

Unity will either make the right decisions or they won't, doesn't matter there's alternatives.

Well it's been fun guys and gals, I wish you all the best of luck with your developments.! Cioa.!

 

You'd be surprised how often the obvious seems to be anything but that. This is a good example of one. At times you would think Unity is the only engine the way some people respond to comments.

 

Well from what I have seen No Man's Sky is a fair step up in complexity over the mobile games they had been making:

But... they've been around for 8 years now and seems to be another group (when originally founded anyway) that were previously working for various AAA game dev companies. Certainly seem to have some very experienced people working there and their site lists about 15 people so they should be able to handle about anything at this point I'd think.

It is funny how they describe that as a tiny team (they say they will stay tiny). I mean I get compared to the credits listed for most AAA games that is a small number. Yet I can't help but to think that with even 1 to 2 other people working on a game what a huge difference it would make. In my mind, a team of 2 artist animators, 1 music & sound person and 2 programmers should be able to rule Steam (obviously if the people know what they are doing).

 

Nah.
Occasionally someone else might say something that accidentally gives you a hint which will in turn lead you to something interesting or useful.

Occasionally during discussion, when YOU talk about something you might make something clearer for yourself.

So, it is not all a waste of time, but at the same time it is not exactly basking in rays of someone's inhuman wisdom non-stop.

Of course, most post most likely aren't going to affect unity technologies in any way, but you still can gain something from discussing stuff.

 

Game engines are so huge and complex, it seems whatever one you go with, there will be some strange quirk or bug you run into. This goes the same for Unity. It would be nearly inconceivable for as complex a program, with features constantly being added, to be bug free. So you will have to accept some level of instability and find work-arounds.

The author claims to lose 20% of the team's time on Unity issues. Sounds high, but I could believe it. However, how much time do they save by using Unity? It's really easy to run into one major bug and then assume you should use a different engine (or roll your own). But how much time would it take to switch engines? How much time would it take to create a custom engine with all the features you need (that probably already exist in Unity)? I think it would cost more time than working around the bugs.

 

Our studio currently has 3 game teams. (There are other teams as well, and as needed may build additional game teams). The game teams are ~50 people (a little higher or lower depending on where the game is in its lifecycle, my current team is a little lower).

Most of our games do use a custom framework, but it still uses the unity API, it's more of game framework. Our asset pipeline is built specifically to avoid those issues mentioned. We don't wire things in the inspector and generally don't use scenes at all, and we have built two separate nested prefab solutions. Our only serious unity issues arise when we upgrade unity or there are platform updates.

I'm a little surprised at the reimport issue. It is very simple to avoid by just using an asset server. And 20% of development time dealing with (any) engine issues is outrageous. If it's really that high, you are doing it wrong. Either there is a lack of skill/knowledge or poor choice of engine for the project. Honestly I'm pretty skeptical.

 

Phew. I was seriously starting to think there was something to this "ditch Unity" bandwagon... if you're skeptical, that's good enough for me.

 

Also, it should be noted that dude's post was late last year. More specifically, right in midst of the horror show that was the series of patches for the version of unity that is never spoke of. It may just venting from dealing that version. We all did It.

 

It would take few years to develop an engine equivalent to unity.

Few months.

From few months to a year, or even more, depending on the project.

Depends on the situation and on the bug. Trying to work around some bugs may reduce unity to a little more than a libSDL equivalent. Basically, if you reach a point where your project uses custom rendering system, doesn't use unity physics and has custom animation system too, it might make sense to use a custom engine.

 

He list everything that made me stop loving Unity; these issues are absurd and I/we came across all of them every week when working on anything not *small mobile app*

 

I think this is the result of them hiring corporate coders and CompSci male member wavers who did not understand the component based, human readable architecture of previous versions and force their paradigm down our collective throats and then pat themslves on the back for their cleverness. Cleverness is highly overrated in this paradigm because it stops dead the facility of rapid game dev that was, and I repeat was Unity's hailing strength. I tend to forego the event system code and write functions that the UI components can access through the panel below where you drop a component script and choose the function from a menu dropdown list.

 

I read all you guys (and girls) said, but then went to the link, and looked at other answers to that question. The answer in the link is the weakest of them.

To the question: why big companies don't use Unity? there were good answers:

- Many do, you just don't know it (AssCreed Unity, Heartstone, Hitman Go, etc);
- Many use another engine more suitable for a specific projet;
- Many develop their own engine in-house, pure and simple.

Unity has many bugs and workflow problems? Yes it has. Every engine has, even in-house ones (like Frostbyte). Every software has. You need to understand it and work through them.

Unity has many workflow problems? Yes it has. But if you are an experienced Unity developer, you know them before you start a project, plan around them with your own solution, and go for it. Experience lets you avoid that "oh, you can't nest prefabs??" excuse, and big companies can employ only experienced workers.

Unity doesn't support doubles? Purchase the source from Unity, or get another engine more suitable for the project. Or work around it! I already had trouble with very large worlds, and worked around that with game design; now, I know before the project starts that I'll stumble on that, so I can plan accordingly before starting.

Seriously, that sounds more like a guy that hated working on Unity from the start (like I don't enjoy Unreal just because), than serious flaws with Unity.

Oh, and I love working in Unity!

 

I'm not disagreeing, but that reads like "Experienced Unity developers have been burned often enough by stuff that didn't work, so that now they don't even bother trying to use these built-in systems, and go for their custom workaround straight away."

 

The thing is, I understand what they were trying to do, but the ugly 3rd argument breaks the whole idea. You shouldn't need static callback in this situation, or it should be auto-generated.

Assassin's creed: Unity uses Anvil engine.

 

I think you'll find the pressure points hit when you're tackling the 3D side of Unity quite heavily, they do exist, and it is in a total state. You'd find lightmap baking to be utterly broken, physics have bugs and so on - and issues that have persisted for years. Now I'm not knocking your studio but if you are still using 2D then you have very little chance of hitting Unity's pain points.

The pain truly begins with larger scope 3D titles, I've never had any problems with 2D so far. Also we don't have source access so we can't fix or work around some issues. I guess when you do have a studio, the issues are often just bluntly coded around with your own solutions - things that are hard for 2 man teams

 

I actually deeply agree with this.

The overall approach to the new UI system feels very "framework" and stands in sharp contrast to Unity's old low idiom much more open, direct approach. Purists may hate S*** like 'magic methods', but the reality is that the older approaches are really more flexible, powerful and empowering.

I actually wish that they kept the NGUI guy on the project and canned the other guys instead. His code may have been confusing, but he 'got it'. He wasn't trying to jam a framework down your throat, he was giving you tools that you could use how you wanted.

 

Well you're not going to get "tools you could use how you wanted" from other engines either. It's pretty normal that a company will enforce it's own design. With UE4 you'll be doing things the epic way, and this is actually normal. Can you code your own? of course. But framework is essentially necessary or you create something so open it can't be used. You have to pick a team, basically.

 

Since you've just done a ton of UI work, looking back, what advice would you have given yourself to do differently right from the start?

 

I would probably go back to NGUI for the next project.

The thing is that Unity's old code showed a different kind of philosophy. Very few idioms (few 'ideas' but used together in combination), generally open data. By keeping things minimalist but open, you allow the user to arrange the functionality how he see's fit. The new UI stuff doesn't do that. It builds its own sets of idioms and very, very strongly encourages you to follow form.

For example... they created their own version of friggin transform. They built in a dependency that all your ui stuff have the new kind of transform. Instead of using colliders and cameras, they invented their own kind of raycasting system that doesn't share an interface (or results) similar to normal camera raycasts...

The list goes on and on, instead of relying on Unity's existing functionality and the existing idioms, they constantly decided to build their own - and those custom versions are almost always more annoying to use.

There are deeply inconsistent rules about how alpha affects raycasting and how canvas groups work - what exactly raises events when, etc. Let's not touch on performance... deactivating images (maskedgraphics) is ridiculous. There is a pointless 'pooling' system that sucks up insane amounts of memory on deactivation. Basic things like a mouse up on drag end also triggering a mouse click event (this is like event system 101 stuff).

 

Their transforms are actually similar to qt layouts and are quite flexible when you get hang of them.

The issue is they don't fit well with normal transforms (as you said), and I don't quite understand logic behind using floats fro pixel coordinates in ui. Positioning of anchors is very imprecise as well.

And yeah, entire raycasting stuff is very awkward.

Thanksfully UI and event system has source code available on bitbucket. However, I gotta say that when I opened it for the first time I felt like I'm reading UE4 source code again.

 

Easy to use in the editor, but really a pain in the ass to use from code.

 

I found opposite to be true, though. In editor transforms don't snap to pixels, which makes moving anchors painful.

In code, you can set up anchors and offsets, it is fairly quick, see .anchorMin, .anchorMax, .offsetMin, .offsetMax.

 

But any large studio has to build a production pipeline to fit the way the studio operates, regardless of engine. It's only the small guys, where working on a custom engine is completely off the table, that have to bear with "the Unity way" or take a hit and spend serious resources to work around it.

 

I mean like figuring out the post layout bounding of a component relative to different tranforms or translating things into different coordinate spaces - not like typing out the layout.