Why is it said that unity promotes bad programming practice compared to other Engines?

First OF ALL : This is not a Engine vs Engine Thread. Just a question about coding practice in general.
In many forums/ videos I have seen that people often says unity encourages bad programming and unity skills are not transferable to other game engines.
Why is that?
I don't have enough working knowledge about other game engines. Tried unreal engine for a week just out of curiosity. Didn't liked it as it was too unstable for me , didn't liked the chunky UI - also could not make c++ project work due to a common project compilation bug. Kismet/Blueprint/Visual scripting is just not my thing - so came back to unity.
If anyone out there who have enough experience with multiple game engines, please response. TY in advance.

Edit :
Example 1: (https://www.reddit.com/r/gamedev/comments/3hr8al/coming_from_a_net_programming_background_unitys/) ,
Example 2: (https://www.reddit.com/r/Unity3D/comments/4qrxo2/why_do_some_people_say_unity_encourages_bad/)

 

With Unity Engine currently dominating the games industry (1, 2, 3), it doesn't really seem to be a big deal to me whether Unity skills are transferable to other game engines. I would rather ask if skills are transferable to Unity, because it might be the technology I have to use in the future.

 

It's always important to remember to take anything you read on the Internet with a grain of salt. Having read a number of threads and watched a number of videos where this took place my experience has been that the vast majority of the people taking part in these had very little knowledge when it came to game development.

Many of them are often just repeating what they've heard from other people who are just as much in the dark as they are and if you've ever played the childhood game where you repeat statements down a line you'll know that what may have started off as one statement may be a completely different one by the end.

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

 

Because some people are idiots who can't tell the difference between actual engine practices and beginner tutorials that don't use best practices. Beginner tutorials rarely use best practices because they're designed around easing people in to programming.

 

For commercial, marketing, and historical reasons, Unity does a lot of things in a way thats not generally considered very elegant or at odds with .Net best practice. They are getting better but they have an onus to maintain backwards compatibility, and changes will always take time.

I'm sure sometimes Unity's choices were just bad decisions and others good decisions that weren't inline with the status quo.

A lot of people get very worked up about these kinds of issues, even though they don't necessarily have a material effect on developing useful things. I mean older versions of Java didn't have a number of key features that .C# has, Lambda's for example, but despite that it was sill the most popular language, used to achieve many wonderful things.

And thats the thing, you might miss a few language features, or have some odd implementations here and there, but its very rare that it prevents you doing what needs to be done.

 

Better to say that Unity enables bad practices rather than promotes it. (The exceptions, as @Murgilod mentioned, are some of Unity's code examples, which were written for brevity rather than best practice, so you could argue that as learning examples they promote bad practices.) Unity provides multiple ways to accomplish tasks, in part because it's evolved over several years. You can use good programming practices or sloppy ones, just like you can use sloppy project structures and sloppy scene organization. Admittedly Unity is so sprawling that it's hard for new users to know the "best" way to do things. But ultimately it's up to the developer to choose to use good practices or not.

 

I still blame this on Unity, its one of the few frameworks/engines/tools out there where the beginner examples use practices that would be considered out-right bad, and they don't even make note of it.

I expect this has a lot to with the fact that the target audience is often much less skilled than that of a typical programming framework and also with the rapid pace of Unity development. That said I think they could do with a bit more focus on removing older documentation, or updating key docs with side-bars about best practice, etc.

 

@TonyLi , @JohnnyA
what would be a proper example of good programming practice?
Does that means Using ECS instead of old Component/Monobehaviour based approach ?
Or some thing else?
Don't hesitate to go all technical.

 

The thing to realise is that there are many ways to do things, each with their own pros, cons. If using ECS made your game 5% faster but you didn't need optimisation and it took you twice as long to build then it may not be a good commercial decision. For another game that speed boost may be critical.

That said a very simple example from the past: for a long time Unity didn't support namespaces on MonoBehaviours. This, among other things, made it a pain to share code and tools with others.

There are lots of other current examples, although some may be a bit more controversial and I'd rather not get in to arguments about them. Google I'm sure can fill in the blanks.

 

The way I take it from those reddit threads, it's not about which design and architecture patterns you choose, but about safe, maintainable programming practices.

As @JohnnyA mentioned, Unity 1 - 3 didn't support namespaces, so it was easy to write code that conflicted with others' code. Unity 4+ supports namespaces, but that in itself won't stop you from improperly putting all your code in the global namespace. Similarly, Unity still has SendMessage() method to support legacy projects, although it now also provides safer alternatives. At this point, Unity's API and compiler support is robust enough that it's just a matter of choosing to use good practices over bad.

 

Because people on the internet who generally spend all their time posting their opinions of how things “should be” aren’t spending thier time actually doing things like making games. Even if it were true, a game created using “poor coding practices” is a bigger life accomplishment than thousands of whiny reddit posts.

 

((Bad mood mode: On))

The guy in the first thread you linked is an idiot.

Alright, maybe it is too harsh and maybe he is not an idiot, but his problem is "coming from .NET background".

.NET background teachs you specific programming habits (object immutability, anyone), that in unity would result in a poor performance. And that is the issue.

.NET/C# provides very few tools for tackling timely resource deallocation, for example, and rather than being "proper" language, C# in unity is used for scripting. Meaning it is hacky, it is not perfectly suitable, but this is what the have and can use right now.

The thing here is, if the programmer is still in the honeymoon phase with their language and programming in general and the wisdom of ideas like "programmer's job is to get things done" haven't yet dawned upon them, their head will be full of ideas like "proper way" to do something, "idiomatic way" to do something, etc, or worse, they'd be looking for "beauty" in their code, believe in "code smell" and such. So, they can delude themselves into thinking that they're doing something useful by constant refactoring, while in reality 98% of their work would be a waste of time. I kinda been there.

The reality is programming is dirty and unelegant, no practice should be used in all circumstances (even stuff like "never use goto" has exceptions), and it is REALLY, REALLY, REALLY important to concentrate on "make best solution in shortest amount of time, smallest amount of effort, smallest ongiong cost and get paid for it".

This dude - in your reddit here - isn't there yet. He hasn't reached this point where you figure out that you are not some mythical programming wizard, or voodoo shaman, or whatever else, but you're an auto mechanic with your hands covered in grease all the way to the shoulder.

A lot of stuff he speaks of is bullshit.
Future proof? Games have 2 years releaase cycle. There's no future. In 20 or so years .NET itself might be phased out, how far into the future is he planning to look.
Hacky api? Well, that's result of compromises made for performance. C# is second class citizen in C++ engine, and alternative would be spawning bazillion interfaces like "IBeginHandler", etc, which would be garbage, as you'll have to essentually write a method name twice (first in interface implementation, then in actual method).
Support for polymorphism? Why is it even suppsoed to be a good thing?
Api Discoverability? We have documentation, try reading it. It is very good.

Thsi guy is in love with idioms and "the right ways to do it", stuck in it, and fails to realize the real world "get stuff done" issues. In a few years he'll maybe get there, but right now complete disregard of all the things he errorneously hold sacred causes him experience horror.

And that's all there is to it.

My opinion is that a person accusing unity itself - the whole engine - of being responsible for bad programming practices, ... I think those people need to get more experience, and more experience with real world problems, that fall into category where, as my friend aptly described the thing the is working with... "our codebase is a big hangar made out of poop, with more poop propped up to support it, and painted to look good from distance". As it is what a lot of projects are.

Unity has surprisingly clean API, and fairly good documentation. There are shortcomings, but if they can't live with that, they need to grow up and get more experience.

At least that's the way I see it.
((Bad mood mode: Off))

So, long story short, a lot of people say this, because there are a lot of people online that could use more programming experience.

 

When people complain about Unity, they are missing the real point of Unity's success. There are many games made in Unity. Some of those games are fantastic, and some are not.

The comment from the first link is silly and wrong:
"The API actually encourages your codebase to be a dust-bowl of spaghetti-western cowboy-code loosely-held-together-with-strings with no care for the basic software development principles like separation of concerns or encapsulation."

The API does not encourage bad coding practices. At this point, Unity is flexible enough that game developers can choose to code well or code poorly, and get a working game either way. Obviously a game is easier to expand and will perform better if it is coded well, and some Unity games are coded very well.

And especially with the addition of DrawMeshInstanced, ECS, and the Jobs system, there are ultra scalable coding practices that can be done using Unity 2018.

 

Exactly. In most cases, some simple C# script can be attached to a game object to make something cool happen in a game, and that is all that needs to happen. A simple hacky solution is often the right solution for many games, because it is quick and easy. The user in the first link should definitely be working on their own game and gaining experience building games instead of complaining in a forum.

Since both links were 2 year old rant threads, I wonder how those users are doing. Did those users ever successfully make a game? Did they switch engines? Did they create additional rant threads about other game engines?

 

I heard the Unity forums encourage bad posting practices. Why is that?

 

Any bad practices you follow are yours alone and you would make them outside of Unity if you do them. The only valid complaint is Awake\Start\Update\FixedUpdate not being API discover-able

But the rest, Unity is just an API it's up to you to create conventions and best practices for your game. Unity is an engine to create an engine (For your game).

 

We lost our dragon overlord to one of the research and development teams. Without her to whip us into shape we quickly devolved to discussions about engines, mocking the splash screen, and why the light skin is slowly blinding us.

 

Hmm... I think it's a debatable point, at the very least. If nothing else, Unity has a heck of a lot of globally accessible stuff, and taking advantage of that global accessibility is often the easy way to do things... short term. And on the topic of "encouragement", stuff like the tutorials often encourage people who are learning to do stuff like make things public. Yes, it's to keep things brief and simple, but nonetheless... that is directly encouraging something that is considered bad practice.

That said, I think that much of this complaint likely comes down to using a .NET runtime in an environment that's fundamentally not compatible with the general .NET way of doing things. .NET is mostly about letting humans define data and algorithms and letting the computer deal with stuff under the hood. That's a great way to develop general applications because it lets the programmers focus on what the users need, and on writing easily maintainable, neat, clean code. But games need performance, which sometimes means handling some of that under-the-hood stuff yourself, or doing things in less clean but more efficient ways.

I once had the experience of working on a Unity project with a couple of good .NET developers. After about a week one of them commented to me that working in Unity doesn't "use" .NET so much as it "subverts it" for its own purposes. I learned a heck of a lot about the .NET way of doing things from them over that project, and can't disagree with the statement. I responded to the comment that "yeah, I've never really considered this as a .NET environment. It's a game engine scripting environment that happens to also be a .NET runtime. And as a game engine scripting environment, it's one of the better ones I've used."

 

I would have made an awesome game, but the darned engine forced me to learn bad habits. Do better work people!

 

I think the real question is, what's an example of bad programming practice that is both easier to implement than its 'good' counterpart, and actually has a real impact on anyone's life?

Good code is code that you can read, and works the way it's intended to.

 

Code (csharp):

1. public float speed = 3;

As compared to:

Code (csharp):

1. [SerializeField] private float speed = 3;

In the latter case, it's not going to get changed unless you specifically allow it to be changed, and it's easy to provide some mechanism to be able to observe it, even if that's just dropping a break point on a setter.

 

Also keep in mind that "easier to implement" is experience based.

I know from experience that making something accessible by writing "public" in front of it is not "easier" because sure, it saves me a few seconds now, but I've untangled the resulting spaghetti more times than I care to remember.

So these days I'll type out a private serialized field followed immediately by a public get/set Property almost by autopilot. Takes a few seconds longer, but even if there are no sanity checks or guard conditions I need to apply now, I know that the habit is saving me far more grief than typing a few more lines.

There are exceptions to this, but they're just that - exceptions.

 

Macros. get+tab

 

Personally, I agree with you on that example - although I very rarely begin a game project or prototype with getters and setters, it's just too tedious. At some point where I feel that a certain stability is reached, I will add them (unless I'm just putting some small thing together for fun). The flame of inspiration often doesn't have enough fuel to put up with maintenance of coding standards, and I'm perfectly happy to shoulder a certain level of risk for a period of time.

But what I was really objecting to (and maybe wasn't too clear about it) is this idea that Unity or some other system 'promotes' bad practices, as if that will somehow destroy our collective lives. There is no such thing as bad code, there is only code that doesn't work as intended (which your example is an example of, when somebody changes the variable without meaning to). There is coding speed, ease of bug-fixing, performance efficiency, extendability, bug risk management and all sorts of other things that compete for valuation according to project-specific goals, none of which are necessarily more important than others that conflict with them.

In my opinion it's better to ask 'what code do I need to write to achieve certain things and avoid certain problems' than it is to ask 'how do I write 'good' code' as if there is some arbiter somewhere who will look it up in the Book and bestow one with the correct answer.

Of course when working on other people's code, or selling code assets it's necessary to always follow a general principle of best practices and put less value on speed. But that's because you don't want to put a burden on them they're not aware of.

 

Lets be honest. There are only two engines in the market. Unity and Unreal. They use different languages and paradigms, and not much is directly transferable between the two engines. Worrying about transferable skills between engines is largely a waste of time.

Ultimately games (in any engine) have their own set of best practices that are completely different to most other programming environments. In game development performance is king. If you can shave a few milliseconds off the performance of a loop, you do it. This is opposed to other environments were maintainability, extendibility and reliability are often more significant concerns then performance.

Looking at the reddit posts you linked, many of the concerns have been addressed. Unity now has proper support for interfaces, which means SendMessage is only used for are edge cases. The shortcut property accessors are deprecated, which makes the API much simpler and cleaner. Magic methods are still a thing. I don't think we will ever get away from those. However I've never heard of Unity devs with even a medium amount of experience running across the problems the OP described.

 

I don't know about that. I've written a lot of code in my time that works, but which I would consider to be "bad code" specifically because it's a pain to maintain, is hard to understand, or lots of other reasonable things. "Sure this thing works as intended, but I see at least another two late nights during this project herding cats to keep it that way, and while it's like this any changes to X, Y and Z are going to be like walking on eggshells."

Once you get to a certain point you stop thinking about code being "good" or "bad" based on simply whether or not it works, and instead start thinking more across the board about "time to project completion". Anything that reduces that time is good. Things that increase it are bad.

There's a lot more than two engines out there, and a huge amount of knowledge is transferrable between them. Heck, when people ask me about learning to program for making games it's not even game-specific resources I refer them to at first.

 

One thing I thought of...

What would the people who complain about unity encouraging bad habits think if they worked, say, with SQLAlchmy or Flask (Python).

SQLAlchemy and Flask have amazing pattern where something that can be passed into a function can be.

• An actual class
• A dictionary object that has the keys that matches the fields of the class that are used by this function. (because duck typing)
• A string with a name of variable you're referring to. This is used in sqlalchemy ORM a lot to address foreign tables and keys, and it is incredibly annoying if not infuriating for someone with C++ or even C# background. Because along with python way of doing things (some errors won't trigger at compile time), it makes your code feel very fragile.

 

Really 2/3 of that reddit post is a rant about SendMessage.

Honestly, I agree that SendMessage sucks, frankly the Unity team did as well which is why they're moving away from stuff like that in the future.

I really wouldn't take that post too seriously though, like in the years I worked with Unity, I only used the string based invocation a handful of times. It's not like you need to use that method to do everything (which is kind of what he implies).

Finally, String based method invoke or string based field references are a serious pet peeve for a lot of developers. You lose intellasense and automated refactoring when you use features like that. I know a lot of very good developers who have a problem with WPF's PropertyChanged events because they use string to property name mappings.

I don't really like SendMessage, but it's really not a big deal.

 

Reading some of those reddit comments reminds me of something I read at the beginning of a 3D game development book from the 1990's that stuck with me all these years. Take the "correct way" of programming and throw it all out the window. Replace that with the "fast way" both in performance and development time.

The "correct way" of programming puts way too much focus on elegant design, class security, reusability of code, and future proofing. All of which generally result in poor performance when performance is of high priority for games, and all of which take longer to code which means it will take longer to complete a task and move on to the next one.

Yes occasionally you'll run into issues that are a result of ignoring the "correct way", but just deal with them as they come up.

 

We are two senior system architects from the enterprise business world doing a game together. We use most paradigms and best practices we would in our day jobs, the iteration time is very fast (if you count in we both have full time day jobs) and the performance is great.

 

I think the biggest problem facing Unity is that the free version of Unity displays its logo at the start of every game. The most visible Unity games are those made by people who cared so little about their game that they didn't even care to buy an upgraded version to remove the splash screen.

Unity also (for me) seems to have limited testing ability. I've been a professional developer for more than a decade and have installed every type of IDE extension imaginable, but I could not for the life of me figure out how to integrate NUnit with Unity. In the end, I wrote my own unit test suite. Neither process is easy for someone who's never even used a unit tester before. Lots of game developers have no idea what would happen if an NavMeshAgent bumps into a CharacterController in the corner of a wall. I know for a fact that it'll clip the character through the wall because I could programatically test hundreds of variations and repeat it until I figured out how to fix it. Most people play their own game the way they would play it, but bugs show up in fringe cases.

 

Did you try Unity's Test Runner?

 

Personally, I think Unity makes things too easy. Developers can throw together working prototypes and mini-games in a matter of hours and have them up and running for a game jam in a few more.

It's physics game engine sandbox and quick play features make it too easy to throw together a game.

However, the quick and dirty way of throwing things together in Unity does not make a multi-level performant modern scalable game starting point.

And it's the scaling up of a game and how easy that is to do that is the real test of any game engine and editor.

Unity's empty sandbox makes it easy for developers to build things up the wrong way quickly and end up paying for their mistakes later.

Other game engines have a pre-built framework that you have to use and will push you to build your project in a more scalable fashion. This works well for some game genres that fit but will be limiting for others.

What is interesting is that ECS with it's more rigid data-driven structure might provide a more scalable development framework than the old Monobehaviour Kitchen sink approach.

Do you think ECS brings more scalability?

 

If the "correct way" and the "fast way" are one and the same, all the better

 

Of course not. Just like everything in life, you don't two different tasks exactly the same way. One of the great things about unity is the ability quickly cobble things together. It is brilliant for prototyping and user/experience testing. You can quickly explore and test a variety of things. But... you don't build a game that way. If you are walking to the store, you prepare and do it differently than if you are spending a week hiking a high altitude mountain trail. Though they are both walking. Know what are doing, and proceed appropriately.

Al lot of these comments are really about that, developer knowledge and understanding what the hell you are doing. Unity is a tool set. They are providing you a saw, hammer, screwdriver and tape measure. You need to learn how and when to use which.

 

Problem is most programmers think they are doing the correct way but instead they over design things etc,etc. It's a balance

 

I do think Unity could add some systems to its toolkit to deal specifically with project scaling:

For example, a lot of scaling up a game is where the work to add one new thing is multiplied by the number of things it can interact with and Unity to my knowledge does not have an easy UI/UX for this aspect of game development. I imagine that some kind of entity interaction matrix would be ideal for this aspect of gaming.

Or the behavioural aspect of NPCs seems to me to need a better toolkit e.g. Behavioural trees or Finite State Machines.

It's these kinds of system that bring down the complexity of aspects of game development that could really boost Unity's 'Ease of Scalability'.

 

"Best practices" is a purely subjective term. There are language standards, which are VERY nice to try to adhere to whenever you use that language. It increases the chances that others going through your code are using the same syntax and style, and can more quickly understand everything you wrote and why you wrote it.

I'd say "Better practices" is a more objective a term. There are several things that are considered just-about-nearly-objectively bad, such as using goto statements in C#. But the overwhelming majority of style, syntax, and approaches to solving a coding problem boil down to preference. That isn't to say that some approaches very clearly are more performant, safer to use, and will be more pleasing to edit for the next programmer - but I don't think those are the majority of lines we write. And I've yet to see a situation where I feel like Unity promotes a less-optimal approach to the same problem (when all options are available). I always go with what gets me the best results.

Frankly, the only thing I have ever encountered in Unity that makes me think I am writing suboptimal code is the restrictions imbued by the available .net version. A lot of code that I find is much more readable, much simpler to write and understand, and generally just better - is simply not available in Unity.

 

This has been addressed by the nameof operator.

 

Yes. ECS definitely brings more scalability.

Prior to ECS, there were ways that a hard core programmer could get scalability with Unity, but it was too difficult for most people to use. For example, I developed data driven "Instancing Pools" for my space game that used DrawMeshInstanced instead of a separate game object for each projectile. I was able to scale to insanely high levels this way. What ECS does is provide a pattern to let everybody do much the same thing in their games. ECS brings that massive level of scalability to everybody instead of just the most hard code coders.

 

Unity is programmed using C# in a specialised Unity context. This gets even more Unityfied with ECS.
Love it or hate it, that is exactly how it'll stay. But that only goes as far as your interaction with the engine.

Everything else (ie most of your game code) can employ all the religious and sacred programming practises for C# you'd care to look up on the internet. Warning though: probably make your game slower.

And I'm OK with all of that.

 

Programming language are just enforced pattern and practice anyway. The are monolithic in their approach and don't allow for multi view of a problem.

I'm a bad programmer, for 20-10years, getter and setter makes code unreadable, ugh!

As a designer first, good code to me is code that get sh*t done, that allow to iterate fast as design problem come, evolve and go. Elegant and performant™ code is the antithesis of that. It's only useful once things has been figure out.

Preaching my church!

There is the physics layer stuff already as a sneakpeak, but also that's the paradigm of klik and play, the game factory, multimedia fusion, construct 1 and 2 ... ad it's a mess. I had a similar idea when I was hating on programming the casio, but you realize quickly:
- it grew exponentially very fast
- it's hard to read
- it need multidimensional matrices to be actually representative of all the interactions, but we can already lose track with simple system that has 2 dimensions (ie only two interactions per objects)
- it's sparse yet you have have to consider every permutation of dimensions.
- It's unwieldy.

IN design space there is the QFD matrix method as an example of how incredibly clunky it is as a practice. https://en.wikipedia.org/wiki/Quality_function_deployment
I'm still using it mentally for local operation, but it's incomplete. Don't show it to some producers let you sabotage a project. Causal loop is better (it's also similar to Joris Dormans excellant machination model) https://en.wikipedia.org/wiki/Causal_loop_diagram Still suffer from spaghetti, but you can learn to quickly detect pattern of behavior and diagnostic them early.

We have'nt had a breakthrough in representing interaction yet.

 

Best practices always originate from a specific context of some type. Personally I hate the term because it's most often used by developers trying to win an argument they are losing or clueless manager types., Who invariably when they realize they don't have a freaking clue about what they are talking about, fall back to claiming that they are of course right because everyone knows it's a best practice.

 

I agree 'Best Practices' are just styles like the decor in architecture and I think the real subject here is architecture or frameworks/scaffolding that allows great game architecture to be built.

 

Or are Linux users who won't upgrade until there is an official Linux editor..

 

Look at this spaghetti code from the networking part of the engine https://github.com/jamesjlinden/uni...ster/UnityEngine.Networking/NetworkManager.cs I like Unity but it could be much better in some areas

 

That's not good code at all, even in a Unity context. I'm glad it's depreciated and will be removed. Unity are doing a new networking library.

 

Everything can be better. Welcome to software development. Good news is that the unet stuff is going away, it was a mess.

 

Yes it's a good thing they are getting rid of unet, hope they replace it with something better . Seeing bad code isn't new to me, just a bit frustrating at times.

 

Wow. I never ever saw someone mirror my thoughts on the subject as much as you have here. I just copied this to a couple programmer buddies.

I usually use the "junkyard engineer" metaphor instead of the auto mechanic metaphor, but I think yours might be better cuz the grease monkey image is brilliant.

+1 sir.