Does Unity make game dev too difficult?

Did you test it out already? Looks like a nice map you built if so.

 

I think I'll need to look at it in greater detail again. Full control over movement is not a bad thing and It could be very useful, especially when the goal is retro-style game.

 

But the Oscar goes to Unity.

 

This is their documentation picture.

If i continue it will take lot moreto add textures , particles effects ,different kind of AI, UI, more weapons, doors and keys, items, menu , interesting and balanced level.

 

Of course! The more you add the more time required. That is one of the points of this thread. That is why development speed is very important. Especially the larger the scope is. First because like you mentioned "if I continue"... you'd be more likely to continue as long as you're making rapid progress and second if anyone wants to do it for a business and make a living from it a person can't waste time on slow development.

The more efficient the development is the less cost it has and that directly ties in to being able or not being able to make enough money to cover the development expense and hopefully more to carry a person forward to make their next game. As in the faster a given scope of game can be completed to the same level of quality the faster it can start generating money (if it does).

Anyway it'd be good to see what you come up with!

I guess maybe now that I've had a little break from game dev I might spend 1 hour (and no more than 1 hour!) tonight checking out N6 and see how it goes.

If I can't make some quick and decent textures, build a basic (doorless) level and have the player moving around in 1 hour then I'd say there is no sense in me considering N6 further. Well beyond fact that I have never used it and know nothing about it except a video or two of games made in it. lol But that is my point. If it is a streamlined dev tool with a straightforward architecture and api picking it up should take no more than 5 minutes.

 

This is why i consider taking the right and best approach and tools are important.

When you learn something it's always when it is longer, anyway once learned you should be able to throw some games in some minutes and you can focus on making pixel textures.

 

Minutes ... Well eventually I suppose if I wrote all of the systems and created libraries that can be imported (I did notice in a video somewhere that one can create libraries for N6 so it is great it shares that feature with C#) it should be possible to get "Generic Raycasting Game" up and running in minutes.

But that is just the core right and yes I would love to be able to start a new project and be to that point in say 10 minutes or less. Because that is just the underlying nuts and bolts IMO. The actual real game dev work begins at that point. Bringing a vision to life. Creating this specific game.

This is the reason I think it is smart for any solo dev to make basically the same game or same kind of game over and over building up an easy to use tech base and foundation as they go. I focused on that in Unity but spread out too much working on everything from shmups to platformers to single screen arcade games to 3D maze exploration games.

I did end up with some good rapid game dev workflows and some good solutions to various things but... I need to choose a single genre and stick with it for 4 to 5 games. Then by time the last game is created there will be enough underlying tech to actually make something cool in a reasonable amount of time.

But I do think N6 might be a jump start to a point like having the tech in place from making one or two games. If so that is a huge deal. I will find out tonight.

EDIT: I should say I guess that is the point of some of the kits/templates on the Asset Store. Unfortunately in my experience they never save time.

First I need to learn all of their custom stuff (and due to the component architecture things can be scattered all around... where is this thing set ah here it is out in the Inspector on this GO. So where do these values come from... ah finally I found it this time hard-coded over in this file) and then the way they decided to implement means basically rearchitecting (a core rewrite) to get around limitations in their design choices. So it ends up adding much more time.

I suppose some might be good though but which ones. lol And in fairness to those devs it is a true art in itself to know how much to implement, how to implement and where to stop implementing. Less is often much better than more (less overall design & direction choices made before we take over).

 

@zenGarden Hmm... I may need to explore further. I spent 45 minutes on my lunch break today checking out N6. Created 3 new texture images for floor, ceiling and wall. Reproduced the original map (without doors at this point) and then writing the program to handle player movement.

I have no idea what happened to the first couple of seconds of the video but anyway... now this is more what I expect from 45 minutes of work.

I do have to say though that map editor can definitely be improved. There are a couple of easy things that would make it much better. That was the most tedious part of the whole effort. The important thing is I have this out of the way so I don't need to spend my precious after work time on it.

It made a good first impression. Although I think many people here could probably do the same thing in Unity. Anyway, next time I feel like doing something I guess I will continue exploring.

 

I mean for those retro FPS with tile based editor, you can draw a test map in some minutes, not a interesting map lol

Some are too complicated others are more easy with less options but lot more adaptable or customisable.
And there is all plugin tools, lot are usefull , for this retro FPS, i use Tiled and Playmaker and they awesome.

This is the whole purpose of having ready to go tile editors, you don't spend time on it and you focus on game content.
Something like Tiled or Octave 3D are tools that help you that way, you draw a test level in some minutes painting tiles.

If you feel at ease stay with it. I would like to know how easy it is to add ennemies, items and game logic.

 

Oh yeah outside of Unity that is exactly what I use Tiled. In Monkey X I just built my own higher level tilemap "engine" on top of the open source bit.tiled library. Like I said my disconnect has always been in Unity. I open it see all of these GameObjects and stuff and just am not sure where to begin. lol But I did manage to grind through some projects.

Well that is an interesting thing you just said. Yes I immediately felt super comfortable in the N6 environment because there was nothing but a tool to build maps and then jump straight to the code. There was nothing else. No GOs, no monobehaviours, nothing period. And the absence of all of that architecture and the presence of "nothing" but a void is a place I felt very comfortable.

 

You think Unity doesn't start with a void?? You would die if you opened Unreal Engine.

 

I think he means a more literal void. Like, no visually represented objects at all and everything represented in code. I could be wrong though, since I never used N6 in my life.

 

You are right. Well I didn't die but I certainly didn't like it. I looked at all of that GUI and thought "what in hell is all of this crap?" Same for Gamemaker Studio. My step son loved it. Loved the way it had all of the GUI and found it very intuitive. On the other hand I spent 5 minutes looking at stuff thinking "what is all of this crap?" and closed it out.

I've actually almost kind of become used to Unity though. But yes it seems barren compared to either of those other two.

I don't know I just see it like all that is needed is a quick way to build levels, a nice api for loading resources and drawing things and playing audio, a nice game oriented api in general and an editor to write the code. Notepad even works fine except some of the modern things are handy so an actual code editor can save some time.

 

Yeah I meant both. Lean all around. Nothing to get in the way. I don't see Unity as too bad though other than GOs, monobehaviours and some other stuff it is definitely usable! Well I mean it is usable already even with those things.

EDIT: It just occurred to me that is the issue I have with these things. Where I guess other people are seeing these things as helpful I view them as obstacles in the way. Something sitting between me and what I want to do and would prefer "a blank canvas", a "clear road ahead". That was good insightful moment!

 

If you see gameobjects, monobehaviours, rigidbodies, the editor, etc. as obstacles, you're basically saying you see Unity itself as an obstacle.

Maybe you should just use Monogame or a similar framework and do everything in code and be done with it instead of forcing yourself to use Unity when it's obviously not what you want.

 

Honestly, I must say I have been thinking the same thing. This last little demo project in Unity this past weekend was a pretty good experience overall. But you are right. I do feel like I have been coming back trying to force myself to get into Unity for about 3 years now. And I think this last project was kind of a final attempt to see it the way the rest of you do (made some progress toward that goal!)

I've spent far more time with Unity trying to make myself "click" with it than I have actually creating. And time trying to use it in a way that it is not intended to be used. And a few times (including this latest) trying to use it the way it seems to be intended to be used.

Yes it has been a hell of a lot of effort spent on just trying to use this one particular thing only because I like the community (for the most part lol). And probably has been a waste of time when looked at that way. It might even be a part of why I was getting burned out on game dev and seeing it as more of a chore than as something fun.

So basically I have come to same decision I think. I appreciate your frankness.

 

Now I suspect that the problems I see in the 'Unity's way' might not be the same as what @GarBenjamin does.

However, I can say that I do conceive MonoBehaviour as an obstacle also, and I've been trying hard to find a sensible way to create games in Unity while avoid using it as much as possible.

And I guess it's working quite well so far, as among 120 classes I have in my current project, only a couple of them inherit from MonoBehaviour, which allowed me to handle them in the same way that I would do in any non-Unity projects.

 

Funnily I checked blitz3D today and some one started to port the aging code to modern platform, looks like I will only use unity for serious production if they complete it!

https://github.com/blitz3d-ng/blitz3d-ng

 

I honestly don't understand why would anyone want to do that. MonoBehavior is simply a convenient container attached to something in the scene.

Then again, when I worked with UNreal engine, I tried really hard to avoid blueprints. I suppose it might be similar.

 

It might not be an ideal example, but it's basically the same as why people hated EJBs so much before they accepted the same kind of criticisms from developers and came up with a new version.

Probably, the main argument regarding testability might not entirely be relevant in the case of Unity, because most of classes in that environment will require other components like Camera or Transform that cannot be instantiated outside the platform anyway.

But other minor points still hold, I believe, like its inability to follow such a common practice of declaring every required properties as constructor arguments, thus effectively preventing the instance from being created in an invalid state.

And in case of Unity, the way MonoBehaviour works is pretty much a 'magic', because it relies on many assumptions which are not visible from looking at the API documentation of classes that derive from it.

For instance, why a certain class can handle collision events? It's only because somewhere in its hierarchy, Unity expects it to define a method which is exactly named 'OnCollisionEnter', but there's no type hierarchy or an abstract method that enforces the contract.

It's just an implicit rule between Unity and its developers, that 'if you name your method such and such, we will invoke it when appropriate'. And as such, it's not important if its declared as public or private, or even missing a few arguments.

It's more of a way in which such dynamically typed languages like Javascript would work, not such languages like C# in which one is supposed to design with statically typed class hierarchies.

And as its name suggests, MonoBehaviour is truly monolithic(I'm not too sure of its etymology though), as it deals with whole bunch of seemingly unrelated functions, from collision detection to tracking mouse position. And generally speaking, it's in direct opposition to a commonly accepted rule of assigning only a single responsibility or a role per a type, when it comes to design a software in OOP manner.

I have no doubt that more pragmatically minded people will have little problem with using MonoBehaviours to make great games. But I believe that it's also true that there's quite a significant gap exists between the way a typical Unity developer would code one's game and the way other C# developers would design their systems, as mentioned above.

So, I think that it might not be an entirely meaningless endeavor to minimize such a gap, by trying to follow such commonly acknowledged best practices in developing C# programs in general as closely as possible in Unity development as well.

 

It sounds like you are going down the same path as I did. My very first Unity project I basically followed all of the normal Unity stuff even used the Animator. Never finished that game and that started me on a path to see how much I could throw out.

The most productive environment I reached was using singleton managers and a "GameManager" GameObject. That contained a "GameManager" monobehaviour. It grabbed references to the various managers (that were all plain non-monobehaviour classes). So that single monobehaviour GameManager was the hook into Unity. It was the only thing with Start() and Update() methods that were called by Unity. In this way it made it very much like using C# & XNA, Monkey X or various other programming languages and apis.

Of course, I still had to use GOs but they were all updated by the appropriate manager class.

Honestly, I'd suggest right now before you get too much further along stopping and either embrace Unity and the monobehaviours or find something else that "fits" your preferred style better. Only saying that because it may save you frustration and time. Of course, I also understand you won't do that for the same reason I didn't. You're having fun molding the game engine to work the way you want it to. lol

It is a great game engine and there is the actual problem for me. I don't want a game engine and "weird" stuff like GOs, monobehaviours and so forth. Only a game oriented api (that is well designed) that works with a decent programming language.

Best of luck though whatever you do. Like I said I was the most productive in Unity when I threw out 95% of it and did everything "my way". It can be done but after a while it becomes a question of if I am not using Unity like Unity (as in don't like the core ideas of it) then why I am I using it at all. lol The dead easy multi-platform support was a reason. It made it incredibly straightforward to produce both desktop and web games.

It is also quite possible that you don't mind the other stuff and only dislike monobehaviours. So that could make a big difference.

 

Yeah, you are right that I happen to be enjoying it, at least for now I guess it might be because I haven't yet a very clear idea about a game I want to create with Unity in future. So, I'm kind of trying to 'prepare the ground' in a way that I'm most accustomed to in writing codes in other languages.

I guess the reason I'm seemingly having a bit more success in my search could be that I found a way that bridge the both of the worlds - that is of Unity and POCOs - in Zenject. I believe it's much better than relying on singletons and wiring up messages by hand.

And as you said, I'm not really against using other parts of Unity as Animator or RigidBody, so I can only concern myself about replacing Unity's MonoBehaviour oriented component model with something I can feel more comfortable with. (Ok, maybe the legacy IMGUI API too, it's truly horrendous even to look at, so I have to refuse to use it as it is.)

Anyway, thanks for the encouragement, and I hope you would find the best way to develop games that suits your preferences soon too

 

That's.... no offense... a very wrong ... kind of reasoning, because unity is not a normal C# program.

You need to understand C# place in unity.

C# in unity is a scripting language. Also, C# as a scripting language provides exceptionally poor control over memory management. Meaning commonly accepted programming practice/techniques like making everything immutable will spew ton of garbage allocations, thus killing performance of your game.

For example... did you notice that Update, Start, OnEnable, OnDisable do not require an override specifier?
That's because MonoBehavior does not have an Update() method. Here's entirety of MonoBeahvior:

Code (csharp):

1.  
2.     [RequiredByNativeCode]
3.     public class MonoBehaviour : Behaviour{
4.         //
5.         // Properties
6.         //
7.         public extern bool runInEditMode{
8.             [GeneratedByOldBindingsGenerator]
9.             [MethodImpl(MethodImplOptions.InternalCall)]
10.             get;
11.             [GeneratedByOldBindingsGenerator]
12.             [MethodImpl(MethodImplOptions.InternalCall)]
13.             set;
14.         }
15.  
16.         public extern bool useGUILayout{
17.             [GeneratedByOldBindingsGenerator]
18.             [MethodImpl(MethodImplOptions.InternalCall)]
19.             get;
20.             [GeneratedByOldBindingsGenerator]
21.             [MethodImpl(MethodImplOptions.InternalCall)]
22.             set;
23.         }
24.  
25.         //
26.         // Constructors
27.         //
28.         [GeneratedByOldBindingsGenerator, ThreadAndSerializationSafe]
29.         [MethodImpl(MethodImplOptions.InternalCall)]
30.         public extern MonoBehaviour();
31.  
32.         //
33.         // Static Methods
34.         //
35.         public static void print(object message){
36.             Debug.Log(message);
37.         }
38.  
39.         //
40.         // Methods
41.         //
42.         public void CancelInvoke(){
43.             this.Internal_CancelInvokeAll();
44.         }
45.  
46.         [GeneratedByOldBindingsGenerator]
47.         [MethodImpl(MethodImplOptions.InternalCall)]
48.         public extern void CancelInvoke(string methodName);
49.  
50.         [GeneratedByOldBindingsGenerator]
51.         [MethodImpl(MethodImplOptions.InternalCall)]
52.         private extern void Internal_CancelInvokeAll();
53.  
54.         [GeneratedByOldBindingsGenerator]
55.         [MethodImpl(MethodImplOptions.InternalCall)]
56.         private extern bool Internal_IsInvokingAll();
57.  
58.         [GeneratedByOldBindingsGenerator]
59.         [MethodImpl(MethodImplOptions.InternalCall)]
60.         public extern void Invoke(string methodName, float time);
61.  
62.         [GeneratedByOldBindingsGenerator]
63.         [MethodImpl(MethodImplOptions.InternalCall)]
64.         public extern void InvokeRepeating(string methodName, float time, float repeatRate);
65.  
66.         [GeneratedByOldBindingsGenerator]
67.         [MethodImpl(MethodImplOptions.InternalCall)]
68.         public extern bool IsInvoking(string methodName);
69.  
70.         public bool IsInvoking(){
71.             return this.Internal_IsInvokingAll();
72.         }
73.  
74.         [ExcludeFromDocs]
75.         public Coroutine StartCoroutine(string methodName){
76.             object value = null;
77.             return this.StartCoroutine(methodName, value);
78.         }
79.  
80.         [GeneratedByOldBindingsGenerator]
81.         [MethodImpl(MethodImplOptions.InternalCall)]
82.         public extern Coroutine StartCoroutine(string methodName, [DefaultValue("null")] object value);
83.  
84.         public Coroutine StartCoroutine(IEnumerator routine){
85.             return this.StartCoroutine_Auto_Internal(routine);
86.         }
87.  
88.         [Obsolete("StartCoroutine_Auto has been deprecated. Use StartCoroutine instead (UnityUpgradable) -> StartCoroutine([mscorlib] System.Collections.IEnumerator)", false)]
89.         public Coroutine StartCoroutine_Auto(IEnumerator routine){
90.             return this.StartCoroutine(routine);
91.         }
92.  
93.         [GeneratedByOldBindingsGenerator]
94.         [MethodImpl(MethodImplOptions.InternalCall)]
95.         private extern Coroutine StartCoroutine_Auto_Internal(IEnumerator routine);
96.  
97.         [GeneratedByOldBindingsGenerator]
98.         [MethodImpl(MethodImplOptions.InternalCall)]
99.         public extern void StopAllCoroutines();
100.  
101.         [GeneratedByOldBindingsGenerator]
102.         [MethodImpl(MethodImplOptions.InternalCall)]
103.         public extern void StopCoroutine(string methodName);
104.  
105.         public void StopCoroutine(IEnumerator routine){
106.             this.StopCoroutineViaEnumerator_Auto(routine);
107.         }
108.  
109.         public void StopCoroutine(Coroutine routine){
110.             this.StopCoroutine_Auto(routine);
111.         }
112.  
113.         [GeneratedByOldBindingsGenerator]
114.         [MethodImpl(MethodImplOptions.InternalCall)]
115.         internal extern void StopCoroutine_Auto(Coroutine routine);
116.  
117.         [GeneratedByOldBindingsGenerator]
118.         [MethodImpl(MethodImplOptions.InternalCall)]
119.         internal extern void StopCoroutineViaEnumerator_Auto(IEnumerator routine);
120.     }
121.  
122.  

The class is not monolithic. It is empty. It does not have Update(), OnEnable(), OnDisable(), Start() method. It is not a virtual base for which you override methods. It is an object which C++ side of the engine pokes and queries for known entry points. That's why function names are used.

I'd also recommend to take a look at UNreal's C++ api (which also doesn't really let you pass thing through constructor).

Basically... adhering to practices of "normal" C# will result in negative consequences because C# lacks certain tools, and because game programming has different requirements. It is also important to realize C#'s place in unity and recognize that you're not writing a normal program. In fact, many normal practices can be harmful.

When working in unity, you're writing an equivalent of a plugin dll with performance in mind. Not a normal C# software.

-------

Basically, the reason why you fight monobehaviors is because you want Unity to be a normal C# program. The problem here is that unity is not a C# program, but a C++ engine that talk through C# with you. I think it is important to understand the difference and realize consequences associated with it.

 

Well, it's not a "contract". They're optional things that you may use if you'd like. Either of the solutions you suggest would force you to have them, which would actually be really bad. (Read on below, though.)

I see where you're coming from, but don't personally see it as "monolithic" because, as above, you're not required to implement all of those methods. Yes, a MonoBehavioud can receive collision calls, and it can do a whole bunch of other stuff, and if you do make use of all of those things in a single class then you're probably making a monolith... but just because you can do it that way doesn't mean Unity is making you do it that way.

All of that said, I also personally detest the whole magic name thing Unity has going on. In the case of MonoBehaviour it's a kludgy solution to things that C# already did quite well. Why* use magic names when Interfaces are already a thing? (Which would in turn make them contracts as you mentioned above and come with all of the related benefits, like our IDEs being able to tell us when we messed them up.)

* I'm sure there's a reason that made sense at the time. Maybe the two other languages supported at the time didn't have an equivalent?

 

As @negionfinity has explained, there is indeed such a gap, and while it may not be deliberate it's almost certainly necessary. You aren't using C# in vanilla .NET to make a desktop application here. You're using C# in a game engine to do stuff that's presumably real-time and often has performance constraints.

As an example plenty of C# standard practices allocate new memory without concern. For desktop apps that's not usually even worth the effort of thinking about. In a game trying to optimise for performance, though, it's another story entirely.

 

No offense taken, as I think I do understand, at least in most part, what you are saying, including potential problems with immutable design and all.

But I think admitting that there are specific (performance) requirements in writing games doesn't necessarily mean that we should not make any compromises for other types of benefits.

If it was absolutely prohibitive to do anything that might affect performance adversely in games, I guess Unity probably wouldn't have minded supporting C# as its main scripting language at all, because having such a layer as Mono will always slow things down compared to such a case just write everything in a pure native language.

It's my understanding that it was a decision to trade off a bit of raw performance for ease of development, which I think was well paid off considering how Unity became the most popular game engine among indie developers.

And if such a trade off can be made, and be justified, why not we can say the same about introducing a DI container between the POCOs and the game object's world? Does it really incur that much performance overhead to be really prohibitive in creating games?

The overhead - if it's not already negligible, as I suspect - mainly exists in the way that the container instantiate its dependencies. And in most cases, it doesn't have to occur in every frame. And at the very least, even if we can prove that there was a perceptive overhead in the process (which I highly doubt it), I'm pretty sure that there would be many types of games where losing 1-2 fps won't be too much of a sacrifice, if it could allow its developer to write the game logic in a way that he or she's the most accustomed to.

I'd understand that if for some people, being able to write code in POCOs won't look to be an advantage that's worth introducing another layer of complexity.

But if one's already very familiar with how a DI container works, or how to design softwares in purely OOP manner, then I don't see any reason why such a person should not try to choose such an approach, especially when the framework that allows such a development has been already on Asset Store for awhile, as it's getting very positive reviews and even used to create such successful games like Pokemon Go.

 

I'd like to add that Unity EventSystems uses Interface-based approach and it is ... extremely kludgy/ugly. Even worse than magic names.

For example, see here:
https://docs.unity3d.com/ScriptReference/EventSystems.IDragHandler.html

Code (csharp):

1.  
2. public class DragMe : MonoBehaviour, IBeginDragHandler, IDragHandler, IEndDragHandler
3. {
4.  

Now, let's see declaration of IBeginDragHandler:

Code (csharp):

1.  
2.     public interface IBeginDragHandler : IEventSystemHandler{
3.         //
4.         // Methods
5.         //
6.         void OnBeginDrag(PointerEventData eventData);
7.     }
8.  

Seriously?

I don't know about you, but I see an overuse of OOP paradigm. A class is supposed to represent a complete something. A class that only has one method isn't that. For all the practical purposes, such design means that you'll need to type the name twice (OnBeginDrag AND IBeginDragHandler) and gain nothing from it.

I would say that Magic names are cleaner option. After all, at least some langauges have main() method as an entry point. And that's what those named methods represent - they're entry points.

 

The decision to use C# for scripting is one of the unity decisions I do not really fully understand to this day. It is not on the same level as Unreal's obsession with blueprints, though. I would prefer C++ api, as I mentioned before. As far as I can tell, the primary reason for using C# is IL, which can later be recompiled on many other platforms.

The rule of the thumb is : when you ask a yes/no question, the answer is the one you won't like.

Also, difference between 29 and 30 fps is a millisecond. It is a big value when someone wants to maintain high framerate.

In my own experience trying to do really time-sensitive heavy lifting on C# side of things in unity is a bad idea. Things that you can pull off in C++ and get 600 fps - easily - cause hiccups due to garbage generation on C# side. So with that in mind, I'd rather not see features added in order to "make code more elegant". I would prefer performance isntead. C++ bindings would be even better.

 

I suspect that we have very different approach when it comes to design and write softwares. I never argued that the OOP is the one and only way that everyone should write programs in. But on the other hand, it's hard to deny that at least it's a valid, and a very popular paradigm with which many successful softwares were created.

When I write any kind of software in such languages like Java, Scala or C#, I always begin with the most abstract concepts. For example, if I'm to create a RPG game, I imagine what core concepts there are in such kind of a 'system', and come up with things like 'character', 'item', 'weapon', 'NPC', and etc.

Then I write them down as interfaces (or traits) like ICharactor, IItem, and so on, and as I can clearly see that 'NPC' is just a special type of a character with an AI, or that a weapon is just a special type of an item, I express such relationships as type hierarchies, like "INPC : ICharactor", or "IWeapon : IItem'.

I probably won't have to say any further on the subject, because as I see it, it's quite a common practice in designing a software with the OOP paradigm.

In your example, I agree that it might not be the best example, as I don't see such interfaces like 'IDragEndHandler' depicts such a clearly defined concept like 'ICharactor' as mentioned above, for instance.

And again, I wouldn't mind if other people have found it better not to follow OOP at all in creating games with Unity. But unless there's some specific reason like significance performance penalty, for instance, I don't see why I should not do it in OOP either, especially when it's the method that I feel the most comfortable with, and when it happens to be the most widely followed approach when it comes to writing applications in C# in general.

 

The suggested 'overhead' was a hypothetical one. As I said above, the overhead with a DI container mainly happens in the initialization stage, so it does not really affect FPS during a gameplay (if we set aside for a moment the case with dynamically created objects). And I'd be surprised if it actually incur as much as 0.1 second of overhead in the process.

Of course, I'd understand if some would argue that they won't tolerate even the slightest possibility of losing performance. But I'll protest if they claim further that every one should follow that approach regardless of what type of games we develop or what design approach we prefer, and etc.

 

I'd like to argue that it's a major part of the reason why one might choose a statically typed like C# over other dynamic languages.

Even with dynamic languages, most modern IDEs won't have too much problem in providing such features like auto completion, and etc. So, if everyone thought that enforcing such contracts at build time to be a bad idea, there wouldn't be any reason why one has to use statically typed languages at all.

Rather, those who are accustomed to design softwares in such statically typed OOP languages like C#, tend to see it more as a 'tool' to express their ideas about how each components of a system must be defined, in their conceptual or functional relationships with each other, rather than an unnecessary limitation that only annoys a programmer.

For example, if I define a 'weapon' to be something that can strike other item to cause damage, I'd much prefer to be able to enforce that every instances of IWeapon to implement Hit(IItem target) method, rather than simply saying 'oh, I'll send a Hit message when this weapon hits something, I promise to do that even if you can't see it in its signature, and I can't guarantee that it won't change in future'.

 

I highly recommend to at least try to let this approach go for several projects - for the purposes of broadening the horizons.

Basically, you're trying to do what I once did - you're attempting to write a normal program.

What works significantly better is trying to program your game as if it was a robot swarm.
Where number of "classes" is smaller by order of magnitude, and there are a lot of independent and VERY simple systems, rather than one huge cathedral of source code where you're all-seeing omnipotent god of everything.

The difference in speed. "Robot swarm" approach is faster.

 

I dunno, I used to spend a fair bit of time finding and fixing typos in the magic methods. I certainly spend less time doule typing then I used to spend fixing errors.

There is also the advantage that its easier to grab all of the components that implement a particular method and do something with them. I frequently use this to create 'fake' events. This was doable with the magic methods, but more challenging.

But above all what I'd really ask is that Unity simply make up their mind which system they want to use and run with it. Currently OnCollision is magic, OnClick requires an interface, and OnLevelLoaded requires subscribing to an event. The internal inconsistency is painful.

 

I have to admit that I haven't much experience with Unity yet. But honestly, I don't think I will have too much trouble, if I was forced to create something like Wolf3D clone in a typical way in Unity, too. It's not that I want to try it differently because I don't know how to do it in a 'normal' way, in my case.

But I do agree with you one your other point, to a degree at least, that sometimes it's better to design a big software using a component based approach. It's just that I do not believe that it's the only way to do things - for, what's wrong with playing a god, as you described, in a universe that I create myself with codes? It might even be the reason why enjoy writing softwares!

And even when I design softwares in such a manner, I usually prefer to have at least something cleaner, and more lightweight (structurally, not as in performance) than MonoBehaviour as the basis for its components.

 

I made a rought AI chase with no optimisations in some 15 min
NavMeshAgent and Animator reduces your code to the bare minimum, i want to say Unity makes game development easy

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4. using UnityEngine.AI ;
5.  
6. public class rabbit : MonoBehaviour {
7.  
8.     NavMeshAgent nav ;
9.     GameObject player;
10.     Animator anim ;
11.  
12.     public float distChase;
13.     public float distAttack;
14.     public float distance;
15.  
16.     // Use this for initialization
17.     void Start () {
18.    
19.         nav = GetComponent<NavMeshAgent> ();
20.         anim = GetComponent<Animator> ();
21.         player = GameObject.FindWithTag ("Player");
22.  
23.     }
24.  
25.     // Update is called once per frame
26.     void Update () {
27.    
28.         distance = Vector3.Distance (transform.position, player.transform.position);
29.  
30.         if (distance <= distChase && distance >= distAttack)
31.             chase ();
32.         if (distance < distAttack)
33.             attack ();
34.         if (distance > distChase)
35.             idle ();
36.     }
37.  
38.     void chase (){
39.         nav.SetDestination (player.transform.position);
40.         nav.isStopped = false;
41.  
42.         //animation
43.         anim.SetBool ("move",true);
44.         anim.SetBool ("attack",false);
45.     }
46.  
47.     void attack (){
48.         transform.LookAt (player.transform.position);
49.         nav.isStopped = true;
50.         anim.Play ("attack");
51.     }
52.  
53.     void idle(){
54.         nav.isStopped = true;
55.  
56.         //animation
57.         anim.SetBool ("move",false);
58.         anim.SetBool ("attack",false);
59.     }
60.  
61. }
62.  

 

I think @neginfinity is dead on here.

I think you're looking at the meaning of inheritance here too literally. When you subclass monobehaviour you are really just exposing an object to a bunch of callbacks. How, when or where you use those callbacks is up to you. Don't think of monobehaviour as a "base type" think of it like a tag enabling callbacks.

Imagine it's called UnityEventRouterBase if that floats your boat.

I would also assert that MonoBehaviour has a fairly narrow range of responsibilities. OnCollision isn't a different responsibility from Start, both of these are just message types and MonoBehaviour is a base type for receiving messages in a spatial hierarchy (transform hierarchy).

Just because MonoBehaviour exposes an OnCollision message doesn't make it responsible for collision handling. You can have a dedicated 'collision handler' class somewhere that handles the responsibility. In this case, the MonoBehaviour acts more as a message router (which is closer to what it actually is).

In other words, your mental model of what a MonoBehaviour is and what inheritance means in this case is off.

More of a point of problem is coupling behavioral hierarchy with spatial hierarchy. There are many, many times when I would prefer being able to specify behavioral hierarchy without any assumption of spatial hierarchy, but honestly it doesn't matter, and the coupling here makes things simpler in 90% of use case with very little real cost in the other 10%. So this was probably the right decision on UT's part.

In terms of DI and stuff, just write your own or download one. I'm not sure why this is a point of contention at all.

 

As for the "magic method" complaint, sure. But as @neginfinity points out - the alternatives IDragHandler are awful.

A lot of UGUI api moves more toward the interfaces in place of magic method stuff and honestly it's a pain in the ass to work with. I would go further and say that it's by far the least pleasant part of the Unity API to work with.

In fact, in practice, it's the only part of the Unity API that I've ever really had a problem with. It's philosophically wrong and it's using 'best practices' in places where they are not actually the best practice.

Man, do I really hate the UGUI api. It borders on irrational. The design choices they made there make me angry. When I have to subclass PointerEventSystem or whatever in order to expose protected fields that hide critical data like PointerEventData for no reason, I want to strangle someone.

 

Should post video or at least gif to bring it to life here.

Code looks very straightforward. Of course animation is hidden out in the Animator Controller thingy but that's okay. Actually looks good here.

The important thing is you seem to be enjoying the project and feel that Unity is making everything simpler. Shows that Unity is a great choice for you.

As long as a person is completing games use whatever even Unity. lol I think that is what matters. Not the tool or approach but actually getting things done and doing so in a way that makes development feel easier & less involved instead of more difficult and more involved. Use something that basically makes game dev fun.

Probably each person posting in this thread believes strongly the way they are doing things is the best way. The way that makes the most sense. And we all need to keep in mind it is rarely the case. It really is the way each person wants to do things... the way they feel most comfortable with.

Like with @mysticfall... if the approach he shared is more comfortable then so be it. People use all kinds of approaches. I've seen dev logs of people using a purely oop inheritance approach to all interfaces to MVC to even one or two doing what I did (with their own spin of course). Whichever way gets the project done faster with less hair pulling is probably the right way and that will be different for different people.

 

While I do think Unity could use some improvements (No inheritance\nested of prefabs is probably the biggest one that many games would benefit, or maybe a system of prefab template through code that you can inherit from in code similar to Unreal) it does not make it too difficult at least in comparison to developing your own engine.

I also disagree that the interface approach is bad, it's more C# idiomatic and while it's more verbose it's easier to follow without custom Unity based plugins for your IDE\Text editor. I would prefer them to use interfaces for the other messages as well and just completely remove the MonoBehaviour class in it's current form and replace it with something you inherit from to tell Unity it's attachable to a GO.

I kind of prefer to not use a kind of modding tool for my game development, the workflows I can create through unity editor scripting is much better than most workflows I find elsewhere (Minus tile mapping, at least until 2017.2).

 

In OOP, 'inheritance' doesn't just mean "exposing bunch of functions" of a parent class. A type in a OOP system should represent some concept that is clearly defined, and plays an important role in a domain, and inheriting it means that there is a 'is-a' relationship between the parent and child types.

And even if I pretend that such widely different activities, like tracking mouse position, handling IK callback, catching player connection in a multiplayer game, and so forth to somehow represent a single responsibility, it does not change the fact that they are all handled by some hidden assumptions, a.k.a 'magic methods'.

Again, I might understand if they call it 'the Unity way', or whatever and saying that it's the method that works best for them. But it's simply not the way it's supposed to be done with a statically typed objected oriented language like C#, outside Unity platform.

As to DI, I'm also not sure why this is a point of contention at all. All I've been saying is that it's considered a best practice outside Unity world to design your system with lightweight POCOs as much as possible, and it's actually achievable even in Unity with a help of such DI frameworks.

If you don't agree or don't care why it's called a best practice, or think MonoBehavior's magic methods are the best way that suit your need, then it's fine with me. I don't want to force anyone who see traditional OOP as something cumbersome, or not applicable to Unity to change their views.

But why must I rely on MonoBehaviours myself, when it's actually possible to replace them with POCOs to follow the best practice that I've been accustomed to?

The objected oriented approach is at least an well established principle, that is far more widely understood and accepted among developers than the 'Unity way'. C# itself is designed around that principle, and its IDEs are full of such features that would make your life easier it you follow that approach, and there are tons of learning materials, design patterns, and etc which are based on its core concepts.

There's a good reason why people try to use interfaces or POCOs in C#, even if you don't see the point of it, or prefer other alternatives like such 'magic methods'.

You can't say that OOP is useless just because people have been creating good games in Unity without OOP. I don't see any reason why people who are already accustomed to the principle should not try to adopt OOP when they develop games on Unity platform.

 

I would say it depends. In many cases it just makes things easier for beginners to rely on these magic methods.

But I have to say that when I've pushed myself to write the best code I can, for example in stuff I've made for the asset store, I find myself extracting and storing monobehaviour data in my own classes, writing my own methods for accessing them that I can control the efficiency of, and writing interfaces for a cleaner and more efficient way of accessing them - in short, avoiding using monobehaviour methods altogether.

I can't be sure that it's a better idea for Unity not to do things the 'Unity way' for approachability purposes, but I can see why they can create a bit of an organisation and efficiency problem.

 

But inheriting from MonoBehaviour is a clear "is a" - the question is "what is it" in the first place.

If you think of monobehaviour as "event hook base" then it makes perfect sense (plus spatial hierarchy).

^^^ a mono behaviour is not responsible for all of this

It is just a host for event notification attached to a transform. This is why your mental model needs adjustment.

It is not a "responsible for every aspect of game logic" - it's an adapter for the c++ side to fire callbacks into the c# side.

How you choose to use those callbacks is up to you, but you are making assumptions of the code that are your assumptions.

http://www.dofactory.com/net/adapter-design-pattern
^^ adapter pattern, this is essentially what a mono behaviour is.

That you may choose to place all the implementation for handling the message in the monobehaviour itself is your call (usually the simplest way for sure), but that does not mean that your implementation choice is inherently part of the responsibility of a monobehaviour.

 

Yes, this is true.

Everyone is free to only have one MonoBehaviour in their project that acts as an entry point into their game as a way to use the Unity API. That doesn't stop the MonoBehaviour class from being a great source of frustration for noobies who think everything must be a MonoBehaviour, mostly because Unity tutorials are structured that way.

Personally I enjoy writing all logic away from Unity and then expose in MonoBehaviours in a nice designer friendly way.

 

MonoBehaviours are non idiomatic C#, and this is a point of confusion and frustration for some people.

That said, if you want to really evaluate them, you should be willing to evaluate the benefits as well as the drawbacks. There are many, many benefits. A purely dogmatic analysis will skip over these and simply focus on 'conceptual misalignment'.

In real world practice, any system based purely on ideal notions sucks. There must always be compromise between ideal and practicality. Trying to adhere too strongly to ideological goals produce awful systems. This applies to almost everything, from code to game design all the way up to government policy.

Good design does not come from rigid application of dogma, the art of good design revolves around the compromises. Finding the right point and degree of compromise is by far the most skill testing aspect of good design.

 

Why making complicated when you can do it simple and resulting in the same gameplay ?

At first Unity didn't looked easy, but once i learned and practiced the basics like using NavAgent,Animator and using collisions , it's always the same way of using these tools and components for most games staying on the basics.

Anyway, you are right , each people will have it's own way and tools preferences that makes them feel comfortable and keep fun making something.

It's a basic use of the controller.

You create states, for each you select your character animation.
For example move state will play "rabbit_move" animation with speed = 1




You create two boolean parameters to control the whole system.
For each transitions between states you define a rule using these boolean parameters.

For example '"move state" will be active only when boolean move = true and boolean attack = false



What is hidden ? Or where is the difficulty ?

This reduces greatly your code as you don't have to call for each animation methods like play, setSpeed ,blend etc ...
You only set boolean controller variables to change what animation to play
anim.SetBool ("move",false);
anim.SetBool ("attack",false);

With some clicks you have your states, animations set up, blending and rules.

 

I think you are trying to tell me why it's the way it is, and how I can change my views to see it in a less objectionable manner.

But as I said, I found an actual working method that allows me to do away with MonoBehaviours in most cases. And it's not some sort of a weird hack but a favorably reviewed Asset Store item with which such games like Pokemon Go was created. So, all I did was simply pointing out that you don't have to abandon the traditional OOP to use Unity, if that's the way you think to be a better approach.

So, why should I force myself to use MonoBehaviour when I don't really have to?

And if I define a player entity using MonoBehaviour, what does really mean other than 'it can define a bunch of magic methods to get callbacks from network backend, GUI system, particle system, animator, and etc'?

If all I may want with my player entity is to hold some stats, for example, then why should I ever care about such things?

And let's say that I do actually care that it handles some IK stuffs for the player character. Then how does the fact that it extends from MonoBehaviour make that intention clear? Don't every other classes also have to extend MonoBehaviour, whether they care for animations or not? And how do you know that my player class is interested specifically in animation events, when there's no real contract is enforced by being a subclass of MonoBehaviour?

It's simply not a good case of using inheritance to specify a specific role or a meaning of a type in OOP.

And I know that MonoBehaviour is designed that way, because it's just a thin wrapper around Unity's native layer. But I don't think it to be the same thing to say why it ended up as it is, and arguing that it should be as it is, even though there's other alternatives.

I do agree that we better be pragmatic in designing softwares.

But how come simply saying 'there's a working alternative with which you can apply more idiomatic C# approach in Unity' could be considered an adherence to some 'rigid dogma', while simply dismissing it by saying that I should accept the 'Unity's way' as the best approach is not?

Is the 'idiomatic C#' approach something inherently bad, or do you have any pragmatic reason why people should not try something like DI to adopt it more fully, if they choose?

If not, all it really means is that you don't like the approach yourself. While I admit that it can be a good enough reason for you to stick with the more common 'Unity's way', I don't think it entitles you to call any other alternatives as a 'rigid dogma'.

 

This reminded me that I was thinking a while back I should have spent a year building a custom layer... basically my own programming language and api in perhaps even in the form of an interpreted language.

Classes, interfaces, DI and so forth can be good and they are interesting in their own way but I get tired of all of that stuff. I think that is another reason for my view and why I ended up stripping everything down to a purely procedural programming methodology.

I am guessing the rest of you never get bored with all of this stuff and find the idea of switching to pure procedural even Assembly perhaps as being refreshing. Just for "something different". Change of pace. Different problems to solve.

Anyway I think I will spend some time working in other tech for a while at least and maybe forever. I don't know. N6 looks very interesting and maybe even check out that PICO-8 virtual console at some point. I do kind of like the idea of making my own very high level yet very simple programming language and api that compiles to something else such as N6 or even Unity.

For me it is mainly about making this fun again.

 

I'm not saying "embrace the unity way". I'm trying to explain that your mental model for what a MonoBehaviour is - that model is inaccurate.

Subclassing from MonoBehaviour doesn't say you are "interested in animation events" or "interested in handling mouse behaviour" - it says you are interested in registering for callbacks from the unity engine.

That's all it says. It does not make assumption about which callbacks you want, nor does subclassing it tell you anything about the game play responsibilities.

What it tells you is that the class is registering itself for Unity events and that it exists in the context of Unity's transform hierarchy. That's what subclassing monobehaviour means.

That you may choose to implement your animation logic in a subclass of monobehaviour in the callback for IK messages is your implementation choice.

Your mixing vastly different levels of abstraction together.

EDIT-----

Why would you want this to be a monobehaviour at all? A set of player stats has no relationship to unity events and should probably not have position data.

I would go further to say that making this 'stat' object a monobehaviour is incorrect. Even if you want to expose it in editor, it shouldn't be a monobehaviour.

 

BTW is it possible to drive unity entirely by code? or the IDE is non avoidable for basic set up (ie at least place 1 GO to write in the script you would attached, controls, build set up, graphics quality set up, input configuration, etc ...)

 

@mysticfall I think maybe what you are comparing is apples to oranges. The way you know a particular monobehaviour is interested in Animation events is by looking at the code or else looking out in the inspector. Some things are hidden from the code as part of their composition model.

So you spend time working in the editor specifically the inspector and that is how you look at (inspect) your various monobehaviour scripts and see which each deals with. If one has an AnimationController or whatever it is dealing with Animation (or else the developer shouldn't have added that component). If you see a SpriteRenderer then its area of concern is a sprite. By looking at the other properties exposed from the script you can probably see a narrower focus for that particular script.

At least that is what I got out of it.