23 May 2011

Optimization is a big thing in games. Today, it seems like every single millisecond counts, and a moment of computing that could’ve been cut in half is considered completely and totally wasted. Along those lines, the standard code behind an ordinary tile-based platformer is incredibly unoptimized. Games tend to waste time by comparing the location of more tiles than needed to the position of the player. With my current project, I figured I would try and optimize it in a way that I thought had never been done before.

In my idea, every block on the “map” was represented by a 1 on a grid that consisted primarily of 0’s and 1’s. Rather than moving smoothly and realistically, the player object would move in a more classic fashion in that its speed would be constant (as opposed to accelerating over time, with deceleration in the form of damping). Because of this, it became easy to ensure that whenever the player passed into a new cell on the grid, it’s x/y position could be updated. Then, rather than comparing the EXACT locations between the ball and a block, the game would only have to compare two positions on the grid. Now, this was perfectly fine when movement was 1-dimensional; if the player saw that the block to the right was occupied, it would stop moving forward. However, things began to break when gravity was added. The issue is difficult to explain, but it basically involves the player’s position on the cell not being updated until it passes FULLY into the next cell on the grid. Because it doesn’t always travel exactly 1 cell vertically or horizontally, there are times when the player is in between two¬†separate¬†cells. If, on one side, there’s air below the player, and on the other there is a block, the player might fall thought despite having landed on the block because the game thinks that the player is on the cell with air below it. Errr, why don’t you try the prototype to see what I mean:

Honestly, I don’t know why I’m bothering to post this. It’s not like there’s any people reading along that could throw an easy fix my way that wouldn’t require completely restructuring the “hittest” code… Still, typing out the issue did help me better understand the issue, and when I solve it, I’ll make sure to post the solution.