Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Trouble with C# classes

Discussion in 'Scripting' started by XHuntinatorX, Sep 18, 2014.

  1. XHuntinatorX

    XHuntinatorX

    Joined:
    Sep 18, 2014
    Posts:
    3
    I'm having a hard time understanding the concept of "Classes" in the C# language. I have some experience with "ActionScript" and "GML"...Game Maker Language" and can make simple games but C# seems to be a different beast than the languages I'm familiar with. The whole "Classes" concept seems unnecessary and redundant to me, so I'm obviously not grasping their importance or function. The closest analogy I can draw on is that in Game Maker "GML" I can create a script that isn't attached to any object and then call that script with code from an object, pass arguments to it or not, and return a value or not. Am I on the right track here?
     
  2. cmcpasserby

    cmcpasserby

    Joined:
    Jul 18, 2014
    Posts:
    315
    Classes are part of object oriented programming, you can have 1 class that is used as the template to define the methods and datatypes in many different objects, but each object will contain its own data.

    Classes also allow for inheritance say i write a class for a enemy type, than i want to make a other enemy that is slightly different or has some extra abilities, i can make my new enemy class inherit its methods and data from the enemy class, than add new data and methods, or override some old ones to create a new enemy type that inherits the functionality of the old one as well as adding to it.

    The difference between methods and your functions in GML would be that methods can access all the data available in the class, which helps streamline things since you dont have to pass in data that object already owns
     
  3. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    EDIT: Look at my post below. This post just talks about the importance of classes but doesn't actually explain anything. >.>

    Object Oriented Programming (OOP) is not specific to Unity or C# or JavaScript, but it is a very very *very* common way of organizing code. It's the very core of how Unity works. It's usually taught in the first year of any Computer Science program in college. It's so common that when I interview prospective programmers, if they can't explain what a class or polymorphism or encapsulation is, then that's an immediate red flag and I wouldn't consider the Unity programmer for more than maybe an intern.

    When programming, syntax is usually the hardest thing to learn for beginners. Object Oriented Programming is the next logical step after learning syntax. Yeah, the concepts are hard to grasp for everyone. I don't think I've met anyone who picked up OOP in a week or even a month. But it's well worth it and learning it has paid off ever since!

    A forum post is much too short to explain OOP, but after learning how to make a class (blueprint), then instantiate/construct some objects using that class (objects are the actual things in the game made from the blueprint), the next step is probably inheritance (extending a blueprint to do more/different things). The rest of OOP follows from there. If you want to learn programming, it is a good idea to get a book, find someone to help you, or take a class on OOP.
     
    Last edited: Sep 19, 2014
  4. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    Maybe someone can point out some good tutorials on OOP? I'm curious how people are learning OOP these days.
     
  5. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    I'm not happy with the non-answer I gave.
    A class is a blueprint of something that holds a collection of related variables and functions.

    For example, I have a class that represents "Enemy" and it stores both information about the enemy, as well as functions to make the enemy do things

    The enemy has it's own variables to track it's health, position, what it is currently doing, it's artwork. Not only does the enemy store data about itself, but it has commands like TakeDamage(), Attack(), Patrol() are all functions related to the enemy.

    So this is kind of cool, we can organize all our enemy related stuff in a single place. But where OOP really shines is when you want something that is an enemy, but you want it to do something more than just a normal enemy. Then we can make a BossEnemy class that is based on the Enemy class. It automatically knows to store the same data as Enemy, and has the same functions as Enemy, but we can give it additional stuff like a function DoBigBadBossAttack() that a normal Enemy might not have.

    Now just having a class script in a file doesn't do anything. If I want 100 enemies in the game, I have to use the class to instantiate 100 enemy objects. The class is the script, while the objects are the 100 copies of "health" and "position" stored in memory, the actual living enemy that is active and doing stuff.
     
    Last edited: Sep 19, 2014
  6. Cpt Chuckles

    Cpt Chuckles

    Joined:
    Dec 31, 2012
    Posts:
    86
    What GameMaker calls "objects" in the "object editor" are actually Classes in every other language and in Object-Oriented Programming in general.

    when you define a new object in gamemaker, you are defining a new Class.
    when you create an instance in gamemaker, you are creating an Object of that class.
    it's confusing because gamemaker appropriated the word "object" to refer to what is actually a Class.
    when you instantiate a Class in any OOP language, it's referred to as an object rather than an instance, but in principle it's what a gamemaker "instance" is.

    events in gamemaker "objects" (classes) are the Methods (which is what we call functions that are members of classes, which is distinct from the global-scope functions you would encounter in something like c++ because Methods are actually part of the class). so if you have an "object" in Gamemaker and there's a step event, that's identical to the Update() function for a Unity MonoBehaviour class.

    when you create a "script" asset in gamemaker that's not attached to any object, that's kind of just a globally accessible function, it's not a "script" like in Unity.

    so in unity, when you create a new C# script, it's not a "script" in the sense of it being just a piece of code. it's a Class, which is like an object in gamemaker. it has its own "events" or Methods, like Update() ("step event") and Awake() ("create event"). you stick all these classes together onto a unity prefab, and all the little parts work together to make something work, if you made them right.

    basically, for every little enemy you see in a Unity game, it will be driven by multiple objects all working together to produce that result.
     
    GarthSmith likes this.
  7. XHuntinatorX

    XHuntinatorX

    Joined:
    Sep 18, 2014
    Posts:
    3
    Ok, the light clicked on! Thanx for the help guys...Now I can give another look at some of the Tutorials and maybe they will make more sense to me. Thanx again for the explanations.
     
    GarthSmith likes this.
  8. Krysalgir

    Krysalgir

    Joined:
    Aug 30, 2010
    Posts:
    95
    Also a simple point of view is a MonoBehaviour.
    All the scripts you put onto a GameObject are defined as class XXX : MonoBehaviour { ... }
    this means that your class XXX inherits from the base class MonoBehaviour, and every single time you put that script on a GameObject (or you instanciate a GO with that script) there is a new *object* that is created using that class' blueprint.

    One file/class - several gameobjects-objects

    In a MonoBehaviour you also have a slight view of overriding functions, when you write down your own Wawke or Update ( or any other MonoBehaviour core function). Actually, you say that YOUR Awake()/etc. function is to be used instead of the original one from a MB.
     
  9. cdevl

    cdevl

    Joined:
    Apr 10, 2013
    Posts:
    180
  10. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    I would hope 17 months is enough time to get a grasp of how classes work with C#.

    EDIT:
    Oh, and welcome to the forums =).