Sponsored By

Alt.Ctrl.GDC Showcase: Too Many Captains

Too Many Captains (And Not Enough Wire) will involve a lot of wire-swapping (and communication between friends) to safely pilot a starship through dangerous territory.

Joel Couture, Contributor

February 1, 2018

8 Min Read
Game Developer logo in a gray background | Game Developer

The 2018 Game Developer's Conference will feature an exhibition called Alt.Ctrl.GDC dedicated to games that use alternative control schemes and interactions. Gamasutra will be talking to the developers of each of the games that have been selected for the showcase. You can find all such interviews by clicking here!

Too Many Captains (And Not Enough Wire) will involve a lot of wire-swapping (and communication between friends) to safely pilot a starship through dangerous territory. One player is given access to a control panel and only enough wire to power a few ship functions (shields, weapons, etc), but only knows what to hook up based on what other players tell them to as they won't be looking at the screen. This turns ship piloting into a frantic game of teamwork and communication as players work their way through space. 

Gamasutra spoke with Avi Romanoff and Giada Sun, developers of Too Many Captains (And Not Enough Wire) to talk about the thoughts that went into the game's wire-plugging controller, and how it inspires players to get creative with their communication and work as a team.

What’s your name, and what was your role on this project?

We’re Avi Romanoff and Giada Sun. We’re both current students at Carnegie Mellon University, and we’re answering the questions together. We are the whole team so far, and enjoy having fluid roles. We’ve both done programming, interface and art design, game design, and helped build and prototype the physical controls.

How do you describe your innovative controller to someone who’s completely unfamiliar with it?

Think a 1900s telephone switchboard meets the controls on a ship from Star Trek. Colorful, lots of lights, but the main interaction is plugging and ka-thunking thick wires into holes.

What's your background in making games?

Romanoff: I think I’ve always been into games. As a kid, I remember making my own trading card games out of index cards. In middle school, I set up a website that hosted flash games so my friends and I could play them in the computer lab, bypassing our school’s content filter. In college, I found myself building weird physical/digital installation games for my school’s Spring Carnival. Too Many Captains is definitely the most time I’ve spent working on a game... and I’m really liking it!

Sun: I was totally addicted to Warcraft III’s World Editor when I was in high school. I spent most of my time after school on making several DotA-like games. I really enjoyed making games because it's a comprehensive art — you need to think about the story, how the characters look, how the players will act, and how to design enjoyable mechanics that make people want to keep playing. It was also an opportunity to learn graphic design and some coding. Too Many Captains really evokes tons of my high school memories for me.

What development tools did you use to build Too Many Captains (And Not Enough Wire)?

Architecturally, our game is very modular, and everything — including the hardware — is written in TypeScript. The “engine” and on-screen display is actually a website, using HTML5 canvas and the Phaser framework. The engineer’s controller is a Raspberry Pi, which controls a WS2812 (“NeoPixel”) light strip, buttons, and the wires. Since hardware is hard™, we also wrote a software “emulator” of our custom controller in React.

All of the different components of our game communicate with each other via WebSockets (with a super simple Node.js server serving as a message broker). We write code in vim and VS Code, and design assets in Illustrator and Sketch.

What physical materials did you use to make it?

We’re still experimenting with materials, but our current prototype controller is basically a lot of black foam core, wood, and tape. That worked surprisingly well, but it’s kind of falling apart, so we’re looking into laser-cutting and 3D printing components, such as MDF and acrylic.

How much time have you spent working on the game?

We started working on the project in mid-November 2017. Actually, we submitted our application to Alt.Ctrl.GDC about 3 weeks from the inception of the project. About 10 days before the submission deadline, someone suggested our project might be a good fit, but that we probably couldn’t make it given the short notice. We took that as a challenge... we basically lived a small hackerspace for a week.

How did you come up with the concept?

We were taking a class called Experimental Game Design taught by Paolo Pedercini (aka Molleindustria), and our assignment was to come up with non-traditional control schemes in Unity. Neither of us really knew Unity, and we’re both a little weird, so instead we brainstormed some wacky ideas like slapping computers, shouting at inanimate objects, swapping control schemes mid-game, and eventually plugging wires in.

Originally, we wanted the game to have an instruction manual — with dozens of different wire combinations. We played around with a lot of different ideas, and scrapped everything and started over a few times.

What drew you to tie controls to someone who cannot see the screen? Who isn't even with the other players?

We knew we wanted to do something with asymmetric controls, and drew a lot of inspiration from games like Keep Talking and Nobody Explodes, Lovers in a Dangerous Spacetime, and the Star Trek movies (where the engineers are in the lower decks of the ship, communicating with the bridge via intercom). Having one player not being able to see the screen was a really fun and challenging constraint to embrace. Having that player not be in the same room ended up not being so important to the gameplay, and we’ve relaxed that requirement with our latest prototypes.

What difficulties came up in designing the game where problems can quickly be seen and communicated to the player outside the room?

The biggest challenge was designing gameplay that was both easy to jump into, but that was still challenging and skill-based once you mastered the basics. We also ran into another problem — ensuring both the captains and the engineer had sufficient agency. We experimented with microphones, manuals, and LED indicator lights. What we found was that the challenge of communicating was the fun part. So instead of trying to impose restrictions or structure on how the players communicated, we tried to make it as flexible as possible. “Say whatever you need to say!” This leads to lots of different strategies, like appointing a single head-communicator, having each captain focus on different priorities, developing shorthand, etc. It turns out that our game is a lot more about communicating and teamwork than actually piloting a starship... and we love that.

What thoughts went into the wire-plugging controller? How did you create frantic play with it without making it overwhelming? How did you design the game around this unique interface?

We spend a lot of time thinking about pacing. Although our game is essentially a side-scrolling shoot-em-up, the pacing is way slower than most games in that genre. The elements on the screen, including the players’ ship, move very slowly. And yet, yeah, the game is often super frantic. Part of this is because controlling the ship effectively is really hard. Even though there’s only 3 buttons and 3 wires, the objectives of the captains tend to change constantly. Engineers quickly learn how to move up with one hand and swap wires with another. Captains discover that they can spend more time firing weapons or repairing if they raise and lower their shields quickly, and fire a precise number of bullets to destroy a particular enemy.

It’s precisely because the controls are so cumbersome that players find ways to speed things up. The game is actually pretty slow — it’s the players that bring the frenzy.

How do you think standard interfaces and controllers will change over the next five or ten years?

We definitely think alternative physical controllers are the way of the future. Virtual and augmented reality technology is making it possible to create realistic and immersive virtual worlds, with complex real-world objects. At the same time, it’s becoming increasingly frustrating to have meaningful, realistic interactions in these worlds.

When all you have is pixels on a 2D screen, hitting a button to drive a car or using a joystick to aim a bow and arrow doesn’t seem so far-fetched. But when you’re in an immersive virtual world, it becomes totally unsatisfying. People want to touch, bend, twist, throw, plug, shake, etc. As our game worlds become more visually complex, the interaction models need to catch up. We see alternative and indie controllers playing a big part of that.

We’re also very excited that it’s becoming easier than ever to build alternative controllers. Inexpensive hobbyist platforms like Raspberry Pi and Arduino and maker-centric fabrication techniques like 3D printing and laser cutting are leveling the playing field for controller design. You don’t need to spend thousands of dollars on injection molding and circuit board design. You just need a laptop, some parts from Amazon, and maybe access to a makerspace. Or maybe you just need lots of cardboard!

Read more about:

event-gdc

About the Author

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like