Wow, heh, I mean this in the nicest of ways but you need to relax...
Of course it''s very important that you plan ahead. Nice design is also very...nice. But good design is something that takes a long time to learn (usually) and you learn by doing (mistakes). So don''t panic if your design isn''t perfect, in many (most?) professional cases it isn''t either... Besides what some people see as good design other may view differently.

To answer your first question though; if you know at compile-time that a certain instance will never use a certain set of methods then that''s a typical sign that those functions doesn''t belong to that class, like in your case. What I recommend is that you split your Entity-class into two classes (to begin with), one Player-class and one Enemy-class. It can be good to have both those classes derive from a common base-class, i.e. Entity (or whatever you like to call it). But if you have trouble grasping the concept of inheritance you can wait with this.

To answer your second and third question in a short way; no it''s not bad design for a method (class function) to call a global function or a method of another class. In fact it''s essential that you do, otherwise you won''t have much of a program.

About tips for OOD/OOP, I suggest you familiarise yourself with the different concepts of OO, such as inheritance, virtual functions, constructors, destructors (for those languages that apply), etc. Also make sure you learn how to use them. Finally don''t believe that everything should be OO, some concepts fit very well into an object model, some don''t. So don''t be afraid to use other design strategies where you see fit. All this will of course take years of practise, but you''ll hopefully have a lot of fun while learning.

Good luck!

EDIT: Above post is better and I asumed your using C++

Why not have a single generic draw function (or an over-rideable virtual one) to draw all states.
For example, you could have

void Draw(int state){    switch (state) {        case STATE_ENEMY_DEAD:            /* Draw Enemy Code */        break; case STATE_PLAYER_DEAD:           /* Draw Player Code */        break; default: break;    }}  

or

void Draw(int state){    // Assume that DrawBitmap draws a bitmap somewhere.    DrawBitmap(BitmapImage[state]);} 

where BitmapImage is an array of Bitmaps.
and then do this:
enemy.Draw(STATE_ENEMY_DEAD);
player.Draw(STATE_PLAYER_DEAD);

Another way would be to do something like this:

class CCharacter{private:    IMAGE* Images[3]; // You will probably want to dynamically allocate this.    int State; // Used to determine which to draw.public:    CCharacter(IMAGE* normal, IMAGE* scared, IMAGE* dead)    {        Images[0] = normal; Images[1] = scared; Images[2] = dead;    }    ~CCharacter() {/*Destroy the images here*/}    void Draw()    {        // Now Draw Image[State]    }    void SetState(int s) {State = s;}    int GetState() {return State;}    static const STATE_NORMAL = 0;    static const STATE_SCARED = 1;    static const STATE_DEAD = 2;};...CCharacter Player(ImagePlayerNormal, NULL, ImagePlayerDead);Player.SetState(CCharacter::STATE_NORMAL);// No scared player image.// Now at a later stage, draw.Player.Draw();  

The above is the way I would do it if I didn't want to use inheritance. Of course, I would use something more flexable than a static array of images, but I hope you see what Im getting at.

Alternatively you could do something like this (though this uses inheritance, which you said you haven't learnt yet...):

class CCharacter{public:    CCharacter() {}    virtual CCharacter() {}    virtual void Draw()=0;};class CPlayer: public CCharacter{public:    void Draw() {/* Draw Player Code goes here*/}};class CEnemy: public CCharacter{public:    void Draw() {/* Draw Enemy Code goes here*/}};CPlayer Player;CEnemy Enemy;...Player.Draw();Enemy.Draw();  

Which way you would do it depends on how much C++ you know, though none use any really advanced stuff.
Others may have better ways than I and I probably wrote horribly ugly code but I hope you learn something from it nontheless.


[edited by - issch on March 18, 2004 6:09:33 PM]

your thread didn''t disappear it''s right here:

http://gamedev.net/community/forums/topic.asp?topic_id=213917

if you want to find your threads, enter the forums area and click on the profile link at the top of the page (near register, bookmarks, active topics, etc). then click "view your profile" then you can see all the recent threads you''ve started and replied to.

-me

Yeah, don't worry too much about design for now. If you're starting, getting it to work is already a big step, regardless of how ugly you think that your code is. Design is part experience, part innate ability, I think. Computer science isn't really an engineering discipline yet because we just don't know what is "the" right way to approach a given problem. It's more like a craft. You learn from your mistakes, and by discussing it with people around you.

[edited by - Cedric on March 18, 2004 7:41:17 PM]

Sounds like analysis paralysis

Up front design was popular in the Waterfall methodology. You'd have an analysis phase, a design phase, a coding phase, a testing and bug fixing phase then release.

There are many other methodolgies, and waterfall has come to be acknowledged as difficult.

Check out some of the articles here to get an idea of how to design as you go, to be free to refactor, etc. See other articles like the one on Waterfall methodologies, especially Iterative and Incremental Development parts II and III.

[edited by - petewood on March 19, 2004 6:49:14 AM]

global function are only truely bad due to namespace pollution .. throw them in a namespace and they are no worse than "class" or "static" functions that have been used since the original SmallTalk ...

as for base class having function which really belong in derived classes ...

first the disclaimer - design serves a function ... to AID development ... try to never let your design hamper your development. as you learn, you should become better and better at design, and therefore, at any moment the "right" solution for GETTING SOMETHING DONE, depends on your current talents and understanding - don''t fret over design flaws that aren''t biting you.

that said however:

in an ideal case, base classes should not have derived class specific knowledge at all ... their are design methods you will learn that make this unneccesary ...

for your particular example .. the case is to have a virtual Draw() function, and have each class implement Draw() based on it''s internal state ... so the Enemy might be "dead" and if so it''s Draw() draws it dead ... and a player might be "scared" and if so it draws that way ... but their is not a unified property for the player and the enemy, if only one may be scared and only the other may be dead (man I''d love not to be able to die) ...

The key is, the virtual function in the base represpents the FUNCTION as viewed from the main programs desire ... such as DrawObject(), MoveObject(elapsedTime), SaveToStream(stream) etc ...

and then each class has custom state (if it needs to) and custom implementation of those virutal functions (if it needs to) and any custom functions it needs to help out ... then it "does the right thing" - FOR IT - when the virtual functions are called ...

for example, in my SciFi game, my:

IGameObject - is serializable (save / load to stream), and able to be looked up by ID in the central GameObjectManager.

IPhysicalObject - is a game object which adds a position in the physical world.

IDynamicObject - is a object but must also be updated based on time passing, cause it may change locations, etc.

so you see my Fleets would be Dynamic Physical objects, but my Solar Systems are just PhysicalObjects and my Technologies are not Physical at all.

I also have classes layered in their for implementing the program, such as:

IScreenObject - something which should be drawn on screen .. with guess what ... a Draw() function

so you see, the key is, these objects are derived from the types / interfaces that make sense, and only have the funtions which are valid for them ... then they get inserted (usually at creation or shortly thereafter) into the right lists that make the game "go" ... like the list of VisibleScreenOjects, that calls Draw() on each .... the list of DynamicObjects that calls Update(timeElapsed) on each ... etc ...

hope this gives you some ideas ... and good luck