Hi all! Now that I've gotten my sleep schedule mostly in order again, I figured I'd write a bit about making Robot Walk.

If you haven't played it yet, you can find the game here. It's quick to try out and doesn't need a download :)

The concept

The starting concept for robot walk was that you'd have a robot companion that you had to keeping running, i.e. "keep it alive". I liked the idea of being able to run around inside the robot, like in Regular Human Basketball. The theme and those mechanics flowed well into the idea of having various tasks on the robot that you'd have to keep tabs on, e.g. steering the robot out of the way of danger, fixing its engine, etc., reminiscent of games like Lovers in a Dangerous Spacetime or Overcooked.

If you've played the submission, you'll know that almost none of those ideas made it into the actual game. That is because this concept was far too ambitious to complete on my own within the 72 hours. I underestimated a lot of the programming work, and didn't even consider how much art it would need to really be what I imagined - particularly given my inexperience with making art.

While the concept was overscoped for a jam game, I don't regret that I stuck with it. I'm glad that I picked something and ran with it, rather than agonising over finding the "perfect" idea for far too long. An upside to the concept was that I had a strong idea of what I imagined the game to feel like, which was useful as a guiding direction while making the game.

Making the robot walk

The main aspect of the game that I did manage to implement was the robot itself, in particular its walk animation. I spent all of day 1 and part of day 2 on it, going several iterations of the logic behind it.

The first version was based on this short tutorial, which laid the groundwork of moving the main robot body directly (imagine you're controlling a very slow car), and having the feet move whenever they got too far away from a "target point" that moved relative to the main body. This is what the earliest version of that looked like, with only one "foot".

I used that technique to build a robot with 6 legs. While that technically worked, I found that the distance-based foot movement lead to situations where all legs would move in quick succession, followed by a span of time where nothing moved. This didn't really fit with how any animal moves their legs, where movement is fairly rhythmic.

I got to the final version of the walking after realising that I made the problem more complicated than it needed to be. Given that I wanted a certain steady rhythm of the feet moving, I implemented the walking based around the timing, instead of doing it indirectly through the distance between the feet and their target positions. The gist of the approach is that I calculate how long it should take for an individual foot to move forwards, based on the speed of the robot and the distance a foot can be behind the body before its leg has fully extended. Then, as long as the robot is moving, each foot is moved forwards one by one, in a zig-zag order based on how real four-legged animals walk. This way, one foot is always moving, causing that steady rhythm that I was aiming for. I also switched to only 4 legs because I found the staggered movement of the legs more interesting than the grouped movement that 6 or 8 legs would do.

After I got the walking looking the way I wanted, I cleaned up the logic a bit, and added some visual touches to the robot. I split up the legs into an upper and lower segment, with the upper being a fixed length. This helped to make the robot look more mechanical. To convey some depth, I tweened the scale of the feet and the leg segments whenever a foot moved, mimicking them moving closer to the camera.

Player interaction

With the robot working, I added the other important part of the game, the player. Once I got the player in as a sprite moving around, I also adjusted the robot scale to be much larger than the player. It's quite surprising how much a player character helps with conveying relative scale - as soon as the player existed, it really felt like I was moving along a giant lumbering machine!

For entering the robot's internals, I created a tilemap with some rooms, and attached it to the robot's body. Triggers at the entrances detect when the player enters or exits the robot, and either attaches or detaches the player's transform to the robot's transform - this way, while you're in the robot, you move and rotate with it. To my surprise, this all went smoothly, with my collision system only needing a few small additions to handle this case.

At this point, I didn't have enough time left to add any actual game features, but wanted to at least create some player interaction. This came in the form of the the robot steering, which even made me create some custom graphics for the buttons and robot interior (the first tileset I've ever made!) I was quite pleased with the fact that I could make a simple button animation just by flipping between two different tile visuals. This also helped to communicate when you were interacting with the buttons. I finished out the submission with some camera tweens while you're steering the robot, so that you can see more of what's ahead of you. (Even though there's nothing to see currently :D) A dynamic camera really makes the game feel a lot more alive!

Conclusion

Overall, despite not making a "proper" game, I'm quite happy with the end result of this jam. I learned a lot about what matters for the experience of the game, and based on the feedback so far, even in this basic form it seems successful at conveying the feeling of steering a big robot that I was going for.

I used the (still in development) luxe engine for this game, to test it out in a common use case. If you want to read about another game made with luxe and the process of making it, check out this post by @ruby0x1.

Thanks for reading! Find me on twitter @keymaster_ for updates about whatever I'm working on - which hopefully will be an expanded version of this game!