Add Properties to a GameObject

"Talk about the pot calling the kettle black..." seems to be a similar saying to what I had in mind.
So perhaps...

Gotcha?

I didn't miss it. I just don't understand the inconsistent explanations and requirements you're posting, because they contain contradictory statements, as pointed out multiple times.

The reason you came here was that you cannot subclass GameObject.
The question we asked multiple times is, why do even think that a subclassed GameObject could solve the problem any better than a component in the first place (this being your reasoning to call everything else a kludge, and bad OOP).

You still haven't given an answer after all the time. Heck, you haven't even posted any useful pseudo code. Only how your methods look like, which isn't really useful because, you know, these method can simply move to a different type.

So yes, t's just a different type you deal with, everything else is a blackbox. For the desired functionality, it doesn't matter whether your manager references a subclassed GameObject, a subclassed MonoBehaviour, an interface type, a plain class...

 

I had hoped YOU were not an automaton. Ah well.

And as I mentioned earlier it is disappointing that you cannot see why the proffered "solutions" do not fit the requirements. Such, along with the originally proposed kludge, has been accepted though, with an open request to anyone else to provide a better one.

 

Is that really what you believe? Everyone here is providing solutions based on what you've been posting. Different approaches. In other words, if you believe the solutions don't work, either your real requirements are not what you posted, or you don't understand them.

Make a short list, we'll go through it. I can tell you what works, and what's contradictory.

 

A definition of insanity is doing the same thing over and over and expecting a different result. We're good.

I'm quite comfortable that I have presented my requirements sufficiently and that the proposed solutions do not improve on the selected kludge.

 

Ahh! Like this?

(I know you were referring to my offer of re-iterating your requirements... but this fits just as good.)

Dunning-Kruger Effect

 

In one breath, you call the kludge obvious given the limitation. In the next you state that the posts have improved upon the kludge

I'm sorry your automaton behavior gave you no choice in posting this.

 

Inheritance is not a silver bullet, actually its most often just clutters the domain and make it unmaintainable. Also, compositions is more flexible.

Take this real world example from our game.

Let's say we didn't use composition but inheritance. You have a Handgrenade base class, a frag and smoke grenade subclass. One explodes and kills evruthing within a radius etc, the other one emits smoke.

Now you want a c4 for your search and destroy gamemode. It has the same explosive nature as a frag but none of the Handgrenade attributes. How do you solve this with inheritance?

 

::sigh::

What I hoped you would realize (but apparently didn't), is that your original idea cannot solve the problem any better.

You pointed out multiple times that all kludges suffer from a particular problem, as follows below, but well, what everyone can tell for sure is that your GO subclass would suffer from it just as well.

That is:
If your subclass can solve the problem, you can solve this with a "kludge" as well.
If a "kludge" cannot solve it, your GO subclass cannot solve it either.

Why's that? Because you're merely moving the logic to another type.

What I'm referring to in particular:

And this:

Once again, if your "kludge" must to do it that way, your subclass approach must do so, too.

An additional information regarding that second quote:
Even if you had to integrate component identifiers, you wouldn't end up with "impossibly large datasets". The overhead for identifiers can be a tiny fraction of the total size, given that you use the right tool.
And it's even the opposite, it allows to apply various data size reduction techniques, like those required in networking systems.

Of course you need to know the right tools, and it certainly takes time and research to find a suitable solution.

 

Who stated inheritance was a "silver bullet"?

Looping is not a "silver bullet". Floating point math, is not a silver bullet. They each have their uses for which they are very well suited. This is one of them.

 

This is categorically false. The same system built around inheritance would not require a manager class to maintain it. Placing indexing data in the dataset does indeed create "impossible large datasets". That you don't know what data is being stored, yet state this with certainty should tip a small alarm off.

Perhaps someone who hasn't created networking systems that have found their way into hundreds of millions of products could jump to such a conclusion.

 

If this is one of those cases, then it should be obvious how you implement it, so what's stopping you again?

 

As has been repeated occasionally, Unity does not offer inheritance on its GameObjetcs. Perhaps you mixed pronouns..

 

That is obviously gonna be your GO which
1) either knows other component-like types, hence needs to access them in some way (which you probably are going to deny, because "components!" "kludge!"),
2) or implements completely everything through inheritance (which would yet again be contradictory to some statements you made).

Choose your fate.

The fact that you've never shown a useful example of your ideal inheritance based solution compared to your kludge speaks for itself.

Make a GO vs Component example illustrating why one cannot do the other. At least try to get out of your comfort zone. It's been requested so many times, yet you don't (or can't) do it.

Apparently, the alarms ring somewhere else if you cannot even remember what you posted, and what not...

I'm not surprised at all you're struggling so hard.

Well, let's leave out all the personal experience I've made over the past years (including lots of networking).

You know, there's something called research, scientific papers, case studies, even open source projects you can look into.
But well, if you wanna talk all of these down... yeah, how could I just forget that, you know everything better. That's why you also come up with your own terms and definitions for everything. Keep living in your own illusionary world... what was it called again?

 

My post was meant to be sarcastic (I almost always use that emoji when being either sarcastic or joking). Clearly it's not a silver bullet because it's not a path you're able to take with Unity.

 

OOP 101 = Inheritance.

 

OOP 101 = Object Identity, Encapsulation, Abstraction, Inheritance, Polymorphism

And in more modern days Composition.

There's more to OOP than just Inheritance.

 

I think a good correlation is in order.

In your other thread about component ordering I mentioned how the component ordering isn't guaranteed. Because my years of experience with Unity lead me to this conclusion because that's how it was.

But @Joe-Censored came along and corrected me, pointing out that Unity changed it, and that now the order is preserved. And sourced documentation demonstrating as such (if only placed in a weird location in the documentation).

My response wasn't "new stuff be damned!" but rather instead "oh, nice, that's a good new piece of information to learn."

That's composition.

Sure it wasn't originally when OOP was dreamt up back in the 60's and 70's... but today, Composition is a huge part of OOP. Computer scientists by and large have come to that agreement. And it's why more modern oop languages build in composition helpers like interfaces and the sort... or languages like golang where Composition takes the forefront (you don't directly inherit in golang, instead inheritance is implied by compositing the type you want to inherit).

 

If you took your OOP course in the last 25 years your curriculum should probably have included the Gang of Four book about design patterns, and in the first chapter they discuss the principle of composition over inheritance(although that chapter is also about interfaces, so you probably didn't read it). Based on your posting you probably think you know better, though.

 

I'm just seeing someone who's desperate and obviously incapable of throwing in some useful information in order to back up his arguments.

Instead, the best you're able to come up with are poor und failed attempts to discredit someone, while you actually just demonstrate your own incompetence in this particular matter and apparently that you're also incapable of reading what you're replying to.

That's just sad on the one hand, on the other it's a sign of pure ignorance with which you're trying to protect your false view of OOP.

Talking about inheritance basics, you should have covered the various different types of associations between objects which can be used 1) as an alternative 2) to accomplish flexibility so that you do not need to inherit again and again. So we can utilize other modular units in order to not repeat code and at the same time, it enables us to adhere to several important principles in software engineering.

But I guess that's "kludged" OOP for you, too.

I think it's time that someone (perhaps @hippocoder) decides whether this is still a useful discussion or not. Apparently it's not, since you don't wanna listen to recommendations, nor do you post any practical examples of how your ideal solutions look like.

I can only repeat that you'd face the same problems with a subclassed GO if you were able to do so. There's no point in debating whether or not it's true.

 

Discussion is obviously not going anywhere but I would suggest people just stop replying really. Spend time on own projects etc.

 

Of course there is more. However it is a part that one must kludge around when not present.

 

On the other hand, if component ordering was a standard feature of Unity and it suddenly wasn't, you can bet there would be a good number of people here asking for a "kludge" that gave them such functionality.

And then there'd be you stating it's silly to emulate such a method...

(see floating point example above.)

 

I agree it's silly to debate it further. It's false, and you should have come to that realization posts ago. I don't hold your inexperience against you. In any event since you seem to think commenting on behavior is fair game, you might want to ask yourself, what keeps you coming back for post after post when the OP, me, stated pages ago, I have implemented a working kludge, and your assistance was no longer required.

I have asked others who might have better kludges to work around this limitation to post or to PM me. What exactly did you hope to gain by your last post?

 

To think that composition is uniformly better in all situations to composition is simply incorrect.

 

As already stated, not only by me:
If your kludge needs to access a list of components, your subclassed GO would need to do that as well.
If your subclassed GO would not need to do it because you solve it with inheritance, the closest "kludge" can solve it with the same approach.

Code your ideal solution, replace the base class. That's all it takes (plus accessing the GO's own properties via gameObject.xyz instead of just xyz).

The fact that this is interchangeable is not a Unity-specific thing. It's merely a different base class, plain dead-simple C# basics. It is not an opinion, that's how the language works.

I kept coming back because i had hoped to make you understand that the above is true. After all we're a community to help each other, and this works fairly well with almost everyone here.

I'm just fine with my knowledge about the language and the engine, heading towards a decade. I understand what I'm doing.

Some of the others who have posted have well over 10 and 15 years of coding.

Anyway, good luck with your project.

 

JavaScript is a Prototype language it does not have classical inheritance. Its still regarded as a object oriented language. You can achieve inheritance through prototype declaration but its not required and it differs from C++ and C# in many ways. Inheritance != OOP

 

The subclassed GO would not have components. Why do you believe it would need access to components that do not exist?

 

Inheritance is a foundation concept in OOP. As mentioned many times, it is not the whole of OOP, but when that tool is removed from the toolbox, you need to find a kludge to work around the deficiency.

I've worked in languages with no floating point math. It was still a programming language, and when you needed floating point you still had to find a "kludge" to work around it not being there.

 

Well, composition is a much better tool than inheritance, so learn to embrace it.

 

I overheard two of my friends talking one day.
One stated he wanted to go buy a Coldplay album, and asked where the best place to buy one.

The other stated Coldplay sucks and he shouldn't go buy a Coldplay album, classical music was much better.

My friend stated he did not want to listen to classical music, he wanted to listen to Coldplay, where was the best place to buy a Coldplay album?

The other berated him. Haven't you heard of jazz or swing? Any of those let you listen to music, and better music than Coldplay!

"But I'm not looking to listen to any music", the first said, "I want to buy a Coldplay album and listen to Coldplay."

"I've already given you multiple answers to your question", the second roared. Coldplay is OLD music. Good musical tastes dictate you listen to some other group, the second persisted.

So my friend asked me.

"Eh, The only local store I know that might carry those is on the corner of 4th and Broad.", I told him.

He went to the store, and bought a Coldplay album and listened to it.

The second friend came to this thread evidently.

 

Has that advice ever truly worked on these forums?

 

you guys are getting super trolled by this guy right now lmao

 

But its comic gold though

 

Not so far in this thread...

 

Because you keep saying over and over again that the kludges require to maintain lists of components, which you don't like.

And we keep saying: if your ideal solution doesn't need components, the closest solution available (subclassing anything else instead, e.g. MonoBehaviour) doesn't necessarily require any additional components either. Just move the implementation and it'd work just as fine without additional components.

The other way around: if your kludge requires additional components, the same sort of implementation for a subclassed GO would require components as well. And that's what I was getting at in the post that you quoted.

 

Except as mentioned before it does not. Same requirements as laid out previously for the Game Manager to not be required to know the internal structure of the GameObject.

 

In case you refer to the statement that your go subclass wouldn't need to maintain a list, yes you mentioned it. And our response is: the "kludge" wouldn't need it either. Perhaps we're talking past each other. I don't know.

 

It would seem that way. With inheritance, there would be no component list to maintain (as there would be no components)

 

But why do you think that another type all of a sudden requires components? Treat one type as if it was the GO type you desire, and it can satisfy all your needs. You can implement everything that you'd implement in a GO's derived type.

Switching to another base type doesn't force you all of a sudden into a completely different architecture. You'd literally just move all the code to that type, and you'd be done.

 

Because, as you and others have stated repeatedly, you cannot add a property to the GameObject. Instead you must add it to a component. See the previous 4 pages of the thread.

 

It's only one type (doesn't even need to be a unity component) that you need for your way of doing things, not multiple types and/or components, if you wish to go ahead with the architectural decision's you'd have made with the subclass of GO.

Just like you'd only need ONE subclass of your GO in your ideal solution, you'll only need that one subclass of (for example) MonoBehaviour, or anything that you wish.

Sure, it's been suggested that forcing everything into a single hierarchy is most-likely sub-optimal, as you'll sooner or later probably realize, hence we said you can compose that entire thing of multiple components (can != have to), but that's a different topic we won't need to discuss here, due to some very obvious reasons.

Strictly speaking, since you said the ReplayStateManager is not supposed to know anything about the objects it deals with, except for those particular methods in order to set/get replay state, we can even go back to what has been suggested way earlier: an interface.

It'll no longer be the "closest" solution as in "the only thing that needs to change is the base class of your implementation", but it's (from the perspective of various common and important software principles, like SOLID) the most flexible, and likely the most ideal, as it doesn't force a specific base type and constraints access to that tiny yet only relevant piece of API.

As a consequence, this would eliminate that whole discussion about whether GO or Component is the right choice for the base class, but interfaces... we had that discussion already and you still considered them as kludge (they're fundamental in C# and many languages).

That is, your replay state manager could even be used for non-unity objects, you could even use it in different projects (e.g. console apps, winforms, wpf... anything that runs C# or accepts .Net assemblies), because an interface is not bound to any type that implements it. That's the greatest advantage of them, compared to using base types in C#.

*Edit*
I'm curious: Do you have a C++ background?

 

I doubt it:

Serious C++ work without interfaces?

 

Definitely not.

Though I still know some people who don't want to accept that term when talking about C++, or haven't ever really used it, even though that's just what describes the concept very accurately. They prefer talking about it using lengthy descriptions of what requirements such class/struct needs to match.

Anyway, you're not that far off. Some posts made me think that he might have worked with multiple inheritance (so very likely with "interfaces" as well). That'd explain some of the posts, because in the context of a language such as C++ they'd make sense, whereas in the context of C# they're contradictory to some degree.

Just trying to get to the root of the problem. Perhaps that's the right track...

 

Yeah, I read back some of his posts when he started to tell me to eff off in this thread and this is the reason I told that he's seeing nails everywhere. He finally learned how to use the hammer. This is common among relatively fresh developers. They learn a "new" thing and they learn the "academy" and then they try to push trough the cube on the round hole because they are familiar with the round hole. Eventually he will learn more and will see that choosing the tool for the job is a necessity.

 

Relatively fresh self-taught developers at that. I remember having a similar "inheritence is clearly the best way" mentality back when I first started learning C++ (prior to that my experience was limited solely to structured languages). I barely interacted online at the time too so it wasn't until Unity that I started actively using composition.

By that point though I had already run into C#, had run into the concept of composition when creating UIs, and was no longer completely focused on inheritence. The OP will eventually reach that point but it's likely going to take a while.

 

Maybe. I guess I was lucky because I am a mostly self-taught as well, but I started two different languages very early on And very different paradigms. C64 Basic and C64 Assembly. I guess the constant battle to choose the right tool for the right job taught me this early on. You know, Basic was easy to write but slow as hell, ASM was pain in the butt to write but it was fast(er) to run, so I had to choose when to use which. And then I carried this "open mind" and "natural" inclination to to choose the optimal way I can get and even think about if I can have more optimal way in a given situation. Well, I guess.

 

Oh I see what you're saying.

(I'm curious, does that brush you off yet?)

 

Actually 30+ years experience with more products in the field than I'd imagine the majority of the posters in the thread have. I don't hold your youth and experience against you all though.

 

And please make up your mind if it needs components or doesn't need components, then feel free to get back to me.

 

I ran into a lot of rookies like you back in the day. They'd find a shiny new tool and suddenly it was the right tool for every job. It was fun to watch the maturation process as they realized different tools were better for different jobs.

Now if you mean relatively fresh to Unity, yes. Thus asking how to kludge around its limitations.