A Lot Done

Posted in Uncategorized on April 30, 2010 by xna232stang

Got an ass load of work done the past couple of days, as far as prepping my code goes.  Added a coupla new classes, and did some more work refining the other classes.  Had to take some online tutorials to teach myself inheritance in C#, and I still don’t quite get it.  I seem to remember it being a lot easier in C++, but whatever.

On the road to making it so that the main Game1 class of my game has to do a minimum amount of the actual work, I’m getting closer.  I just need to add some more classes (probably all static) to handle the various game screens – i.e. the Title Screen, the Gameplay Screen, Game Over Screen….etc, etc.  After that it’ll be a matter of putting in specific code to make the game work on the XBox 360, not to mention the specific logic of whatever game I want to make.  However, since each game will have its own logic, that will be last.  That way, I can first save the probject workspace as a generic solution and re use it for each new game I make.

As for what I’ve done the past few days, it isn’t much…but teaching yourself C# as you go tends to make it a lot slower.

Firstly, changed up my GameObject class a bit.  I also added a derived, or child, class called “Bling”.  Don’t ask.

Firstly, the changes to GameObject mostly involve adding an initialize() method to set all of its initial values.  I originally did this in its constructor, but because it will have derived classes, and those classes need to borrow those values without necessarily calling the GameObject constructor, I gave them the protected initialize method.

The constructor went from this:

public GameObject(Texture2D loaded_texture)
{

Texture = loaded_texture;  //set the object’s sprite to be whatever is passed into the constructor
Origin.X = Texture.Width / 2;  //set the origin to the center of the sprite
Origin.Y = Texture.Height / 2;
Position = Origin;  //set the default position to 0,0
Scale = new Vector2(1.0f, 1.0f);  //set the scale to 100% by default
Rotate = 0.0f; //construct without rotation
Red = Green = Blue = Alpha = 255;  //default to opaque and no tint
Tint = new Color(255, 255, 255, Alpha);  //default to no tint
Depth = 0;
ObjectEffects = SpriteEffects.None;

}

To this:

public GameObject(Texture2D loaded_texture)
{

Texture = loaded_texture;  //set the object’s sprite to be whatever is passed into the constructor
initialize();  //set the default values for

}

All of the crap I cut out went into the initialize() method.  Of course, just in case I wanted to instantiate an object of the GameObject class, without the added functionality of a child class, I had to keep the statement that sets the Texture equal to loaded_texture.  This is overridden in the child class.

Speaking of child class, the template is in place, but it doesn’t do anything specific except inherit the members from GameObject.  It’s on my TODO list to make the child class actually useful.  When it comes down to it, there will probably be several derived classes that all handle their own input and so on (ex. Hero, Enemy, etc).  But that involves game logic, so aside from setting up a test class, I won’t be doing much with that in the short term.

The final major addition was built and refined shortly after the last entry.  This one’s important.  It’s a GameInput class that’s partially static (stands on its own) and partially instance (used by objects or instances).  For instance, GameInput has a static public method called GetMousePosition() that returns a vector to the mouse pointer’s position.  It looks like such:

public static Vector2 GetMousePosition()
{

Vector2 mousePosition;
mouseState = Mouse.GetState();
mousePosition.X = mouseState.X;
mousePosition.Y = mouseState.Y;
return mousePosition;

}

This makes setting a GameObject’s, or its child class’, x and y screen position as simple as something like:

Object.Position = GameInput.GetMousePosition();

No actual object of GameInput actually has to be created, keeping the code a bit more concise.  There are three other class method’s, but only one is non-static.  I’m working on a way to make it static.

The other two important, public static class methods are

IsKeyPressed(Keys input_key)

and

IsKeyReleased(Keys input_key).

Neither of these really needs to be copied and pasted here, but their purpose is to accept a specific keyboard key to check and see if you’re currently pressing it, or if you WERE pressing a specific key and just released it.  These are simple as well, so for instance you might use these methods as such:

if(GameInput.IsKeyPressed(Keys.Space))
{

react to key input

}

That’s about it for recent updates.  Once I finish messing with GameInput, I can start on the GameScreen class and prep it for derivatives.  Now that I mention that, I’m also going to need to set up “overlays” or textures for things like backgrounds, or text strings, or whatever else is a non-interactive 2d texture.  Then it’s on to a test game which will be a little bit more interesting than what I’ve been doing so far.

Optimizing Code – Setting the Stage

Posted in Programming, XNA with tags , , , , , on April 26, 2010 by xna232stang

Spent a couple of hours struggling to optimize my code tonight, but after some trial and error I’ve had some success.  Being more familiar with C# would have made this a lot easier, but that will come with time.

Basically, what I’ve been working on is getting the “behind the scenes” code set up so that I can start work on the game proper.  First thing I did was create a custom class called GameObject.  This object basically stores a texture for a Sprite, its gameworld coordinates, its rotation, and everything else that a Sprite will need to have in my first test game.

More importantly than anything else, it’s going to give me a reusable member method/function that will handle all of the messy parameter-passing behind the scenes so that my main Game class can stay simple and easy to use.

For instance, if I wanted to render a Sprite of a GameObject instance on the screen from the Game class, here’s what the function call would look like:

spriteBatch.Draw(ExampleObject.Texture, ExampleObject.Position, null, Color.White, ExampleObject.Rotate, ExampleObject.Origin, ExampleObject.Scale, SpriteEffects.None, 0.0f);

I would have to type this EVERY time I want to draw a texture or sprite to the screen!  No thanks…

In order to pare down that mess that the XNA Framework provided to me, I added this member method to the GameObject class:

public void Render(SpriteBatch objectBatch)
{

objectBatch.Draw(Texture, Position, null, Color.White, Rotate, Origin, Scale, SpriteEffects.None, 0.0f);

}

Ok, that’s a little bit cleaner, but not very impressive yet. Well, actually this is a recursive method. I wrote it once, and unless I need to change it, I’ll never touch it or type it again. The real help it gives me is changing that ultra long function that I typed way up there into this:

ExampleObject.Render(spriteBatch);

Yeah, I’ll take this over that monster function any day.

Small step that was made a lot harder due to my lack of familiarity with C# and the XNA Gamestudio, but considering I could recycle this method into every game I make, it’ll be worth it.

One potential problem I can see with this is that creating an extra spriteBatch every time I draw a sprite may be a waste or resources, and or be problematic for system performance.  I’ll have to do some research on what exactly a spriteBatch really is….

Day One

Posted in Uncategorized on April 26, 2010 by xna232stang

First post of the blog.  This is really just for me to keep tabs on upgrades to my car and my progress in programming games for the XBox 360 using Microsoft’s XNA Framework.

This is just for my family, but if you aren’t my family, feel free to check it out.