• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ISDCaptain01

Why are my two classes sharing variables? C++

25 posts in this topic

Okay I have two classes:

 

SWORDBEAM: This one basically handles the projectiles that come out of the player, its pretty simple:

class SWORDBEAM
{
public:
	
	int x, y;
	int alive;
	int dir;
	int xspeed, yspeed;

	//COnstructor
	SWORDBEAM()
	{
		x = 0;
		y = 0;
		alive = 0;
		dir = 0;
		xspeed = 0;
		yspeed = 0;
	}


	//Core Functions
	void drawbeam()
	{
		int n;
		int px, py;

		px = x;
		py = y;

		//Is the beam active
		if(!alive)
			return;

		//Draw sword beam sprite
		if(dir == UP)
			al_draw_bitmap(swordbeamUp, px - mapxoff, py - mapyoff, NULL);
		if(dir == DOWN)
			al_draw_bitmap(swordbeamDown, px - mapxoff, py - mapyoff, NULL);
		if(dir == LEFT)
			al_draw_bitmap(swordbeamLeft, px - mapxoff, py - mapyoff, NULL);
		if(dir == RIGHT)
			al_draw_bitmap(swordbeamRight, px - mapxoff, py - mapyoff, NULL);
	}

	void movebeam()
	{
		int px, py;

		px = x;
		py = y;

		//Is the beam active?
		if(!alive)
			return;

		//Move the beam
		x += xspeed;
		y += yspeed;
		px = x;
		py = y;

		//Stay within the screen
		if(px < link->x - (gameBufferWidth/3) || px > link->x + (gameBufferWidth/3) ||
           py < link->y - (gameBufferHeight/2) || py > link->y + (gameBufferHeight/2))
		{
			//If it goes off screen, than kill it
			explosionSprite->alive = 1;
			alive = 0;
			return;
		}
	}

	void fireweapon()
	{
		//Ready to fire again
		if(!alive)
		{
			alive = 1;
			al_play_sample_instance(swordcomboInstance);

			//Fire the beam in the direction that link is facing
			switch(link->dir)
			{
			   //Up
			   case 0: 
				   x = link->x + link->width/2;
				   y = link->y + link->height/2;
				   xspeed = 0;
				   yspeed = -swordspeed;
				   dir = 0;
				   break;

               //Down
			   case 1:
				   x = link->x + link->width/2;
				   y = link->y + link->height/2;
				   xspeed = 0;
				   yspeed = swordspeed;
				   dir = 1;
				   break;

				//Left
			   case 2:
				   x = link->x + link->width/2;
				   y = link->y + link->height/2 - 3;
				   xspeed = -swordspeed;
				   yspeed = 0;
				   dir = 2;
				   break;

				//Right 
			   case 3:
				   x = link->x + link->width/2;
				   y = link->y + link->height/2 - 3;
				   xspeed = swordspeed;
				   yspeed = 0;
				   dir = 3;
				   break;
			}
		}
	}
};


//Declare a swordbeam
SWORDBEAM swordbeam;

My other class is the enemy, It basically moves in a path I set for it:

class OCTOROCK
{
private:

	int x, y;
	int width, height;
	int curframe, maxframe;
	int framecount, framedelay;
	int dir;
	int alive;
	int pathx1, pathx2;
	int pathy1, pathy2;
	int speed;

public:

	//Constructor
	OCTOROCK()
	{
		x, y = 0;
		width, height = 0;
		curframe, maxframe = 0;
	    framecount, framedelay = 0;
	    dir = 0;
		int speed = 0;
		alive = 0;
		pathx1, pathx2 = 0;
		pathy1, pathy2 = 0;
	}

	void setUp(int px, int py, int pwidth, int pheight, 
		       int pcurframe, int pmaxframe, int pframecount,
			   int pframedelay, int pdir, int pspeed, int palive,
			   int ppathx1, int ppathx2, int ppathy1, int ppathy2)
	{
		x = px;
		y = py;
		width = pwidth;
		height = pheight;
		curframe = pcurframe;
		maxframe = pmaxframe;
		framecount = pframecount;
		framedelay = pframedelay;
		dir = pdir;
		speed = pspeed;
		alive = palive;
		pathx1 = ppathx1;
		pathx2 = ppathx2;
		pathy1 = ppathy1;
		pathy2 = ppathy2;

	}

	//Responsible for updating the octorock
	void updateOctorock()
	{
		if(alive)
		{
			//Give octorock a path to follow, only dealing with x axis for now
			if(x > pathx2)
			{
				dir = LEFT;
			}
			else if(x < pathx1)
			{
                dir = RIGHT;
			}
			
			//Move the octorock
			if(dir == UP)
			{
				x += 0;
				y -= speed;
			}
			if(dir == DOWN)
			{
				x += 0;
				y += speed;
			}
			if(dir == LEFT)
			{
				x -= speed;
				y += 0;
			}
			if(dir == RIGHT)
			{
				x += speed;
				y += 0;
			}
		}
	}

	//Responsible for drawing the octorock;
	void drawOctorock()
	{
		//Is it alive?
		if(alive)
		{

			//South
			if(dir == DOWN)
			{
				if(++framecount > framedelay)                    
				{
					framecount = 0;

					if(++curframe > 1)
					{
						curframe = 0;
					}
				}
			}

			//North
			/*else if(dir == UP)
			{
				if(++framecount > framedelay)
				{
					framecount = 0;

					if(++curframe > 3)
					{
						curframe = 2;
					}
				}	
			}*/

			//Left
			else if(dir == LEFT)
			{
				if(++framecount > framedelay)
				{
					framecount = 0;

					if(++curframe > 5)
					{
						curframe = 4;
					}
				}	
			}

			//Right
			else if(dir == RIGHT)
			{
				if(++framecount > framedelay)
				{
					framecount = 0;

					if(++curframe > 5)
					{
						curframe = 4;
					}
				}	
			}

			if(dir == RIGHT)
			{
				al_draw_bitmap_region(octorock_images[curframe], 0, 0, 
								   al_get_bitmap_width(octorock_images[curframe]),
								   al_get_bitmap_height(octorock_images[curframe]),
								   x - mapxoff, y - mapyoff, NULL);
			}
			else
			{
				al_draw_bitmap_region(octorock_images[curframe], 0, 0, 
								   al_get_bitmap_width(octorock_images[curframe]),
								   al_get_bitmap_height(octorock_images[curframe]),
								   x - mapxoff, y - mapyoff, ALLEGRO_FLIP_HORIZONTAL);
			}
		}
	}

	//Sees if the octorock got attacked by link
	void detectCollision()
	{
		int playerx;
		int playery;

		int x1;
		int x2;
		int y1;
		int y2;

		if(alive)
		{
			playerx = link->x;
			playery = link->y;

			x1 = x;
			y1 = y;
			x2 = x1 + width;
			y2 = y1 + height;

			if(inside(playerx, playery, x1, y1, x2, y2))
			{
				if(link->curframe == 0 || link->curframe == 1 ||
				   link->curframe == 2 || link->curframe == 3 ||
	               link->curframe == 4 || link->curframe == 5 ||
				   link->curframe == 6 || link->curframe == 7)
				{
					hearts -= 1;
				}
				else if(link->curframe == 9 || link->curframe == 10 ||
					    link->curframe == 11 || link->curframe == 12)
				{
					alive = 0;
				}
			}
		}
	}

	void octoPosition()
	{
		cout << "X Pos: " << x << endl;
		cout << "Y Pos: " << y << endl;
	}
};

OCTOROCK octorock[1];

The problem is that when I shoot my projectiles, my enemy gets shot out along with the projectile sprite. I have no clue why this is happening.

I have console window running keeping track of all postions and it seems like the swordbeam and octorock are sharing variables. If they are separate classes then how so?

Edited by ISDCaptain01
0

Share this post


Link to post
Share on other sites

Are you sure you don't have some globals variables named exactly like in your classes or something? I can't see anything wrong with the code, maybe i am missing something... also the bug might be elsewhere, who knows. Did you tried debugging it? The error shoud be pretty oblivious, find what's changing the enemy location when shooting the sword.

Edited by Vortez
1

Share this post


Link to post
Share on other sites

If you're using Visual Studio, use a debug build and make sure to enable all the run-time checks (especially to check for out of bounds writes).

 

Finding the error would also be easier if the code wouldn't be so C-ish and cluttered.

 

-Stop declaring uninitialized variables

 

Seriously, what's the point of creating uninitialized variables and then assign stuff in the next line? Eventually you might want to start writing const correct code and that simply won't work if you stick with that. A similar thing goes for constructors. Embrace initializer lists.

 

-Don't assign values you'll never use

 

Not only are px and py in movebeam() completely pointless, they are also first assigned values and then overwritten without these values ever having been used. The function as about twice as long as it should be, only due to doing lots of pointless things.

 

-Don't declare at the top of the function, but at point of first use

 

That you way you would have noticed that n in drawbeam has become completely unused and pointless.

 

-Avoid useless clutter

 

What's the point of px and py in drawbeam?

 

-There's more types than "int"

 

alive doesn't track types of being alive (which should be an enum) or a degree of being alive. It's a bool. Why create doubt about the usage and meaning of a variable by not using the appropriate type for it?

 

-Vectors are nice

 

They would also prevent moving into a direction turning into a messy if/else-copy/paste orgy (if left and right do the same thing, why is this not one block for both?).

 

 

Finding bugs just from looking at code is a LOT easier if the code is clean and well written, without unnecessary clutter that makes everything look more complicated than it actually is. You're trying to find a bug in your code and your code being at least 3-4 times longer than it needs to be makes it at least 3 times harder to find it.

 

I can't see anything obvious that should result in the bug to describe (potentially for all the above reasons), so the obvious first step would be setting up breakpoints that trigger if the rock position is assigned a value that greater or smaller than a reasonable value, then check the call stack to see who's responsible for it.

 

Yeah I understand, and I appreciate the criticism. Im just gonna scrap the class and rewrite over again from scratch testing it fully.

0

Share this post


Link to post
Share on other sites
I'm on my phone and can't see all of your code, but from looking at the video, I wonder if it's your collision code. Maybe you put "=" instead of "==".
0

Share this post


Link to post
Share on other sites

Just curious. You set a lot of class variables as private. Any reason why you do that?

0

Share this post


Link to post
Share on other sites
^Orogonally they were publoc, I thought I should make them private just to see if that was the cause of this bug. Im still very much a beginner when it comes to O-O programming.

@Squared
Good idea, ill take a look.
0

Share this post


Link to post
Share on other sites

Where are the variables (or constants?)

swordbeamUp, swordbeamDown, ... octorock_images[curframe]

etc. declared?

 

I suppose those are global stuff, which seems a little shady.

I agree with Vortez ... the code that uses the classes is probably more interesting than the classes themselves.

Edited by DareDeveloper
0

Share this post


Link to post
Share on other sites

well I am trying to solve it. Heres what Im doing now. I scrapped the swordbeam and all projectiles from my game. Now im reimplementing the octorock class with better incapsulated code:

class OCTOROCK
{

private:
	SPRITE sprite;
public:

	//Constructor
	OCTOROCK()
	{
	}

	//Destructor
	~OCTOROCK()
	{
	}


	//Set the position of the octorock
	void setPosition(int x, int y)
	{
		sprite.x = x;
		sprite.y = y;
	}

	//Set the dimensions
	void setDimensions(int width, int height)
	{
		sprite.width = width;
		sprite.height = height;
	}

	//Set the frames
	void setFrames(int curframe, int maxframe, int framecount, int framedelay)
	{
		sprite.curframe = curframe;
		sprite.maxframe = maxframe;
		sprite.framecount = framecount;
		sprite.framedelay = framedelay;
	}

	//Set the speed of the octorock
	void setSpeed(int speed)
	{
		sprite.xspeed = speed;
		sprite.yspeed = speed;
	}

	//set the direction of the octorock
	void setDirection(int dir)
	{
		sprite.dir = dir;
	}

	//is it alive?
	void isAlive(int alive)
	{
		sprite.alive = alive;
	}

	//moves the octorock
	void moveOctorock()
	{
		if(sprite.dir == RIGHT)
		{
			sprite.x += sprite.xspeed;
			sprite.y += 0;
			sprite.curframe = 4;
		}
		else if(sprite.dir == LEFT)
		{
			sprite.x -= sprite.xspeed;
			sprite.y += 0;
			sprite.curframe = 6;
		}
		else if(sprite.dir == UP)
		{
			sprite.x += 0;
			sprite.y -= sprite.yspeed;
			sprite.curframe = 2;
		}
		else if(sprite.dir == DOWN)
		{
			sprite.x += 0;
			sprite.y += sprite.yspeed;
			sprite.curframe = 0;
		}
	}


	//Draw the octorock
	void drawOctorock()
	{
		al_draw_bitmap(octorock_images[sprite.curframe],
			           sprite.x - mapxoff, sprite.y - mapyoff, NULL);
	}
};
0

Share this post


Link to post
Share on other sites

Your original code looked fine. It may not have even been the classes that was causing the problem. Without seeing the full code, as Vortez pointed out, it may have just been an issue with variables outside the classes. Depending on what you passed the objects, you may have inadvertently been giving the same data to both so it was doing the glitch of drawing the enemy at the player's location and moving it forward.

0

Share this post


Link to post
Share on other sites

Swapping the variables is a good idea to get a better idea if the variables are overwritten "by name" or "by address".

 

Anyway, if you already know which variable changes, any decent debugger lets you set a breakpoint to when this variable changes and have a condition for the new value. It's a lot less painful than stepping through code that might run dozens of frames before the bug happens while manually staring at the watch window.

0

Share this post


Link to post
Share on other sites

I tried finding the bug and just couldn't, also I wasn't happy with the overall implementation of it, so I decided to nuke it and code it much cleaner this time.

0

Share this post


Link to post
Share on other sites

Just curious. You set a lot of class variables as private. Any reason why you do that?

 

wat  

0

Share this post


Link to post
Share on other sites
I think i found out the bug today guys. Basically what happened was that i declared an array of octorocks:
OCTOROCK octorocks[4];

But what i did wrong was that initialized it like this
octorock[1].x =......
octorock[2].x =......
octorock[3].x =......
octorock[4].x =......

What i did wrong is that i didnt access octorock[0] and did a memory violation by going out of bounds in tbe array with octorock[4].
2

Share this post


Link to post
Share on other sites

 

Just curious. You set a lot of class variables as private. Any reason why you do that?

 

wat  

 

In a simple answer, data hiding. It is usually common practice to make class members (variables) private and only allow access by way of constructors(mainly for initializing the class object) and class methods (functions). 

 

 

I think i found out the bug today guys.

I'm glad to hear you may have found it. It is looking good so far, IMO.

Edited by BHXSpecter
1

Share this post


Link to post
Share on other sites

I think i found out the bug today guys. Basically what happened was that i declared an array of octorocks:
OCTOROCK octorocks[4];
But what i did wrong was that initialized it like this
octorock[1].x =......
octorock[2].x =......
octorock[3].x =......
octorock[4].x =......
What i did wrong is that i didnt access octorock[0] and did a memory violation by going out of bounds in tbe array with octorock[4].


Don't worry. Mistakes like this are quite common. That's why I tend to look to see if I've made silly mistakes first when debugging. I hate it when I end up making major changes when the original bug just turns out to be a missing minus or something. Glad you found the answer.
2

Share this post


Link to post
Share on other sites

 

 

Just curious. You set a lot of class variables as private. Any reason why you do that?

 

wat  

 

In a simple answer, data hiding. It is usually common practice to make class members (variables) private and only allow access by way of constructors(mainly for initializing the class object) and class methods (functions). 

 

 

Yes.. Except he's asking why they are private, not public. I guess it was a typo.

0

Share this post


Link to post
Share on other sites

My apologies. Meant to quote just Buckeye and didn't realize I had quoted your post. It wasn't aimed at you. Again, I'm sorry, I should have paid closer attention to what I was quoting before submitting it.

0

Share this post


Link to post
Share on other sites

I think i found out the bug today guys. Basically what happened was that i declared an array of octorocks:
[...]
What i did wrong is that i didnt access octorock[0] and did a memory violation by going out of bounds in tbe array with octorock[4].

So it was indeed bad pointer management!
These kind of symptoms are really common in these cases.
0

Share this post


Link to post
Share on other sites

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  
Followers 0