Blaster Tutorial Design Questions

#1 Let me give it a shot.

First, the "#region" tags are purely cosmetic. There's actually no functional reason to put your code in one region over another, it's just to make life easier on you if you ever need to refer to it later (for example, "where did I define that property? Oh, it's probably in the public properties region").

Quote:"A static property that lets you easily get the Game instance from any game class."

I wasn't sure if both "static" and "property" were confusing you, so I'll try to address both. A "property" is a C# concept that lets you treat things like variables in code, even though they're really implemented as methods. The most common usage is when you want the the "rest of the world" to see your data one way, but want to store it internally in a different format (for example, maybe you have a temperature variable in a component, and it makes the most sense to store it in Kelvin internally because you're doing lots of physics calculations, but you want the rest of the world to use the variable as if it was in Fahrenheit because that's more familiar to most people. You could implement the Fahrenheit/Kelvin conversions in the get/set methods of your functions. The other useful feature of properties is that they make it very easy to "hide" your internal data from the rest of the program, which is good object oriented programming practice. The other cool thing about properties in Torque X is that they let you expose the control parameters of your components to Torque X Builder (although that's not really important for this particular example). In this particular case, it's mostly so you can just write code in the rest of your program as if you could access the Instance variable directly, rather than having to call a method like GetInstance() or something.

When something is static, that means there is one per class, not one per instance of the class. So, for example, if you wanted one of your components to keep track of how many objects were in the scene that had that component, you could increment a static variable whenever the object was registered into the scene. Any other instances of the component could read the data from the same static variable (since there's only one) to tell how many total instances there were. Since there's only one static "thing" per class, you don't need to have a particular object in order to get a reference to it -- you can just do MyGame.Instance (or whatever it is, I don't have the tutorial in front of my right now). If it wasn't static, you'd need a reference to a particular instance of a class before you could access it (which would be kind of redundant for this "instance" property). The idea in Blaster is that it knows there will really only be one instance of the game, making it available via a static property just makes it easy to get a reference to that instance in the rest of the code.

Did that make sense?

#2 I understand, thank you. It wasn't what I was looking for, I'm sorry to say, because you gave a good and lengthy response, and for that I am appreciative.

I found the region tags to be of great use helping me understand the components of the Blaster tutorial. It gave structure where there usually is none, because like you said, it doesn't have to be there. I think I'm looking for more structure. A blue print that says "Put collision code here" and "Put things that will appear on the screen" here. Or, in this case, an explanation of why the code was laid out the way it is. I can write functions and logic, I just have trouble figuring out "where it" goes.

Thanks again for you help.

#3 Yeah I hear you... but to be honest - you don't need to get that rigid with your coding.. that the beauty of it. You could just dump everything into the Game.cs file and it will run.

The region commands allow you to collapse the areas (if setup in visual 2005) so you can make your code easier to read...

The main areas to review are the initialize function and update functions - this is where the meat/potatoes of the code goes. Init does just that.. sets things up before the level is loaded. Update is where the main loop of the code goes and is called each cycle of the game running.

If you check out some of the basic XNA tutorial over at the XNA creator club, they have some good stuff - riemers tutorials are good and the best I've found yet are over at: http://www.xnaresources.com/pages.asp?pageid=8 - hope this helps...

#4 I think you're right about need to understand XNA better. Thanks for the URL.