Debugger Screenshot

libGDX Jam Day 3: Slow ‘n Steady

Reading Time: 3 minutes

Check out the latest commit!

I didn’t get as far as I would’ve liked these last two days, but I still got a few things done:

I made a debugger

One of the complications that comes with this sort of space game is that unlike classic Asteroids, we’re going to have a larger game world that can’t fit on the screen- our camera is going to need to move and follow the player as they fly about. Space is big, and it can be hard to find or track things. Thus, I decided to create a small debugging framework.

The code is all here on GitHub so I won’t go into all the details, but suffice to say I decided to borrow a page out of Mojang’s notebook and create an in-game debugger:

Debugger Screenshot

If you press F5, the debugger will toggle on and display green grid lines for the world, blue text for the camera, and (in the near future) red lines for collidable objects. I also created the debugger as an Ashley system, so removing the debugger from the final project just means removing one line of code!

I know it doesn’t do very much, but it was really helpful in debugging the endless star tiling, and I’m sure it will evolve as the jam continues.

I added tiling

To be honest, I thought this would be one of the easier parts, but it turns out to be an interesting little programming problem. You see, normally we would have a fixed number of tiles, and then just render them using a for-loop. However, since the player will be able to fly in any direction for as long as they like, we run into a problem since we can’t render infinite tiles.

Instead we have to only try and render the tiles we know will be seen by the camera. But how do we know which tiles those are?

Endless Tiling

Essentially we need to imagine the world as if it was grid paper, and the squares we want to fill are the ones that overlap with the camera. We do this by “rounding down” the camera’s position to the next lowest grid, and then drawing tiles until we would draw one outside the camera completely. The algorithm is below:

<code>
float cameraLeft = camera.position.x - camera.viewportWidth / 2f;
float cameraRight = camera.position.x + camera.viewportWidth / 2f;
float cameraTop = camera.position.y + camera.viewportHeight / 2f;
float cameraBottom = camera.position.y - camera.viewportHeight / 2f;</code>

float width = background.getWidth();
float height = background.getHeight();

batch.begin();
for(float column = (float) Math.floor(cameraLeft / width) * width; column &lt; cameraRight; column += width) {
    for(float row = (float) Math.floor(cameraBottom / height) * height; row &lt; cameraTop; row += height) {
        batch.draw(background, column, row);
    }
}
batch.end();

Admittedly it isn’t that pretty, and is kind of expensive, but it works until we actually need to optimize it.

Where to next?

The next thing to do (which I really hoped I’d have today) is the actual player ship flying around. Normally this would be easy, but I’m trying to blend three different libraries together:

  1. Ashley: This library lets one create entity-component type systems. The idea is that all of your game objects become bundles of “components” which let them do different things (act as a gravity well, have health, get rendered, etc.). Essentially we create a bunch of different parts which can be snapped on to any entity we want like Lego bricks.
  2. Scene2D: Scene2D provides a graph which is very useful in tracking parent/child relationships. For example, we may want to have engines or shields or lasers or turrets which are components of our ship. Scene2D will update their position and rotation relative to the position of their parent.
  3. Box2D: Box2D provides physics (which are a real pain to do from scratch). This will be very useful for detecting collisions and acting accordingly. For example, we’ll want to know when ships collide with asteroids.

One way or another I plan to get these three to play together tomorrow so we can move on to more of the fun stuff.

Thoughts? Suggestions? Snarky comments? Let me know below! Also make sure to check out the other libGDX Jam Dev logs here!