Delegates, virtual, events etc?

Can someone explain to me all these:
1. delegates
2. enumerator
3. inheritance
4.polymorphism
5.Ienumerator
6.protected,virtual

in relation to game programming?
unity tutorials doesn't do me well...i'm not sure how to imagine Delegates using += to add events....

 

You mean the topics individually, in relation, or in relation specifically to delegates?

 

Could you give a little insight about your programming background? It would help to direct you to sources that take into account your knowledge level and explain with familiar terms.

You could start with checking f.e. C# fundamentals on MVA - lessons 14-16, 21, 23 immediately come to mind from the topics you mentioned.

 

You topic list can be splitted into two parts:

Object Oriented Programming (OOP):
-inheritance
-polymorphism
-protected,virtual

OOP is the current programming trend. Nowadays, it is essential for a programmer to master this methodology. I would suggest learning the concepts involved in the following order: class, object, member (property/method), encapsulation, inheritance, polymorphism.

The second part are C# specificities:
-delegates (see also lambda expression), these are often use to manage events.
-IEnumerator/Enumerator, used to generate listing, used in Unity to implement coroutines.

Overall, these topics involve a lot of concepts that can not be explained in one forum post. You would require to follow a complete introductory course to programming to understand them properly.

 

May I suggest figuring some of those out as you go along? lol, here's why I say that...

Lets start with delegates...didn't even know what they were until I needed them. But first you have to have something your tying to accomplish. Otherwise your just getting theory.

In my case, I was working on an editor tool that needed to be able to add persistent and non persistent listeners,

Code (csharp):

1.  
2. Overall.onValueChanged.AddListener(delegate {girl.GetComponent<BoneMorpher3>().XIn(Overall.value);});
3.  

Overall = a ui slider
girl = gameobject(rigged model)
BoneMorpher = the script that had the function I was trying to add to the slider
XIn() = the function from bonemorpher I'm trying to add...

in that case I used delegate to add the function. Why? Its like a container for the function. If I tried to give you a lego set without the box, it would be nothing but a mess. A container makes it manageable, in this case both for you and the script. I'm hoping that made sense, it did in my head before I typed it <_<

So rather then just trying to absorb it all at once without any context, which without a proper programming background will likely do you more harm then good, create a context. Just a suggestion <_<

 

This is like a semester's worth of information. Polymorphism and inheritance alone took up most of my 101 class when I went to Uni.

The (very short) version is that you code up an is-a relationship to share code; so both a wolf and a sheep is an animal.

It's not the only way to share code - and often it's the wrong way - but it's a must-have tool to write complex C# programs. If you're just starting out programming, I'd suggest focusing on the fundamentals first.

 

Delegates:
https://msdn.microsoft.com/en-us/library/ms173171.aspx

Enumerator and IEnumerator (to understand the difference between the 2, you need to know Inheritance and Polymorphism):
https://msdn.microsoft.com/en-us/library/system.collections.ienumerator(v=vs.110).aspx

Inheritance:
https://msdn.microsoft.com/en-us/library/ms173149.aspx

Polymorphism:
https://msdn.microsoft.com/en-us/library/ms173152.aspx

Access Modifiers (protected):
https://msdn.microsoft.com/en-us/library/ms173121.aspx

virtual:
https://msdn.microsoft.com/en-us/library/9fkccyh4.aspx



First do your own research... THEN come back with any specific questions you have...

 

Boss. Jesus, you just rape these forums...

 

Hm,,, more like real examples in game development...
in Unity tutorials they don't clarify that so well... or the mathemathic abstracts just escapes me.
I need some game-like explanation... Something pop culturish and imaginable.

Like, do you use delegates or polymorphism in building an ocarina of time? which part exactly?
What's its purpose in a game? Something like that.
I know it's all guesswork but i guess i can get better image with it.

Thank you for the link. I got into programming just for game making purpose thanks, nothing else.
so far i manage to understand generics operations...and its "arguments" still baffles me.
refs, outs, enter...i'm still not clear with parameters.
I've been programming for at least a month. Manage to play with character velocity and arrays, animation related events.

Somehow, i'm forced to take that code of yours as being rather.... suggestive...
Seems like an intersting design... But the lego analogy is so distracting. What i got about delegate is its multifunctioning design, something like how Raycast can acquire different varible datasets and pattern... or is that polymorphism?

...Share what?
And yes, both wolf and sheep is an animal yes... OOP basically about designing the data around/inside a class to indetify it..is it? Although i don't have any comparison to that though process...
C# is basically my first language... and unity made it easier for actual visual application in runtime, while playing around static Main and Console.writeline in Visual C# is more into its computational thinking...

Well, i guess, nothing comes easy.

 

uh....okay. 1) didn't mention lego's at all in an analogy, 2) and nothing like a raycast 3) And I have no idea how that was suggestive, it was a line of code actually being used and broken down to a fair thee well...so...yea.

and in regards to "I got into programming for game design, nothing else" yet you don't know what that entails, so how are you going to discount the resources you were offered? It seems like your looking for someone to hold your hand and walk you through making your first game. If your not willing to read the resources their giving you because "your not interested in that" then perhaps do as so many of us end up doing, and figuring it out with the power of google? You say the resources aren't there, yet so many of us seem to find and use them...so, I'm forced to think what your real problem is effort. It takes hours to master any craft, if thats not something your interested in, may I suggest getting a programmer? If you want to make a game yourself, know that it entails LOTS of different arts and skillsets. If this part is to much of a challenge, I really don't know what to tell you. Good luck with that, I suppose?

Lord of Duct does tend to be a bit...short with his patience, but I have to grant him, he has a hell of a point in this instance <_<

P.S. - I double checked with my projects modeler who has gentler people skills to verify I wasn't being to harsh...I've been assured, no, no I wasnt.... <_<

 

@RavenMikal One gets the idea... if one's so inclined... Hopefully, you didn't use any string nor rigidbody, otherwise you might need to rate your code "Pegi 18+".

 

bwhahahahaha....lol...get your brains out of the gutter! lol

the model was a female model, the script attached to it morphs the bones scale, and that line was to effect only the X scale field...does make for a hella dirty joke, though...

and I totally used a rigidbody...ribbed for her pleasure. !!!!

Thanks for spelling it out for me...

Got so caught up on details, I actually failed to notice it...but I can't bring myself to apologize... =p

*sighs* yea, you may be right about that rating...lol

What makes it worse? The editor script is called "RackMaker.cs" >_< lol

 

A free book about c# programming for those who are tired of video tutorials... there is not a duck on the cover any more...but bananas are also yellow:

http://www.robmiles.com/c-yellow-book/

 

Haha as @ericbegue clarified it. Only a few has too much attention to such implied details...

@RavenMikal And you said i needed "a holding hand". Honestly so far my problem in developing anything at all has been about taking in too much unnecessary details and is unable to rely on other people to work with me.
And yet now i am asking the crucial questions, and it seems like instead of "game like" insight, i'm being given yet such more "life abstracts" descriptions, which i fail to accept to a certain level.
Call me dyslexic, or stupid, but they just don't make good presentation, and i don't understand them at all even after rewatching and rereading it all.

Your code had given a bit of light, maybe abit too technical.
I guess this thread is more about, gathering crude insights on how to apply it all into a game engineering, rather than system/computational programming paradigms, logics and whatnot.
Since the two looks and feels similar, but does not work the same way.
Much like how a professor in analythic mathematic or rocket scientist may not be equipped with the intuition to study game programming.

And no, you aren't being harsh. None of you are.
Just bits distracting like those links you copied and paste. Not very game logic and application.
Only some of it gives away abit more insight in abstract like extension methods, polymorphism, inheritance and delegates.
I went through MDSN abit, and i think i get more understanding of variables and methods from it than from unity's tutorial.


It is all simply a matter of insights...i'm just looking for comparative ideas and...analogies to help me study.
Maybe that's too much trouble, but i had imagined it would be more fun and somewhat creative way of learning.

 

Game programming is a software engineering process. I would even add that programming a game requires even more mathematical abstractions than regular softwares. For instance you need to have some fundamental knowledge about Linear Algebra just to be able to place and move your game objects around. You need to know about Computational Geometry if you want to process your 3D meshes and such...

To use Unity, it's a requirement that you have some solid basis in programming. There's is no way around this; if you want to program a game, you need to know how to program in the first place.

I don't want to discourage you. I am just warning you that game programming is not always as fun as you might think, and you need to learn the "boring" and "abstract" programming concepts, and that even more than a programmer that does not program games.

 

@metamorphist - this

I'm more than happy to discuss these topics above, but they're HUGE topics that have been discussed to death on the internet. May they pertain to video game development or any other kind of development.

We don't know the depth of your understanding of any of those topics, especially the deep ones like polymorphism and inheritance.

I included links to the basics, the foundation upon which any and all oop programming in C#/.Net, may it be video games or business software, so that we have something to build the discussion on. Read them (unless you already have), then form more specific questions about how a single topic out of those many may pertain to game development.

Otherwise... give me a month to write you a novel that covers all 6 topics, as well as going into other topics that those topics deal with.

And even then I probably won't answer your question well enough... and you'll STILL have to put in the work by reading those pages and pages of text...

I love talking about this stuff, look at my post count, I have over 3000 posts on this forum alone (and 10's of thousands more on other forums) discussing programming. I'm known on every forum I go to for my walls'o'text, because I'll go on and on about a topic... hell, I'm going on and on about how you should give me something to talk about.

So, please, give me a question to answer. I'm MORE than happy to give you an answer... but don't just walk in the room and say, "Evolution, Geology, Biology, frogs, toads, dirt... can you explain these things, and how they pertain to the meaning of life?"

...

Or, even better, because I find it so damn ironic.

Someone on another forum I frequent, introduced me to this article when informing another user of why we as forum users ask for well formed questions:
http://www.catb.org/esr/faqs/smart-questions.html

I then pointed out how funny it was that the article was enormous, as anyone who doesn't want to put in the leg work to research or ask a specific question probably doesn't want to read something that long.

But srsly... read it. At least read the "Introduction" if anything at all (replacing the word "hackers" with "forum users" or "lordofduct").

 

@ericbegue It's not exactly boring. I just need something concrete.
I even buy scripts and download assets just to read other people's work. And not all of it is profound.

But i guess it's like what @lordofduct says, it could take novels to explain everything, and i have to say that bits of analogy clarified a bit more about the rest and before.
Just a minute ago someone by the name @TonyLi wrote examples of codes about animation states and its relations to how it executes and actions, an entire framework... And i am mentioning him for the credit he deserve.
His whole answer was so well coded, even if rather hacky, i'm not even sure how to reply it.
I do understand it though, since it uses mostly generics and simple overloads... but once it gets to interfaces and overrides, it gets confusing. I guess the wisdom just don't come as easy, but like what i said, i came to gather some examples...

Maybe an idea, way of thinking.

What is a well formed questions? Now that's tough too...
Do i ask when i get an error? The unity answer is so dead or mine is just a desert.
Or do i throw a whole chunk of codes and let you solve it?
I find it rather crude, as i am not well equipped with enough skills.
Lots of examples, lots of ideas.

Perhaps a focus, yes.


Something rather specifics.
But again, as you say maybe this is just the irony,
i can listen to a video about polymorphism for months, and would never get the right question to ask.

 

OK...

how about this, I'll ask you some questions.

I'm going to pick the topic of polymorphism, since you mention both 'interfaces' and 'polymorphism' in your post.

Let's get specific with your question by starting with focusing on ONE of your topics, rather than all of them.

So...

What do you know of polymorphism?

Consider what is said in the article I posted on it earlier:
https://msdn.microsoft.com/en-us/library/ms173152.aspx

Try to explain it to me in your own words. And we'll try to point out the flaws, as well as expand on the topic from your starting point, and even try to tie it in to video games.

 

This actually a good idea.

But about polymorphism,
I honestly have no distinct ideas. It has the colon marks like when we call the MonoBehaviours.
And when you removed the MonoBehaviour, it 'll lose access to alot of statics, generics and enums already in the system.
it seems like it grants a classification to a class, all its methods and stufss..

But then, what about namespaces? What about a class or a static?
Does the colon makes it all different? The way something is called into the script?

I'm already at lost, since after that there's derived, virtual and override included.
It's like a dictionary where i have to keep looking back to previous topics, but either one does not have something really concrete since they're both advanced. And i'm not so sure if i have to use it, since my game project too, has not been above anything but Vector maths.

And you know, what, english is not my native, if you haven't figured it out.
So i'm trying to look for something more universal to have it explained. Like game.

 

You're mixing up inheritance and polymorphism (though they're very much related).

When you say:

Code (csharp):

1.  
2. public class Enemy : MonoBehaviour
3. {
4. ...
5.  

This is inheritance, you're saying that Enemy inherits the functionality of MonoBehaviour. This way an object that is an Enemy can do all the things a MonoBehaviour can.

Here in lies polymorphism now.

Polymorphism is the idea that you can treat like objects like they're similar.

Anything that inherits from MonoBehaviour can be treated like a MonoBehaviour. If I needed to get a list of all 'scripts' attached to a GameObject and change the 'enabled' property to false (disabling all the scripts)... I don't need to know the specific type of each script on the GameObject. I just need to know that they're a MonoBehaviour:

Code (csharp):

1.  
2. foreach(var c in this.GetComponents<MonoBehaviour>())
3. {
4.     c.enabled = false;
5. }
6.  

THIS is polymorphism, in its most basic form.

In an exanded form it could be overriding a method from a class you've inherited from. So the objects are treated the same, but act different.

Polymorphism doesn't just have to do with inheritance from a class though. It can also do with the implementation of a 'interface'. Because really, the outside access of an object is through its interface (public methods, properties, and fields), you could have 2 completely different objects inheritance wise, but similar in interface.

For example an 'IList'. Array, List, Dictionary, etc all don't inherit from some like type, yet they all can be treated like an IList because they all implement similar methods to one another. Thusly they can be treated similarly.

For example, all 'IList' objects have a 'Count' property telling you how many elements are in it. They all can also be enumerated over. You don't need to know that you're looping over an Array vs a List... you just need to know it's enumerable (IEnumerable, IList the interface inherits the interface of IEnumerable).
https://msdn.microsoft.com/en-us/library/system.collections.ilist(v=vs.110).aspx

 

Polymorphism = several-shapes-ism (in simple English ). Does that tell you more? No, it doesn't. Then not understanding what it means is not a human language problem. It does not matter whether you are native English or not. I think you know enough of English to learn about the meaning of polymorphism.

About the semi-colon problem, that's just syntax. The semi-colon is a shortcut for "Is a" or "Inherits from". You won't learn nothing by staring at the code. Note that a programming language is often designed to allow a programmer to type code faster; the shorter the better. The source code is unfortunately the less expressive part of a software, therefore is not the best place to learn the fundamental concepts from.

If you don't know what inheritance means, there's no way you are going to understand what polymorphism is. Are you sure you know what an object is? What a class is?

You have to take your learning process step by step. And you can't skip one step. And it's not possible to learn several concepts at once; like physically/biologically impossible. You need time to absorb one concept after another, like anybody does.

I would suggest to first focus on two concepts: object and class. Once you've mastered these two concepts we can go on with more complex concepts. You have plenty of websites and videos on internet explaining these. And if you're stuck somewhere, you can always ask on this forum for clarifications and more guidance.

 

Thank @ericbegue, but i actually enjoy @lordofduct approach. I am considering to ask/question in that manner to next time. And wow, semi colon? You meant colon? this : or ;? i thought semi colon is to end a statement?
Honestly, i'm a noob, so any slight misexplanation can blow me ashore. Something i am very afraid of since i really need to complete a game.

So when using a colon, on things like
inheritance, interface, : ikillable, iequalable, it actually meant "is a"?
That's super cool and neat.
I honestly think staring at codes help if i can read it all in full human language spelling, somewhat narrative approach.
Rather than saying parentheses, brackets. I even download existing game framework just to read the codes, since they are not so very intuitive for me to use.

What's more distracting from polymorphism is how it can upcast and downcasts using parentheseses, it's so hard to read and understand.

Code (CSharp):

1. foreach(var c in this.GetComponents<MonoBehaviour>())

That's polymorphism? i thought that's a loop, or a generic.
really, is it a class, a method? or a way of usage allowed by the system but already includes existing methods and declaration? Why do you downcast? why do you upcasts?
When do you do so? and why?

 

It's a great complement to ask questions here, as you can see. Although I suspect that you will miss so many important concepts, there are questions you wouldn't even think of asking etc. In the end you'd save time and headache by reading through a C# book, working through the examples..pretty much stuffing your brain with a "basic package", not overly concerned about the purpose.

 

@metamorphist yes, I meant colon ). Sorry about that. Yes, you can perfectly read it as "is a", "inherits from" or "implements" ( when used with interfaces).

I did not proposed an approach. I've just stated in which order the concepts has to be learned. The same way you've learned addition before multiplication (since multiplication is defined by addition), understanding polymorphism requires to know about object, class, inheritance and method overriding.

 

Polymorphism isn't a line of code.

Polymorphism is a concept.

OOP is a way of thinking about putting programs together (a specific language can facilitate that with constructs that make it easier to do so).

It's like we might have nouns, verbs, and adjectives in English. But these are just constructs like class, for loop, and variables.

Where as we may have formal and informal ways of speaking/writing English. These are more conceptual. Both generally follow the syntax and semantics of the language, but add in their own approach to how to word something to give it that "formal" or "informal" approach. You can't point at the word "be", "ain't", "dog", "lit", "cool", and call any formal or informal, it all hinges on how you use it... the context in which you find the words.


So no, that line of code is a basic for loop.

But it's ALSO demonstrates the most simple form of polymorhpism. The fact that objects that are like, can be treated like they're the same. When you call GetComponents<MonoBehaviour>(), you could get any number of objects back all of their own unique type (script type), but you can treat them all the same as a MonoBehaviour becuase they share that in common.

Of course there is a lot more to polymorphism than just that... that's just the simplest example.

Polymorphism as a design shows its power in things like overriding methods, implementing interfaces, and the sort. Where implementation can be vastly different despite similar likeness.

List, HashSet, and LinkedList all operate like a Collection... but they all act in vastly different ways. But if all I'm concerned about is if it's a collection... I don't have to care about which one it is. I just care about if I can put things in it.

 

@ericbegue Yea that make sense actually. Just about a few while ago i don't even understand anything about programming, slowly understanding arrays and classes, kinda opened my idea.
But just this few things, really, really hard. OOP itself is a concept, so to understand it all is like understanding a whole new language.
And apparently, the need to make a game, a specific genre of game, kinda make me need to rush the understanding.
But yeah, that made some sense in me, maybe if take bit sizes of learning again, i'll get better idea about polymorphism and these few things.

But then as @lordofduct say, i can acquire var c = GetComponent<MonoBehaviour>()?
I've never tried but does that mean that i can put MonoBehaviour as a component, and then my own class can inherit say : Character, and i can still use all of MonoBehaviour functioning but maybe with every c? each c will be able to do its own MonoBehaviour eh?
I seriously have never tried even removing MonoBehaviour because it seems like everything stops running and i can't see any reason not to include it.

 

That's what inheritance means. If your Character class inherits from MonoBehaviour, it means that Character is a MonoBehaviour, which implies that the Character class has all the characteristics of a MonoBehaviour (it has the same members: variables, methods and properties); it is by definition a MonoBehaviour. However, it does more than a MonoBehaviour, it is a MonoBehaviour specialized at being a Character.

If you remove the inheritance from MonoBehaviour, it is expected that it breaks everything, since Unity expects that a script is a MonoBehaviour attached to a GameObject.( Also, note that a MonoBehaviour inherits from Component, and only objects of type Component are attachable to GameObject).

 

We have not really cover polymorphism yet. Before that, it is required you have a firm grasp of inheritance and method overriding.

Let us know whether everything is clear for you about objects, classes and inheritance. If you want something clarified over these topics, fire your questions.

 

rofl! we need to rename this thread Programming C# 101 Spring Semester bwhahahaha....

With lectures from Prof. Lordofduct and Prof. Ericbegue, as well as other various guest speakers...

Huh...with them making a Unity Certification, I may only partially be joking... <_<

 

@RavenMikal Haha, could be, maybe.But i am not sure i've asked anything good, so this is more of a private lesson.
Um, what Unity Certification?

And to @ericbegue yeah, true, the more i read your explanations and compare it to the readings on mdsn, the more i begin to understand it's more of a "whole" concept that a singular method or delegate declaration...
On its own, its simply not a "thing"....

But that's fine, i think i'll keep learning about it.
linking classes and scripts around....

Meanwhile, when do one use delegates compared to interfaces and classes?
I noticed all of them are somewhat similar... with interface forcing you to implement everything, and delegates looks like this empty container for you to add methods and...variables?

Why not use classes instead everywhere? and then inherits around it...
Much more practical and direct?

And as for virtual and override, it seems like they are like, the animation override system, where you "override" existing clips and replace it... but according to MSDN, it can also "extend" the method...
It seems like making a class, but with a new method with the same name... like you make a vector3.transformdirection
but with...different result?

 

@RavenMikal definitely agree this thread is turning into a course .

@metamorphist , indeed OOP is whole thing, it's a paradigm. It takes time to learn and understand every aspect of it. So don't rush it.

Before attacking other concepts, I want to make sure you've acquired what object, class and inheritance are. So I have some questions for you. You have to make your answers as short and as meaningful as possible.

What is an object?
What is a class?
What is the difference between an object and a class?
What is an instance?

What methods can you call on an object of type B?

Code (CSharp):

1. class A
2. {
3.     public void Method1()
4.     {
5.     }
6. }
7.  
8. class B : A
9. {
10.     public void Method2()
11.     {
12.     }
13. }
14.  

Using the same class declarations as above, what methods can you call on the object o?

Code (CSharp):

1. A o = new B();

 

1. object, is...a concept? collections of datas and variables, and its relations in it
2. a class is structure, blueprint of sorts to generate or modify or instantiate an object's data.
3. a class can be an object, but an object is not always a class. one contains data behavior, the other one may contain only datas.
4. an instance is a copy.

5.

Code (CSharp):

1. void o(){
2. Method1();
3. Method2();
4. }

 

That's very broad, everything is a concept after all.

That's almost it. An object is a collection of data and processes. The data are the variables and the processes (or the actions you can do on that object) are given by its methods.

A blueprint is a perfect analogy. It could also be analogous to mold.

That just does not make sens.

Yeah... not quiet. Using the blueprint analogy, an object is the product you've build from the blueprint. An instance, is a concretisation of a class.

What is this?


You have not answered the following questions.

Overall, I think you have an idea of what a classes and objects are. But is not completely solid yet.
So far, I don't know how well you understand inheritance. So what would be your definition of it?

I would suggest to watch this playlist:
https://www.youtube.com/playlist?list=PL8m4NUhTQU48oiGCSgCP1FiJEcg_xJzyQ
Just watch it up to track 6, the other videos are not OOP.

The next step would be about encapsulation, this has to do with the keywords: public, private and protected.

Also, don't try to guess what stuff mean. Rather, get your definitions from online documentations or a from a book.

 

1, An object is a runtime instatiation of a class, you can have many objects from the same class instatiated at the same time.

2, A class is a code structure, you are right it operates like a blueprint, if you say myobject = new myclass() then myobject is the instance and myclass is the class that you are creating the instance from.

3, An object always comes from a class. A class cannot BE an object, an object is created FROM a class as in the answer above.

4, An instance is not a copy, it is an object. An object is an instance of a class.

The code you have pasted is not an object or a class, but is a method that calls other methods!

 

Reading this thread is interesting as it seems to highlight a misunderstanding amongst people who want to write games, and seems to pervade through even some professional developers.

Writing games is no different to writing any other program. All of the concepts are exactly the same, you may have different concerns with some games (performance being the most obvious) but code is still code. The only difference is that instead of using a framework for say a web application (ASP.Net MVC for example) you use a framework that allows you to render meshes and detect collisions in a loop (so a game engine, like Unity).

So the framework is different, the API is different, but the concepts remain. In fact you don't NEED a game engine per se, you could use Direct 3d or Direct 2d to render your game, which is the same technology used for things like Excel and the Edge browser.

I guess my (rather long winded) point is that learning to code in a non-game related course or tutorial will still teach you OOP or efficient memory management in c# or whatever else you want to learn and will apply the same to a game as any other application.

 

@DanHedges I completely agree.

 

Not that I want to confuse OP or anyone else...

but this is not true.

A delegate is an object, and is not from a class. A boxed value is an object, and is not from a class. An iterator/generator function is an object, but not from a class (well that one gets even more tricky when you look under the hood of it). You can have all sorts of objects that don't come from a class. And it all hinges on the language you're even in.

Furthermore, a class itself can technically be an object, distinct from objects instanced from the class. You can reference types. You can even define new types/classes at runtime (though due to restrictions in Unity on platforms like iOS and web, it's not allowed).



An object is more like a concept. You can get objects in all sorts of manners. For example a class implies that an object is to follow, but you could define classes that never instance to objects (like a static class).

An object is a set of data that represents 'state', and methods of accessing that data to modify its state.

A class creates objects that have fields (variables) that represent its state, and methods (functions/properties) to modify those fields.

An iterator/generator function creates objects that have the current yield statement it is on for a state, and is enumerable which modifies its state.

A delegate contains any multiple references to functions (and scope of those functions) as its state, and can be appended, redacted, and invoked, as ways to modify its state.

Even boxed values have state, the value that is boxed.

 

I think we will be going in circles until we backtrack a bit.

In order to understand polymorphism, we need to understand inheritance(which has been covered a bit) and type casting.

For example,

Code (CSharp):

1. class Foo : MonoBehaviour{}
2.  
3. class Test
4. {
5.     Foo coolFooObject;
6. }

What type is `coolFooObject`?

Spoiler: It is.....

A bit of a trick question for a new guy. `coolFooObject` is obviously an instance of type `Foo`. But it is also an implicit type of `MonoBehaviour`, `Behaviour`, `Component`, and `Object`.

This is the idea of polymorphism. We can treat `coolFooObject` as any of those types.

Why would we want to treat our `coolFooObject` as any of the others? Well, this would allow us to be agnostic in how we treat a group of unique objects. If we only care about enabling a group of Components, we can simply cast our specific scripts into the common type. Example:

Code (CSharp):

1. class A : MonoBehaviour{}
2. class B : MonoBehaviour{}
3.  
4. class Test
5. {
6.        A class1 = GetComponent<A>();
7.        B class2 = GetComponent<B>();
8.  
9.       List<Component> components = new List<Component>();
10.  
11.      components.Add((Component)A); //cast A into it's base type Component
12.      components.Add((Component)B); //cast B into it's base type Component
13.  
14.      foreach(Component c in components)
15.     {
16.              c.enable = true;
17.             //we are agnostic towards the true type of the object, as far as we are concerned they
18.             //are all just Components; however, they still are references to the complete object and
19.             //therefore we can cast them back into any type that they implement.
20.     }
21. }

This way, we can group a mass amount of objects together based on their common elements(in this case `Component`) and access their common properties. This is the tip of the iceberge of what you can do with this principle, as some outlined above.

Edit: Sorry, heading home now. Will try to get back to this later.

 

Agreed...

but after seeing the response from OP when I described polymorphism, with the expectation that OP read the links I had previously read.

I noticed OP has NOT read the links I posted before.

OP REALLY needs to read those links, as well as any basic entry level text (not tutorials... textbooks and the sort) on the C# language, and on OOP (which are distinct from one another!).

The topic is humongous, and with the mass numbers of people on the forum with varying levels of knowledge on the topic, OP, nor anyone coming here with zero understanding of the topic, is going to learn anything.

At best we can be used as a peer study group. A place to bounce our individual concepts we learned from text off one another. OP shouldn't be learning the foundation off of us, but rather discussing it with us to better solidify the foundation gained from some text book.

Otherwise you're going to get this "well ericbegue said this, and lordofduct said that, and DanHedges said this, and landon91235 said that... which one is the correct answer!?" And how do you parse that all out?

You need a concise narrative, like that found in a text book, to form the foundation. Then come to people like us with our own ideas (just like the author of the textbook) to then realize... this is all malleable, it's conceptual, and no one person actually will tell you the 100% factual this is it for all cases and possibilities... because there's not.

So OP, GO READ A TEXTBOOK ON THE TOPIC, then come back and ask any individual specific questions that you're struggling with.

And bugger this whole "I don't want to bother with anything none game related"... well it's all game related because it's programming. You don't know how to program, so you can't tell if the topic you're currently learning will be used for games. Then one day will come, years down the road, that you end up using it IN A GAME, and you go "ohhhhh, that's how it's related to games".


(and never forget, OOP isn't the only paradigm in the world... heck it ain't the only paradigm in C#)

 

@lordofduct Well, okay, I was trying to simplify it a bit for the OP and perhaps that statement was a little strong. Although delegates etc use classes under the hood... https://msdn.microsoft.com/en-us/library/system.delegate(v=vs.110).aspx

I don't agree that a class can be an object of itself, you can reference static methods on a class without instantiating it, but I don't think that makes it an object.

 

@lordofduct What you say is technically right for C#, and someone experienced like you perfectly understand all the subtleties that it implies without problems. But introducing theses technical implementation details for a beginner in OOP will only add more confusion. At a conceptual level a class is not an object, and it is better to make a clear distinction between class and object for a beginner to make the concept assimilation easier.

I agree that a forum is not the best place to learn the fundamentals (since discussions can get quickly noisy ) and that @metamorphist should acquire his fundamentals from a text book or a programming course instead. The forum should only be secondary.

 

I'm talking about System.Type, which is reference to a class.

And the System.Reflection and System.Reflection.Emit namespaces which can be used to reflect classes, and even create classes at runtime.

To both the quotes...
My point was better described in my following post. Where misinformation will creep because there's 20 people talking at the same time, all leaving out information to "simplify it" for OP.

Where as things get way more technical, and under the hood things get really weird. For example, as you point out all delegates inherit from System.Delegate, which is itself a class. But heck, all structs inherit from System.Object... heck EVERYTHING inherits from System.Object in some manner in C#... are stucts, enums, ints, etc all classes?

It's weird.

OP should NOT be consulting us for the fundamentals.

We leave out these technicalities... it gets confusing. We put them in, and it gets confusing. Especially when we make strong statements like "always" and "never"... which it isn't "always" and "never".

Because we're dealing with programming concepts, but then how those concepts are realized in ONE specific language.

 

OP you should read a few books.

Get a book on C#/.Net itself. Learn the language.

Get a few books on OOP, Gang of Four Design Patterns for example.

Get a book on functional programming (or just watch a tutorial), just to round out the concept that OOP isn't the only paradigm.

Get a book on fundamentals of discrete mathematics, I suggest "Concrete Mathematics" by Graham, Knuth, and Patashnik:
http://www.amazon.com/Concrete-Mathematics-Foundation-Computer-Science/dp/0201558025

"The Art of Programming" is also awesome to read slowly over time just to form a respect for programming:
http://www.amazon.com/Computer-Prog...985433&sr=1-1&keywords=The+Art+of+Programming

Get a book on assembly, a simple intro book (art of programming actually has its own assembly language it uses for example). So you can see, in human readable form, what's really going on at bare metal.

Maybe also check out books on some other languages like C++ and Java (to see where and why C# does the things it does). A book on VB.Net (it's easy to compare to C# since it's the same framework, but different language all together). And check out some completely different languages and paradigms (like Haskell, python, brainfuck, etc) to really understand that these are just expressive languages to describe simple machine codes and none of what you learn really is hard truth and is going to change at any moment.

Progress through them at the order I describe... it's going to take TIME.

And this goes for anyone out there.

Come talk to us about things you find interesting, or are struggling with.

But trash this whole idea any of us are going to be RIGHT about anything. We're all morons typing on keyboards because we're bored at home.

 

Sorry, just drank a redbull, I'm TWEAKING right now.

 

Surely you are not suggesting that the first stage in learning game development is learning to program... ;-)

 

And if you don't want to do all that leg work... and you just want to get to scripting.

Then really... IGNORE OOP in general. Ignore other paradigms outside of imperative. Ignore all this heavy lifting. And just go write some code. Be a script monkey, and script away.

Really, in Unity, to get most work done you actually don't need all this stuff. You can stick to really simple imperative code written on a script per script basis.

You won't become a highly skilled programmer doing this, but you'll definitely get some games made.

But if you expect to make huge massive games with huge massive and complicated systems in it... well, you're going to have to learn the fundamentals.

 

Why not?

Concepts and implementations are two things. if you don't have your concepts right in the first place, the implementation will surely be wrong. Also, you can apply OOP principles in non-OOP language like in pure C. To understand the concepts, you don't need an implementation at all.

That's right, Unity does not strictly follow OOP principles, which is a good thing for us . Though, having good grasp of OOP can only be positive and be great addition to your technical skills.

 

Just because Unity is a component based designed doesn't mean it doesn't follow OOP practices. And everyone should follow OOP designs. It was designed for a reason. A reason that allows teams to not kill themselves when making a large scale application.

This thread has turned into TROLOLOLOL.

@hippocoder close this S***

 

Is this real? Is this actually real? Because without understanding at least how class and variables works, i couldn't put a finger on scripting.
What are these magical, simple imperative code?

I read Joe Mayo's C# Succinctly, which apparently "borrowed" and translated without his name credited locally here.
It's so hard to learn without the actual Visual solution files as an example like the ones on his website.
How exactly, do you learn all this computer "stuff" without at least one programming wares available?
That's my point really.
All those books, and i'm still stiff in the finger.
Correct me if i'm just wrong or stupid or dyslexic, but honestly, how do you take those books in?

And this strange paradox. What is this.

YOU got a few points right on the spot and one though, it's fun learning from people on the forum, but it is yeah,
very distracting. And a book is like, one single person's voice. Which could fit or not at all.
Yeah, yeah, I'll go for books. I'll go for any books now.

And meanwhile now that it's decided for practicality and efficiency, are there any books that goes for C# and game programming framework? Both at the same time, because i cannot see one existing without the other one while we're still at unity.

 

I already stated why. Conflicting statements from multiple different people that only confuse OP, as they already have.

Yep. See previous statement.

Yep... see previous comment.