Nick Gravelyn

When I started Bloc, there were only two classes in the game with Update methods: the blocks and the circle. Oh how quickly did I realize that doesn’t even come close to cutting it. Soon after I found myself adding powerups. Those needed an Update method. Orbs? Update method. Heck even the score wound up with an Update method before the game was done.

My new approach is that, off the bat, all classes should implement an IUpdatable interface and have the Update method. Why? Because more often than not, you’ll want to update your objects.

There’s all sorts of obvious examples, but let’s look at the less obvious ones. We’ll start with my GameScore class:

public class GameScore
{
    private float score;
    private int targetScore;
    public TimeSpan PlayTime;
    public int Score { get { return Math.Floor(score); } }

    public void AddScore(int increment) { targetScore += increment; }
    public void Update(GameTime gameTime)
    {
         if (Score != targetScore)
         {
              float scoreChange = (targetScore > Score) ? 2.1f : -2.1f;

              if (Math.Abs(targetScore - Score) < scoreChange) { score = targetScore; }
              else { Score += scoreChange * (float)gameTime.ElapsedGameTime.TotalSeconds; }
         }
    }
}

So the Update in this case is so that we can update the score over time to catch up with the target score. This is how Bloc achieves that rolling score effect. It’s a feature that might be overlooked now, but play the game without it and you’ll see just how much polish that adds to the game.

I have now adopted this policy such that all objects in my future games will have update methods. This is great for interpolation of scores, positions, rotations, or scaling; polling for input; or simply for clamping objects in certain bounds. At least from Bloc and the initial steps of my next game, it seems that is a pretty good route moving forward.