Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 19, 2018
arrowPress Releases
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


The History of Captain Forever Exclusive

 The History of  Captain Forever
March 30, 2015 | By Farbs




This is the story of Captain Forever, a game that exploded onto the indie scene in 2009 and did not make me rich. Captain Forever is also the name of a series of games, the first three of which we will now dissect. There are nine Captain Forever games overall… sort of. It’s complicated.

The Game

Captain Forever is “Lego Asteroids” – you fly a space ship in an Asteroids-inspired fashion, adding and removing functional parts from the enemy ships you destroy. The core idea was inspired by Sean “th15” Chan’s Battleships Forever. Whereas Battleships Forever has an RTS-like interface, I wanted to fly my space ships directly, and whereas it had a separate ship editor executable, I wanted to modify my ship as I flew. In particular I wanted to defeat enemies with more capable parts, then equip those parts and hunt down even more powerful foes, and so on along a high speed RPG hamster wheel. The rest of the design fell out from these core concepts and my desire to get the game finished.

I adopted a flOw-inspired progress system, allowing the player to determine their own level of challenge by deciding which randomly-generated enemies to fight. I randomly generated the enemy ships to avoid designing them myself, and to create interesting and surprising challenges in my own play sessions.

As a reward for reading this far you can now go play Captain Forever in your browser, for free. Enjoy!

The Plan

Early one morning in June 2009 I opened a fresh text file and poured into it every game idea from the back of my head. Riding high from my freeware release ROM CHECK FAIL I had recently quit my job to live the fulltime indie dream, and now I had to choose my first project. Having studied the successes of Petri Purho and 2D Boy, I figured I would follow their lead and create a series of prototypes. I hoped one of these prototypes would be my Crayon Physics / Tower of Goo, which I could build into a Crayon Physics Deluxe / World of Goo. I didn’t expect my first prototype to succeed so I picked Captain Forever, mostly because I wanted to play it. A few weeks later a friend stayed up all night playing an early build, and on hearing this I decided to knuckle down and commit a month to building a release-grade prototype. Three months later it was finished.

Toward the end of this period I started thinking about growing the game, and how I would expand on the minimum-viable-funtime of the prototype to create the vast Elite-like spacescape that I felt the game wanted to become. After consulting with my community I decided to split the game up into a series. Each game would build upon or branch out from another game, allowing me to add features and explore new directions without messing up the games that people already owned. I called it a Supporter system, and set a fixed price for all the games in the series. At that time Kickstarter and Early Access didn’t exist, but the Minecraft alpha had sold to around 1,000 customers so this seemed like a viable path.

By September I had the slimmest version of the game finished, and was itching to get it into people’s hands. My plan had been to release this version (dubbed “Captain Forever”) for free. I would attract eyeballs by embedding it in a web page, with all subsequent games available for sale in the supporter package. Having never built a user login system or integrated a payment solution before I was nervous about launching these systems, and opted to instead pre-launch the game, selling supporter accounts at a discount and giving them access to the first eventually-free game while I fixed bugs and worked on the sequel.

Two months later Captain Forever had been well received and I removed its paywall, while also releasing the next game in the series, Captain Successor. Successor is a greatly expanded version of Captain Forever with around 5x as much content. Early the next year I released the next title, Captain Impostor. This time I opted to shift the design rather than building on it, creating a new mode where instead of building your ship you would clone the designs of other ships around you. This forced the player to pilot a much more diverse collection of ships than they would usually build for themselves, but also strayed a long way from the original game’s appeal.

What Went Right

Core Design

The destroy-build loop turned out to be as compelling as I’d hoped, and the rest of the design fell into place with very little effort. Dragging and dropping modules to build a ship was intuitive, and for the most part the player was able to draw on experience from other games to determine how Captain Forever would work. Since the game applied nearly constant pressure on the player they were rarely stuck wondering what their goal should be, and instead set to work surviving and thereby pushing the upgrade hamster wheel around.

Since Captain Forever launched before the recent deluge of sandbox construction games the core design also offered something relatively new and unique to many players.

Working Solo

Working without a team has a lot of advantages. For example, I didn’t need to build tools for designers and artists to add and edit gameplay data and assets. Nearly everything was hardcoded, with formulae taking the place of data tables and ship-module-specific render code creating my animations. This meant I also didn’t have to worry about process and tool documentation, or file versioning. Speaking of versioning…

…I didn’t use a version control system. Every few days I’d zip up my project directory and copy it to an offsite server or flash drive, but that was pretty much it. This meant no check-in step, no binary file locks, and no merge conflicts. Sure it was also a little risky, but I found flying without source control quite liberating. Heck, in my earlier solo projects I would write all the gameplay code in a single source file, and if flash had allowed me to do that for Captain Forever I probably would have. Working without source control could easily have backfired and landed in the What Went Wrong list, but there were no substantial hiccups and this simply saved me a bunch of time.

Interesting Things

I’m easily distracted, and often run off on a tangent to implement some cool new unscheduled idea. On the flip side, if I’m struggling to implement something I can often gather momentum by finding a way to make that feature interesting. For example, I spent a few frustrating days digging through sample libraries in search of the perfect laser sound. I was trying to create a realistic audioscape, however lasers aren’t known to make any particular sound, and the classic PEW PEW videogame chirps were exactly the sort of thing I wanted to avoid. Making no progress whatsoever, I decided to try applying an envelope to a constantly running loop instead of firing off individual samples. This led me to experiment with more interesting loops, and eventually I shipped with a heavily filtered chorale phrase, pitch shifted for the four different laser bolt types. This produced a melody determined by the rates of fire and types of lasers you had attached, and the “singing lasers” became a point of interest for players and media to talk about.

Similarly I added things like the Remote Pilot Projection System, which projected your webcam footage back on screen and lit it in response to game events as if it were your pilot’s reflection, an embarrassingly lo-fi realtime voice synthesizer, and a help file in the form of a flight manual. In each case, making the task interesting helped me out of a rut, filled the game with a little more love, and gave people something to talk about.

Visibility 

I released the free game in-browser, which had a huge impact on awareness. At the time you could expect ~10x as many people to play a browser game compared to a downloadable demo. I suspect this strategy would be less effective now as people tend to stick to social streams and game portals, but it may still be effective.

The ship sharing system also brought eyeballs to the game. During a late playtesting round on an IRC channel I saw a lot of people sharing screenshots so as to show each other what they had built. Building on this idea, I added a system whereby you could export your ship to a URL, and anyone who clicked on that URL would get to fly your ship. Although this wasn’t the ideal way to introduce someone to the game it did help people show off their creations, and in turn created a significant amount of interest in the game.

I think it would probably be remiss of me not to mention that having some reputation as an indie developer probably helped a lot, as did releasing back when there were far fewer games in the market. I have no idea how people sell games today. It’s terrifying.

What Went Wrong

Sales Model

A few years ago a friend introduced me to two of his students, who gleefully boasted that they were the biggest Captain Forever fans. Neither of them were paid supporters. Although the free game was successful in bringing attention to the series it was also a complete experience, and so there was no natural point for players to transition from it into the rest of the series. Lots of people loved the core game, but very few people bought the series, and a surprising number of Captain Forever players were not even aware that the other games existed. I suspect another issues was that the value of the other games was hard to communicate – they looked more or less the same, and promised similar gameplay. There wasn’t enough reason to buy.

Pre-launching the series may also have been a mistake, as it confused messaging about what would be free and what was for sale. I even read news posts erroneously explaining that the entire series would eventually be given away for free, which was never my plan. Add to that the fact that the first game in the series shared its name with the series overall, and you find yourself with a very confused player base.

Finally, building a series was less successful than I had hoped. I had expected that the series would grow in popularity, figuring if there are many games in a series then that suggests the product was worth building into a franchise. But no, the sales bump from each successive release was smaller than the last, I suspect as a result of waning interest in a not hugely dissimilar series of games.

No Standalone Build

Who wants to buy a game to play in their browser? Nobody, apparently. Web games get a bad rap, and are expected to be free and insubstantial since so many of them are. As a result few people will pay to play them.

Although I’ve always planned to release standalone versions of the games I’ve been held back by platform issues. The first three games all use flash’s software renderer, and this scales up to fullscreen resolution very, very badly. CPU speeds have improved over the past five years, but monitor resolutions have also gone up, and it’s still impossible for modest hardware to play a Captain Forever game at 60Hz, 1920×1080. Given how simple the visuals appear this just isn’t acceptable for a commercial release, and so for now these games have remained in-browser. Since the release of Stage3d I have been working on hardware rendering for the series, but that is outside the scope of this article.

Insufficient Playtesting

A downside to working solo is that there’s nobody around to share a perspective from outside your head. Working from home meant few opportunities for over-the-shoulder playtesting, and I ended up launching a game that some people just didn’t understand how to play. Most people simply don’t read the pause/instructions screen, or the scrolling help text, or the flight manual, which seems obvious to me now but came as a surprise at the time. Sometime after pre-launching Forever I added a contextual prompt system, which would detect various issues players had with playing the game and try to nudge them in the right direction with a text box in the middle of the screen. It’s not an elegant solution but it was the best I could do at the time.

What Went Next

In early 2010 sales declined drastically, and I decided to go all out and build the giant capstone game that would either make or break the series. Captain Jameson, as it was called at the time, would be a modern take on Elite within the Captain Forever universe, and it would be finished in December that year. Except it wasn’t. In part II of this post-mid-something-mortem I’ll share the great tales of how the design lost its way, found its way, dragged on, and eventually – miraculously – came back to life as The Dawn Star, alongside the very excellent offshoot game Captain Forever Remix. Did I mention that Captain Forever Remix is now in Early Access? And did I mention that it’s very excellent? I’m allowed to say that Captain Forever Remix is very excellent because I didn’t make it myself. Regardless, it is very excellent. You should check it out while I write part II of this article. Enjoy!



Related Jobs

Endnight Games Ltd
Endnight Games Ltd — Vancouver, British Columbia, Canada
[09.18.18]

Senior Programmer (Generalist)
Wombat Studio
Wombat Studio — Silicon Valley, California, United States
[09.18.18]

Backend Engineer
Wombat Studio
Wombat Studio — Silicon Valley, California, United States
[09.18.18]

Graphics Engineer
Obsidian Entertainment
Obsidian Entertainment — Irvine, California, United States
[09.18.18]

Engine Programmer









Loading Comments

loader image