Unit Theory - input requested

This is a discussion on Unit Theory - input requested within the Game Programming forums, part of the General Programming Boards category; Im writing a classic arcade clone game, the one with the plane you control and shoot all the other planes, ...

  1. #1
    mov.w #$1337,D0 Jeremy G's Avatar
    Join Date
    Nov 2001
    Posts
    704

    Unit Theory - input requested

    Im writing a classic arcade clone game, the one with the plane you control and shoot all the other planes, while trying to dodge enemy fire (and ships as well). Featuring spread fire power ups, bombs etc. etc. I think it was like aero asssult or something like that.

    Any way I've come to a fork in the road on two possible options for class (unit) structure.

    So far I have the following:

    CUNIT // top level abstraction for every unit in the game
    -base vars all units must have
    --x,y,z,life,collision mask
    -moveTo(x,y)
    -moveBy(x,y)
    -virtual render()

    CSHIP : public CUNIT // base air/space vehicle unit
    -variables and functions related to air/space vehicles
    -render()
    -virtual moveFunc()
    -virtual init()

    CXUAF : public CSHIP // this is player one ship
    -moveFunc()
    -init()
    -variables for player one
    --score,life,level etc

    Basicly my two choices are this:
    -For every ship type i can create a class that inherits from CSHIP. All i have to define function wise is movement function, and initiation.
    -Make one general ship class, and for every ship type create a new class and give it a pointer to a moveFunc() and Init() function.

    So i can make a bunch of classes with only moveFunc() and Init() that differs them, Or i can make a bunch of moveFunc() and Init()'s and pass them as pointer functions when ever i make a ship type. This seems like it might be less code, and a better rout as two functions isn't usualy a good reason to make lots of classes, but Im inclined to go with more classes option. Not sure why, a gut feeling I guess.

    Any suggestions on which way i should go?

    btw, the player one ship class is called CXUAF, as the name of my clone is xUA Fighter, or (x)prototype (U)pgradable (A)ssualt Fighter :P
    c++->visualc++->directx->opengl->c++;
    (it should be realized my posts are all in a light hearted manner. And should not be taken offense to.)

  2. #2
    carry on JaWiB's Avatar
    Join Date
    Feb 2003
    Location
    Seattle, WA
    Posts
    1,972
    You might want to keep things simple...If not make sure it is well-planned or you will probably end up with quite a few problems

    Also...You might want to rename the CUNIT class...I misread the name at first...
    "Think not but that I know these things; or think
    I know them not: not therefore am I short
    Of knowing what I ought."
    -John Milton, Paradise Regained (1671)

    "Work hard and it might happen."
    -XSquared

  3. #3
    C++ Developer XSquared's Avatar
    Join Date
    Jun 2002
    Location
    Ontario, Canada
    Posts
    2,718
    >>Also...You might want to rename the CUNIT class...I misread the name at first...
    Hehehehe... I was thinking the same thing. Also, typos could be dangerous.

    Other than that, KISS. Keep It Simple, Stupid.
    Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah

    You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie

  4. #4
    Banned frenchfry164's Avatar
    Join Date
    Oct 2001
    Posts
    1,552
    I've always hated the idea of having one "Base entity class" and having the entire game derive from it. It's stupid. Are people really too lazy to just retype x, y, z, and a couple other variables? Instead they want to waste RAM by deriving from a class that only has a couple variables you'll ever use. I can understand maybe having a base actor class and have NPC's and PC's derive from it, or maybe a base terrain class and have all type of terrain classes derive from it, etc. but having the whole game revolve around one class is stupid. People are like, "I'm using C++ so I better use every last feature it offers, otherwise I might as well use C". That is so retarded. When you use Linux, I don't think you use every last feature of it. Do you say "Oh, I might as well go back to Windows, because I'm not using every feature offered by Linux"? No, you don't, unless you are a numbskull.

    Anywho, I wasn't referring to you at all, dbgt, because you are doing it well, having a base level class for a group of similiar classes. I don't use abstract classes much, but my game I'm working on right now has them in the design.

  5. #5
    mov.w #$1337,D0 Jeremy G's Avatar
    Join Date
    Nov 2001
    Posts
    704
    I have to disagree with you. The base abstract class is very important.

    The whole point of abstract classes is abstract handling. Every unit in the game must have an x, y, z location, a velocity x, velocity y, collision mask, life value, id. They are used for movement routines, collision checks, damage functions, and several other roles.

    Now, in order to spawn the units you have to have variables for them. If all units are their own classes, and say I have 12 unit types. That means I have to have 12 arrays in my game to manage the units. This complicates EVERYTHING.

    Any function that consideres all units would have to cycle through 12 arrays every call to check every unit. There would have to be implimented 12 ways to call specific functiosn of classes.


    If you use an abstract class, all 12 of everything can be made into 1 perfect handler. Collision detection functions, moveing functions, timing and control functions, ai functions, and more all only have to have one variable type to deal with all 12 classes (that inhereit from one abstract class) which is CUNIT in this case.

    Code:
    CUNIT gameUnits[77];
    
    // super coolness for abstractness
    bool CollisionCheck(CUNIT *collider) {
         for( int i = 0; i < 77; i++ ) {
             if( collider->x >= gameUnits[i].x ) && ....... etc
               ....................
               collider->takeDamage(gameUnits[i].life);
               gameUnits[i].takeDamage(collider.life);
             }
         }
    }
    My example of 12 units is pretty small. Think of an RTS, where theres like 30 unit types of buildings and people. It HAS to have abstracted classses to handle it efficiently.
    c++->visualc++->directx->opengl->c++;
    (it should be realized my posts are all in a light hearted manner. And should not be taken offense to.)

  6. #6
    mov.w #$1337,D0 Jeremy G's Avatar
    Join Date
    Nov 2001
    Posts
    704

    Back to the first post,

    I remember why I wanted to make classes for every ship type, rather then passing in moveFunction pointers.

    But I finally decided to go the better rout.

    I will code several moveFunc()'s and pass them as pointers to one type of ship class. moveFunc() will take two parameters, a pointer to X and pointer to Y.

    heres example of the code
    Code:
    // unit.cpp
    void CSHIP::MoveFunc( pointerToFunc ) {
         pointerToFunc( &this->x, &this->y );
    }
    
    // mover.cpp
    void mover_elipse( *y, *x) {
    ...
    }
    void mover_elipse2( *y, *x) {
    ....
    }
    // etc.
    By doing it this way, I allow myself to change the move function of units with out having to change its class. Going the other way, the move function would have to incorporate its flying pattern to its entering and exiting pattern (PAIN N ASS). But now I can do a few type of entry patterns, several move patterns, and a few exit patterns and pass them to the ship unit on the fly using my GameController(timing entity that spawns, destroys, and takes care of all np units).
    Last edited by dbgt goten; 11-16-2003 at 12:25 PM.
    c++->visualc++->directx->opengl->c++;
    (it should be realized my posts are all in a light hearted manner. And should not be taken offense to.)

  7. #7
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    Yes, in general, I would try to keep the number of unit classes to a minimum -- ideally, only one class. The class would have a data member which would tell how to draw the unit (for example, an int for model ID) and a data member telling how to control the unit (either a simple function/functor, or, if necessary, a pointer to some base AI class).
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  8. #8
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    Your base class declaration will make or break your game if you derive from it.

    Having a good abstract base class or even just a good base class is very important if you intend on using a class hierarchy for your objects - which, by the way, I highly recommend.

  9. #9
    Banned frenchfry164's Avatar
    Join Date
    Oct 2001
    Posts
    1,552
    Anywho, I wasn't referring to you at all, dbgt, because you are doing it well, having a base level class for a group of similiar classes. I don't use abstract classes much, but my game I'm working on right now has them in the design.
    So you're are disagreeing with me agreeing with you?

  10. #10
    mov.w #$1337,D0 Jeremy G's Avatar
    Join Date
    Nov 2001
    Posts
    704
    Originally posted by frenchfry164
    I've always hated the idea of having one "Base entity class" and having the entire game derive from it. It's stupid. Are people really too lazy to just retype x, y, z, and a couple other variables?


    Thats what i disagree with.
    c++->visualc++->directx->opengl->c++;
    (it should be realized my posts are all in a light hearted manner. And should not be taken offense to.)

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Checking array for string
    By Ayreon in forum C Programming
    Replies: 87
    Last Post: 03-09-2009, 03:25 PM
  2. For loop problems, input please.
    By xIcyx in forum C Programming
    Replies: 2
    Last Post: 04-22-2007, 03:54 AM
  3. I would love some input on my BST tree.
    By StevenGarcia in forum C++ Programming
    Replies: 4
    Last Post: 01-15-2007, 12:22 AM
  4. About aes
    By gumit in forum C Programming
    Replies: 13
    Last Post: 10-24-2006, 03:42 PM
  5. Simple Console Input for Beginners
    By jlou in forum C++ Programming
    Replies: 0
    Last Post: 06-21-2005, 01:50 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21