Game design, classes and inheritance?

[enkitosh]

Hi. I'm making a shooting game and since my code was getting a bit messy and big I decided to divide it into couple of classes and files. I'm confused of how to correctly split these files and classes up though. As I imagine it without really knowing if that is the best way or not I have one base class called game, this is the class that draws the map, display's all the objects that are not moving and handles stuff like updating graphics for these items (when player loses his live it wipes out a heart etc.)
Next I have a class derived from this base class called Player which handles all the player related stuff, updating his position and drawing him on the screen. I also have another class derived from the base class called enemy which handles the exact same things as in the player class but just with enemies position etc.

Now what I was hoping to do is this
Update map seperately
display player on map but be able to draw him every couple of times per second + bullets etc
do the same thing with enemy

I have created a virtual function for draw but there is a problem. My map covers the whole screen so I can't just pass things in and out of it without having access to the base class map, objects of other classes will of course just create their own map.
What would be the best way to hande this? to seperate these processes but still be able to keep one stable map?
By the way my game map consists of a char array, are vectors better for this?

I'm quite new to game making so I'm also just looking for general advice on how to do things.

best
Doddi

[Lerner]

There is a game development forum on this site. I don't go there much so I don't know if people who do routinely spend a fair amount of time here, or not. I also expect you could get some idea of the way other people do it by doing a search on Google use a query such as game development C++ and the name of the Graphics Library you plan to use

[mike_2000_17]

This is a huge topic and you will have to think it through much more than that to make it out alive (figuratively).

What you want is a game engine. Either make your own simple design or pick one off-the-shelf.

If you want suggestions for an off-the-shelf option, I would suggest Ogre3D (and its game logic extension NeoAxis).

Ogre3D also gives you a very typical example of how things are generally structured when making an essential part of a game engine, i.e., the renderer. You can see its core structure here.

Overall, a game engine has three main parts: renderer, physics engine, and game logic manager.

The renderer takes care of putting things on the screen. Typical features include rendering maps and objects, lighting, cameras, visual effects, particle systems, pixel shaders, shadows, etc.. This is the kind of tasks that Ogre3D does.

The physics engine takes care of all the physical interactions between objects, such as integrating motion, computing forces (often called "rag-doll" physics), kinematics (often called "skinning"), collision detection, etc... The Open Dynamics Engine (ODE) is a very basic example of such a physics engine.

The game logic manager takes care of all the "rules of the game". This might range from taking input from the user, to keeping the scores.

There are also other auxiliary parts to a game engine, like handling menus, network gaming, etc..

The reason why all these parts are generally separated is that they have very distinct tasks with little overlap. Also, each part can be individually customized for a particular problem. For example, for a racing game, you probably could do fine with a basic renderer (since most of the scene is static and passes by too fast to require nice rendering), then you combine that with a good physics engine for driving dynamics and a simple game logic manager for the user input (very simple for a racing game) and taking the lap times. For a shooter game, it would be very different, you need a renderer with nice effects (particle systems, dynamic lighting, etc.), the physics engine needs to be good at collision detection and impact dynamics, while the game logic would mostly be running AI. And so on. Some application might not even require some parts, and each part can be used by itself.

Each of these parts are usually implemented as independent parts consisting of several base classes and derived classes. All in all, this can easily grow to become a huge project. That's why I would recommend that you either use off-the-shelf libraries for all or at least a good chunk of your project.

[enkitosh]

Thank you mike for your thorough answer. I had not heard of Ogre3d before but yeah their structure looks quite like what I'm looking for.
I'm off the console now, I was going to start off by an easy console game but to write for it you just have to put up with so much bs, plus
you can't use any sound or other cool effects, so now I want to move on to a graphics library that can handle stuff but is still quite "easy" to understand. Somone mentioned SMFL , I like the look of it. I'm going to study game engines and try to pick one of these libraries , thanks again ;)

[Tumlee]

SFML still has some maturing to do. The last time me and my friend tried to make something with it, it turned out it didn't even support certain computer architectures. In the meantime, I suggest using SDL, and it's extensions, SDL_mixer and SDL_image, to make a game. With the proper knowhow, you can make a full 2D game with sound, music, and graphics.

[sergent]

Yes Tymplee is right. SDL is cross-platform and really useful. You can also add 3D graphics with OpenGL to it if you want to.

[Serapth]

There aren't very many tutorials out there about how to split up and structure your game. This tutorial covers exactly that while taking you throug the process of creating a complete game in C++ using SFML. It is quite long ( 10 chapters ) but covers quite a bit in addition to code design. Hopefully it will be of some use to you.

SFML has some warts ( including a really nasty ATI crash bug ), but it is a cleaner, better documented library than SDL, if you aren't targeting mobile.