Results 1 to 5 of 5
  1. #1
    Join Date
    Mar 2009
    Location
    Bellevue, WA
    Posts
    803

    How to Approach OOP in Unity?

    Hey guys I tend to jump around from project to project. I have some C++ stuff I work on and then I also jump over to C# stuff but have been giving scripting in Unity a go as well lately.

    I'm finding scripting a bit odd in Unity. Not because of the syntax or anything, it's C#. I'm finding that the approach to problem solving and software architecture a little hard. I'm use to creating projects/games from the ground up sort of how Buzz approached stuff in the XNA series. You design your game, layout a class structure and hierarchy and begin to code with an object oriented approach.

    In Unity however everything is component based and specific to the gameObject. Everything must inherit from a Monobehavior in order to be attached to a game object. Then it seems all I am doing is providing a set of methods that provide actions to each gameObject.

    Is there a better approach to software architecture in Unity? Is there a way to set up and use design patterns and also create my own classes from which my gameObjects inherit behavior or would you have to create your own base class that inherits from Monobehavior and then inherit your gameObject from that base class using Multiple inheritance?

    It just seems a bit odd to me, but I am having fun with Unity. I wish there were some good articles or tutorials that approached a more professional way of handling design in Unity. The majority of scripting tutorials use javascript and stick to very basic demonstrations.

    Are there any tutorials anyone knows of that shows how to use design patterns in Unity? Also, since you guys are doing live classes are there plans on doing a live scripting class for Unity?
    " Imagination is the preview of life's coming attractions " - Albert Einstein
    " If you can't explain it simply, you don't understand it well enough." - Albert Einstein

    My Website: http://www.gamedevlounge.com/

    If any post is informative please provide positive feedback by clicking the star below.

  2. #2
    Join Date
    Jul 2008
    Location
    Portsmouth, England
    Posts
    436
    Do you want a bit of advice that's going to save you tons of time as well as help you write more efficient and easier to understand code?

    Forget about inheritance. Even within there sphere of OOP, it is by far the least important concept and it frustrates the hell out of me that most courses and books that teach programming emphasise it so much. For sure, there will be situations where it is useful and the right choice to have some classes inherit from one or at most two levels of hierarchy, but that's the kind of thing you want to discover and then refactor in after designing the classes that matter.

    For the avoidance of confusion, because C++ doesn't make any distinction between implementation inheritance and interfaces, I am talking about implementation inheritance here - interfaces are of course hugely important. When you have common behaviour between classes, before considering inheritance, consider aggregation. That was the way Smalltalk (the first OO language) handled it, and Objective-C maintains an emphasis on delegation and aggregation over inheritance.

    And that's where components come in. When computers and consoles got powerful enough that you could write a game in C++, a lot of developers went crazy with it and make inheritance hierarchy for their game entities. You'd have a base Actor class and then you'd have skeletal actors that could be used with character animation. Then you'd have attachment points on them for weapons. And you'd have actors that were vehicles, but some vehicles need attachment points, so you push that up into the base actor class, but then all the vehicles that didn't need attachment points would carry that baggage around. And that's just the start of the problems.

    You have two key with inheritance: (1) everything that's needed in two or more branches of the hierarchy has to but pushed up to the nearest common parent regardless of whether any other classes need it. (2) You can't take away anything you inherit from parent class. These two problems create competing goals (add lots of stuff to base classes/keep the base classes as sparse as possible) and that's why beginners now get their heads in a spin trying to work out the right class hierarchy before they've even started.

    So the idea with components is to keep the basic game entity very simple. If it needs a skeletal mesh you add that type of component to it, if it needs to be able fire a projectile you can add a different kind of component. Some experimental OO languages include a concept of 'mixins' instead of inheritence and components are a programmer-implemented version of the same idea.

    Again, don't go crazy with this stuff - in general you are only going to have one monobehavior per gameobject. But here's the thing, once you are in C# land you can do whatever you want. You can create instances of other classes that Unity knows nothing about. The Update event in your Monobehavior can just call code in other classes. But my advice would be to keep things as simple as possible.

  3. #3
    Join Date
    Mar 2009
    Location
    Bellevue, WA
    Posts
    803
    Thanks rhm. My main thing was not necissarily inheritence in terms of base classes and building hierarchies so much as wanting to know how to handle inheritence when using design patterns like the observer pattern, finite state machines, etc...

    So let me get this right. Does only one script attached to my object need to be iherited from MonoBehavior? I'm not a javascript programmer but I looked at the scripts attached to the Android or Robot game that comes with unity 3.5 and one of the enemy objects I looked at had 3 scripts attached and none of them appeared to be inheriting from a monobehavior.

    This may just be because I'm not sure what inheritence looks like in Javascript as I'm used to the syntax in all the C based languages.

    Are there any good scripting articles that go into some of the advanced scripting topics using C#? All of the ones I find are aimed at complete beginners and just do simple things like translate, rotate, etc...
    " Imagination is the preview of life's coming attractions " - Albert Einstein
    " If you can't explain it simply, you don't understand it well enough." - Albert Einstein

    My Website: http://www.gamedevlounge.com/

    If any post is informative please provide positive feedback by clicking the star below.

  4. #4
    Join Date
    Jun 2003
    Posts
    150
    Any script that you want to attach to a game object needs to inherit from MonoBehaviour at some point. You can however create a class that inherits from MonoBehaviour and any script that inherits from that can also be attached to an object as a script.

    I would definitely keep the Unity Scripting Reference open at all times as more and more of the documentation provides C# examples as well as UnityScript(which is based on javascript). Also keeping the MSDN on hand will be helpful as well.

    Not all your classes need to inherit from MonoBehaviour, just the class that is attached to a game object to get things going.

    Know the differences between Awake() and Start(). Awake() is called when the script component is first created and attached to the game object. Start() is called right before the first set of Update() methods(Update(), LateUpdate() FixedUpdate(). Also know the differences between these updates. Update() is called before rendering, LateUpdate() is called after rendering just before the next full cycle and FixedUpdate() is called every 30th of a second(used for physics updates primarily and things you want to happen at a set pace without the need for Time.deltatime).

    I would also look into the SendMessage(), SendMessageUpwards() and BroadcastMessage() documentation(found under GameObject). Just be careful not to abuse and rely on these to solve all your communication problems as they can be relatively slow. SendMessage() basically allows you to "call" a method in another script attached to the game object as well as any objects on the same object hierarchy level. Upwards() sends the call to the parent and his sibling game objects. BroadcastMessage() sends the message downwards to the children game objects. Make sure to add the argument of SendMessageOptions.DontRequireReceiver if you're not sure if the game object will have a method to respond to the message else you will start throwing exceptions left and right if they aren't there.

    Most of learning Unity scripting is learning about how to work with Component/Composite based objects over using inheritance altogether. I'll link the requisite cowboyprogramming.com article. http://cowboyprogramming.com/2007/01...your-heirachy/
    Other people often site the Dungeon Siege slide show but I found that difficult to follow(a lot of that may have had to do with the text formatting of the PowerPoint viewing program I was using).

    If you can get a copy of AI Programming Wisdom 3 you'll find more articles on working with component based objects and what are some of the snags. I've also got some C++ code I can send you on a component based system I created and how it dealt with the issue of communication between components.
    Last edited by Edge Damodred; 03-24-2012 at 06:16 AM.

  5. #5
    Join Date
    Mar 2009
    Location
    Bellevue, WA
    Posts
    803
    Thank you Edge! That's some good information. I will checkout the article as well.
    " Imagination is the preview of life's coming attractions " - Albert Einstein
    " If you can't explain it simply, you don't understand it well enough." - Albert Einstein

    My Website: http://www.gamedevlounge.com/

    If any post is informative please provide positive feedback by clicking the star below.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •