What I find wrong with Unity Developers

Nah. The way I see it those who are easily scared away had no chance to begin with.

Realizing that you usually need teams is part of being competent.

 

On a side note, if I were to criticize Unity's API I'll probably begin with its general disregard of OOP and other common design principles.

It seems they have a bad habit of just copy pasting code around rather than properly organize them into a class hierarchy.

For instance, both SphereCollider and CapsuleCollider have center and radius properties, but they are not related to each other, so making it cumbersome to write common logic depending on them. And the IMGUI API is a complete mess, with GUI and GUILayout each duplicating most of the functionalities of the other, which could have been easily solved by following proper design principles.

And even though Unity provides a quite sizable API, it contains only a handful interfaces, most of which are simple event handlers in the UI namespace. Even though number of interfaces is not a good measure of code quality, such extreme ratio usually indicates insufficient abstraction in design, especially when it comes to a platform type API like Unity.

And another nuisance is that it does not follow the common C# convention in its naming of class properties. In the documentation, it refers properties as 'variables' which are not exactly the same concepts, and name them like they are some local variables, without capitalizing the first letters.

I'm not denying the usefulness of Unity API. But even though being quite functional, it deviates quite far from commonly recognized design principles, so it has a room to improve in that regard.

 

I'm speaking from experience, that's not true, many people just aren't cowboy who like to shoot in the wild (which I'm kinda oups). Gave them the proper saddle and they might be the most straight performer of the art, I have introduce many of these people who are now ahead of me in the domain I introduced them.

That's why you have school and some people simply can't start with this type of framing. I learn on myself, true, I'm sure many of you do, but a vast majority of people need a bit more push, especially when held back by perception of socio economic status or lack of role model.

 

We already have very good learning resources and a section of the forum dedicated to beginners. About the only ways left to improve the situation for beginners might be to have interactive tutorials built into Unity itself and having beginner modes for the user interface.

 

Not sure what your problem is with coroutines. Everything in every programming language or framework is misused by someone. Doesn't mean it's a bad feature.

Coroutines were provided to developers for the purpose of preforming asyncronous programming on the main UnityEngine thread. Coroutines allow you to preserve context in executing code and schedule continuations.

In fact, if you examine how the C# compiler translates async/await code at compile time you'll see that the result is something very similar to Unity coroutines and the main goal of both are the same. Though it's not implemented as an IEnumerator but instead a much more complex type is composed capturing context, slicing the continuations up and building a a state machine that implements IAsyncStateMachine.

https://weblogs.asp.net/dixin/understanding-c-sharp-async-await-1-compilation

The way to do that in .NET/C# would often be Interfaces. There is a reason though for Unity not implementing any interfaces. They have written a hack for equality comparison that would actually break if you were to reference Unity components as an implemented interface.

See this Unity blog post: https://blogs.unity3d.com/2014/05/16/custom-operator-should-we-keep-it/

 

That is the dessert after a spaghetti dinner..

 

I believe this doesn't apply to the case I mentioned, since it's not directly related to any runtime behaviour. I can understand, for instance, if I cannot declare a property of IRadialCollider (if such an interface existed) which holds an instance of SphereCollider, and expect this information to survive after the deserialization process.

However, it doesn't really prevent both SphereCollider and CapsuleCollider from implementing IRadialCollider, so that we can write a method that takes an argument of the latter type, for instance, so that it can calculate a collider radius without much hassle.

And as to the case of GUI and GUILayout, I cannot really see any reason other than lack of familiarity with C#/OOP practice to write so much duplicated code between them, as they are not even an runtime object that has some native peer.

 

It wasn't about having a property that is an interface. It is about having any UnityEngine component implement an interface. They CANNOT do that due to the issue and reason, which is to be honest a hack, described in the blog post I linked. They override the equivalence comparison for UnityEngine.Object types and due to how the C# language works this behavior is subverted when you reference an object as an interface.

You can refer to this: https://stackoverflow.com/questions...ide-the-equals-operator-for-an-interface-in-c as for the behavior of equivalence operators and interfaces. If Unity were to implement interfaces on their engine types they would break the ability to null check components when they have been "destroyed".

This is how things become "null" in Unity. If you've ever wondered as a .NET developer how the Unity engine can magically make references you hold null when they are destroyed elsewhere this is how. Implementing interfaces breaks that expectation for the user since you can't rely on == anymore.

Unity can't implement interfaces because then they'd have to tell all their users to never ever reference any of their types as any implemented interfaces. It's just not reasonable. It's baggage design from a long time ago that sucks but there is no easy fix at the moment.

 

Thanks for the clarification. But it seems that they don't follow the rule anymore themselves, as many of the classes in UI namespace for example, implements quite many interfaces despite their extending MonoBehaviour:

As noted in the link you posted, probably they are now second guessing their initial decision to overload == operator, and maybe even decided that it was a mistake.

Anyway, I don't think it to be too much of a problem if they have to introduce another such quirk when they haven't really been consistent about it themselves, and the platform is already full of such peculiar Unity specific rules.

At any rate, it doesn't apply to the problem with GUI/GUILayout since they are not game objects.

 

The UI is very new, and open source, and they may have had internal plans to depart from the equivalence operator hack. In fact I believe that was going to happen in 5.x but never materialized. They definitely were thinking about it as you can see from that blog post. I can't find a source for this claim though that it was in the works.

Only a Unity Technologies developer could chime in and let us know why the new UI implement interfaces which would break the null checking if referenced as those interfaces. I don't know.

 

Or anyone that's actually worked with it.

The UI system (or at least the part that uses interfaces) is pure C#. There is no underlying C++ object to link to. Thus you can hand around pure interfaces as much as you like.

Although in reality the interfaces are just markers. They aren't used to hold references or pass them around. So they never need to be null checked.

There is another way, although it's slightly painful.

Code (CSharp):

1. public Interface IMonoBehaviour {
2.     bool isDestroyed {get;}
3.     // Other stuff
4. }
5.  
6. public class MonoBehaviour : IMonoBehaviour {
7.     bool isDestroyed {get { return (this);}}
8. }

This sort of behaviour could give Unity devs time to get used to the concept, with the eventual idea of killing the equals override. Ou could even implement it yourself.

But... And this is a big but... I'm not sure that this really is a good idea. While its occasionally painful, in most contexts the override is useful. For example:

Code (CSharp):

1. // Currently
2. if (myGameObject ) ...
3.  
4. // Without the override
5. if (myGameObject != null && !myGameObject.isDestroyed) ...

 

//opinion.
Finding the proper saddle is their job and not mine/unity's.
Nowadays there's sea of information at your fingertips, and things are ALREADY very easy to get started with, so they still need encouragement and a better saddle, their gamedev career is not meant to happen. They're supposed to make the first step.

Erm. Unity implements interfaces on multiple components, once in a blue moon I also end up with "IInteractive" on my objects, plus IIRC it is even possible to use GetComponent<InterfaceClass>().

So, you're incorrect/mistaken.

Interfaces can be used and are supported. Now, REFERENCES to the interfaces won't serialize, but as long as you don't attempt to use interfaces for public fields in inspector (you can still make it work with custom editors), you're fine.

 

The blog I linked from Unity Technologies explains in depth the issues and problems they currently face implementing interfaces on engine components. The stackoverflow question I linked described the semantics of == even when overridden when the rhs or lhs Types are references as interfaces. I cannot really say much else. I use interfaces all the time all day long. I was only trying to point out why they rarely ever use them on engine components.

Using GetComponent has nothing to do with the fact that Unity is overriding the behavior of the equivalence operator to allow for null checking which if the object compared as any of its implemented interfaces that behavior will be broken.

 

I am aware of unity overriding operator== (I saw this article many times), but I see no deep or significant issue here.
Unity blog post does not mention anything related to interfaces. And stackoverflow thread mentions nothing related to unity. As far as I can tell the reason for not using interfaces is largely historical.

 

But IMGUI is functional. It's not OOP, nor is it trying to be. Also if you want to see an example of Unity trying to be OOP with IMGUI, dig in to UnityEditorInternal for ReorderableLists... and then realize it's incompatible with PropertyDrawers and only can be made using custom editors.

 

I actually like IMGUI a lot. While the cleanest OOP way to work with widgets is still Qt (in my opinion), the IMGUI offers a very clean/flexible way of creating highly dynamic and very flexible layouts.

 

I was just reacting because I don't see a reason to shut down the initiative or the plea altogether. Also most tutorial are terrible for anyone who don't have already a background on tech stuff, coming from a background where computer were a luxuries for a very long time (I only got in because I'm a damn nerd you used millimeter paper to emulate screen and draws pixel art 30 years ago, which I did for 10 years before accessing a computer at schools, essentially using it against its purpose) I totally understand why someone can be intimidated.

While I currently have access to internet, for a long time I had to transit 30mn to get a connection at a free spot with super slow connection. Also most tutorial don't teach you to scale from experiment to full scale game, so a lot of stuff are missing, and there is a lot of specific vernacular you must understand just to start a tutorial, and then most tut are in english, that's another BIG barrier, the entire world isn't speaking in english.

I have met these kind of hurdle trying to help people who wanted in, which you don't suspect when you are deep in tech culture, a lot of reflex we have are actually complex culture ritual when you don't know any of them. And since unity is all about democratization already, I would say they already dedicate themselves to that ...

 

My opinion on the matter has no weight, and same applies to yours. Unity will do what unity will do. I can say what I think (and so do you) but in the end the decision is unity's.

I personally see catering to beginners as a waste of resources. They have a lot of other products. Beginner-focused software often focuses on less efficient workflow. In general, I'd say there's too much beginner-focused material, and not enough material for intermediate or advanced level. Since being a beginner is a temporary phase anyway, there's not much point on concentrating on it for too long.

Look, I wrote my first serious program in a library on paper (20 or 30 pages of code), without computer, compiler or an internet using books for a reference. Back then youtube (and its bazillion tutorials) didn't exist. By default I expect any decent developer to be capable of doing the same thing.

So when people say that with all the information they have access to right now, they somehow find things HARD, I can only see it as them being spoiled/too pampered and unwilling to put work into it.

Maybe I'm old fashioned, but I think that to achieve something you'll have to work on it, and not expect everything to be presented on a silver platter. Game development, programming, and even art after all implies that an individual needs some sort of curiosity, stubborness, and have some kind of inquisitive spirit. Someone who is easily discouraged/scared off in most cases does not have what it takes.

Don't get me wrong I value well compiled information, and it should be available, but when people start talking about making unity more user friendly, well, excuse me, this is already at the level you're supposed to be able to handle by default.

At least that's the way I see it.

 

I guess what you meant was 'procedural' rather than 'functional', because the latter usually means things like Haskell or Scala. And you are right if I understood you correctly that it is indeed procedural API, but I believe there's no real reason why it has to be that way.

But firstly to avoid confusion, I actually believe that such an API like GUI can very well be procedural because it's just a low level facade for drawing various UI components and it doesn't represent any object with state.

However, if you need another class that does basically the same thing in a very slightly different manner, and you decide to copy paste source of the former to create a new one, it's simply a lousy way to design any software.

It seems that they were not sure how to generalize over classes which have similar methods with different type of arguments, which actually can be solved very easily if they understood some common OOP design approach.

The drawback of such a mistake might not be immediately felt if you are not the one who have to maintain the duplicated codebase. But if you try to build some high level API on top of such a mess, like I did, you might wish they had designed it in a proper manner.

For instance, I once made a prototype of high level UI API around IMGUI, so that I could use it like more popular GUI toolkits that supports stateful components.

It went quite well, except for the fact that I had to duplicate large portions of my code for every single component type because of the unnecessary dichotomy between GUI and GUILayout. In the end, I decided to abandon the latter all together and came up with my own implementation of layout API to workaround the problem.

Even though it worked decently, it shows exactly the type of problems you might expect when the underlying API wasn't properly designed.

 

Probably, since computer scientists love creating terminology with only mildly nuanced meanings.

I'm struggling to understand why you would even care about GUILayout when it's just a higher level API on top of GUI as it is. From there it just sounds like self-induced suffering, because of course it's going to be painful to wrap one paradigm in another.

That's only an issue if you're mixing paradigms though. You should never have to rewrite functions verbatim if it's being done procedurally.

 

That's the thing you and me are crazy peoples, lol, now I'm surrounding with other type of peoples, they are capable but with different expectation, lol That's why I get on forums, to get a bit of that crazyness back lol or I'll get insane by "normality"

 

Actually, I tried not to dwell on your mistake too much because I thought it was not important to the topic. But as you brought it up again, I'd like to point out that functional programming and procedural programming are two completely different things.

If you say they are different only in subtle nuances, it's like arguing Witcher 3 and Counter Strike are essentially the same kind of games, because concepts like FPS or RPG are mere words that the game industry loves making to get more attention.

GUILaout is not a higher level abstraction over GUI class, if you understand 'abstraction' in the same sense that it's understood in software engineering. Rather, it's just a duplicated version of the latter with only a slight difference in its implementation.

The reason why I wanted to create a (real) high level wrapper on top of IMGUI was that such method of drawing GUI elements are suitable for certain type of usage.

Here's a code that I wrote using my wrapper API which was built on top of IMGUI to allow Java Swing like approach when building complex GUI:

Code (CSharp):

1. public class MainMenu : Box
2. {
3.     public MainMenu(IUIManager manager) : base(
4.         new BoxLayout(BoxLayout.BoxOrientation.Vertical), manager)
5.     {
6.     }
7.  
8.     protected override void Initialize()
9.     {
10.         base.Initialize();
11.  
12.         Text = "Main Menu";
13.  
14.         var btnQuit = new Button(Manager)
15.         {
16.             Text = "Quit to desktop",
17.             Padding = new RectOffset(30, 30, 10, 10),
18.             Color = UnityEngine.Color.red
19.         };
20.  
21.         var btnDismiss = new Button(Manager)
22.         {
23.             Text = "Return to game",
24.             Padding = new RectOffset(30, 30, 10, 10)
25.         };
26.  
27.         Add(btnQuit);
28.         Add(btnDismiss);
29.  
30.         this.Pack();
31.         this.CenterOnScreen();
32.  
33.         btnQuit.Clicked
34.             .Subscribe(_ => OnQuit())
35.             .AddTo(this);
36.  
37.         btnDismiss.Clicked
38.             .Subscribe(_ => OnDismiss())
39.             .AddTo(this);
40.     }
41. }

It's easier that way, for instance, if you plan to allow your GUI elements to be extended later, or you want to dynamically add or remove components.

Actually, it's a quite common approach that many popular GUI toolkits take. They often provide components API that is a high level OOP layer on top of a lower level procedural API which deals with actual painting or mapping with native peers, and etc.

It was not I that decided to copy & paste most of the functionalities in GUI class to create GUILayout. A procedural style neither mandates nor prevents such duplications.

 

The problem I have is that function and procedure mean the same thing, but then they use the mathematics function to make functional programming. Add in that no one ever uses procedure anymore, so the first word that comes to mind is function.

But every function of GUILayout is different from GUI. Even if we assume the main structure of each function is identical (like it doesn't simply get a rect then call the same GUI element), it's still bound to be that most of the lines of code are modified.

Did I say abstraction? The whole point of the layout classes is that it's all of the regular GUI widgets, but now auto-magically handling layout.

 

When we say some piece of code is written in an 'object oriented style', we don't simply mean that it uses some sort of 'objects' like data structures, for instance. Rather, we imply that the code is following such a principle that utilizes polymorphism to model a problem domain.

The same can be said about 'functional programming'. While it's true that a code can contain functions without actually following the functional paradigm, when we say some API is written in 'functional style', it almost always means that it actually does.

They are only different in a single aspect, that is how to determine target bounds of the components. And there are many well known approaches to generalize such a minor difference without copy pasting the whole source code.

I'm not very knowledgeable of Unity's history. But if GUILayout was introduced later as an after thought, I might understand potential hesitation about changing the existing API too much. But even if it was the case, it doesn't really change the fact that the whole dichotomy of GUI and GUILayout is a pretty lousy design.

You said that GUILayout was a "higher level API on top of GUI" in your previous post, and when people say something is 'higher level' than something else in programming, it usually means that it's higher in abstraction level, not that it has more features or more difficult to learn, and etc.

By the way, I'm not intending to make it a big deal about the GUI / GUILayout problem, as now I don't even use them anymore. It's just that I found the Unity API to be somewhat lacking in design quality, and that particular API happens to be one of the few examples that I personally had trouble with.

 

Not only that, but people often confuse "using Unity" with "Game Development". There are tons of beginner/simple to use game development tools (GameSalad, GameMaker, etc...). If someone is completely new, and want to start easy/simple, they should start with those types of tools.

 

Sorry and you're who? Why should anyone listen to your opinions? You've done what?

Why do they affect you? Perhaps make your games if it's so "quick and easy" and stop letting other people bring you to ranting on a forum.

 

No. The way I see it. That's default normal minimum expected proficiency level.

In my experience, it is not a good idea to get hung up on precise technical definitions of things. If you understand difference with procedural/functional programming, using objects and using OOP, etc, that's all good, but rather than correcting people about incorrect use of term, a better idea would be to ignore it, try to understand the actual point the person made, and respond to that point.

Arguing about perfect definitions results in semantic and dictionary arguments that go on and on, with responses being bigger and bigger while utlitmately resulting in nothing useful. Talking about definitions is all about what the person said. The important part is not what they said, but what they meant.

Just a few cents.

 

In my initial reply to @RockoDyne's post, that 'correction' amounted to a single sentence, which I made to avoid confusion. After that, all I said about definitions was to reply to his or her refutations.

It's amusing to see that you had to single out that part which was quite insignificant and irrelevant to the topic, only to lecture me how I better not nitpicking others and stay on topic

 

It was a single sentence used for example.

I didn't feel like going through every sentence in the post writing detailed analysis of every single one of them, sorting them by relevancy to the argument, backing it with 50 walls of text, bunch of links etc.

I prefer human communication.

 

@RobAnthem Coroutines makes code unreadible? Sorry, that invalidates your entire post.
Coroutines are what makes code readable, for example this is code from our game

Code (CSharp):

1.         private IEnumerator ShowSwitchTeamConfirm()
2.         {
3.             var confirm = ShowConfirm(AvatarController.Instance.IsDead() ? "Switch team?" : "You are not dead, you will lose a life. Continue?");
4.             yield return confirm;
5.  
6.             if (confirm.Result == ConfirmResult.OK)
7.                 GameMode.Instance.RequestSwitchTeam(Networking.PrimarySocket.Me.NetworkId, false);
8.         }

Imagine doing this without Coroutines, ShowConfirm spawns a new UI Panel that we want to wait for until player chooses an action. Mini workflows like these are a breeze with CR.

edit: I wish UI event handlers automatically worked with methods returning IEnumertors though. Its very ugly needing todo StartCoroutine everywhere

 

Then why don't you just move along and heed your own advice about staying on topic?

Even I don't agree with @RockoDyne, we were at least discussing about something relevant to the topic, before you came in with your 'two cents'.

 

I agree that polymorphism is important in a API like Unity, like your collider example. But Its far from the best solution in your everyday life as a game programmer. We lean to more and more strategy patterns over OOP in our game. Here is an example from our game

Lets say you have a Grenade base glass, you then have a FragGrenade and a SmokeGrenade subclass implementation of these. Now you want a C4 bomb that can explode just like the FragGrenade that has zero Grenade logic

We instead did it with components (Which is a strategy pattern). Example would then be a grenade component. And then a component that makes the grenade explode and the behavior that emit smoke would be in a separate component. The Grenade can then use pub/sub or GetComponent to communicate with the dependent components. Alot more solid/flexible code in many cases

 

I think your example is simply a case where 'composition over inheritance' principle is implemented on the components level. It seems that the approach is actually what Unity recommends in general, but it can also be implemented using classes just as well.

But I do agree that pure OOP is not the silver bullet, especially when developing games on Unity. Personally though, I wish Unity could adopt more of OOP, because as long as it relies on C# as its primary scripting language, it'd help if it also embraces the most commonly followed design principles or conventions among the existing C# programmers, rather than introducing more quirks that only matter on this specific platform.

 

@mysticfall Yeah, Like I said, polymorphism is very important in SDK level stuff, OOP in your domain, not so much. I mean you should combine them offcourse. But be very strict abotu when you use OOP

 

Well, my advice wasn't about "staying on topic".

 

Well, if you insist that there's a world of differences between "staying on topic" and "talk about actual point".

Either way, I don't really care and I don't think it has anything to do with the topic or point of this thread either.

 

My recommendation was not to concentrate too much on precise technical definition of something (programmers in general are very prone to this), and try to understand the point the other person is making. Instead of arguing over precise definition of what they say, it is a good idea to attempt to understand what they mean. Dictionary wars and semantic arguments quickly become recursive and usually result in nothing useful, but when people look past the precise definitions, it is the area where it is possible to actually learn something from the exchange.

As for the actual topic, the original poster, as far as I can tell, has run away after posting their "sample code" at the beginning of page #2. So it is unclear what the topic is even about anymore.

 

Ok, let's see what I really did regarding "arguing about perfect definitions" and "correcting people" as you said.

This was the post that started the conversation :

So, I replied as follows :

So, you had to give me your 'two cents' and all those lectures because what I wrote above was a needless nitpicking with precise technical definitions? Oh, come on...

Who's really trying to 'correct people' with things that have nothing to do with the actual points here?

 

I think @neginfinity has a point though, it's really common for programmers to nitpick about specific definition (we deal with specificity all day long after all). Although, I side with @mysticfall that functional and procedural really are meaningfully different.

I will say that IMGUI is an interesting case study though. In terms of interface, I love it on a theoretical level. There's something incredibly appealing about the direct connection between statement (as verb/function) and presentation.

When I compare IMGUI to something like this:

Code (CSharp):

1.  
2.         var btnDismiss = new Button(Manager)
3.         {
4.             Text = "Return to game",
5.             Padding = new RectOffset(30, 30, 10, 10)
6.         };
7.  
8.         Add(btnQuit);
9.         Add(btnDismiss);
10.  
11.         this.Pack();
12.         this.CenterOnScreen();
13.  
14.  

I would strongly prefer something like IMGUI, the problem being "Pack()" and "CenterOfScreen()" which deal with too much hidden state. The more hidden state involved, the more effort needed to keep clarity on what the state is and how it's defined and when it changes.

On the other hand, IMGUI is a total nightmare to use in practice. Was that nightmare caused by the fully procedural interface? No. Did it perhaps exacerbate the problems? Yes.

UGUI is probably the set of API in Unity that I detest the most. It also was plagued by deprecation and changes. I strongly disagree with a large number of their design decisions. I've cursed endlessly at UGUI while working with it, and run into countless, "how can such a simple task be so hard?!". Is UGUI better than IMGUI?

Well, the drag and drop experience kicks ass. But from a pure code standpoint? I'd rather suffer through IMGUI than suffer more in UGUI if purely populated via code. UGUI's advantage is the drag and drop wysiwyg stuff and the built in unity serialization that goes with that.

UI is really it's own discipline, and it's very hard to get a good UI API 'right'.

 

UI is simple, Knockout and Caliburn Micro are doing it correctly

 

In my opinion, both stateful and stateless UI implementation have their respective advantages and disadvantages. While it could be more straightforward (and even appealing, as you said) to construct a UI using a stateless API like IMGUI, but it might make it more complicated if you want to allow extending, or dynamically changing UI elements, for instance.

(Of course it's at least doable with IMGUI, but it usually involves a lot of boiler plate code like conditional variables, passing coordinates around, defining template methods for some specific point in execution, and etc.)

By the way, Pack() and CenterOnScreen() methods in my example were just some extension methods that I couldn't decide if they deserve to be declared on instance level because they are too simple:

Code (CSharp):

1. {
2.     public interface ILayoutRegion : IBounded
3.     {
4.         IContainer Parent { get; set; }
5.  
6.         object LayoutConstraints { get; set; }
7.  
8.         Vector2 MinimumSize { get; }
9.  
10.         Vector2 PreferredSize { get; }
11.  
12.         RectOffset Padding { get; set; }
13.  
14.         RectOffset Margin { get; set; }
15.     }
16.  
17.     public static class LayoutRegionExtensions
18.     {
19.         public static void Pack(this ILayoutRegion region)
20.         {
21.             region.Size = region.PreferredSize;
22.         }
23.  
24.         public static void CenterOnScreen(this ILayoutRegion region)
25.         {
26.             var size = region.Size;
27.  
28.             var x = (Screen.width - size.x) / 2;
29.             var y = (Screen.height - size.y) / 2;
30.  
31.             region.Position = new Vector2(x, y);
32.         }
33.     }
34. }

I partly share your frustration with uGUI, and actually I'm trying to write another wrapper around that API even though it shouldn't be needed because it's already a stateful API.

As you noted, I found it to be quite cumbersome to create a code driven UI with the API, and its prefab based workflow doesn't seem to go well with its lacking any styling / theming feature. And even though I tend to use a lot of interfaces in my own code, I don't find it to be very useful that the components themselves implementing a whole bunch of event handling interfaces, like those uGUI components do.

Unlike with IMGUI, I haven't yet found a satisfactory approach for uGUI to cover most of its warts. But like you said, it's quite painful as it is to work with uGUI currently, especially when you need to populate UI elements from code, so I'm intending to spend sometime in trying to find one that works for me.

 

If you mean JS knockout, I do tend to like the mvvm approach. I wrote a pretty sick javascript lib once to do a mixture between D3 and knockout that got rid of html entirely.

I think the trick with either of these though is that they were built on top of HTML/CSS which was absolutely a revolutionary development. In other words, the genius there isn't in the libs on top - the genius was under the hood.

HTML/CSS was really a revolution. I'm shocked that design by committee ended up producing something as solid as it ended up being.

 

They really do a piss poor job of converting between coordinate spaces and dealing with placement. Anchor agnostic placement and stuff is eye-rollingly painful.

The API was obviously designed around the inspector and drag and drop usage, and everything was built around facilitating that. They did a good job, it's really a pleasure to work with visually... but man... that API.

 

Caliburn Micro is a MVVM library for xaml based applications. It's conventioned based and also have their own in my optionen better implementation of Coroutibes.

MVVM can be applied on any UI engine flexible enough

 

I used MVVM in Unity without any api for a while. You need almost nothing to use an MVVM based approach as long as you aren't being pedantic about definition.

I must admit, I do really like MVVM for UI stuff. It's a very good implementation strategy.

 

I agree to an extent but I think you're being a bit too harsh, games development is one of the most difficult practicle applications out there involving a multitude of different skill sets. Compounded of course by being an indie which you're generally jack of all trades master of none..

It really depends on what you want to get out of it, I was happy for years dicking around with game engines / frameworks (finding "interesting" problems) exploring the nitty gritty of how it all comes together and how you should do X.. Which automatically increases background knowledge, but if you want to make something within a reasonable timescale you're adding years on by going down that route.. I thought the point of all these pre-made "indie" engines was to avoid all of this?

I was building websites and messing around with Click n' play (ahh fond memories), coding with ZX speccies etc. decades ago so yeah I get that it's possible even without the internet and it shouldn't automatically be handed to you on a platter but on the flip side whilst some things have become easier (far easier) others have become ridiculously more complex to the point you need hundreds of engineers involved (like most major engines).

I remember the uproar after I said coding an RPG is "trivial", which to me it is.. Time consuming? Yes, complex? Not really.. Some of the issues you've mentioned with UE, I think they're simple as hell to sort out, here's the thing though what's simple to you / me doesn't automatically make it simple to someone else. IMO to advance you have to be very open and it's tough to be so on the internet where some like to be a jackass for the sake of it.

So in that vain I'll be straight up, some of the stuff you've helped other people with.. Didn't really understand what you was talking about, I've bounced back and forth between so many applications doing so many things (some times I won't open the editor for a month whilst cracking on with art) I'll of forgotten some of the basics.. For someone who has coded for the amount of years, worked on complex games, worked on complex projects and worked with Unity for a long time, I've looked up Unity learn one too many times.

Although fortunatley it's not a massive issue, the major advantage of experience is I can pick things up quickly and move extremely fast compared to the learning phase.. It allows you to make educated guesses, it doesn't automatically make every topic you'll come across easy or in some cases even understandable..

When it boils down to it, I agree you can't be afraid to ask and you have to be stubborn as hell. Whether you're a beginner / intermediate / advanced it doesn't matter we are all in the same boat, just trying to tackle different issues.

TLDR;

We are after all human..

 

My first ever taste in making games (making sequels to Operation Overkill ), and my first introduction to conditional If Else statements

 

I've noticed you seem to have mellowed out a lot recently. Good to see!

Anyway great post man.

 

30 years ago, like I said I didn't have a computer, but I was always buying those books with "basic listing" you had to type, using observation and gleaning tangential explanation from these books, I inferred how to program, by tracking variable (using color coded pencil) and loop to know how it all works. I never since then stop reading code. I have tons of code written by now.

Result I'm still S*** at it while other people I introduced to the practice are now making a living having their own company. I just keep at it because I need it, but there is a threshold at which I lost proficiency, no tut or youtube have compensate the slow grind that generally ensue. Also I don't know when to quit.

Not everybody are made of the same cloth.

When I'm saying accessibility, it's much more than cultural performance. It's not about dumbing down either, it's about allowing other to realize they can.

 

I think unity had the right idea maybe but it never materialized. They make the engine the asset store provides the missing pieces they don't provide. But the engine started too basic I think and then lots of stuff got added on top to fast. Not to mention they built it on top of mono. Which I think had a lot to do with its design and traditional lack of oop design. And then what they did provide for the API didn't give enough control to the more advanced devs. So somewhere they forgot their vision.

I also think there is too much beginner material. And it's advertised incorrectly. As in "want to make a game just go to the asset store and in no time you'll have everything you need!" But instead you get
"I downloaded these 5 assets from the store, why don't they all work together?"
Or
"I copied and pasted this code I found why doesn't it work"

I think it people had to start with simpler parts and understand them they could build up to the point of handling more complex tools and assets. But now they are just given access to the deep end and then encoraged to jump in. And then since they are yelling the loudest they get the most attention paid to them.

But all these things seem to be getting a little better. But still I don't feel like they have any kind of architecture team at unity. It's all seems like here you 3 guys add this feature and do it however you want. And you two add this one and use whatever you want.