TEAMS OF RIVALS: CO-OP LESSONS FROM JAMESTOWN
In a pressurized cabin about 40,000 feet above the Rocky mountains hurtling towards San Francisco at over 500 mph, on a laptop that was well past its prime, at absolute end of a brutalizing two-month crunch, our lead programmer Tim added 4-player co-op to Jamestown just in time for the Game Developers’ Conference, and then promptly passed out in his complimentary airplane peanuts.
The Jamestown in question became an indie pixel art shoot-em-up with 4-player local co-op, for the PC, Mac, and Linux. It took us about two years to make, with three full-time developers (2 programmers, 1 artist), and the help of various super-talented freelancers and friends. Co-op was an area of special interest for us, so we decided to treat it as a first-class feature with every bit of importance as the single-player game. This was a huge undertaking, and forced us to contend with countless problems we never could have anticipated.
Solving those problems stands as one of the proudest accomplishments of our lives.
But when people ask us how Jamestown’s cooperative experience came to fruition, we often tell the story above; mostly because it’s fun and short, and because it alludes to our never-say-die, seat-of-the-pants, oh-my-god-we’re-all-going-to-die indie life choices. Also, it alludes to Tim’s considerable moxie. And it is a true story.
Behold! Our pre-alpha UI in all its glory!
However, it omits rather a lot of useful information that, presumably, the folks who ask us that question are interested in hearing. It also glosses over the year-plus of additional work that went into actually finishing the core co-op game systems that Jamestown features today, which is a problematic message, because there ain’t nothin’ easy about adding good co-op to a single-player game.
That dismissive tomfoolery ends today; we’re here to share some of the hard-learned lessons from our two-year stay at The Co-Op Problems Hotel.
A NOTE ON
Playtesting is the method we used to evaluate every one of our assumptions and ideas. Everything we’re about to describe was empirically verified by dozens and dozens of playtests. We believe this is the safest way to navigate the treacherous waters of game design, and we’re (in)famous for our tendency to expound on the virtues of that process at the drop of a hat.
Pictured: an experiment in progress. A serious, serious experiment.
So if you take nothing else from this article, please take this: playtests are the experiments you do to verify the unsubstantiated hypotheses you refer to as “your design.” If you want to make something truly fun, try to subject it to constant, deliberate scrutiny, and keep integrating what you learn into the next version. The journey may be hard, but it will take you to good places.
Alright, finally: let’s get into it.