Blog Posts

Helicopter Tennis Devlog 1

Helicopter Tennis is a game where two players use helicopters to play tennis against each other.

Leaves the room.

...

Peeks inside through the door.

Ok, I know, I know - you didn't come here just for the elevator pitch. Helicopter Tennis is a two-player local multiplayer action game that I have been working on with my friend and collaborator, Chapin Boyer.

We started development in February of this year, prototyping at a leisurely pace for a few months before defining a production schedule and deadline for ourselves in late June.

I'm writing this devlog while we are smack-dab in the midst of our production timeline because I want to capture my nascent thoughts as we sail the turbulent waters that are the game design process. I want to share our current heading and our ideal goal so that we can reflect on our journey together when we disembark on some island out there.

Catching lightning in a sketch

During one of our conversations last Winter, Chapin shared an idea that had been on his mind for many years - "What if, instead of cars playing soccer, you had helicopters playing tennis?" Instantly, an image coalesced in my mind and I sketched it out.

I pitched the game to him, influenced by my thoughts on production at the time. We could make a small, focused experience in a short period of time and focus on release so that people could play our game ASAP, rather than let the momentum from our prototyping fizzle out mid-development. Considering our combined niche interest in multiplayer action games with weird control schemes, we both got excited about the concept. We kept the game brewing in the back of our minds through the busy holiday season.

Prototyping Phase - Chill Game Design

When we started prototyping in February, our core design pillar was 'chill game design' - we kept the goals and process for the prototype loose and unstructured. We avoided creating a kanban board that would have easily filled up with todos of dubious importance. We wrote the fastest code to test functionality rather than the most robust or optimized version (I was inspired by listening to this episode of The Eggplant podcast). We allowed ourselves to take it easy and avoided aiming for big swathes of changes every week. The intention was to keep our ideas flowing freely, assuming a low-stakes, low-pressure approach to every prototype. This was our exploratory design phase - we wanted to follow the fun.

Our prototyping philosophy in commit messages

The only constant we kept was playing the latest prototype together every time we met. This has been valuable throughout our process - reminding us of the game's current status, revealing design challenges and bugs, sparking ideas for new features and always providing direction on what to prioritize working on next. During this stage, we showed the game only to a few other designers and close friends or family. We wanted to be more precious about our baby, since we already knew it couldn't quite walk on its own yet.

Our baby prototype copters

It's important to understand what feedback you're looking for before any playtest of your game. You're asking for trouble (and probably a whole lot of negative feedback) if you just allow your playtesters to blast you with any and all problems and opinions they have with your game.

Production Phase - Shifting Gears

At some point (coughs June coughs) we found ourselves playing more than a few rounds and volleying back and forth somewhat consistently during our weekly check-ins. We figured this would be the right time to shift gears and setup a clear production schedule for ourselves - and what better way to outline a plan than to set an external deadline?

Chalking out our production plan on a Miro board

We looked into festivals to apply to and selected a few coming up to plan around. That gave us a date to have a final build and from there we worked backwards to plan what features and polish we wanted and when we needed to complete them. During our prototyping phase, our mantra was 'If you have an idea, test it out quickly even if it's janky!'; our new mantra was 'If it's out of scope - cut it!'. It's hard to stop ourselves from scope creeping and adding more features and more polish but we've had to put on our producer hats and remind ourselves that the goal is release. In my opinion, a game is only alive if players are playing it.

An old, chunky helicopter sprite

Now that we had confidence in our core gameplay loop, we shared our game with as many friends and folks as we could. Now that we could share a stable build of the game, we wanted to get as much feedback as possible from a wide range of players. Did the control scheme make sense? Was the learning curve for the controls satisfying and smooth? What was the average length of a rally? Were there any degenerate strategies we had missed? We stuck to our weekly meeting schedule and mandatory dev playtests. We also decided on a 2-game minimum playtest length before implementing any changes or tuning to the game. That way, we could test the changes with both sides serving.

We're currently still wading through the latter half of our production phase - mainly focused on adding juice and polishing the game. As we've learned from our previous games, adding juice to an action game is vital - it's not just fluff you can slap on without consideration. It's another way to communicate to the player when they are playing well and guide them when they fail.

Playtesting a Local Multiplayer game Remotely

Since we're collaborating on this game remotely, we have the challenge of testing a local multiplayer game over the internet...again. We used Parsec for our weekly playtests and they were crucial despite any latency.

We realized partway that reducing the bandwidth on the host from the default would reduce the latency, hopefully this knowledge saves you some trouble when you test your multiplayer game remotely with your teammate over parsec.

Reduce the bandwidth limit until your latency issues are minimal

We also planned some sporadic in-person playtests with friends which let us observe the learning curve and skill acquisition of new players in person. It also gave us mini milestones to create builds of the game and see if it could stand on its own with minimal explanation and interference from us. We would have loved to attend more in-person festivals and events but understandably, most are still online or remote-only. That makes it hard to show a local multiplayer game but fingers crossed for when that's possible again.

What's on the Horizon

Our current plan is to 'go gold' with our game by the end of this month. Following that, we'll switch gears again to focus on releasing the game on itch.io and Steam. That way we can focus on the logistical tasks required for release and sharing the game. Until then, I'll share biweekly devblog updates on our progress. Thanks for reading this far and see you in the next update!