Game Dev Journal

Again

2011-09-06T15:31:00.000-07:00

This repurposed blog has once again been neglected. I'm back doing Ruby and having great fun. If I do start blogging again, it probably won't be on blogger and definitely won't be this blog. :)

Adios

Breakout Week 4: Building a Wall (Part 2)

2011-03-25T20:34:00.000-07:00

This is part two of my two part post of building the wall in my Breakout game.

With the wall in place, the next step is to make the ball break the bricks as it hits the wall. This bring us back to collision detection and response again.

I did quite a bit of reading on this because there are a number of ways you could do it. The collision detection part can be fairly easy, where you just check if the ball is within the bounds of each brick, but it gets complicated by the fact that once you know a collision occurred, you also need to know which side of the brick the ball hit because it could hit any of the brick's four sides or corners. You need this in order to know in which direction to bounce the ball after it hits the brick. There seemed to be a couple common techniques for doing this, well common ones I found in a quick google search at least.

The first technique involved looking at the previous position of the ball and it's position relative to the brick. For example, you create regions based on the edges of the brick and find which region the ball was in before it hit the brick. The regions would like this:

If the ball was in the top, bottom, left or right regions then you assume that was the edge that the ball hit. If it was in one of the diagonal regions, then it the corner. The problem with this method is that it doesn't take into account the direction or velocity of the ball. Consider the case of a ball being in one of the diagonal regions but travelling fast enough and at the right angle that by the end of the frame it was going to hit one of the edges, not the corner. This diagram illustrates this:

Because this method ignores the direction and speed of the ball it would detect a corner collision here, even though it is clearly hitting on the bottom edge of the brick. This would give you a lot of false corner collisions which would look weird, since a corner collision results in the ball bouncing back the way it came.

Another technique is to, once you know a ball collided with a brick, do a line intersection test between each edge of the brick and the line created by the previous and current position of the ball. So basically if the ball is travelling up we create a line segment from the center of the top edge of the ball's starting and ending position and see if it it intersects the bottom edge of the brick. Which looks like this:

You would then do that for the x-direction as well and which ever edge the ball intersects is the edge on which you reflect the ball's direction. If you don't get an intersection then you have hit a corner and you can just reflect back in both x and y directions. This is the method I actually implemented and it works reasonable well, as you can see in this video:

However, you might notice that occasionally the ball hits what looks like the edge of the brick but bounces back in the opposite direction. This just looks weird and it totally the opposite of what the player would expect. We can see why this happens though by looking at the algorithm for detecting the edge that was hit. Basically, to do the line intersection test we need to pick a point on the edge of the ball that is closest to the brick, the central point of that edge makes the most sense, but in doing that we also increase the threshold for detecting a corner collision. Consider this collision, which clearly occurs between the top edge of the ball and the bottom of the brick (note that Ball A is the starting position and Ball B is the end position of the ball):

The line we would test for a collision on the bottom edge of the brick would run from the center of the top edge of Ball A to the same point of Ball B, which would look like this:

But that is going to miss the bottom edge, which is not what we want. If we say, ok lets also check the center of the left edge, then sure that will intersect but not if the ball is on the other side, so you'd have to check right side as well. So it becomes apparent that what you really need is the Axis-Aligned Bounding Box Sweep Test that I talked about a couple of weeks ago (the circle is complete). With the sweep test you can get the exact position at which the collision occurred and then determine which edge was hit by doing the region test based on the collision position. This will be much more accurate and corner hits will only occur when the ball actually does hit the corner, which would be pretty rare. It will also be easier to handle collisions on multiple bricks.

So my next task is to convert my existing code, that uses the line intersection method, to the AABB sweep test. I'll do that this week. I haven't included the code from the intersection test in this post because I will pretty much be replacing it next week so it didn't see worthwhile explaining the guts of it. If anyone is interested, it is available up on GitHub with it's own tag at week4p2. So you can see the method I was using detail if you want.

Also, if anyone is interested in the details of the line intersection code, I based mine on this excellent example from Third Party Ninjas.

'til next week...

Breakout Week 4: Building a Wall (Part 1)

2011-03-21T04:02:00.000-07:00

I had a pretty busy week last week, okay that was mostly due to the fact that Dragon Age 2 came out and I spent several nights playing and not sleeping. Despite that I did manage to find some time to work on Breakout. The goal for this week was to get the wall drawn and handle the collisions of the ball against the wall. I did manage to get that all working, which I was pretty happy about, but I also came to the conclusion that the way I am handling the collisions is not very good, particularly for the wall.

Because there is a lot to go through with the collision handling and I also want to cover how I setup and draw the wall I'm going to split this week's post in two. This post will cover the setup and drawing of the wall and it should be relatively short. I'll write another post around mid this week where I'll cover handling the collision of the ball against the wall, the problems with my approach and how I'm going to improve it. So for now, lets get stuck into the setup of the wall.

As usual, we have a Wall class that handles the setup and drawing of the wall. Just like the paddle and ball it is created by the Breakout class. Here are the main instance variables of the wall.

class Wall {
   private const int bricksPerRow = 20;
   private const double wallHeightRatio = 0.20;
   private const int numRows = 7;
   private static readonly Color[] colors = {
     Color.Red, Color.Orange, Color.Yellow, Color.Green, 
     Color.Blue, Color.Indigo, Color.Violet
   };

   private readonly int screenWidth;
   private readonly int screenHeight;
   private float brickHeight;
   private float brickWidth;
   private Rectangle wallBounds;
   private Texture2D sprite;
   private List<Brick> bricks = new List<Brick>();

There are some constants at the top of the class that define the number of rows of bricks we will show and the number of bricks per row, height of the wall as fraction of the screen height and the color of each row, in this case it will be a rainbow. We also store the screen and the brick size and wall bounds which will be calculated in the constructor. And lastly there is our brick texture, which is just a white square and our list of bricks that make up the wall.

This is what the constructor does:

public Wall(int screenWidth, int screenHeight) {
    this.screenWidth = screenWidth;
    this.screenHeight = screenHeight;

    double wallHeight = screenHeight * wallHeightRatio;
    wallBounds = new Rectangle(0, (int)(wallHeight / 2),
                screenWidth, (int)(wallHeight + wallHeight / 2));
    brickHeight = wallBounds.Height / numRows;
    brickWidth = screenWidth / bricksPerRow;
}

The important parts to point out here is how we calculate the wall height as the fraction of the screen height defined by wallHeightRatio, the brick height as the wall height divided by the number of rows of bricks and the brick width as the screen width divided by the number of bricks per row. This means that the wall size will scale with the screen size and we can tweak to constants to get different wall configurations.

Lets move on to the InitialiseBricks method. This method is responsible for filling the list of bricks that make up the wall using the parameters we calculated in the constructor. It is called by the LoadContent method after we load the texture for the bricks.

Actually, before we look at that, here is the Brick class:

class Brick {
    public enum BrickState { ALIVE, BROKEN };
    private readonly int column;
    private readonly int row;
    private Rectangle bounds;
    private BrickState state;

    public int Row {
        get { return row; }
    }

    public Rectangle Bounds {
        get { return bounds; }
    }

    public BrickState State { get; set; }

    public Brick(int row, int column, float x, float y, float w, float h) {
        this.state = BrickState.ALIVE;
        this.row = row;
        this.column = column;
        this.bounds = new Rectangle((int) x, (int) y, (int) w, (int) h);
    }
}

As you can see it is really simple. It just stores the brick's row and column position, its bounding box and its state, i.e. whether it is alive or has been "broken" by the ball. So now, back to the InitialiseBricks method:

private void InitialiseBricks() {
    for (int i = 0; i < numRows * bricksPerRow; i++) {
        int row = i / bricksPerRow;
        int column = i % bricksPerRow;
        bricks.Add(new Brick(
                row, column,
                column * brickWidth, 
                wallBounds.Top + (row * brickHeight), 
                brickWidth, 
                brickHeight));
    }
}

So what happens here is that, for each brick we need to create, which is determined by the number of bricks per row multiplied by the number of rows, we figure out it is row and column and the then its screen position. The screen x-position is done by multiplying the column position by the brick width and the screen y-position is determined by adding its row position time the brick height to the walls top position. Once this is done, our bricks list is full of all the bricks we need to draw the wall, which, of course, is done in the wall's Draw method:

internal void Draw(GameTime gameTime, SpriteBatch spriteBatch) {
    foreach (Brick brick in bricks) {
        if (brick.State == Brick.BrickState.ALIVE) {
            spriteBatch.Draw(sprite, brick.Bounds,
                  colors[colors.Length - brick.Row - 1]);
        }
    }
}

So all we need to do here is loop through the bricks and for each brick that is alive we draw it. We use the overload of SpriteBatch#Draw that takes a rectangle and colour. We grab the colour from the wall's colour array, using the colour at the index of the brick's row, but reversed so the top row is draw with the last colour and the bottom row is draw with the first. Passing in the brick's bounds as the destination rectangle will ensure that the right place in the screen is filled for that brick and our texture will automatically get scaled and coloured to fill the brick's rectangle. That's it, here is what it looks like:

Isn't that pretty, well my 3 year old daughter thinks so at least.

That's it for part 1 of week for. It was pretty light but I think worth covering for completeness. Later in the week I'll put up the post on wall collision detection which will probably take me longer to put together than this did. I hope this was useful to someone though. As usual the code is up on the Github, if you want to see this part of week 4, the pre-collision detection stuff, checkout the week4p1 tag.

Breakout Week 3: When Balls Collide

2011-03-12T01:33:00.000-08:00

This week was all about collision detection and collision response. The plan was to add the ball to the Breakout game, get it moving around the screen and bouncing off the walls and the paddle. I probably did much more research than was required this week since I spent a lot of time reading about various collision detection algorithms and the physics of collision response. It turns out that didn't actually use any of the techniques I read about since a very simple technique works well enough for Breakout. It was worthwhile reading all that though, if for no other reason than I now have a much better appreciation for what I need to learn.

So, research aside, the coding up of the ball itself was very easy, it only took about an hour and half and most of that was spent tweaking various parameters to get the "feel" right. So on to the code.

As with the paddle, there is a class for the Ball with LoadContent, Update and Draw methods that are called by the Breakout class. The Ball tracks it's own state in these instance variables:

private Texture 2D sprite;
private Vector2 position;
private Vector2 direction;
private int speed;

This is slightly different to the paddle in that we store the speed as a scalar value and the direction as a vector. The direction is a unit vector so it contains no speed information, which is why we need the speed as a separate variable. The reason I did it this way is that the ball can move in both x and y directions, unlike the paddle, so using a unit vector allows use to calculate directional changes for the ball without needing to worry about the length of the vector, since it will always be 1.

The ball also has a few other instance variables that hold initial states, ranges of speed and position and whether the ball is currently active or dead.

So, once again, all the interesting stuff happens in the Update method:

internal void Update(GameTime gameTime) {
    if (state == State.Active) {
        UpdatePosition(gameTime);

        if (position.Y > screenHeight) {
            state = State.Dead;
        } else {
            HandleCollisions();
        }
    } else if (state == State.Dead && 
           Keyboard.GetState().IsKeyDown(Keys.Space)) {
        LaunchBall();
    }
}

The first thing the update method does is check if the ball is active or not. If it is isn't the player can launch a new ball by pressing the space key. The LaunchBall method just sets the state to active and initialises the position and velocity of the ball, so I won't cover it here. If the ball is active, the first thing we do is update it's position:

private void UpdatePosition(GameTime gameTime) {
    float time = gameTime.ElapsedGameTime.TotalSeconds;
    position = position + direction * (float)(speed * time);
}

This is the familiar motion equation we used for the paddle, so nothing new here, except that the velocity vector is split up into direction and speed components so we need to multiply them back together here.

Once that is done, the Update method checks if the ball has gone of the bottom of the screen and should become dead, if not it then checks for the collisions. The HandleCollisions method first calls HandleBoardCollisions which checks if the ball has hit either the top, left or right edges of the screen.

private void HandleBoardCollisions() {
    if (position.Y < 0) {
        position.Y = 0;
        direction.Y = -direction.Y;
    }

    if (position.X < 0) {
        position.X = 0;
        direction.X = -direction.X;
    } else if (position.X + sprite.Width > screenWidth) {
        position.X = screenWidth - sprite.Height;
        direction.X = -direction.X;
    }
}

So here all we do is check if the ball has gone off the screen on each axis and if so we reverse the direction of the ball along that axis and move it's position back into the screen. This will ensure that the ball doesn't get stuck on the edge and reversing the direction on the axis gives us a realistic reflection off the wall so that the angle of incidence is maintained.

Once this is done, when then check to see if the ball hits the paddle. This was what most of my reading and my research went into. I already new that it was pretty easy to check if a rectangle intersects another but I was worried about the movement of the ball. For example, consider this case:

The ball starts the frame at position A but after it's position is updated it ends the frame at position B. If we do a bounding box check against the paddle at either position we are not going to get a collision, but clearly the ball has hit the paddle. There are algorithms for solving this called sweep tests where basically you create a geometry for the moving object that covers its movement through the entire frame, so the above situation becomes this:

And we check whether those two geometries intersect and at what time within the frame they would. The most appropriate algorithm for this particular case seems to be the Axis-Aligned Bounding Box sweep test.

However, this is only really an issue for small fast moving objects. If the object is going to be moving less than it's dimensions on each axis in each frame then it is not an issue. I wasn't sure if it was going to be an issue for my ball and paddle collisions so I decided to start with the simplest case and see how it looks. The simplest case is just a standard bounding box test and it seems to work well enough, the ball doesn't pass through the paddle even when it is travelling at pretty high speeds. Of course if the frame rate dropped or we changed size of the ball or paddle this might change, so I wouldn't be surprised if I end up implementing a sweep test anyway.

This type of collision detection was really easy to do in XNA, well it's pretty easy anyway but XNA makes it very easy. The Rectangle class has an Intersects method that checks whether the rectangle intersects with another. This is what we use in the HandlePaddleCollisions method of the Ball class:

private void HandlePaddleCollision() {
    if (direction.Y > 0 && paddle.Bounds.Intersects(this.Bounds)) {
        direction.Y = -direction.Y;
        position.Y = paddle.Bounds.Y - sprite.Height;

        direction.X = ((float)Bounds.Center.X - paddle.Bounds.Center.X) / 
                      (paddle.Bounds.Width / 2);
        direction = Vector2.Normalize(direction);

        // Increase the speed when the ball is hit
        speed += speedIncrement;
        speed = Math.Min(speed, maxSpeed);
    }
}

Line 2 of this method does the check. Also notice that we only do this check if the ball is moving in a downward direction. This is important because we don't want to check if the ball is moving up, since it is both a waste and could lead to bugs where the ball gets trapped inside the paddle.

So once we know there is a collision, we need to do something about it. This is where I spent some time reading about collision response, in particular, the sections on collision response in my copy of Physics for Game Programmers (that I have had for almost 10 years and not read enough of) and Chris Hecker's excellent article on collision response. This stuff is really interesting and is definitely something I want to get explore more, maybe even for the Breakout game later on. But in the interest of getting the ball working this week I opted for a simpler solution. This is implemented in the body of the HandlePaddleCollision method.

First of all we need to reverse the y direction of the ball, this "bounces" it up and sends towards to top of the screen. We also need to move the ball outside of the paddle so it doesn't get stuck. This is done on line 4.

Then comes my cheat for not having proper physics. If you just change the y direction the ball will always be travelling straight up and down, which will lead to a very boring Breakout game. The player needs to have some control over the direction of the ball. I did a bit of research into how other people have implemented this, I found a few references to splitting the paddle up into thirds and setting the x direction to a fixed number based on which third it hits, sort of like this:

But that would be a bit boring and predictable.

Looking at some old Breakout videos it looks like the angle of the ball is based on the distance from the paddles center, the further from the center the sharper the angle. So I ended up using this formula:

xDirection = ballCenter - paddleCenter 
             -------------------------
                 paddleWidth / 2

This will set the x direction to a value between -1 and 1 based on the position it hit the paddle. So you get a range like this on the paddle:

Once the X value of the direction vector is set on line 6 we need to normalise the vector again on line 8 so it remains a unit vector.

There is one downside to this approach, since the Y value of the direction is always going to -1 or 1 and the range of the X value can be is -1 to 1, this means that you only have a range of angles of +/- 45 degrees. This might not be that big a deal though, the range can always by increased by adding some constant to the denominator of the xDirection formula anyway.

Once the direction has been set we increment the speed on lines 11 and 12 so it gets a bit harder as the player keeps the ball alive. And that does it for ball movement, this is what it looks like:

I can assure the framerate is much better in real life. I might have to find some better screen capturing software, if anyone can recommend some please do in the comments.

Handling collisions like this is not without its problems though. You can have the situation where the ball hits the side of the paddle but then gets propelled out of the top of the paddle, since we are just checking that the ball is within the paddle. To resolve this you would probably need some sort of sweep test followed by an intersection test to find which edge of the paddle the ball hit and then reflect it off that edge instead of always assuming it hit the top edge. I'll leave this for later though.

Next week I'll start implementing the wall of bricks. This should cover more collision detection, dynamic drawing of sprites and maybe some particle effects.

Week 2: With a Paddle

2011-03-04T20:54:00.000-08:00

With all the installation and setup out of the way, this week I finally got to write some code.

I decided that the goal for this week was to get some initial classes laid out for the Breakout game and implement the basics of the Paddle. Let's start with the class design.

When you create an XNA project, it auto-generates a Game class for you. This class is the core of your Game. In it you implement methods for loading content, updating state and drawing a frame. However, I don't think it is the best place to put much game logic. I've always tried to avoid pointing too much custom code into classes that extend from framework classes since it makes it harder to test your own code in isolation and it means large amounts of you own code could break if the framework changes. The Game class will act mainly as glue between my game implementation and the XNA framework's game loop. To this end, I created a Breakout class which is instantiated by the generated Game class. Here is what it looks like:

public class Breakout {
    private SpriteBatch spriteBatch;
    private Paddle paddle;
    private Ball ball;
    private Wall wall;
    private int screenHeight;
    private int screenWidth;

    public Breakout(SpriteBatch spriteBatch) {
        this.spriteBatch = spriteBatch;
        this.screenWidth = spriteBatch.GraphicsDevice.Viewport.Width;
        this.screenHeight = spriteBatch.GraphicsDevice.Viewport.Height;
        this.ball = new Ball();
        this.paddle = new Paddle(screenWidth, screenHeight);
        this.wall = new Wall();
    }
}

It's pretty straight forward, Breakout has a Paddle, a Ball and a Wall, just as you would expect. The Breakout constructor is passed in a SpriteBatch instance which it will use to draw all the graphics for the game. The SpriteBatch is created in the Game class's Initialize method, where the Breakout object is also created, like so:

protected override void Initialize() {
    breakout = new Breakout(new SpriteBatch(GraphicsDevice));
    base.Initialize();
 }

The LoadContent, Update and Draw methods, which are called by the Game class, just pass the calls onto the respective methods of the Ball, Paddle and Wall, so each component of the game is responsible for loading, updating and drawing itself; all cleanly separated. You could go even further down the dependency injection path and provide an abstraction layer for the SpriteBatch class, but I'm not going to bother at this point.

The next step was to implement the Paddle. I started by applying my graphic design skills to come up with this fantastic piece of art:

There are two paddle images there, the bottom will be used for flashing when the ball hits it, but we'll ignore it for now.

It turns out that adding and loading graphics into an XNA game is remarkably simple. Visual Studio generates a GameContent project that is referenced by your main game project. To add an image to this you simply drag and drop it into the project. The image can then be loaded in the LoadContent method. This is how the paddle image is loaded by the Paddle class like this:

sprite = contentManager.Load<Texture2d>("paddle");

That is almost too good to be true. The last time I dabbled in Windows game development was back in 2000, I was using DirectX 5 and reading Windows Game Programming for Dummies. There is a big section in that book, and there was a big section of my code, that dealt with manually loading sprites from bmp files and handling colour palettes etc. Reading in encoded file formats was not even dealt with in the book because it was deemed to complex. Having a single line of code do it for you is pretty great. Makes me wonder what the catch is, or at the very least I need to read up on the XNA content pipeline some more to find out what formats it supports and what its limitations are.

Anyway, back to the Paddle class. The Paddle class has some state that it uses to keep track of the position and movement of the paddle, these are stored in instance variables as Vector2 objects. After the sprite is loaded in the LoadContent method we also initialise the position of the paddle so that it sits 10 pixels from the bottom of the screen in the middle of the X-axis. This is done like so:

int x = screenWidth - (screenWidth / 2) - (sprite.Width / 2);
 int y = screenHeight - PADDLE_OFFSET - PADDLE_HEIGHT;
 this.position = new Vector2(x, y);
 this.minPosition = new Vector2(0, y);
 this.maxPosition = new Vector2(screenWidth - sprite.Width, y);

x, which is the paddle's starting position on the horizontal axis, is calculated by finding the center of the screen and then moving to the left by half the width of the paddle's sprite. y, which is the vertical position just places to bottom of the sprite 10 pixels from the bottom of the screen. We also calculate the min and max horizontal positions of the paddle, this will be used later to make sure that the paddle doesn't go off the edge of the screen.

I think the most interesting part of the Paddle class is how it handles the movement of the paddle in response to the user input. The goal of the movement is that when the user presses the left or right arrow keys, the paddle will move to the left or right. If they hold the key down the paddle should accelerate so the longer you hold the key down the faster it goes.

To do this we just use the the classic equations of motion:

v = velocity
 u = initial velocity
 a = acceleration
 t = time
 s = distance travelled

 v = u + at
 s = vt

This is implemented in the Update method like so:

internal void Update(GameTime gameTime) {
    float time = (float)gameTime.ElapsedGameTime.TotalSeconds;
    KeyboardState keyboard = Keyboard.GetState();

    if (keyboard.IsKeyDown(Keys.Left) && !previousKeyboard.IsKeyDown(Keys.Left)) {
        velocity = new Vector2(-INITIAL_SPEED, 0);
    } else if (keyboard.IsKeyDown(Keys.Right) && !previousKeyboard.IsKeyDown(Keys.Right)) {
        velocity = new Vector2(INITIAL_SPEED, 0);
    } else if (keyboard.IsKeyDown(Keys.Left) && previousKeyboard.IsKeyDown(Keys.Left)) {
        velocity = velocity + (-ACCELERATION * time);
    } else if (keyboard.IsKeyDown(Keys.Right) && previousKeyboard.IsKeyDown(Keys.Right)) {
        velocity = velocity + (ACCELERATION * time);
    } else {
        velocity = Vector2.Zero;
    }

    position = position + (velocity * time);
    position = Vector2.Clamp(position, minPosition, maxPosition);
    
    previousKeyboard = keyboard;
 }

I've just used a constant acceleration in this initial version to keep it simple, but I might play around with it later if it doesn't feel right.

Right off the bat, I don't like those conditional statements, they are a bit hard to read. Essentially what they do is the first two check if the left or right key has been pressed for the first time, i.e. it wasn't pressed in the last frame, and the second two check if the left or right buttons have been held down. I'll refactor this out into a clean input class next week I think, but for now we'll have to deal with it.

So lets go through the code line by line.

On line 2, we grab the number of seconds that have elasped since the last frame. This becomes our t in the motion equations.
On line 3 we get the current keyboard state.
Lines 5 - 15 deal with calculating our new velocity.
- Line 5 checks to see if the Left arrow key has been pressed for the first time, if so, on line 6 we set the next velocity to the negative of the initial speed. It's negative because we are going left.
- Likewise, line 7 checks if we are going right for the first time and line 8 sets the velocity to the initial velocity, positive this time because we are going right.
- On line 9 we check if the Left arrow key has been held down. If so, on line 10 we increase our velocity by the negative of the acceleration * time. This is the v = u + at in our motion equations.
- Likewise on line 11 we check if Right has been held down and on line 12 we do the v = u + at again, this time in the positive direction.
- And finally, if neither Left or Right are held down, then we set the velocity to 0 on line 14.
Once we have our velocity we can calculate our new position. We know distance travelled is simply v * t so we can just add that the current position on line 17.
Then on line 18, we make sure the position isn't outside the screen bounds
And finally save the keyboard state to check against in the next frame.

So that's it, pretty simple but it was pretty fun to do something based on actual physics formulae. I particularly like the way the XNA Vector2 structure, provides operator overloading here, it makes the code much more readable than having a bunch of nested methods calls like Add or Multiply.

Once we have the new position we can draw the paddle in the Paddle class's Draw method like this:

internal void Draw(GameTime gameTime, SpriteBatch spriteBatch) {
    spriteBatch.Draw(sprite, position, source, Color.White);
}

All done. The paddle now shows up on the screen and responds to the keyboard input. This is what it looks like (well slightly better than this low-res video at least):

As usual the code is up on Github if anyone is interested. Next week I'll be cleaning up the input detection a bit and implementing the ball, so more graphics and 2D motion this time and maybe some collision detection.

And before I forget, I found these tutorials by George Clingerman really useful to get up to speed on 2D graphics in XNA, so thanks George!!

Week 1: Setting up and Installeering

2011-02-25T21:37:00.000-08:00

This week was not the most exciting in terms of this project, but necessary nonetheless. It was all about setting up my development environment and a bit of troubleshooting to get things working.

First of all, I grabbed a copy of Windows 7 professional and installed that into a Bootcamp partition on my iMac. This didn't exactly go without a hitch, Windows 7 doesn't seem to include the right ATI driver for the graphics card in the late 2009 iMacs. So when you get to the third stage of the installation, the screen goes blank... not very helpful. Thankfully there is a pretty simple work around that involves booting up in repair mode and deleting the ATI driver. This forces Windows to use a generic driver, but one that actually works. So with that done I could complete the installation and then install the boot camp drivers to get a proper ATI driver for the graphics card.

From there it was a matter of installing some development tools. I got Visual Studio Express Edition with Windows Phone Developer Tools, which in fact contains XNA Game Studio, not that you would know by the product name. The install for this went without a hitch. I also installed Git Extensions, however for some reason the Visual Studio plugin didn't work, I'm not too fussed about that though since I'll probably use the command line most of the time.

With all that setup, I fired up Visual Studio and created a new Windows game project, called Breakout, that I'll use for building my first game. This was simple enough but there was one hitch, I wasn't able to run the game within Parallels, I got an error saying there was no suitable device support HiDef. Fortunately the Internet came to the rescue again. Apparently this is caused by Parallels only supporting DirectX 9. The fix is pretty simple, you just need to right click on the Game project, select Properties, then change the Game Profile to "Use Reach ...", the game should now run and display a beautiful cornflower blue screen.

I also tried out VMWare Fusion as an alternative to Parallels, it also suffered from the same HiDef support problem, so there wasn't really any reason to switch. I'll see how it goes with Parallels for while, I do get the sense that I'm eventually either going to need more RAM, or I'm going to have to reboot into Windows more often, but I'll see how it goes.

---

In order to get up to speed with C# I read through Intro to C# from Objective-C and Java. I've gotta say, it's not the best document. I realise it is only 24 pages, but it seems to really skim over important language features at the expensive of talking about the CLR platform. For example, it has a list of about 15 items that Java has but are different in C# or that C# has but Java doesn't, like indexers, different inheritance syntax, access restrictions on overriden members, clashing interface inheritance but it doesn't actually discuss how C# does it. And yet there is a page and half on garbage collection, which is essentially the same between the two platforms. Oh well, I'm sure I cope.

---

I've also setup a Github project at http://github.com/seangeo/breakout. It's a public project so anyone can grab the code, although at this stage there isn't much to see, hopefully it will get more interesting.

Next week I'm going to start getting familiar with the XNA API and draw some sprites. If I get time I might make them move across the screen!

Refurbished and Repurposed

2011-02-19T20:11:00.000-08:00

I've decided to repurpose this blog as a journal for my foray into game programming.

I've always loved video games and they have always been a big part of my life. When I decided to to return to university after a brief stint as a sound engineer, my main motivation for doing computer science was to end up as a game programmer. I even dabbled in building a MMORPG in my second and third years. However, at some point I took a different direction. I don't really know why, probably a combination of factors: a lack of local jobs and not wanting to move state again, the idea of another industry being the industry that the best people work in (at least in Adelaide) and some sense that it was time for me to grow up and act like an adult; probably why I cut my hair and started wearing button up shirts.

It's just over 8 years since I graduated. I've never been short of work and I've had some great jobs with some great people. However, I still have a nagging regret when it comes to game programming. I keep wondering what would have happened had I kept my sights on that goal and worked towards it. And most of all, game development is still something I really want to do. Basically I don't want to be in the position 8 years from now where I'm wondering the same thing, only it would be even harder to do something about it.

So, this marks a turning point, my hair is long again and I prefer t-shirts.

To have any chance at a game development career, I need to learn game programming techniques, libraries and platforms, because at the moment, my game development knowledge is pretty minimal, I've spent all my time doing business/commercial development. It's not going to be easy or quick and I have a lot to learn, but really I have nothing to lose. I still need to work and make a living so I need something I can do in my spare time and with a plan that keeps me focussed. I'm going to put about 3 hours a week into building small tech demos or games that will teach me something about game programming. I'll also write a weekly blog post that outlines what I did, what I learnt and what I plan to do next week. If I can stick to this I should learn a decent amount in a reasonable amount of time, but most importantly have a set of demos for a portfolio and a journal to go with it. And from there, we'll have to see.

Which brings me to the first little project. I've spent a bit of time reading and thinking about where to start, it does make sense to use Windows for the project initially though, even though I normally use a Mac and have an iPhone I could develop for, however, the games I would want to work on are PC or console games and most game jobs require C/C++ on Windows, so Windows just makes sense. I don't want to get overwhelmed and discouraged so starting reasonably small would be a good idea, which makes me think starting with XNA Game Studio is a good way to get my feet wet with XBox 360 and Windows development, rather than jumping into the deep-end with DirectX. Even if it is C# as opposed to C/C++, I'm not too worried about that just yet.

I'm going to start by developing a Breakout clone for Windows. This fits the reasonably small criteria but should cover a enough new areas that it should be interesting. I expect to learn about at the least following:

Setup of development environment and building and running a Windows game.
Simple 2D graphics.
Simple UI components.
Simple 2D vector math, trigonometry and animation of the ball and paddle.
Timing of animation.
Keyboard input.
Collision detection.
Simple audio playback.
Simple particle effects.

I'll be storing all the code for the project in my github account. So if anyone wants to see how I'm progressing in terms of the code, check it out. (I'll post a link to the actual repository when I get it set up next week.

That's all for this week, next week I'll post about setting up the XNA Game Studio in Windows.

rAtom 0.3.5 released

2008-05-03T00:17:00.000-07:00

This is just a maintenance release, nothing too exciting:

== 0.3.5 2008-05-03

* Make sure atom:entries appears last.
* Better examples in the documentation.

* Docs for Feed and Entry list attributes.
* Gave Feeds authors and contributors.
* Fixed a couple warnings.

Using rAtom in Rails

2008-04-14T18:13:00.000-07:00

Some mysterious anonymous person asked me for a tutorial on using rAtom within Rails. So I'll show you all how I do it.

Firstly, the big difference is that I treat it more like ActiveRecord#to_xml instead of like a *.builder view. So I'll start with an example.

Assuming you have a blog application with a Post model class, you can add a #to_atom method to your class like this:

class Post < ActiveRecord::Base  
  def to_atom
    Atom::Entry.new do |entry|
      entry.title     = self.title
      entry.updated   = self.updated_at
      entry.published = self.created_at
      entry.author    = Atom::Person.new(:name => self.author)
      entry.links    << Atom::Link.new(:rel => 'alternate', 
                                    :href => "/posts/#{self.id}")
      entry.content   = Atom::Content::Html.new(self.content)
    end
  end  
end

The advantage of returning a rAtom object here is that the atom representation is then composable, for example if you have a Blog class that has many posts you can do this:

class Blog < ActiveRecord::Base
  has_many :posts
  
  def to_atom
    Atom::Feed.new do |feed|
      feed.title = self.title
      feed.links << Atom::Link.new(:rel => 'alternate', 
                                :href => "/blogs/#{self.id}")
      
      self.posts.each do |post|
        feed.entries << post.to_atom
      end
    end
  end
end

To get this atom representation out via HTTP, you would do this in the controller:

class BlogsController << ApplicationController
  def show
    @blog = Blog.find(params[:id])
    respond_to do |format|
      format.atom { render :xml => @blog.to_atom.to_xml }
    end
  end
end

This has been really useful in an application that I am working on because we are using Atom as the main communication format between a bunch of different components, so this composability comes in really handy. For a simple blog it might be overkill, but at least you get the much better performance of libxml-ruby.

You'll probably notice a bit of ugliness in the to_atom methods, specifically this:

      entry.links    << Atom::Link.new(:rel => 'alternate', 
                                    :href => "/posts/#{self.id}")

The URL is hard-coded here because url_for is not available in a model. This is a bit of trade-off between the composability and strict MVC here, if you really wanted to you could pass the URL in as a parameter, or add a block that generates URLs or whatever, it's up to you.

For some applications, like a simple blog, the composability might not be too important, and you might prefer the syntax of atom_feed in Rails, or at least want to be able to render the atom in a view. In this case it would probably be nice to have a rAtom based template format, so you could add a view like "blogs/show.atom.ratom" which allowed you to move the to_atom method into a view and call url_for directly from the view. I'd like to add this at some stage, but it hasn't happened yet, due to time and priorities, but if anyone would like to submit a patch for it I'd gladly accept it.

rAtom 0.3.0 Released

2008-04-01T18:35:00.000-07:00

I've just release rAtom 0.3.0. This version adds support for simple extension elements and also checks that content is in UTF-8 before serializing to XML.

As defined in the Atom Syndication Format, simple extension elements consist of XML elements from a non-Atom namespace that have no attributes or child elements, i.e. they are empty or only contain text content. These elements are treated as a name value pair where the element namespace and local name make up the key and the content of the element is the value, empty elements will be treated as an empty string.

To access extension elements use the [] method on the Feed or Entry. For example, if we are parsing the follow Atom document with extensions:

<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:ex="http://example.org">
  <title>Feed with extensions</title>
  <ex:myelement>Something important</ex:myelement>
</feed>

We could then access the extension element on the feed using:

> feed["http://example.org", "myelement"]
  => ["Something important"]

Note that the return value is an array. This is because XML allows multiple instances of the element.

To set an extension element you append to the array:

> feed['http://example.org', 'myelement'] << 'Something less important'
=> ["Something important", "Something less important"]

You can then call to_xml and rAtom will serialize the extension elements into xml.

> puts feed.to_xml
<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <myelement xmlns="http://example.org">Something important</myelement>
  <myelement xmlns="http://example.org">Something less important</myelement>
</feed>

Notice that the output repeats the xmlns attribute for each of the extensions, this is semantically the same the input XML, just a bit ugly. It seems to be a limitation of the libxml-Ruby API. But if anyone knows a work around I'd gladly accept a patch (or even advice).

You can get rAtom via gem:

> gem install ratom

or from Github.

rAtom 0.2.1 Gem released

2008-03-08T19:03:00.000-08:00

rAtom is a Ruby Gem for working with the Atom Syndication Format and the Atom Publishing Protocol (APP).

rAtom was originally built to support the communication between a number of applications built by Peerworks[http://peerworks.org], via the Atom Publishing protocol. However, it supports, or aims to support, all the Atom Syndication Format and Publication Protocol and can be used to access Atom feeds or to script publishing entries to a blog supporting APP.

Features:

Uses libxml-ruby so it is _much_ faster than a REXML based library.
Uses the libxml pull parser so it has much lighter memory usage.
Supports RFC 5005 (http://www.ietf.org/rfc/rfc5005.txt) for feed pagination.

You can install via gem using:
# sudo gem install ratom

Usage

To fetch and parse an Atom Feed you can simply:

feed = Atom::Feed.load_feed(URI.parse("http://example.com/feed.atom"))

And then iterate over the entries in the feed using:


feed.each_entry do |entry|
 # do cool stuff
end

To construct a Feed


feed = Atom::Feed.new do |feed|
 feed.title = "My Cool Feed"
 feed.id = "http://example.com/my_feed.atom"
 feed.updated = Time.now
end

To output a Feed as XML use to_xml


> puts feed.to_xml
<feed xmlns="http://www.w3.org/2005/Atom">
 <title>My Cool Feed</title>
 <id>http://example.com/my_feed.atom</id>
 <updated>2008-03-03T23:19:44+10:30</updated>
</feed>

Publishing

To publish to a remote feed using the Atom Publishing Protocol, first you need to create a collection to publish to:

collection = Atom::Pub::Collection.new(:href => 'http://example.org/myblog')

Then create a new entry:

entry = Atom::Entry.new do |entry|
 entry.title = "I have discovered rAtom"
 entry.authors << name =""> 'A happy developer')
 entry.updated = Time.now
 entry.id = "http://example.org/myblog/newpost"
 entry.content = Atom::Content::Html.new("<p>rAtom lets me post to my blog using Ruby, how cool!</p>")
end

And publish it to the Collection:

published_entry = collection.publish(entry)

More Information

See http://ratom.rubyforge.org for more information.

Building Erlang with Rake

2007-09-26T03:09:00.000-07:00

I've recently started using Erlang on a project. This is my first foray into Erlang and I'm using Joe Armstong's new book Programming Erlang as introductory material. It is a great introduction to the language, although I wish it covered more of the OTP. I suppose there is the OTP Design Principles guide but sometimes a good paper book written in conversational style is better when you are learning.

In the book Joe describes building an Erlang project using make and most of the downloadable bits of Erlang code use make too; this makes sense, make is virtually ubiquitous. However the other components of this project are Ruby on Rails applications and make heavy use of Rake, so I figure why subject myself to Make when I can use the beautiful Rake.

Here is my Rakefile for building an Erlang project.

require 'rake/clean'

INCLUDE = "include"
ERLC_FLAGS = "-I#{INCLUDE} +warn_unused_vars +warn_unused_import"

SRC = FileList['src/*.erl']
OBJ = SRC.pathmap("%{src,ebin}X.beam")
CLEAN.include("ebin/*.beam")

directory 'ebin'

rule ".beam" =>  ["%{ebin,src}X.erl"] do |t|
  sh "erlc -pa ebin -W #{ERLC_FLAGS} -o ebin #{t.source}"
end

task :compile => ['ebin'] + OBJ
task :default => :compile

This gives you rake compile which builds all the .erl files in the src subdirectory into the .beam files in the ebin directory. Files will only be built if they have changes since the last build. You also get rake clean which deletes all the .beam files from the ebin directory.

I much prefer this over the equivalent Makefile and it is much easier to extend since you have the full power of Ruby at your disposal.

Enjoy.

Update: Fixed bug when compile many files from after clean.

Testing ActiveResource

2007-09-03T17:11:00.000-07:00

I recently started using ActiveResource on a project. ActiveResource is the client side of the REST picture, that is it can consume the REST style web services you get with Rails, think of it as ActiveRecord for HTTP.

One of the difficult parts of using ActiveResource is testing. You don't want to run it over a real HTTP connection, for one it would significantly slow down your tests and secondly you don't know what horrible side effects it might have. So you need some way to fake a HTTP connection and HTTP requests and responses. Enter the HttpMock class.

HttpMock is a fairly nice class put together by the Rails folk that allows you to register a bunch of request and response pairs for a fake HTTP connection. When you call a method on an ActiveResource in a test, it calls the HttpMock class instead of trying to create a real connection. It is fairly easy to use, although there is no documentation the blogging community has come to the rescue.

Here is a quick example:

  @matz  = { :id => 1, :name => 'Matz' }.to_xml(:root => 'person')
  ActiveResource::HttpMock.respond_to do |mock|
    mock.get "/people/1.xml", {}, @matz
  end

This creates a request response pair so that when ActiveResource tries to GET /people/1.xml it gets back the xml for the @matz hash. Pretty simple.

However there is a problem. HttpMock is misnamed - HttpMock is a stub not a mock. But the difference is more than semantic, a mock object, like those provided by the excellent Mocha library, will allow you to set expectations on a object. An expectation is like saying "for this test to pass, this method with these arguments must be called on this object". HttpMock doesn't do that, instead it is just a stub that returns a value when a method is called with a certain argument, there is no verification that the method is actually called.

To show why this is bad, lets look at the test for resource deletion from the ActiveResource unit tests themselves.

Firstly, in the setup method we use HttpMock to create response for the delete method used on the "/people/1.xml" path:

  ActiveResource::HttpMock.respond_to do |mock|
    mock.delete "/people/1.xml", {}, nil, 200
  end

And here is the test_delete method:

    1   def test_delete
    2     assert Person.delete(1)
    3     ActiveResource::HttpMock.respond_to do |mock|
    4       mock.get "/people/1.xml", {}, nil, 404
    5     end
    6     assert_raises(ActiveResource::ResourceNotFound) { Person.find(1) }
    7   end

So what is happening here? Firstly on line 2 of the test_delete method we call the Person classes delete method. The delete method is a nice one-liner:

      def delete(id, options = {})
        connection.delete(element_path(id, options))
      end

We can assume here that the the content of the delete method is sending a delete request to "/people/#{id}.xml", that makes sense. The rest of the test_delete method creates a request response pair that returns a 404 error when "/people/1.xml" is requested, all that does is test that ActiveResource::Base.find correctly handles 404.

So what ensures that the delete method does the right thing, all the test does is ensure that it returns something other than nil or false. Lets change the method and see if we can break the test. We'll just return true in the delete method:

      def delete(id, options = {})
        true
      end

After this change I re-ran the tests and they all passed. This can't be good. If you can effectively remove the body of a method you are testing and the tests still pass you don't have a very good test. So how can we fix it?

Well if HttpMock was truely a mock we could ensure that the HTTP delete method is called on the "/people/1.xml" path. Fortunately HttpMock stores every request it recieves in a class variable. So we can check that the request was received with an assertion.

Here is a new test_delete:

  def test_delete
    assert Person.delete(1)
    assert ActiveResource::HttpMock.requests.include?(ActiveResource::Request.new(:delete, "/people/1.xml", nil, {}))
  end

This one now fails when the body of the delete method is removed and passes when it is put back in, so this way we know that the tests is actually testing the functionality of the method. However it is a bit ugly isn't it? It would be nice if HttpMock allowed you to do this:

    ActiveResource::HttpMock.expects do |http|
      http.delete "/people/1.xml", {}, nil, 200
    end

But I'll leave that for another blog post.

Index Ruby Objects by an Attribute

2007-05-28T18:41:00.000-07:00


class Array
  def hash_by(attribute)
    self.inject({}) do |hash, e|
      hash[e.send(attribute)] = e
      hash
    end
  end
end

Why GET should always be idempotent: A lesson from Del.icio.us and Sage

2006-04-27T07:56:00.000-07:00

This evening I downloaded Sage, a RSS/Atom feed reader extension for Firefox. It is quite a nice feed reader and a big improvement over Firefox's Live Bookmarks which I find hard to use with lots of feeds and IMO over Google's Personalised Homepage which I find doesn't scale too well with lots of feeds and doesn't provide previews of the content.

Sage had a particularly cool feature that jumped out at me, the 'Discover Feeds' feature. This allows you to find all the feeds referenced in a page, rather than just the feed in a link tag in the header. It seems that what it does is follow links that may be potential feeds and checks if they are. You then get a list of all the feeds in the page and can add them to your 'watched' feeds in Sage.

This got me thinking, since I use alot of different computers it is pain trying to manage my list of feeds on each computer, exporting them and copying them around is just asking to get them out of sync and frankly too much effort. ;) So since I already have a Del.icio.us account where I keep my bookmarks I could bookmark all the feeds I care about and tag them with 'feed' in Del.icio.us. Then I just need to navigate to the page for the 'feed' tag click on the Discover Feeds button in Sage and all my bookmarked feeds are there to be added to Sage! Yay online storage of feed links that can easily be added to my feed reader of choice from any computer!!!

Or so I thought. It just so happens that the Delicious 'Delete Bookmark' link is one of the links that Sage follows when it searches for feeds. This has the unfortunate side effect of deleting all my bookmarks in the feed tag. The ideal fix is that Delicious delete action needs to be changed to only respond to a HTTP POST method. This would be comformant with W3C Recommandations too.

I've submitted this bug to Delicious but for now the dream of online bookmarking of feeds to be accessed by Sage remains elusive.

Tags: Delicious HTTP Firefox Blogs

Calling Web Services From Rails

2006-04-23T23:13:00.000-07:00

I've notice a few places where people have asked whether Ruby On Rails supports the consumption of web services. Rails itself doesn't. I have found the easiest thing to use is SOAP4R, which according to its web page comes bundled with Ruby 1.8.3 and above.

SOAP4R is really easy to use, it simply generates Ruby stubs from a WSDL which will call the web service for you. You just call the stubs as though they were a Ruby API.

If you have ever used any Java or .NET web service clients, it is pretty much the exact same concept.

Tags: SOAP Web Services Rails Ruby

Javascript Graph Visualisation

2006-03-09T15:56:00.000-08:00

I just found this new graphing library for Javascript. I've been looking for something that does this for a while so I can visualise relationships represented in RDF. The last thing I was looking at was Foafnaut which doesn't seem to be very active and only supports foaf information.

This Javascript library looks really promising though since you should be able update the graph using Ajax which would be really cool. It's just in the beginning stages now but I'll definately be keeping an eye on it.

Technorati: semantic web Javascript RDF Canvas SVG Firefox

Active Ontology for Ruby on Rails

2006-02-19T04:01:00.000-08:00

Obie Fernandaz has some ideas for a Ontology based ActiveRecord alternative.

This is a really interesting idea, something I've also been thinking about for a while. One of the tricky things in doing this would be determining what properties a class has. In a RDBMS table you declare that a table (class) has a number of columns (attributes) the mapping to an object model is fairly obvious.

However with OWL and RDF you declare a class and you declare properties, however properties are independant of classes. You can, in RDFS, say that a property has the domain of a specific class, which means that if a Resource has that property it is a member of that class. This is different to RDBMS/OO land where you declare that a class has a property. The difference is subtle but important as it allows you to say things like:

There is a Employee class.
There is a Manager class which is a subclass of Employee.
There is a manages property that has domain Manager.
We can then infer that the manages property also has Employee as its domain since all Managers and Employees. (Note that this the opposite of OO where properties and inherited down the class heirarchy).
We can then create an instance of Employee. It is valid to give that Employee a manages property pointing at another Employee instance. We can then infer that the Employee is also a manager.

When you want to map this to OO though, which class gets the manages property? It is correct to give it Employee since we infered that Employee is a valid domain for manages. Except any Employee who manages someone is a Manager too.

This is one of the tricky things that will arise out of the differences between Ontologies and OO. A couple of the others are multiple inheritence and multiple class membership.

Most of these issues could be worked out after the initial functionality is there, but it should interesting to see how they are tackled.

Update: Man I really need to look at dates before I respond to blogs.

Technorati: semantic web, Rails Ruby

RDF Schema Generator

2006-02-18T21:31:00.000-08:00

I've release my first Rails generator on Ruby Forge. RDF Schema Generator builds a Ruby Module from an RDFS file. The module contains constants for each of the properties and classes in the Schema. If you are using Rails to build RDF based applications you might find it useful.

Install it using gem install rdf_schema_generator.

Once it is installed you can run

ruby script/generate rdf_schema <prefix> <rdfs_url>

and a class called will be generated in the lib directory containing a module with all the classes and properties for the RDFS file retreived from <rdfs_url>.

Enjoy!

Tags: Ruby Rails RDF

First Post

2006-02-18T06:26:00.000-08:00

Well, this is my first ever blog post.

By way of introduction - my name is Sean Geoghegan, I'm a geek, I work as a computer programmer. I'm currently into Ruby on Rails and really want to write a Rails based web application in the guise of flickr or 43things that becomes hugely popular, I just need an idea, if you have one post it in a comment.