Access to derived functions

Hi all

Got a problem I constantly run into when creating small games as programming practice. I am currently practicing keeping the game engine seperate from the game itself, passing the specific game into the engine so the latter can do its thing.

The problem I have is that when creating the Engine's functions, because I want it to process any game I throw at it, I have to use the parent class "Game" as the parameter being passed into the engine, instead of the specific game such as "Connect 4" or "Checkers". In so doing I lose all the functionality of the specific game when passing it into the engine.

Consider the following fragments that should demonstrate my problem:

Code:

---

Connect4 C4Game; // The Game I will pass into the engine. Connect4 is a derivation of the Game class

Engine::PlaceCounter(Game& theGame) // A function in the engine to place counters in whatever game is passed in
{
unsigned short WhereToPlaceCounter;
cout << "Please choose where to place counter: ";
cin >> WhereToPlaceCounter;
theGame.CheckPlacementPossibility();
//...
}

---

I would like "CheckPlacementPossibility" to check with the specific game we've passed in that it's OK to place the counter where the user has requested (since where we can place a counter on the Connect 4 grid will be different to where we can place it on the Othello grid, for example). However, the complier refuses - instead it calls the CheckPlacementPossibility function straight from the parent class Game, where I have a statement that simply reads "you shouldn't be chaining this far up!". I would like the function to call CheckPlacementPossibility ()according to whichever type of Game I've passed in (such as Connect 4).

As I've said I seem to run into this problem all the time and working around it tends to be ugly, legnthy, and often compromises what I originally set out to achieve. If anyone knows of a simple way to resolve this it would be greatly appreciated.

Thanks :-)

Sorry I should've mentioned that - yes I have. But it's as though C4Game has been converted into an object of type Game, and as such it is using all the functions local to that class.

Quote:

---

Originally Posted by Know_Your_Role

But it's as though C4Game has been converted into an object of type Game, and as such it is using all the functions local to that class.

---

That sounds like type slicing. If you use sufoode's suggestion, and also make sure that (smart) pointers or references to Game are used, then this problem should not happen.

post more code.

I've managed to fix this issue but am having a similar issue. I have placed it under a seperate post, but a summary here: In "main" I am creating game objects of various types (Connect4, chess etc) with a view to plugging them into the same generic "Game" engine ("Game" being the base class of the various sorts of game we may plug into the engine). So I may use the following:

Code:

---


Engine* theEngine = new Engine;
Connect4* C4Game = new Connect4; // the constructor allocates the member data
theEngine->RunSinglePlayer (C4game);

void theEngine::RunSinglePlayer (Game* RelevantGame)

---

The data is not passing over from the call to RunSinglePlayer() and the actual function. I can only assume this is because the type of data is now the base class Game instead of derived class Connect4. However this will not work for what I am trying to achieve. Whilst I need the call to RunSinglePlayer() to allow for various different sorts of games which may be plugged into the engine, I still need it to use the object's function calls and member data which would be relevant if were still a Connect4 object.

I don't even know if this is possible but I certainly hope so because this is going to cause a massive problem if not :( If you know a workaround I'd really appreciate - thanks!

However because it is being converted from

Quote:

---

Engine::PlaceCounter(Game& theGame)

---

This looks like a design flaw to me. If the engine is indeed separate from the game then keep them that way. Why does the engine need to know about the game at all? The game could derive from something like IGame to facilitate different type of games in the future. The derived versions of IGame would then use IEngine instead of IEngine using IGame. The game should use the engine, not the other way around.


IGame
- Checkers
- Tic tac toe
- ...
IEngine
- raw Direct3D
- raw OGL
- OGRE
- Irrlicht
- Unreal
- Quake
- ...

It is not simple to abstract this out b/c Unreal, Quake, Direct3D, OGL, etc are all very different. However it is possible to find some commonalities between them that could be applied to all generic 'engines' or rendering 'engines'.

Might I recommend the following book:
http://www.amazon.com/Game-Engine-Ar.../dp/1568814135

Bubba - So you're saying the engine should plug into the game, not the other way round? Ironically this is how I first set this up before deciding it didn't look right! :(

I'm saying the game should 'use' the engine. Nothing says it has to plug-in in the sense of passing a pointer to the engine. Now if you were to use a game interface pointer it wouldn't be as bad but there is still no reason to pass any core 'game' pointers to the engine in that manner.

Much of the communication back and forth can be done by either implementing engine interfaces that have no impl or are designed to be user implemented or by callbacks from the engine.

I would invite you to look at the lightweight rendering 'engine' called OGRE as an example of what I'm talking about. Now this is not the only design out there but I would feel comfortable in saying that most 'engines' operate in a similar fashion. If you have a couple hundred dollars you can buy a license to Torque and see how it is implemented. There are many more samples on the internet on how to structure your core engine and the game using it. I highly recommend buying several books on the topic before getting too far into code. I usually follow a pattern of design, then code, then more design, then more code. A pure waterfall approach has not worked for me so I use a 'stepped' waterfall that is more akin to something like Sprints in Agile dev. The core principle is that you must have some kind of design be it textual or UML before you begin coding or you will end up with issues like the one you are encountering.

What you decide to do from this point on can and probably will make or break the rest of your project. I invite you to take a step back from the code and look at the bigger picture. Do not be so concerned with the implementation as much as the design at this point. If you do not have a design then you will end up re-implementing code over and over and over. So before you move on scope out your project and find out what it's core goals are and how you plan to meet those goals. Even though this is probably a hobby project software engineering practices still apply and will help you later. If I really did not want you to succeed I would just give you answers to your problem instead of giving you some guidance about doing some design work before continuing. So take a few days and start drawing boxes here and there and come up with a rudimentary design for the system. Remember you aren't designing every little aspect of it here - just the core pieces and how they will interact with one another is sufficient at this time. When you get stuck you can then come back and ask some design related questions which many here will be able to assist you with.