Gamelogic in Unity - how bad is it really?

Hey guys

I stumbled over a post on this Forum (about the waveEngine) which I like to discuss:

I like to have the opinion of you guys who did some serious unity-scripting about the issues he mentioned:

A. Design-Patterns, implementing logic and keep the code-structure clean
Coming from the "business"-sector of development and having some experience with XNA, I do have the feeling Smooth P could be right.
But my Unity-Experience is very little, so maybe I'm just not used to the way things are done in Unity?

If you're more experienced with scripting for unity: are things clear and fluent to implement?
How do you work in a bigger team? Do you just need to use a design pattern of your own and define code-organisation which everyone has to follow, or is there some sort of "best practice" which allows to organize bigger projects?

B. Unity API
As I said, I don't have much experience when it comes to unity-scripting.
So far, I don't have any problems with the API.

Are there any problem if it comes to certain tasks?

C. Mono-Implementation
Having no Multithreading is sad, but I don't know of any multiplatform-system who can handle this, so I guess that's fine.

But the information, that Unity is using an outdated version of Mono really concerns me (from a performance-point-of-view).
In the current version of modo, we have a pretty decent implementation of the .NET-framework - as well as a good garbage collector.

If Smooth P's right:
Did you ever had any performance-issues (especially with mobile devices) with more complex things like a rich network-client, AI, or something like that?

Thanks for your opinion!

Cheers
Richard

 

No, it's not bad. Keep in mind that some people have a very narrow view of the "correct" way to do things, and anything that deviates from that is "bad", even though it's objectively not. Certainly there are areas that could be improved, and if the Unity team were to start over from scratch right now, I expect they'd make some different choices, but overall most of it works well.

--Eric

 

isnt that what smooth p said?

anyway, i agree with smooth p. I've been using unity for a few years now and I have had issues with EVERYTHING he mentioned.

 

I can share an opinion on the pattern part. A pattern, to me, means two things:
1) Rules;
2) Efficiency.
What do I mean by this? To put it simply, the more rules you impose in a system, the less room there is for errors.
A pattern essentially describes a set of rules for developing a particular type of application. It provides a (not in all cases!) clean and efficient solution for doing just that. The actual rules are the ones that provide the cleanliness. It's also the actual rules that don't allow the programmer to go braindead crazy and mess crap up.

Having said that, Unity's flow does seem a bit like an anti-pattern. The fact that any GameObject can have complete access directly FROM ITSELF to ANY OTHER entity in the actual game allows you to do all kinds of crazy stuff. Of course, that does not mean you should do it. I have managed to successfully apply the MVC and Observer patterns on big parts of my game. I need to re-think bits of logic because I fell into the trap of doing crazy keyboard input checks from everywhere I could.
Judging from my experience, I can say that Unity allows you to design your game in whatever way you want and use any kind of pattern you wish to use. The only bad thing about it is the fact that it allows you to do lots of rather bug prone stuff. It's basically begging you to build crappy designs and swim through issues.

I cannot share anything regarding the API part. I'm satisfied on this side.

Nothing on the Mono and multithreading part either. Or, perhaps just one thing: I don't think performance is that much of an issue under Unity. It's possible that I might change my opinion later on though.

 

Works fine. It is great in many ways.

Will HL 3 use it? Nope.

 

OMG, could you imagine the uproar if it did? Hilarious.

 

Can you imagine the MEMES?

 

Nope, it's kind of the opposite actually.

Except that's not true...the Unity engine itself has multithreading in several areas, and scripting can use multithreading as long as you don't use the Unity API. (Which isn't ideal, but is far from useless considering most stuff that you put in threads is "just calculating things" anyway, and then if necessary you do your Unity API calls in the main thread after you're done.)

--Eric

 

most of the complaints he made sound more like deficiencies in his abilities.

 

Second sentence says it all in the case of the place you quoted. However, Unity does have its own quirks to be negotiated, based on the architecture you're working with.

For one thing, in Unity, I'm finding uses for the Singleton pattern (which, funny enough, many people claim to be an anti-pattern, because it introduces global scope.) Instead of attaching n heavy Monobehaviours to an object, and telling it DontDestroyOnLoad(), I can create a lightweight Singleton that lives in memory across scene boundaries and holds things like player data, preferences not provided for by the Unity engine (e.g. Music volume, SFX volume, Master Sound volume, Use Click-to-Move or WASD?, the list goes on.) The result is relatively concise, memory-efficient code.

Anti-patterns do exist (for instance, not everything needs to be a Singleton, only very specific things that need to A) have one instance, B) persist across scene boundaries, and C) don't necessarily need to be tied to a GameObject), and I'm not going to minimize that. But, when you realize what Unity can do, you can really make some impressive and performant code, Mono version or other idiosyncracies aside.

 

Unity is more about speed and ease of development rather then being perfectly optimized. It's robustness hinders how much you can optimize the "one thing" that you are trying to do. If you really want that level of control then you have to make your own engine, which is why most open world games have their own engine. Personally, I far prefer speed off use and ease of development over being perfectly optimized or having top tier tech.

 

I have to agree entirely, and I have to disagree with smooth's statement about "completely screwy fundamental design decisions". I somewhat agree regarding threading, but some of the other stuff he says makes me wonder how he's actually trying to use things.

Unity's fundamental design is more or less a textbook implementation of a Component-based game engine architecture. It's not a perfect implementation, but it's definitely an adequate one, and if you're familiar with that approach to software design then it's not "completely screwy" at all. When I first came to Unity from other engines/frameworks where straight inheritance hierarchies were in use I also thought that Unity's component model was weird and performed badly and generally made life hard, but I took the time to learn the appropriate new approaches and now I quite enjoy it. Also, the stuff I write now in Unity significantly outperforms equivalent stuff I'd written in other systems, and I develop it faster.

Additionally, while Unity certainly has its flaws I've found it much nicer to use than many of the tools I used before it. No doubt that's largely due to gained experience, but it is at least in part also because in some ways Unity is a better tool. No engine is perfect, and that includes Unity, but the flaws in Unity are so far the flaws I'm most happy to work with, and its benefits are the ones that are most useful to me.

 

The fact that everything is exposed is a bit of an anti-pattern from an OO point of view (e.g. I can grab any game object and update its transform from anywhere). But its not that hard to enforce an internal rule of "don't do this", you can write an external script to enforce it if you are really concerned.

The behaviour based system is not an anti-pattern, although its not a pattern I'm particularly fond of. The idea is that you can combine different kinds of behaviours on a game object to get a new emergent entity, but the reality is this only happens to a limited extent.

You have to stuff around a bit if you want to use threads, as you can't access unity "stuff" from outside the main thread, but you can use threads, they work on mobile, web, etc. Its not that hard to supply data back to the main thread via properties which are applied on Update().

Quite a few people particularly on mobile have GC headaches. This is in part to do with the older version of mono. Can't really argue with this one.

"its APIs range from underexposed to half-baked to completely broken" should read "its APIs range from good to underexposed to half-baked", there are some missing bits 'n' pieces but I don't think any APIs are bad enough to be considered completely broken. There are also plenty of good ones too.

All the points are valid to some extent, but the tone suggests these are dramatic flaws when in most cases they are minor annoyances.

 

Not at all , Smooth P said it was completely screwy. And Eric5h5 said it's quite fine (but there's always room to improve, which is usually the case with anything if you think about it).

 

This.
I can tell from my experience that I had to write some very complex game logics (latest episode being the nightmarish Network Rollback model), and never was Unity the code design stopper. Only my brain was. And patience was the saviour. Punchline : there's always a workaround.

p.s : when you see how Unity is more and more adopted by kickstarters coming from the AAA industry, I'd trust them more than someone on a forum about how much the engine is capable of

p.s 2 : the best way to realize how far you can go with game logic in Unity is to parse Work in Progress forum, too. There are quite a lot of different game genres there, all with their own mechanics.

 

In some ways, Unity is wonderfully flexible. And it lets me use my most favorite programming language, C#.
But the terrain system is so clunky to use from scripting, and gets so little attention...If I had the skills, I'd just use my own. Then I COULD use multithreading to load them up.

 

i think there are things that forces you to do things the unity way which does not always feel right. when i first started using unity, i always used a single class that inherited from mono behaviour. i did not like the idea of attaching a script to the wheel of a car. it still sounds absurd to me that some people think of scripts as an asset like a sound or image file. so i think one of the major weird thinks about unity is the mono behaviour class. when i first saw that the object class in unreal script contains the whole math library i was confused and it was similar with mono behavior. it is not straightforward to set up your system out of scripts, for ex. you can not define the order of update calls, you have to make your own. you must attach a monob. script to a gameobject to receive collision callbacks etc. these force you to change your code design. well at least understanding the overall api is as simple as reading a child book.

 

I've also been through the nightmare of network rollback. And I'd much prefer to have been able to put all the brain power and motivation that went into figuring out physics workarounds into something more productive. Much like I'd like to be able to use interfaces and constructors and generics and variance and all the things C# and other modern languages are working towards without tons of boilerplate instead of tweaking my script execution order and manually managing the race conditions inherent in the Awake/Start/Update model. Or to have script access to things that should definitely be scriptable instead of futzing around with non-nesting prefabs in the editor. Or to be productive and use deep, nested LINQ instead of spending time managing loops, object pools, and generally making my code less maintainable *on purpose* in order to babysit the GC.


As far as my statement that Unity's "APIs range from underexposed to half-baked to completely broken", I'll give an example of each:

Underexposed: Physics. For something so central, there is a *lot* of working around you have to do to accomplish anything moderately complex... And even CharacterController, which is one of the most important classes in the entire engine, has key properties that aren't accessible via script (eg: skin width).

Half-Baked: Shuriken. Buggy and non-scriptable. Have fun mucking around in the editor doing the prefab dance. Prefabs in general also fall into the Half-Baked realm with the whole non-nesting, stored as binary situation. Input and Networking go here too, if you have anything beyond the barest of needs you'll certainly want to roll your own ASAP.

Completely Broken: OnGUI. I have no idea why anyone, anywhere is using it unless they are literally homeless. Even the official docs warn that it isn't viable for production.


Is Unity useful? Yes, obviously! It's tremendously useful! And generally fun! Depending on your needs there's a high probability that it's the best engine out there. Hell, if you're coming from other game engines or are a newbie to programming the object model and available C# features are probably freaking awesome!

But if you're coming from a professional programming job in a managed code environment outside the gaming industry, where OO, FP, and middleware APIs have reached a much, much higher level of maturity and GCs are fast enough to run billion dollar microsecond trading funds, you're going to find yourself fighting against design decisions that were based on early versions of UnityScript, APIs that made it to a checklist but don't go all the way, patterns that have been counter-productive since string based indentifiers were acknowledged to be a really bad idea and GCs went generational / multithreaded, and the focus on making things "so simple, even artists might occasionally write a script!" as opposed to "so well designed and feature complete, your programmers' productivity will trend to infinity!"

 

And yet we still see games made with unity in the top 300 of the app store. Ski Safari, Zombieville

 

Thanks for the enlightenment and the detailed answers!

Thank you Smooth P for going in depth about your post I referenced.
Maybe I misinterpreted it, but it sounded like unity3d is a show-stopper when it comes to complex stuff.

Cheers and thanks again to all of you!

 

In this context, I'd highly recommend watching:

Jonathan Blow - How to program independent games

Basically, a lot of things that may appear "broken" or "wrong" turn out to be there for very good reasons. Sometimes I agree with how Unity does things, and sometimes I disagree (sometimes even strongly, so ... I'll just say "namespaces" ... or "new Unity GUI" ;-) ).

It's very easy to complain because something isn't done the way we "expect it to be done" but if we knew everything the Unity devs know, I'm pretty sure each and every detail is totally understandable. And yeah, sometimes the reason is "we really felt we needed to push this feature to the people even if we know there's limitations".

In my opinion, the best approach when running into something where I first think "this really sucks" is trying to figure out on my own why it might be done that way and not another way. And if I can't figure it out, I can ask on the forums. Usually, asking why something is done one way or another will give you much better results than making a bold statement that "this really sucks".

In the end, the question is: Do we want to judge other people's work, or do we want to learn from it?

 

This, very much this.

I wanted to add my own thoughts, but nothing I wrote actually improved the message so I decided to quote it instead.

 

Our first title used the "Unity" way of doing things like making good/over use of inspectors, prefabs etc.

We used a FSM for the game loop and made generators that let us instantiate entities in levels etc but it did rely on a fair bit of point and click.

Our next title has a database that holds all our entity and level data, a database layer to set and get data, a game mode FSM to handle "MainMenu" and "Racing" modes, then each menu has it's own class which overrides from a base which we use to handle code like linking up buttons, starting animations and general menu stuff that isn't specifically related to the current game mode.

The menus can all be loaded at anytime and function regardless of the game state.

It's pretty involved process but we have scripts that generate all our UI from photoshop files so we don't have to code it ourselves which gets rid of the "it's overkill" argument.

Unity can easily handle some pretty advanced setups but like Smooth P points out, there are quite a few things you'd love to get access to but aren't allowed to... such as uv3 and uv4 on mesh!

 

+1

 

This,
As much as I love Unity I can't agree more! Unity is the holy grail for any kind of developer (specially designers and artists) but real programmers doesn't feel that much empowered by Unity ways of doing things.

 

well said

 

I wouldn't say well said as it implies that game programmers aren't "real programmers".
Also while it takes some time used to i definately don't feel "underpowered" by unity's model, but i do feel overpowered by the old mono vs the full .net i'm used to.

 

What's your definition of "real programmers"? Game programmers are real programmers. No matter which tools, environment or platform they work with.

 

That's exactly what i meant, in oposition to him saying "real programmers" after naming game programmers. Just to be clear i'm on the side of "game programmers are real programmers", not the other way around.

 

Ok

 

I guess "real programmers" is a term almost bound to make a flame war happen. So I'll try to be cautious.

To me, a "real programmer" is someone who learns to understand the environment he builds upon and uses it in the most eloquent way. A "real programmer" understands the benefits and limitations of any given environment and knows how to work around the limitations and take advantage of the benefits. A "real programmer" knows what he can easily change (his own code, his own approach) and what are things that he most likely will not change (the hardware he's building for, the people using his products, the tools he's using ... unless he's using open source tools and spends his time improving those).

Personally, I'd rather not say "I'm a programmer" (real or "not-so-real") but would say "I earn my living doing software-engineering". And from a software-engineering point of view, yeah, Unity does have a few quirks and limitations; it does have a few design decisions I disagree with, sometimes strongly (as mentioned in an earlier post).

But: Show me a development environment for games that's more powerful (in terms of: lets you do whatever you want to do) while at the same time being as easy and efficient to use (in terms of: you don't have to spend years understanding the tool and then spend a very long time implementing what you need).

As everything in engineering, it's always a balancing act: UT could throw the source code at the people using it, like other companies do ... this would have benefits; but it would also introduce a lot of stuff I personally would find rather annoying. UT chose to give the source code only to those people who are willing to invest heavily. If you want that freedom (and if you want to invest that much money ... and then time figuring out and changing the source code), you can have it.

Also, UT could throw away all (or "quite a few") of their APIs and do it all from scratch, with lessons learned and the most modern approaches. Yeah, this would have benefits ... but it would also have costs I believe no one (including us) wouldn't be willing to pay.

It seems to me like that's what they've been trying with the GUI system - and look what happened: How many years is it by now? 4? 5? (UnityGUI become kind of obsolete when Unity iOS was introduced). Everything has its price, and sometimes, when you want to do something really really right, you'll feel you have failed and start it all over ... and again ... and again; and then you have lots of people ask "hello? what's going on? where's our new GUI?" (and I do that from time to time, too ;-) ).

So the question IMHO is really: What's the point of even thinking about limitations that no one will remove any time near?

If you feel you can do a better job: Go ahead! Just like UT started with 3 people, you can start with a few people, build upon existing technologies, and create something really awesome. If it's really that awesome, people will start to get interested. Eventually, you could be the next UT. ;-) ... or, if you feel you want to create a subsystem - there's the asset store for you. I'm sure the NGUI dev is making quite a little fortune by filling in the limitation that UT has with its "still current" approach to doing GUI.

If you know how to do things in a better way: That guy could be you!


To me, at the current point in time Unity is by far the most empowering tool I have every worked with. That doesn't mean I think it's the holy grail! It's just a tremendously useful and easy to use tool. It's efficient to work with, and I don't feel limited (I did feel intensely limited by its networking implementation - that's why I'm using Photon now ... so yeah, there are things that I don't like but as a "real programmer" it's my job to deal with that in a creative way; that's what people pay me for ;-) ).

 

@jashan,
I just feel limited by some of it's stuffs like those you've named. Networking for example (and yeah Photon is really great, we are using it right now).
But still, Unity it's too much great (Isn't?) that those limitations becomes invisible. Of course it would be awesome if they can be overcome and improved (that's what they are doing at the time we speak).
But to put it out, even with those minimal flaws, Unity still the best and most flexible game engine, no doubt about it.