BOXBOY! Day 2

Turns out Qbby has some pretty charming tells in his design:

1. His legs reveal his collision width! I expected his box to be his, well, bounding box. Instead, as soon as both of his legs are off a platform, he falls. A nice side effect of his being “thinner” than expected is it’s much easier to make him fall down a hole.
2. His leg height makes for easier platforming! Qbby’s jump is one “block” high. Without legs, players would need to land on the platform at the exact right time to reach a ledge. His legs give him a boost, since the collision here is based off his box, not his legs.

For now his legs are just blocks, which is lame. What’s nice though is they’re dynamically sized based on the collision settings, which really drives home the visuals-as-a-guide connection.

BOXBOY! Day 1

Here’s the deal — this is the first time I’ve ever tried building a platformer. Mercilessly most of BOXBOY! is digital, which makes breaking down the game significantly easier. But that still leaves several problems that need solved, like collisions. There’s probably a world where Unity’s built-in physics are good enough. In the spirit of learning something new, however, I’m rolling my own! And so far, so good!

Right now Qbby can run, jump, and collide. My “physics” consist of shooting raycasts horizontally and vertically. It works pretty well, especially when I moved from shooting just one ray to shooting three. Without that, he was able to clip around corners in unexpected ways (Which makes sense, since it was basically acting as a single point instead of a box).

Hello, BOXBOY!

Over the next few weeks, I’m going to be breaking down and reimplementing one of 2015’s best games — BOXBOY! for the 3DS. This is an exercise called “covering” a game.

So what does it mean to “cover” a game? It’s sort of like how musicians start by “covering” their favorite artists before writing music of their own. In the process of mastering someone else’s work, a musician develops a slew of new techniques, as well as better understanding why that track works the way it does.

For games (and gameplay in particular) that means determining how a game or mechanic works, and then actually implementing the design into a playable prototype. Building something is key — more often than not having to program an idea offers just as many opportunities to learn how and why a game behaves.

Which leaves us with BOXBOY! I’ve always wanted to cover a Mario game, since they’re some of my favorite games (And are best-in-class when it comes to gameplay and input). Having never made a platformer before, it felt like biting off more than I could chew. Instead, BOXBOY! allows for a happy medium — digital input meets an interesting “copying” mechanic.

The goal is to cover all of World 1. This means implementing a fair amount of systems (movement, collisions, input) while also ignoring more complicated features (Qbby’s “hooking” mechanic, enemy AI’s, etc).