I used a state manager very similar to yours, as well. I included Initialize() and Shutdown() methods to the game state interface which are called by the state manager. Initialize() gets called when a state is pushed, and Shutdown() gets called when the state is popped. That way, states can set up and clean up as needed. They also include a LoadGraphicsContent() method that can be used to deal with device loss/recreation. The main application calls StateManager.LoadGraphicsContent(), which iterates through the stack and calls each active state's LoadGraphicsContent() method.
Working nicely! One thing that I found that made the game dull is that the X-axis speed is always the same, just being mirrored when hitting the side walls. This makes the game just a matter of waiting for the ball to come up and down, and doesn't let the player have the ability to "redirect" slightly the movement of the ball to their liking, trying to hit those final bricks.
I think this could easily be implemented by dividing the paddle into, for instance, 3 different sections. If the ball intersected the middle section, there would be no modifier to the X-axis speed. If the ball intersected the left section, you could do Speed.X-- and Speed.X++ if it hit the right section. You just need to make sure that the value you increment/decrement isn't big enough to send the ball completely in the opposite direction. You could even divide the paddle into more sections for more detail.
Or another fun alternative would be... take a snapshot of the mouse X position when the ball is like 15 pixels above the paddle, and then take another snapshot on the moment of collision. Subtract both values, and that should give you a value of how "strong" and "fast" the user movement was. You can then finetune the ball speed according to that value.
I've seen a game of this type, that worked with accelerations instead of constant speed. Using the "see how fast the user moved the mouse" method, that game made it possible to give "effect" to the ball, and make it have "curve", which made for some fun stuff!
The mouse is how most users switch between windows. By restricting the mouse to your window you prevent this and your app would not be being very windows friendly.
I didn't want to say this, but I'm glad someone did.
The mouse is how most users switch between windows. By restricting the mouse to your window you prevent this and your app would not be being very windows friendly.
However if you really must do it this naive approach works ok - its not perfect and you need to make sure you only do it when the window has focus.
MouseState state = Mouse.GetState();
IsMouseVisible =
true;
int newX = state.X;
int newY = state.Y;
if (state.X < 0) newX = 0;
if (state.X > Window.ClientBounds.Width) newX = Window.ClientBounds.Width;
if (state.Y < 0) newY = 0;
if (state.Y > Window.ClientBounds.Height) newY = Window.ClientBounds.Height;
if (newX != state.X || newY != state.Y) Mouse.SetPosition(newX, newY);
I do have to ask, how can I lock the mouse in the window I don't want the mouse to be able to move outside the game window while the game is actually playing.
Or another fun alternative would be... take a snapshot of the mouse X position when the ball is like 15 pixels above the paddle, and then take another snapshot on the moment of collision. Subtract both values, and that should give you a value of how "strong" and "fast" the user movement was. You can then finetune the ball speed according to that value.
I updated my game with this, the new code and zip file has already been uploaded.
Haven't looked through all of the code yet, but I liked your idea of StateManager. It's very, very similar to the one I'm using in my own project, but now I noticed there's a few things I can definetly use to improve my implementation!
Could you pack your project So as not having to download file by file
Thanks for the ideas, like I said with my first post, it still is a work in progress, if you push Escape when the game is running, it goes into a unfinished paused screen.
Il look into putting one of these ideas in when I work on it next. (Probably when class starts up again)
XNA Breakout
Shakster
Vitalijus
MelissaA
Seconded. I'd like to look at it, but I'd rather not download each file.
ede1
I used a state manager very similar to yours, as well. I included Initialize() and Shutdown() methods to the game state interface which are called by the state manager. Initialize() gets called when a state is pushed, and Shutdown() gets called when the state is popped. That way, states can set up and clean up as needed. They also include a LoadGraphicsContent() method that can be used to deal with device loss/recreation. The main application calls StateManager.LoadGraphicsContent(), which iterates through the stack and calls each active state's LoadGraphicsContent() method.
Ali Majdzadeh
I think this could easily be implemented by dividing the paddle into, for instance, 3 different sections. If the ball intersected the middle section, there would be no modifier to the X-axis speed. If the ball intersected the left section, you could do Speed.X-- and Speed.X++ if it hit the right section. You just need to make sure that the value you increment/decrement isn't big enough to send the ball completely in the opposite direction. You could even divide the paddle into more sections for more detail.
Or another fun alternative would be... take a snapshot of the mouse X position when the ball is like 15 pixels above the paddle, and then take another snapshot on the moment of collision. Subtract both values, and that should give you a value of how "strong" and "fast" the user movement was. You can then finetune the ball speed according to that value.
I've seen a game of this type, that worked with accelerations instead of constant speed. Using the "see how fast the user moved the mouse" method, that game made it possible to give "effect" to the ball, and make it have "curve", which made for some fun stuff!
Just some ideas! :)
GLutz78
I didn't want to say this, but I'm glad someone did.
RideABike
I went and put all the files into a zip file
Download here: http://joshmackey.net/programming/XNA/XNA%20Breakout/XNA%20Breakout.zip
Adix
Seems like a little much to be making breakout full screen...
JenniferS
The mouse is how most users switch between windows. By restricting the mouse to your window you prevent this and your app would not be being very windows friendly.
However if you really must do it this naive approach works ok - its not perfect and you need to make sure you only do it when the window has focus.
MouseState state = Mouse.GetState();IsMouseVisible =
true; int newX = state.X; int newY = state.Y; if (state.X < 0) newX = 0; if (state.X > Window.ClientBounds.Width) newX = Window.ClientBounds.Width; if (state.Y < 0) newY = 0; if (state.Y > Window.ClientBounds.Height) newY = Window.ClientBounds.Height; if (newX != state.X || newY != state.Y) Mouse.SetPosition(newX, newY);alex121
LandLord323
Prashant_Rai
I updated my game with this, the new code and zip file has already been uploaded.
HavingProblems
Could you pack your project So as not having to download file by file
MKBender
Thanks for the ideas, like I said with my first post, it still is a work in progress, if you push Escape when the game is running, it goes into a unfinished paused screen.
Il look into putting one of these ideas in when I work on it next. (Probably when class starts up again)