Lay me a foundation

This is a discussion on Lay me a foundation within the Game Programming forums, part of the General Programming Boards category; I always get so far with my game project then hit a design snag of some sort and it all ...

  1. #1
    Supermassive black hole cboard_member's Avatar
    Join Date
    Jul 2005
    Posts
    1,709

    Lay me a foundation

    I always get so far with my game project then hit a design snag of some sort and it all falls apart. There are too many to list so I won't, I'll just say I've had > 10 false starts. I really suck at designing, which doesn't put me in a very good position if I'm working on my first game.

    So I was wondering if anyone here could explain how they've laid out their games. BobMcGee123, I'm particularly interested in you since you mentioned you don't use any OOP: how have you structured everything? How have you managed to get data around and... things. I mean I start working on mine then realise I need such and such data from such and such class then start static'ing things, half of my objects end up being singletons and it quickly becomes too "spilly" to continue working.

    The same things seem to happen every time no matter how I try and approach it.

    I start pretty much the same way each time though. I write up a quick logging class (a singleton), well now, when I say write up I mean copy and paste from one of the last gazillion false starts. Then I move onto getting a frame. I create skeletons of classes I know I'll need, Player, Kernel, MessageReceiver, MapTile, MapManager, I think that's it. Then I fill them out with "what they need" as I realise what they need.

    I don't do much on paper - I can sit there for an age with pen and paper and they won't touch. My mind just goes blank as if I've suddenly unlearned everything I knew (or thought I knew ) about OO design. I (used to) prefer manic hacking over design as everybody does when they start programming (I guess).

    It's a bad habit which I'm finding frustratingly difficult to move away from, so I need inspiration. I know it's a little much to ask but even a few links to some articles on design (please nothing from gamedev, I've milked that for all it's worth) would be great.

    Is there any shame in starting by using someone else's design as a base? The Enginuity articles over at gamedev are pretty good but I don't like using other peoples ideas like that. Even now as I use his Singleton base class I feel constantly... dirty.
    Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.

    - Mike McShaffry

  2. #2
    Its hard... But im here swgh's Avatar
    Join Date
    Apr 2005
    Location
    England
    Posts
    1,475
    You make some very good points. Game design is a hard prospect to keep going, as with OOP and classes, making them do what they want and keeping them updated is always an issue. Design is the upmost important, and as you put, planning it all first can save you having to scrap a 15000 line program as you think of somthing you could of done at the start. When I started programming, I was told to sit down, think of a game idea, eg, rpg, text, graphical, then slowly work around the procedures. eg, classes; when i had done this I would plan or "sketch" my idea(s) on notepad or wordpad before I used my IDE to implement them. Having a solid plan in game design is importnant for this reasOn I was told. It is sound advice I was given, and have always remembered it.

    Maybe I'm getting off the subject here a little, but that is my idea on good game planning and design. Theroy = pactical = good game! ( hope!)

    As for links, try google, but you could try www.planetsourcecode.com as they have loads of premade games that people have made to get some insiration from. Good luck!

  3. #3
    Supermassive black hole cboard_member's Avatar
    Join Date
    Jul 2005
    Posts
    1,709
    That sounds like good advice. I just can't seem to get my ideas out unless I need them on the spot, while I'm implementing another. I'll try getting into the habit of jotting down ideas as they come to me while I work.
    Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.

    - Mike McShaffry

  4. #4
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    > I really suck at designing
    It's an aquired skill - practice small and work your way up from there.

    Figure out what sort of program you could write "straight from your head" without doing any kind of up-front design.

    Pick a project which you estimate would be about 5 to 10 times bigger than that and start making some design notes. For this sort of scale, you should be able to figure out in a few hours pretty much everything you need to do. Focus on things like significant algorithms, data structures, class relationships, internal interfaces. Think about how you would test each component.
    Keep refining the details until you have a list of say 10 to 20 "easy" things to do, and have a go at implementing it.
    Depending on how well that goes, use that to calibrate whether you need more or less design for next time around.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  5. #5
    Supermassive black hole cboard_member's Avatar
    Join Date
    Jul 2005
    Posts
    1,709
    Thanks Salem. Is this a method of design you use(d) in your work / hobbies (you work, right?) ?

    I should be back in a few hours
    Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.

    - Mike McShaffry

  6. #6
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,451
    Pretty much, except my designs take weeks or months to complete.
    Projects with 100K+ lines don't just come out of your head in one sitting at the keyboard.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  7. #7
    Supermassive black hole cboard_member's Avatar
    Join Date
    Jul 2005
    Posts
    1,709
    I'm unsure how to design the collision detection. If I have the Player class, I want it to check whether it's colliding with anything each frame, right? How do I do this without knowing what it'll be colliding with?

    I was thinking of having a base class, SolidObject, which other objects can derive from. Something I've never been sure on: If an object inherits from one class, can I use the base class to check for a generic situation, if you see what I mean.

    Something like:

    Code:
    class Player {
    public:
        // ...
        bool CheckCollision(SolidObject& with);
        // ...
    };
    Assuming a class, lets call it Wall, has derived from SolidObject, would CheckCollision still realise the Player is colliding with a Wall by checking on a SolidObject?

    Ok while typing this I've just realised, this is all well and good, but what the hell am I supposed to pass as an argument to CheckCollision each frame? I can't check for a collision with everything in the scene each frame... could I? Maybe by keeping a list of all SolidObject's in the scene. Meh, that just seems stupid to me.
    Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.

    - Mike McShaffry

  8. #8
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    >Assuming a class, lets call it Wall, has derived from SolidObject, would CheckCollision still realise
    >the Player is colliding with a Wall by checking on a SolidObject?

    Yes.


    >Ok while typing this I've just realised, this is all well and good, but what the hell am I
    >supposed to pass as an argument to CheckCollision each frame? I can't check for a collision
    >with everything in the scene each frame... could I? Maybe by keeping a list of all SolidObject's
    >in the scene. Meh, that just seems stupid to me.

    You need some form of space partitioning to check only relavent objects. You could check only the objects that lie in the view frustrum for example (this is oversimplified though, what happens if you back up!)

  9. #9
    Supermassive black hole cboard_member's Avatar
    Join Date
    Jul 2005
    Posts
    1,709
    How do frustrum's work in 2D? Or 3D for that matter - I haven't got a clue.
    Guess I'll wiki it later too.
    Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.

    - Mike McShaffry

  10. #10
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    If your workingin 2D its just the viewable area ( a frustum is a pyramid with the tip cut off, its a 3D shape )

  11. #11
    Call me AirBronto
    Join Date
    Sep 2004
    Location
    Indianapolis, Indiana
    Posts
    195
    When you need to check for massive amounts of collisions you need some sort of a cheaper check to see what has the possibility of colliding, like having a invisibly circle around all of your objects and testing to see if the object of interest is within the distance of the radius of the circle, if its not, then who the hell cares, if it is, well then now we just may have something.

    I dont know how the big dadies out there check in the case of the latter situation but i am sure it has something to do with Axis the Sysmetry theroy, because it works on the principal that it will take the most steps to determine if something is colliding, which is usually the rarest case so it all makes sense.

  12. #12
    Call me AirBronto
    Join Date
    Sep 2004
    Location
    Indianapolis, Indiana
    Posts
    195
    I think I can see your problem when it comes to game engine design.
    First let me explain why I think what your problem it what it is.

    At the beginning of this article you were asking about advice on good game engine design. In the same question you start talking about some of the things you usually do,
    create skeletons of classes I know I'll need, Player, Kernel, MessageReceiver, MapTile, MapManager, I think that's it.
    Then later in the discussion you start asking about collision detection and aspects of it.

    Well it seems to me that you are suffering from what many many people, new and old to programming, suffer from. You are looking at the idea of your game engine, and are thinking about all the specifics that need to be done. There is certainly a time and a place for this, but right of the bat you need to answer a few questions:
    1)"What will I need to be able to do with this engine in a general sense later on". Well since you are not a master of all that is code, you donít know exactly what you will need to be able to do. So this means you need a core design that will allow you to add in any thing as it needs to be added.
    2)ďWhat will need to be able to see certain information, and what will it beĒ. Well you also donít know this because you donít even know all of what needs to be in the engine. So you need to make a system that holds all general information providing classes and provides a means of delivering that information, or the class that dose this, to a calling needer of this information.

    Donít think of specifics like what is colliding with what until you have created a system that can do these things. You need to be able to answer the most general and basic fundamentals of a program before making specifics, and since you are not a professional, you donít know, so just make it so you can add anything at any time. It sounds difficult but really it not to bad.

  13. #13
    Sweet
    Join Date
    Aug 2002
    Location
    Tucson, Arizona
    Posts
    1,801
    To ahluka: I totally understand I have done the same thing to man. As far as having the base class thing I basically generalize everything to a sprite then derieve everything on it considering everything you see on the screen is techniquely a sprite. It looks like this
    Code:
    #ifndef sprite_h
    #define sprite_h
    #include <vector>
    #include "bitmap.h"
    
    //A struct to hold x, y pos for screen location
    struct coord
    {
        short int x;
        short int y;
    };
    
    //A struct for bounding box collision
    struct boundingBox
    {
        short int top;
        short int bottom;
        short int left;
        short int right;
    };
    
    class Sprite
    {
        public:
            Sprite();
            Sprite(const short int ani);
            Sprite(const Sprite &copy);
            Sprite &operator=(const Sprite &assign);
            //Return non-modifiable goods :)
            inline const boundingBox &Get_Collision() const;
            inline const coord &Get_Pos() const;
            //Set the X or Y position of the Sprite
            inline void Set_X(const short int x);
            inline void Set_Y(const short int y);
            //Return the current animation of the sprite
            inline const short int Get_CurAni() const;
            //Set the current animation
            inline void Cur_Ani(const short int ani);
            //Is the sprite currently offscreen
            bool isOffscreen();
            //Collision Detection
            bool operator==(Sprite &collide);
            //Draw to specified bitmap
            void operator<<(Bitmap &dest);
            void Draw(Bitmap &dest);
        private:
            //Update the bounding box collision detection
            bool Update_Collision();
            //All the Bitmaps for animations
            std::vector<Bitmap> animations;
            //Maximum animations for the Sprite
            short int max_ani;
            //The current animation of the Sprite
            short int cur_ani;
            //The bounding box collision of the Sprite
            boundingBox sBox;
            //The X, Y pos of the Sprite
            coord pos;
            //Is this an active bitmap
            bool active;
    
    };
    
    //Inline because they are just one liners
    inline const boundingBox &Sprite::Get_Collision() const
    {
        return sBox;
    }
    inline const coord &Sprite::Get_Pos() const
    {
        return pos;
    }
    inline const short int Sprite::Get_CurAni() const
    {
        return cur_ani;
    }
    inline void Sprite::Set_X(const short int x)
    {
        pos.x = x;
    }
    inline void Sprite::Set_Y(const short int y)
    {
        pos.y = y;
    }
    inline void Sprite::Cur_Ani(const short int ani)
    {
        cur_ani = ani;
    }
    
    #endif//sprite_h
    Woop?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. come and lay down,where ARE YOU FROM?
    By oshindeler in forum A Brief History of Cprogramming.com
    Replies: 9
    Last Post: 08-03-2006, 03:02 PM
  2. need help to logically lay out program
    By Led Zeppelin in forum C Programming
    Replies: 3
    Last Post: 04-07-2002, 10:11 PM

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