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?

Heres a video of the glitch

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.

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.

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.

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

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.

I'm curious about whether or not you were able to solve the problem. Non-fully answered forum post can bring such misery.