Sign in to follow this  

extern game variables

This topic is 3489 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ive come to notice that a lot of my files are beginning to contain a lot of extern variables, that are becoming hard to maintain, when i edit my code. Such as in my weapon.cpp i have an extern to the camera object, so i can set the bullets initial position and extern variables to my IDirect3DDevice9* pointer in most .cpp so i can make device changes, and renders extern variables to keystates and other variables that are declared in the main app .cpp, but need to be accessed in my class .cpps Now the way i see it, is i have 2 options, to pass this data in the class methods, when they are being called, or to create a global struct object, which is created in main, and is coded as a extern variable in all the .cpps that need it. which at the moment is looking somthing like this
struct Global_Settings

{
		bool				TextureMode;
		bool				scriptMode;			//whether or not in scriptmode
		bool				pauseMode;
		bool				displayKeys;
		bool				displayMouse;
		int					timesLeftMouseClicked;
		int					timesMiddleMouseClicked;
		int					timesRightMouseClicked;
		bool				music;
		Clock				time;
		GameLog				gameLog;
		IDirect3DDevice9*	gd3dDevice;
		bool*				keyStates;
		int					ScreenCenterX;
		int					ScreenCenterY;
		unsigned int		TriangleCount;
		unsigned int		VertexCount;
		IDirect3DTexture9*	missingTextureImage;
		Camera*				CurrentCamera;
};


to which i have a lot more to add, but in my eyes is much easier to maintain, as i only have to make the changes in one place but which idea is recommended?, or any other ideas you can suggest

Share this post


Link to post
Share on other sites
You can try using an Object Oriented strategy.

Just wrap all your specialized functionality in classes, including the variables that it uses. Such as all the DirectX code could be put in a class that specializes in rendering. KeyStates can be put into a keyboard class of some sort. Once you organize your code into classes like these you can easily add code into it that should only belong with other similar code.

If you plan it out nicely, everything could fit into a class with other similar variables and code. Once thats done, its easier to use one class that encapsulates more then one variable.

Share this post


Link to post
Share on other sites
First thing that came to mind is that you should decouple your camera from your weapon (and/or bullets). Think about it - does a weapon need a camera to be fired? [wink]

Next, give the weapon a "fire position". Basically, this is where bullets would come out of. When the weapon fires, create a bullet, and pass the fire position and fire direction to your bullet (same idea, except you can derive the fire direction from the orientation of the weapon). Then, the bullet is just a separate object, completely decoupled from anything but itself. In an entity-based update function, it would just travel against it's direction starting at it's base "fire position".

This is why OOP comes in so handy:

class Bullet: public Entity {
private:
vec3 position, direction;
real speed;

public:
Bullet(const vec3 &origin, const vec3 &direction, real speed = 1):
position(origin), direction(direction), speed(speed) {}

void update(real elapsedTime) {
position += direction * speed * elapsedTime;
}
};

Obviously, this is a bit over simplified since bullets move very fast, but it's an example. Notice how the bullet does not rely on anything but itself. The same goes for the weapon - it should have a fire position, and automatically create bullets as so:

void Weapon::fire() {
bullets.push_back(new Bullet(firePosition, weaponDirection));
}


That's the general idea. When you do things like this, you reduce the dependencies, and that gigantic global structure you had would be rendered useless.

Share this post


Link to post
Share on other sites

This topic is 3489 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this