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

Were you seriously expecting quality code to come from a decompiler? Below is a link to the original source on the official repository. If we're going to make statements about code quality we need to use the original code and not the results of a program converting CIL into C#.

https://bitbucket.org/Unity-Technol...anager.cs?at=5.3&fileviewer=file-view-default

 

Thats true for the code monkeys, but you cant make a solid large complex software with only monkeys, you need one or more lead developers or system architects.

 

Honestly, I think "system architecture" is usually little more than hubris and ego. If you understand the consequences in a well written method or function, you can design a large system well.

The difference at high level is human organization and coordination, which is really a different/non technical skill set.

 

No, writing a well defined method is trivial conpared to design a solid domain and software

 

You deeply misunderstand.

The thought process that underlies all code is analysis. As author you are constantly analyzing a problem and asserting a process to solve that problem.

The analysis process involves breaking down a problem, and the assertion process involves expressing a solution both in terms of clear communication (variable naming, statement ordering, formatting) as well as robust practical process (the actual calculation, derivation, transformation, or transference of data).

The same process on a small scale applied to larger scale is architecture. Unfortunately, the actual "architect" position has less to do with this and tends to be more meetings, emails, presentation, etc. In terms of professional software architecture, a huge portion of this position has more to do with sales and pr than it does with actual engineering - as you spend a great deal of time advocating, convincing and selling your designs.

In this regard, architecture is indeed a very different beast, but it has less to do with the engineering side than it does with the public relations/sales aspect (as in selling both your engineers and your bosses on the competence of your design).

 

Yes, but the thought process to keep a system together is much greater than that of keeping a method together.
I wrote system architects though, you talk about solution architects.

 

Maybe we need a clearer definition of bad programming:

It could be that bad programming is:

• Code that looks great but does not work.
• Code that kind of works but has bugs and crashes.
• Code that works but is unreadable.
• Code that works looks good is readable but is so obtuse it's a nightmare to understand, debug and extend.
• Code that works looks OK but is built on a design pattern or architecture that makes it harder to expand upon.
• Code that works but does not conform to your coding style guidelines.
• Code that works but is built on the wrong design pattern/architecture for the problem domain.

 

Explain how or why, if you have your framework under control and know what is talking to what, that using public variables [in some cases] causes issues. I have not run into such a situation prior. I want to be aware of the counter argument when I go off on a rant

 

I call BS on you pal. You seem to have some lofty view of your skills but I recall you making a spaghetti nightmare to control pulling a trigger when 12 lines of code and a mecanim setup with Blend Trees would have done the trick. This backyard hotrod mechanic/code monkey could have completed such a system in 4 hours including the mecanim hand animations and their subsequent setup. I ain't impressed with you C# system architect types... lots of jargon, clunky solutions based on system architecture and not the Unity game engine, disdain for folks who don't give a damn for your vaunted .NET knowledge but understand the environment they are working in and use it effectively...just...not...impressed.

 

says the guy who cant show a screenshot of his "triple A" game.. haha

edit: "system architecture and not the Unity game engine" That doesnt even make any sense

 

Thats a good start on a list. I think maintainability is the key word. Most systems will reach a point were they are no longer trivial, then maintainability comes in

 

I actually just had a talk w/ a buddy about this. I think that gamdev and traditional software tends to have very, very different views of what "maintainability" means, because the software cycle is so different.

Most of the time, traditionally, only minor maintenance is done on a game post release, so "maintainability" in the traditional sense is much, much less valuable.

You work on a game for 6, 12, 24 months - then generally never make significant changes (minor patches). Enterprise software and stuff - you got software a decade or two old still being worked on. That really makes different priorities.

 

Yes but if game Devs did think about maintainability they could reuse alot of parts for their next game. For example our next game will use 100 procent of the code from our current game.

 

I like reading your rants. Have you ever considered doing YouTube?

Typically public is to be controlled because most of us don't have our frameworks under control or know what is talking to what. Most devs aren't smart enough or disciplined enough to keep this all in their head. So they end up using convention or systems to manage it.

The problem becomes that many devs aren't that good at writing systems. So the system they design to protect them self from common traps ends up more cumbersome and has a set of unique special traps of its own. Sometimes it becomes a case of cutting off a foot to prevent a stubbed toe.

 

Yea.... I come from that school of thought as well (old habits die hard). The practical reality is that in all my years of doing this, that almost never actually happens. We came close a few years back, but ultimately we ended up using only about 20% of a prior game framework, but the game was shelved before it launched (those were separate issues, but reusability got less and less). It's always the goal to write reusable code/tools/etc... but the platforms and tech change so fast that the practicality of quickly diminishes.

 

We started on 5.2 and are now on latest LTS and have a working branch with 2018.2 the core domain will survive alot longer than the assets. Good maintainability also comes with a good branching strategy

 

Sure, maintainabiliy is a breeze, necessity is the challenge. Specifics of projects often require different focus on the architecture, and changes to platforms and engines often produce redundancy.

 

I would say alot of programmers dont find maintainability a breeze, probably close to 95 or more procent when we talk Unity since most unity devs are novice to programming.

 

Fair enough. I have one of those memories that can photograph things on the fly and recall all relationships involved..for decades. And..funny you should ask about youtube. I took the cash I got from the enterprise programming job and bought a bunch of woodworking equipment, portable sawmil as I have megatons of free lumber in the forests around me, cameras, mixing board, good vocal mics, Line 6 guitar and tube amp.. I will be doing youtube/bitchute/realvideo, minds, gab.ai and cover game mechanics [not coding], art critique of modern art crap, trivium, quadrivium and metaphysics and their relationship to the current cowboys versus commies cultural warz, time lapse oil painting, custom wood carving and trying to get my huge rock opera crowd sourced and funded.. fun times ahead.. I ain't working for any more enterprise corporate BS where my hands are tied by lessors anymore. Sorry to hijack the thread..carry on.

 

Silly games you play. I have never, ever claimed I create AAA games.. that kind of BS is best left up to bloated egos such as you display often and stick your videos into every thread pretending such. Second..you basically commanded me to produce a screenshot of a VR UI in the middle of my workday and I refused to comply and called you out on your manners. Don't mess with me pal. You ain't got the base to play that gambit successfully. Third..based on your videos there is nothing you can do I cannot and I even have the art chops to do all the art and would have full body characters. However.I do alot of things you cannot do and never will be able to match my skill level at,. Think about this the next time you want to attempt troll waltzing me around the forum dance floor using bogus setups or refer to your fellow developers as code monkeys. Your ivory tower is looking like a basement apartment from my POV.

 

I was going to comment on those 3 shots I saw from a forest you did for a mobile game, but for the sake of good tone at the forum I will not.

 

Good for you. What a fine upstanding and moral denizen you are. Your ability to wield a charientism is unsurpassed. Since II have never made a mobile game with a forest you must be talking about my reproduction of the famous Tail of The Dragon run in North Carolinas about 40 minutes from here.. This thread was about that and has screenshots.. https://forum.unity.com/threads/best-replacement-for-unity-terrain.409810/page-3 from a section of the 21 km run..
Now to continue to have good tone at the forum you might consider not calling folks code monkeys as though you are some elite coder...because you aren't. Carry on.

 

You went apeshit in some thread about VR UI's or something, since then I dont care what you have to say, just a unprofessional hobbyist in my eyes. And you just keep on adding grist to my mill (Funny thing, there is a saying in Swedish to add water on ones mill, didn't know there was a English equivalent to it)

 

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

(to pick only few)

This for sure is not promoting any good practice, in any area. Saying alone programming practice.
That looks really bad on Unity side.

We all go with emotion from time to time, but lets try keep it civil and not call each other.

 

Dont include me in that list, I just defend myself.

 

By tossing out general insults such as code monkey and promulgating that any cyber team needs some distinguished head honcho such as yerself to guide them through their idiocies that inevitably place you at the top of the food chain. Heh.. good one. I could give a damn what you post otherwise.

 

Gentlemen, gentlemen, let's calm down and avoid the inevitable thread lock incoming.

I can completely see the epic @AndersMalmgren vs @ippdev throwdown. There aren't two forum regulars more diametrically opposite on this board. But let's try to keep it civil.

 

I think this statement is wrong, you should ideally be taking a framework/toolkit approach to games development, a lot of the metagame elements are repeated between games e.g. Menu, Controllers, NPCs, Dialogue Systems, Inventory Systems, Loot Box Systems, Particle Effects, Doors, Models, Textures, Trees.

Or if you look at how AAA studios re-use assets and engines across a set of games.

However, with Unity's almost ready sandbox and out of the box components small games can be thrown together with very little code.

This is a bad habit or practice as every time you make a game you could spend a little more time to turn aspects of that game into a re-usable framework that will make your next game easier and faster to produce.

After all,
A bad craftsperson blames their tools.
A great craftsperson makes their own tools.

 

Incorrect. I entered a thread with a casual comment that I used a HUD for my UI that stuck to the HMD. You demanded a screenshot and inferred this was entirely bogus to do so and had no utility. You were upbraided for your anal retentive "my way or the highway" approach by other posters in that thread. I chimed in due to your bad manners and thinking you can demand anything from anybody over the internet or that they are obligated to provide some kind of proof of their statement. Homey don't play that. As to unprofessional hobbyist.. I have paid all my bills since 2010 doing Unity contracts. As to you on the other hand..

 

Well, the problem wit that is, it may be obvious for more experience dev. But not for starters. How Engine could explain new dev, what is a framework, and how to write it in reasonable manner. You can throw bunch of keywords. But if person is just learning moving cube, all information goes out of the board. Then what happens likely, after more testing and prototyping, the topic on good habits is forgotten. Hence is try to keep new dev on top of good path.

Unless Unity will bring popups with hints. That is good I think, for example when applications start. Some big software have hints at loading time, while you waiting. Or even at installation. Why not bring this in, to promote good things.

 

Unity could adopt a more toolkit/framework approach to the learning section linked to packages that provide these frameworks e.g. Do a learn UI section that is then re-used and adapted in other learning sections.

The aim would be to build up a toolkit of reusable elements, the thing is although Unity itself is becoming modular and assets allow re-usability of components it's not simple enough to build up your own library of re-usable tools and frameworks.

 

We wanted a flexible and completely customizable system AND a good workflow. My wife does all the item riggings and its important its user friendly even for a beginner.

 

Part of the thing though is that your "game design" side of your project is incredibly unlikely to require heavy iteration to do well. You're travelling across pretty well worn ground for the most part.

So there's two sides to 'code maintenance' one side is when the requirements are pretty stable and the goals are very well established. Here, the kind of work is mostly minor additions or small tweeks. A change request might come in for a slightly different variation.

As iterations get bigger and wider in scope, as "game design" and requirements get more experimental, changes to requirements are so much wider in scope that it almost requires a different kind of process.

Once the scope of change is big enough - it doesn't matter how "maintainable" the code is, the problems the code needs to solve have completely shifted.

@Arowx - this applies to what you're saying also.

I can build a screw driver. It might be a really flexible screwdriver - and maybe I can hack the screwdriver into being a S***ty hammer. But if the problem set changes to the point where I need a saw, all the time I made building my "screwhammer" is a waste... and chances are a screwhammer just kinda sucks at both.

 

Not true, we got new hand rigs with a better wristbone, she had to remake all of the 300+ rigs

edit: We could have just migrated to the new rig, but then we wouldnt take into account that we could make better riggings with the new more flexible wrist

 

That's kind of my point. If this were an analogy to code - you would tell the person who had to re-rig 300 rigs that they "should have made their rigs more maintainable"

 

Yeah well, in VR with stereoscopic vision the detail level is so high so its need very fine rigging detail. Hard to automate that process.

We were the first VR multiplayer shooter, and we are still breaking ground with alot of new systems all the time. Lastly it was weapon sway which was a controversy subject to VR gamers. https://www.reddit.com/r/Vive/comments/7oas9r/crazy_idea_weapon_sway/

 

But I think that this is how most game systems need to be on highly polished titles. Many very high polish games more like clockwork - many intricate pieces all perfectly working together.

The higher the detail level in a system, the less you can abstract out the parts (or at least, the less worthwhile it becomes).

What were some of your biggest rewrites or changes in the process?

 

I like this article by Juan Linietsky the founder of Godot Engine. His premise is games are about Feel and if you plan on finishing something don't get caught in the trap of over engineering - just make it work. I've spent way too much time in unity and unreal worrying about my code and not focusing on the feel of the game.

https://godotengine.org/article/how-actually-make-your-dream-game

 

Actually you get away with alot on desktop, things can float centimeters above what it should touch without you notice. But in VR (or on a 3D monitor) its very visible. In the same matter clipping stuff must be done much more elegant in VR. Not all clipping will work in desktop either, but its much more critical in VR. Another thing is scale. You wouldn't believe how much is off scale in games without you noticing. In VR you notice it right away.

Example of good clipping



Example of clipping that probably could need some fine tuning when you target VR

You mean in general or just that specific feature? We already had a system in place to addative control the items ontop of the physics syncing to the VR controllers so wasnt that much of a rewrite actually, in that case.

 

Its a balance, not designing at all is a one way street to distaser, as more and more systems need to work together you will run into problems if they were not designed well. On the other side of the coin you have over design which is not good either.

 

Ya shoulda just done what I suggested. It would need one rig and Mecanim blend tree setup and one component of maybe 12 lines for 10K guns and hands..left or right. Typical overwrought control sensibilities of an enterprise business platform architect and a lack of understanding of the Unity environment.

 

Buzzword king

 

Girls, girls, you're both pretty.

 

@ippdev
You can't blame a culture warz and participate in another one you have a lot of wisdom to partake, so no need to get pissed by people who just happen to be different. As long shot get done, I don't care whichever is right, many road lead to rome. BRB getting to rome.

 

When Unity was starting, SendMessage was standard game engine practice. Coding was split into two parts, like in UnReal now: a modifiable C++ backend, with designers using a simple, friendly scripting language (more like Unityscript). SendMessage was in the simple language. It's right at the level a talented technical artist/level-designer can pick up. It kind of still is.

I know people who used Torque around like 2010. When they were thinking of switching to Unity, it having SendMessage, same as Torque, helped them decide Unity was something they could work with.

 

Coming from an enterprise background of over a decade and a few years of light experience supporting Unity developers, I also found a lot of differences between game development and regular software development. I agree to a large degree with the post on the previous page by @neginfinity, although I do think he's lacking some nuance.

It's important to learn the "proper" way of doing things. Most rules/guidelines/conventions/frameworks/design philosophies etc have a specific purpose and are used to minimise or exclude certain categories of problems. It's important to master these solutions so that you know which solution applies to which category of problem. This allows you to choose for later projects which tools/frameworks/rules etc are absolutely necessary, and which solve categories of problems you'll never deal with so aren't worth the effort. So in a sense, you learn the rules just so you know when it's okay to break them.

A second point I don't see mentioned is that the scene appears to be the top of the hierarchy in Unity projects. Objects on the scene have their own internal logic and are added, organised and hooked into each other via the Unity UI. These objects, their internal logic and the way they're connected are not visible when debugging/discovering code. For common application programming this is not a problem, you may be able to know and discover each and every entry point in your application and traverse each possible code path. This allows you to design a proper architecture for the codebase, taking into consideration all relevant concerns for the product. Now I know you can do a lot in Unity to move logic out of the scene and keep most of it in an organised code-base, but the point does remain. To a certain extent, C# is used for "scripting" (let's say: code snippets added piecemeal to objects) rather than programming (an organised code base where all entry points and code paths are transparent and program flow is structured into some kind of hierarchy). The scripting approach can easily lead to bad design (or even a complete lack of design) for a code-base. It can also lead to spaghetti code, causing unexpected behaviours and making things hard to debug since components/scripts may indirectly affect each other without having any obvious relationship.

Then there's the fact that Unity does most of the threading for you (although many platforms also take care of this for the user to some extent). Users may be unaware of what's going on in their application in the background threading-wise. They may think they're doing things right because things appear to work, then they create a mess of threading errors that only manifest in very specific situations, have fun debugging that. To be fair, threading is an advanced topic that leads to confusion on a lot of platforms. I get the feeling a lot of Unity programmers create enitre apps without really having a clue about what's going on threading wise, that *can* be dangerous.

That and the fact that some language features (like namespaces) were unavailable or not working properly for a long time. Unity does seem to have come a long way in recent years though.

 

I never heard that.
It must be too much surfing on the net LOL

 

Never heard what?

I feel like that big middle para is what OOP people call "Dependency Injection". They give the same criticisms: your code is so uncluttered, but nowhere does it say what links to what - you're stuck looking through XML to figure it out (or, in Unity, Inspecting scene objects).

 

This is why the Jobs system exists. It's to make thread safe code easier to write.