🔒 Locked

Program / Object Design in C++ Question

Started by BaShildy Dec 30, 2001 at 3:41 PM 5 replies 600+ views

Original Post

Dec 30, 2001 at 3:41 PM

I’m on a game development team of 5 people, and I am in charge of writing the framework and the design of our program. I’ve been programming in C for 1.5 years, and this will be my first game in C++, although I’ve messed around with the language.

To modularize the project so that everyone is working on a specific area of the game with their own files, I wanted to create a master game class that would hold all of our modules. The only problem with this approach was that other modules couldn’t call each other unless they were passed a ptr to it. I then thought that a namespace would make it easier for the other modules to reach. The structure was like this: (contents of BTC_main.h)

        
#ifndef __BTC_MAIN_H
#define __BTC_MAIN_H

#include "BTC_display.h"

#include "BTC_input.h"
 
#include "BTC_time.h" 

#include "BTC_menu.h"
 
#include "BTC_gamedata.h" 

#include "BTC_network.h" 

#include "BTC_flow.h" 

#include "BTC_lobby.h" 

#include "BTC_setup.h" 

#include "BTC_sound.h" 

#include "BTC_hud.h" 

namespace game
{
	int	(*control)();	// Function Pointer that pts to what 'loop' is in control

	Display	display;			// Display Module

	Input		input;				// Input Module

	Time		time;				// Time Module

	Menu		menu;				// Menu Module

	Gamedata	gamedata;			// In-Game Data Object

	Network	network;			// Networking Module

	Lobby		lobby;				// Lobby Module

	Setup		setup;				// Startup Code

	Sound		sound;				// Sound Module

	Hud		hud;				// Heads Up Display Module


	int SetupGame(HWND hwnd, HINSTANCE hinstance)
	{
		setup.Display(hwnd, hinstance, &display);
		display.Init();
		sound.Init();
		time.Init();
		return 0;
	}

	int ShutdownGame()
	{
		display.Release();
		sound.Release();
		return 0;
	}


}
#endif

main.h included all the files in the project, which contained all the classes listed above. The only problem is that if more then 1 file linked main.h it would give me redefinition errors, despite the fact that main.h has a #ifndef , #define, #endif trifecta. :/ I need a way that I can basically get at the game namespace from anywhere, without redefinition errors. That way I could set the function pointer (which by the way is a rockin way to do flow control) anywhere, and have all the classes interact with each other publicly. If you notice “setup.Display(hwnd, hinstance, &display)” requires me to pass in a ptr to the class. If I’m already inside one of the classes, I can’t do this. Finally, is there any way to friend a class (say the hud) to the display class, I didn’t know the syntax for doing that, and then accessing stuff in the display class. Big thanks to anyone who reads this, and a bigger one to anyone who answers. Oh and if anyone was wondering BTC stands for Black & Tan Client :/ Code comment of the week: bool hack = false; // DO NOT CHANGE THIS EVER Edited by - BaShildy on December 30, 2001 4:42:56 PM Edited by - BaShildy on December 30, 2001 4:44:17 PM

BaShildy

Author

BaShildy

Dec 30, 2001 at 6:39 PM

I think i have come across a sollution. By declaring all variables and classes static within the namespace, i am guarenteed 1 instance of them, so i can then link any .cpp file with main.h and its namespace without multiple definitions. I could be wrong, and this will bite me in a few hours though :/

Code comment of the week:
bool hack = false; // DO NOT CHANGE THIS EVER

Brannon

Dec 30, 2001 at 6:51 PM

try declaring all of the variables in the header as ''extern'', then have a main.cpp (or whatever) where you actually define the variables.

-Brannon

BaShildy

Author

BaShildy

Dec 30, 2001 at 7:48 PM

How would that work with having them all in the namespace though? I understand how to have global variables accessible, but how would i get the namespace containing all of them accessible. I tried externing the namespace but that didn''t work.

Shannon Barber

Mod

368

Shannon Barber

Dec 30, 2001 at 8:13 PM

The OOP way would be to use interface pointers... Make a GameEngine class that holds interface pointers to the sub-systems, and give the sub-systems access to those interface pointer pointers.

quote:

Finally, is there any way to friend a class (say the hud) to the display class, I didn’t know the syntax for doing that, and then accessing stuff in the display class.

1) Yes there is.
2) Don''t do this.

  
class CGameEngine
{
public:
IGraphicsEngine m_pGfxEng;
ISoundSystem    m_pSndSys;
///etc...


Init()
{
m_pGrfEng = new CGraphicsEngine;
m_pSndSys = new CSoundSystem2;
//create other sub-systems


m_pGrfEnd->Init(this);
m_pSndSys->Init(this);
//...

}


};


class CGraphicsEngine : public IGraphicsEngine
{
};

BaShildy

Author

BaShildy

Dec 30, 2001 at 8:27 PM

Thanks for the reply, Magmai Kai Holmlor. So my original class idea was correct, and i did need to use those interface pointers. Would all the modules need to be declared as static? I couldn''t get it to compile without this because it was giving me redefinition errors. Only problem now is, if i make calls from multiple cpp files, it seems to be making multiple copies of the namespace. To use the GameEngine class from multiple cpp files, how would i declare the class and define it and interface it?

Thanks, been having trouble setting this up for the past couple days.

Code comment of the week:
bool hack = false; // DO NOT CHANGE THIS EVER

BaShildy

Author

BaShildy

Dec 30, 2001 at 9:41 PM

Alright I got it working, I’ll explain how I fixed it. Thanks Brannon for that tip, you were right, but I was unsure on how to implement it at the time.

Here are the updated files:

BTC_main.h

         

#include "BTC_display.h"

#include "BTC_input.h"

#include "BTC_time.h"

#include "BTC_menu.h"

#include "BTC_gamedata.h"

#include "BTC_network.h"

#include "BTC_flow.h"

#include "BTC_lobby.h"

#include "BTC_setup.h"

#include "BTC_sound.h"

#include "BTC_hud.h"

#define Text(HDC, x, y, string) TextOut(HDC, x, y, string, strlen(string))

namespace game
{
	extern int (*control)();	 // Function Pointer that pts to what 'loop' is in control

	extern Display		display;			// Display Module

	extern Input		input;				// Input Module

	extern Time		time;				// Time Module

	extern Menu		menu;				// Menu Module

	extern Gamedata	gamedata;			// In-Game Data Object

	extern Network	network;			// Networking Module

	extern Lobby		lobby;				// Lobby Module

	extern Setup		setup;				// Startup Code

	extern Sound		sound;				// Sound Module

	extern Hud		hud;				// Heads Up Display Module


	extern int SetupGame(HWND hwnd, HINSTANCE hinstance);
	extern int ShutdownGame();

}
#endif

BTC_main.cpp (partial)

         
#include "BTC_precompiled.h"

#include "BTC_main.h"

extern	int		FlowTest();
bool	Close_Application	= false;

int		(*game::control)();			// Function Pointer that pts…

Display	game::display;				// Display Module

Input		game::input;				// Input Module

Time		game::time;				// Time Module

Menu		game::menu;				// Menu Module

Gamedata	game::gamedata;			// In-Game Data Object

Network	game::network;			// Networking Module	

Lobby		game::lobby;				// Lobby Module

Setup		game::setup;				// Startup Code

Sound		game::sound;				// Sound Module

Hud		game::hud;				// Heads Up Display Module


int game::SetupGame(HWND hwnd, HINSTANCE hinstance)
{
	game::setup.Display(hwnd, hinstance, &game::display);
	game::display.Init();
	game::sound.Init();
	game::time.Init();
	return 0;
}

int game::ShutdownGame()
{
	game::display.Release();
	game::sound.Release();
	return 0;
}

// rest of main.cpp left out

BTC_flow.cpp (partial)

         
#include "BTC_precompiled.h"

#include "BTC_main.h"

int FlowTest()
{
	game::time.Init();	// Initiate the time (move this to flow - game)

	game::display.screen->Flip(game::display.backbuffer, 0);
	return 0;
}

All functionality from the game namespace is now accessible by any module just by linking the BTC_main.h header. This was the goal of the framework so that each of my team members would not write code in the same files so they would possibly overwrite each other, and so that using namespaces and classes each call would be as self-explanatory as possible. I will try to add Magmai Kai Holmlor’s suggestion of having interface pointers within each class that needs it, so that classes like the hud could call the display class without the caller having to pass in the address of the display class every time.

Thanks guys for all your help, I really appreciate it. This game is a project I’m working on at DigiPen, and they always give us unreasonable times to finish these projects. I’m on break, and trying to get ahead as much as possible :/

Code comment of the week:
bool hack = false; // DO NOT CHANGE THIS EVER

Edited by - BaShildy on December 30, 2001 10:46:39 PM

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.