External Articulation of Concepts Materializes Innate Knowledge of One's Craft and ScienceBeginner in Game Development? Read here. And read here.Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts

Spoiler

How on earth can you go around telling lies, be shown that they are lies, then continue to ignore the evidence to the contrary. I'm not qualified to deal with this, sorry. - HodgmanNever crash to desktop. That's the equivalent of a Starbucks rep punching you in the face when you try to order a coffee with soymilk when they run out of soymilk. - KoobazaurFor programmers, R & D means "Research & Duplicate".Just remember... XML is like violence. If it doesn't work, you just aren't using enough of it... - MoeEvery time I go into my account settings I feel like I've never used the internet before. - booleanPerson X: Do you want to live forever?
Person Y: No, but I want to live a long life.
Person X: Only cowards live that long.
Person Y: And yet, we travel to seek the counsel of these "cowards".

I have no intention of playing it (and the OP did not specifically ask for that), I want to look at the code and critique that.

I read that as "try out my game" as in play it. But critiquing code is always good too.

I'm also not in the habit of downloading and running random executable from forums anyhow, especially this one. It only takes one such instance for us to have a repeat of fongerchat.

Well ok. This is true. But I don't hold that blemish against GD.Net. Plus, that's what VMs are for

External Articulation of Concepts Materializes Innate Knowledge of One's Craft and ScienceBeginner in Game Development? Read here. And read here.Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts

Spoiler

How on earth can you go around telling lies, be shown that they are lies, then continue to ignore the evidence to the contrary. I'm not qualified to deal with this, sorry. - HodgmanNever crash to desktop. That's the equivalent of a Starbucks rep punching you in the face when you try to order a coffee with soymilk when they run out of soymilk. - KoobazaurFor programmers, R & D means "Research & Duplicate".Just remember... XML is like violence. If it doesn't work, you just aren't using enough of it... - MoeEvery time I go into my account settings I feel like I've never used the internet before. - booleanPerson X: Do you want to live forever?
Person Y: No, but I want to live a long life.
Person X: Only cowards live that long.
Person Y: And yet, we travel to seek the counsel of these "cowards".

You have one of the more unusual indentation styles I've ever seen (or was that the forum's useless "helpful" reformatting?). In any case, I will look over this when I get a chance and give you some specifics, but from a quick glance I can suggest two avenues you might want to look at:

Consider looking at a system by which you wouldn't need to hard-code collision detection mechanisms between "the ball" and "the wall" -- how could you generalize your collision representation and handling so you could add new things without modifying the ball code?

Your sprite manager is rather coupled to your game logic in a few key ways -- for example, "StartGame." How could you factor that dependency out so you can reuse this sprite management code in your next project?

Thanks Josh, you the man. Seriously I appreciate a Engineering Lead taking time out of their day to look am some scrub/noob code.

To answer your question about ball/wall collision. I am not really sure how i would do that, but your question has certainly given me something to think about. I don't know if I know a more efficient way to handle that collision.

To answer your other question about my Sprite Manager. I suppose I could could have the brick laying in my StartGame() be a method specific to brick rather than it being in the StartGame(). Or maybe i could have my StartGame stuff in the loadcontent

I will really think about how to improve my code. thanks for the head-ups.

Thanks Josh, you the man. Seriously I appreciate a Engineering Lead taking time out of their day to look am some scrub/noob code.

To answer your question about ball/wall collision. I am not really sure how i would do that, but your question has certainly given me something to think about. I don't know if I know a more efficient way to handle that collision.

To answer your other question about my Sprite Manager. I suppose I could could have the brick laying in my StartGame() be a method specific to brick rather than it being in the StartGame(). Or maybe i could have my StartGame stuff in the loadcontent

I will really think about how to improve my code. thanks for the head-ups.

Simply put and to cover Josh's pointers "code refactoring". Take this scenario in a breakout as your chosen game:-

- you decide to add falling power ups that are spawned when bricks break.

Think about what you need now to catch those falling power ups with your paddle and or the ball maybe? Where would your code need editing?

The same applies to sprite manager combined with game logic in this case. Never be afraid to break your code down and make it useable for later projects. Remember your next game might need collision detection but there are no balls and bricks!

Hey everybody I'm new here was searching google and it's weird because I'm currently working on the breakout project too in XNA game studois 4.0. Except I have the neurosky mindset http://www.neurosky.com/Products/MindSet.aspx and I am trying to design a game where the paddle gets bigger and smaller depending on your brainwave frequency and how relaxed you are. (To be very brief the neurosky mindset reads you brianwaves and that's how relaxed, alert, asleep, in the middle of repaxed alert, or super alert you are)

Good job getting the project done man. Congratulations. I for one am working through this online tutorial on youtube to get a break out game done and I am using both my art (I'm an aritst) and my programming skills to get it done.

It's great though that you got you game done i'm goin to play it first thing when I get home and tell you how awesome it is (if it's breakout, then it's awesome)

This literally serves as an inspiration for me to get my game done. Thanks for even allowing this to exist.

There are two basic ideas that I'm trying to drive you towards: the idea that a given class or interface should serve a single function ("single responsibility principle") and, to that end, the idea that while object-oriented design begins with the conceptualization of types as real world analogues, it doesn't (and shouldn't end there) -- you can have classes that don't correspond to real-world objects.

Your sprite manager code has some game-specific constructs, such as a specific texture variable for the player and the ball. It also handles game-specific initialization and update logic, such as StartGame and the collision checks (even the fact that it handles collision at all is problematic).

At a high level, I would instead expect to see this:

A type called "SpriteManager" should only understand how to manage a list of (generic) sprite objects and send them to the graphics card at render time. While these sprites may include position, width and height as data, that data is not necessarily what is used to perform collision. The idea that collision geometry and render geometry are distinct is a common practice and becomes very important with 3D games or even in 2D games when you have complicated shapes.

You should have a distinct entity for representing collision geometry; perhaps a "CollisionShape" interface contains collision bounds information. These collision entities should be managed by a "CollisionWorld" or similar high-level interface that understands the relative positions of all collision entities and can raise events or invoke callbacks when any set of entities enters or leaves collision (or remains in collision across more than one frame, that can be useful as well).

Your top-level "game" class should be the one that contains all the game specific logic and types. The game class can maintain a set of logical game objects -- either using a single common class or, if their functionality differs wildly enough, many classes. Since we're already attempting to generalize quite a lot, I will leave further generalization of the game logic entities to you and, for the purposes of this example, say we have a Ball class and a Player class.

The game creates a ball instance, and asks the sprite manager to create a corresponding sprite. That sprite is stored in the ball object. Similarly, the game asks the collision world to construct a collision entity with the ball's dimensions and initial position in the world. A reference to that entity is also stored in the ball. Similarly for the player.

Now the game loop consists of, approximately: collecting player input, applying those inputs to the player object's collision entity (to move it), then asking the collision world to update. This will cause the collision world to fire any callbacks registered concerning inter-object collision -- the game would have installed a callback to handle ball-ball collision, ball-wall collision, and ball-player collision, possibly. In those callbacks, appropriate action can be taken by the game class -- perhaps to destroy one or both entities, or reflect the path of one to cause a "bounce" effect, et cetera.

Finally, the game looks at every game entity it knows about (balls, player, et cetera) and transfers the appropriate logical properties -- such as position, or damage state, or whatever -- to the object's renderable representation (the sprite in this case). Then your game asks the sprite manager to render all your frames.

With only this first level of generalization and refactoring (and there's much more you can do on top of this), you should have two systems -- the collision handling stuff and the sprite handling stuff -- that are entirely game-agnostic and can be reused and extended without having to couple them to the idea of a breakout (or any other) kind of game. It's only at the highest level of abstraction where your game-specific logic and means of tying these two systems together exist.

That is a lot for me to take in, but i will strive to understand and apply this knowledge. Seeing as I am a beginner i want to try and do what the pros do, so I am going to attempt to generalize and refactor my code before I move on to the next project. I want to develop smart and efficient habits early on in my programming career, that way I can have a strong foundation. I will do more research on this "single responsibility principle" and see what that is all about, sounds pretty cool. Thanks Josh.