XNA Creators Club Online
Page 1 of 1 (13 items)
Sort Posts: Previous Next

Object class and derivatives?

Last post 3/15/2009 11:15 PM by Vicious Gaming. 12 replies.
  • 3/15/2009 3:52 AM

    Object class and derivatives?

    The truth is, i'm posting this in General because I can't find info specific to what I need. I know it is out there...I just might need a hand getting to it. 

                I'm hoping it is just a simple matter. I have an "Object" class which contains all of the information about any of the objects in my game(laserbeams, enemies, my player, enemy laserbeams, etc.) Things like position, scale, rotation, pixel data, and such.  When I started having them all intersect with each other(and sifting through lines of code to find the Update method for each "Object"), I realized how much easier it would be if I just had them all in classes of their own, with their own Update method,  but still deriving from the "Object " class. That's when I realized I didn't know how to refer to a "Laserbeam" or "Enemy#1"(for example) class that uses information from the "Object" class. I feel like I'm on the right track, but just not refering to the "Object" class correctly or something. 

                Any help would be wonderful. I'm sure that something already exists about this in these forms, If so I'm sorry for double posting and any info or links to find said existing post would be great. Thanks very much.
  • 3/15/2009 4:23 AM In reply to

    Re: Object class and derivatives?

    This is more of a standard Object Oriented Programming question. You might find some good answers here, but there are a lot of better places to look.


    Generally you are on the right track, having all of the moving parts of your game be children of a basic abstract parent.

    You want to start with a base class, (I usually use "Actor" to define this class), and make it abstract. (So its definition would be "public abstract class Actor". If you're not familiar with abstract classes, I recommend picking up a book on OO programming or at least going through some tutorials).

    Actor should define some standard properties and methods that are common to all objects that will inherit from it. Remember to keep your member variables private and use properties to expose them when possible, it will make your life a lot easier if you end up with a large project.

    Some examples:

    In almost any game, all objects will have a position on the screen, so you'll want the Actor class to hold this.
    Objects should always have some way of being moved, so define a basic move method.
    It would be a good idea to make an update method as well. This method may or may not be abstract, depending on the way your game functions. If all Actor children will have their own version of this and you don't need any common logic, make it abstract. Otherwise, define the common logic in it, and have the children override it and call the base version as necessary.


    As for the other issues you've faced, these seem like poor namespacing and design issues, and you might want to familiarize yourself with your IDE some more. In good OO code you shouldn't need to sift through a lot of junk, and Visual Studio makes this even easier to deal with. Take advantage of regions as well, they help keep things nice and neat.

    You can determine the current type of Actor you are looking at by using the "typeof" operator. You should avoid this normally, but it can help in certain situations.

    If you have any more questions, I'll be glad to help you out, but I do highly recommend spending some time learning the principles of Object Oriented Programming, and brushing up on some design patterns.


    -Dan
  • 3/15/2009 4:40 AM In reply to

    Re: Object class and derivatives?

    Thank you so much for your help...as for the poor namespacing and design issues I'll agree with you whole heartedly. I have never programmed  anything before 1 1/2 months ago when i started looking into XNA, so I'm still learning how to learn if that makes any sense. The info you provided looks like it should get me to where i need to be. It's all going to be very useful. Thanks again.
  • 3/15/2009 5:16 AM In reply to

    Re: Object class and derivatives?

    Don't name your base class "Object".  C# has a base class called Object that all C# classes are derived from (even if not explicitily stated).  You can still use your "Object" by using a scope resolution (i.e. MyNameSpace::Object), but life will be a lot easier if you use a name that does not conflict.
  • 3/15/2009 11:09 AM In reply to

    Re: Object class and derivatives?

    I recently went through much the same questions that you have asked here.

    http://forums.xna.com/forums/t/26002.aspx
    Is the thread started about the topic, reading through that you will see that I was a complete n00b at using classes, but the help on offer, particulaly from Craig, walked me all the way through it. Definately look at the World/Street/House analogy.

    Basically you would have something like:


    public class Game1:Game 
    public LaserObject laserbeam; 
     
    protected override void LoadContent() 
    laserbeam = new LaserObject(parameters); // such as position, model, scale etc 
     
    class LaserObject (parameters) 
    {
    Constructors
     
    class OtherClass 
    public Game1 mylaserobject; 
     
    public Other(Game1 laserbody)  
    mylaserobject = laserbody 
     
    //now you can do stuff with any object in Game1 from within OtherClass. 
    mylaserobject.laserbeam.body.force.y = 5.0f; 
     
    // if you changed the Other(Game1 laserbody) to Other(LaserObject laserbody) 
    //you would then be able to do stuff with all LaserObjects created from //LaserObject Class 


    Obviously the above is from the top of my head and most likely is no tthe best way to do it.
    I would love to help further, but I am still learning myself.
    I really found the best way to come to terms with classes and how they can interact was to start a new project from scratch, add a few classes that relate in some way to each other and other instances and then to see what you can do by referencing in different ways.

  • 3/15/2009 7:33 PM In reply to

    Re: Object class and derivatives?

    JuiceMan118:
    I recently went through much the same questions that you have asked here.

    http://forums.xna.com/forums/t/26002.aspx
    Is the thread started about the topic, reading through that you will see that I was a complete n00b at using classes, but the help on offer, particulaly from Craig, walked me all the way through it. Definately look at the World/Street/House analogy.

    Basically you would have something like:


    public class Game1:Game 
    public LaserObject laserbeam; 
     
    protected override void LoadContent() 
    laserbeam = new LaserObject(parameters); // such as position, model, scale etc 
     
    class LaserObject (parameters) 
    {
    Constructors
     
    class OtherClass 
    public Game1 mylaserobject; 
     
    public Other(Game1 laserbody)  
    mylaserobject = laserbody 
     
    //now you can do stuff with any object in Game1 from within OtherClass. 
    mylaserobject.laserbeam.body.force.y = 5.0f; 
     
    // if you changed the Other(Game1 laserbody) to Other(LaserObject laserbody) 
    //you would then be able to do stuff with all LaserObjects created from //LaserObject Class 


    Obviously the above is from the top of my head and most likely is no tthe best way to do it.
    I would love to help further, but I am still learning myself.
    I really found the best way to come to terms with classes and how they can interact was to starta new project from scratch, add a few classes that relate in someway to each other and other instances and then to see what you can doby referencing in different ways.


    JuiceMan, it's better to have an parent object at a much higher tier than yours.

    Think about it, what do players, bullets, powerups, and enemies all have in common?
    The answer is, a lot! They all have positions, the need to be rendered, collision detection, update calls, and much more. You shouldn't only take this approach halfway and make a LaserBeam object. You should make a LaserBeam object that is a child of Actor -> Projectile -> LaserBeam, or something of that nature.
  • 3/15/2009 8:47 PM In reply to

    Re: Object class and derivatives?

    Hi,


    Im going through the same learning process right now, Currently im developing a large SQL database with a front end in visual basic for my work with a team of 3 other people, and some of this seems familiar.

    In VB I was recently introduced and have started implementing interfaces, from what I have just been reading online are these abstract classes the interfaces of visual basic? if so I can see the use completely. The difference I see between this and an interface is that if you want to make something not abstract within the 'actor' then you can make add common logic and that method/property/field can include logic and/or set values?

    Have I got the right idea?

    Craig
  • 3/15/2009 9:04 PM In reply to

    Re: Object class and derivatives?

    Craig Lowdon:
    Hi,


    Im going through the same learning process right now, Currently im developing a large SQL database with a front end in visual basic for my work with a team of 3 other people, and some of this seems familiar.

    In VB I was recently introduced and have started implementing interfaces, from what I have just been reading online are these abstract classes the interfaces of visual basic? if so I can see the use completely. The difference I see between this and an interface is that if you want to make something not abstract within the 'actor' then you can make add common logic and that method/property/field can include logic and/or set values?

    Have I got the right idea?


    Interfaces and Abstract Classes are two different things. In an Interface, you can prototype methods, but you cannot actually implement them. Additionally, member variables cannot be defined. An Abstract Class, like an Interface, cannot actually be instantiated. However, it can implement methods and define its own member variables. Abstract Classes can also force their children to implement methods (like an interface) by declaring the methods as "abstract".


  • 3/15/2009 9:25 PM In reply to

    Re: Object class and derivatives?

    OK thanks I understand that.

    On creation of an abstract class you say it can have its own methods etc.

    I have tried a test expanding on information given to me in the 2D tutorial to make Gameobject an abstract class.

     

        public abstract class Gameobject  
        {  
            public abstract Vector2 Position;  
            public abstract Texture2D sprite;  
            public abstract Vector2 Centre;  
     
     
                public abstract Gameobject(Texture2D loadedtexture)  
                {  
                    sprite = loadedtexture;  
                    Position = Vector2.Zero;  
                    Centre = new Vector2(sprite.Width / 2, sprite.Height / 2);  
                  
                }  
     
        } 

    I also did this initially without the class being public, as this is an abstract class would it make it public automatically?

    I then created a player class with the 'parent' being the Gameobject class.

        class Player:Gameobject  
        {  
     
        } 

    This is fine, what I would like to know is what is the best way of giving my player class the information on the loadedtexture so that it passes it to the base class of gameobject?

    For example in my loadcontent method of game1 i would like to write:

     Player = new Player(Content.Load<Texture2D>("pictures\\Player")); 

    I know I would need to create a public method called Player in my class (the initialisation method) and know how to add the argument to this method, what I dont know is how to pass it to the initialisation of the gameobject class.

    Many thanks

     

    Craig
  • 3/15/2009 9:32 PM In reply to

    Re: Object class and derivatives?

    I have just realised that the gameobject initialisation should not be abstract if im calling it. I seem to be getting a bit mixed up with when and when not to use the abstract keyword.

    On making the gameobject initialisation not abstract I was able to do this in my player class

     

        class Player:Gameobject  
        {  
            public Player(Texture2D loadedtexture):base(loadedtexture)  
            {   
     
            }  
     
        } 

    I guess this will load the loaded texture into my Gameobject.sprite property.

     

    Craig
  • 3/15/2009 9:39 PM In reply to

    Re: Object class and derivatives?

    Craig Lowdon:

    I have just realised that the gameobject initialisation should not be abstract if im calling it. I seem to be getting a bit mixed up with when and when not to use the abstract keyword.

    On making the gameobject initialisation not abstract I was able to do this in my player class

     

        class Player:Gameobject  
        {  
            public Player(Texture2D loadedtexture):base(loadedtexture)  
            {   
     
            }  
     
        } 

    I guess this will load the loaded texture into my Gameobject.sprite property.

     


    Yes, you want to avoid making your constructor abstract, as abstract methods cannot be called directly. (In this case, using base() calls the constructor, and if it is abstract you will certainly see compiler errors)
  • 3/15/2009 9:47 PM In reply to

    Re: Object class and derivatives?

    I think I understand, it seems this keyword is used to provide that limitation and that is its purpose? Im asking as I notice I can call the class as a base class whether it is abstract or not, is the abstract keyword used so it is not possible to instantiate the 'actor' class?

    This is helping me to understand the background behind XNA as it is giving me more idea on the base class within game1 and how it is used. I notice update/draw etc are pulled from the game base class, although I do not understand the override and protected keywords here either.
    Craig
  • 3/15/2009 11:15 PM In reply to

    Re: Object class and derivatives?

                  Thanks for all the help on this post, after looking into these suggestions I seem to already have a pretty firm grasp on the parent : child relationship. Everything I am doing now seems fine, with the exception of the LoadContent Method. I am still not certain on how to do that. The other methods seem to be the same as before. Draw and Update for example. once again any help is much appreciated.
Page 1 of 1 (13 items) Previous Next