Category Archives: Design

About 2½ years ago, I started a new job that limited how much I could work on independent projects (let me tell you, not a fan of policies like this). Still, rules are rules and Voyager, along with my other projects, was put on ice. It was in fine shape at the time, so there didn’t seem to be any harm in leaving it in cruise control.

About 2½ months ago, everything had changed. I was my own boss and beginning the Latin American leg of our journey. BuildDown had shipped, other projects still too green to talk about, and I was looking for a quick win. Voyager was an obvious choice. Problems that had trickled in while I was hands-off grew larger and more serious. The solutions were relatively straightforward… they just needed doing. There were also neat ideas I’d been sitting on for years that I regretted not having in there. A little bit of love would go a long way, so my course was clear: I was going to turn around an update to Voyager, and I was going to do it fast.

Part 2 of a discussion of game design decisions made for BuildDown. Part 1 is here.

BuildDown is a simple, action-oriented game, which made it somewhat challenging to figure out how to monetize. There are no levels, so I can’t exactly sell more content. The mechanics are not friendly to puzzles to force such a content model, either. Instead, I had to weigh the various popular approaches to see which played best to the strengths of the game.Continue reading

Part 1 of a discussion of game design decisions made for BuildDown. Part 2 is here.

One of the first projects I wanted to tackle on the road was to revisit BuildDown, the first game I ever released. I thought it would be relatively easy to rewrite in Unity and have access to the broader mobile market. But there was another reason; the original was something I was proud of, but I always felt like I had left something on the table. Rebuilding it on a new platform was an opportunity to reinvent it, both in game design and software architecture, and to exercise and refine those muscles for future projects.

The basic premise of the game is to merge blocks of the same color into new blocks, which can in turn be merged until they reach an inert state and cannot be merged any further.

Those inert blocks must be lined up along the bottom row to make them disappear.

There’s something I find really compelling about this core mechanic. It combines the pleasure of addictive and soothing micro-tasks (“mindless” repetitive actions, like popping bubble wrap), with the basic human propensity for organizing or tidying up: creating order from chaos, satisfaction with a job well-done, and things fitting perfectly into things.

Global Game Jam 2014. It’s late Saturday night, on the eve of our home stretch. My team was well ahead of schedule. We’d gone with an unusual project, a card game, so we’d been playtesting in no time, working well together all weekend and making great progress. Many hands make light work, and with ten people on our team, work was plenty light.

But with everything going so smoothly, it was almost as if I was missing out on the real jam experience. Looking around at the other teams struggling to finish, I almost felt… guilty. So, I decided to up the challenge for myself a bit. As the clock rolled over midnight – less than a day to go – I popped open Unity and started working on a second game, this time on my own.

A while back I had an idea for a game about launching rockets. Way out of my comfort zone, right? Basically it would be a blend of the engineering and rocket building of Kerbal Space Program, but with a greater emphasis on moment-to-moment skill instead of meticulous planning. I took about a day to prototype the idea, and while I’m not sure if I’m going to do something with it in the future, I did find myself spending a lot more time playing with it than I did building it!

[unfortunately, the Unity Webplayer has been sunsetted, so this demo is no longer available]

Directions: Hold mouse button down to thrust, release to separate stage. Hold down A or D to steer left or right. Reset with Esc.

While the implementation was extremely basic, it was effective at proving the idea and teaching me some interesting things that might be useful later.

Voyager is a game is about science. Not just in the “you’re launching a space probe” sense, but in that the core loop is about experimentation. Make a hypothesis (I need to launch at about 45°), perform the test (3, 2, 1… LIFTOFF), observe the result (missed wide right!), refine the hypothesis (let’s try 30° next time). It took a long time to figure out how to make this process feel natural and intuitive.

In order for it to work, the game needed three things:

Feedback: I need to be able to tell how my current aim differs from my last aim.

Determinability: If I do the same thing two different times, I should get the same result both times.

Precision: I should be able to execute the move as I intended. If I try to launch at an angle of 19°, I should not accidentally launch at 20° or 18° instead.

Solving feedback was the easiest part. The aiming mechanism is very explicit, with an arrow showing the direction and relative power the probe will launch in. Previous launches are shown as dimmer arrows, so the player can easily line up a similar shot and tell how their new one differs. It also straight up tells the user the angle and power of their shot in text, so the values can be written down and reused later. And finally, in-flight probes leave a trail of breadcrumbs, so it’s easy to tell when and how a trajectory diverges from an older one.

This year was my second time participating in the Global Game Jam, and my third 48-hour jam overall. Along that storied history, I’ve learned a few things about how to be an effective and successful (defined here as ending the jam with a playable prototype that isn’t embarrassing for something made in a weekend) jammer. Here are some of those learnings, distilled into handy, categorized-tip form.

What’s included? Mostly UI and UX improvements: stuff to improve the overall play experience. First up, mission sets now display completion percent with a new progress meter. Earn gold with two stars on every mission for a perfect score!

We got rid of the need to visit a sub-menu to select an alternative probe – now you can just swipe side-to-side on the title menu to switch. There’s also a brand new bonus probe: Mariner 2, the first successful planetary flyby and great-grandfather of the Voyager missions, is free for anyone who rates (or re-rates) the game!

On the title menu, there are links to our Facebook and Twitter profiles (please like and/or follow Rumor Games!). Finally, swipe sensitivity has been bumped up in all menus, and the touch target are bigger for small buttons – basically, a bunch of stuff to make the UI feel better and more responsive.

Most of the time, a level starts as an idea for a technique I’d like the player to learn, or a cool experience I want them to have. For instance, a gravitational slingshot is a core mechanic in the game, but at some point I’d like players to figure out how to chain multiple slingshots together to get past several obstacles. I also like the idea of weaving between planets – sort of a space slalom. So, there should be a level between learning how to do a slingshot maneuver and being expected to string them together to win where the chaining concept is introduced and presented in a fun way.

The “Gas Giants” level does just that. It features an arrangement of planets that suggests (but does not require) a winding, between-the-gates sort of trajectory. Jupiter blocks a direct route to the target Uranus, and Saturn gets in the way of a simple slingshot around Jupiter on the right-hand side. Once I’ve got the general arrangement of planets figured out, it’s time to run the Path Predictor.

Path Predictor is one of the more important tools in my design arsenal. It simulates the trajectory for a launch, given an angle and power level (and delay, for levels with a timing element). After running it, I end up with a visualization like this.

Though it’s usually more helpful to filter out angles that result in crashes and misses and just focus on successful paths.

This view makes it clear that there are a few viable slalom trajectories, but it’s also quite easy to just bypass that experience and slingshot straight to the target. I need another way to reinforce the weaving path as something worth attempting. That’s where star placements come in.

In this level, there are a few points where the slalom trajectories intersect, providing natural, ideal locations for stars. This ensures there are multiple viable solutions. And of course, players will experiment with different power levels (or, with the “expert” controls enabled, fractional angles) that could surprise even me.

Of course, at this point the level is still far from done. It needs to be playtested for fun and difficulty before making the cut in the finished product!

Last weekend, I organized and participated in Seattle’s satellite “Dark Side of the Jam,” a space-themed game jam which the Academy of Interactive Entertainment graciously agreed to host. Our mission was to build a game (using at least one NASA asset) in just 48 hours.

Our satellite jam started at 6pm on Friday, with participants filing in until around 7:30. We kicked off the event with some inspirational words by Dan Dixon, the creator of Universe Sandbox, and then started brainstorming ideas. As more people arrived, we decided to split into two teams, but to let everyone collaborate between the two projects (especially our artists and sound designer!).

We tossed around a number of exciting and ambitious ideas, from a game about discovering exoplanets with real-world problem solving elements (along the lines of Foldit) to one about engineering your own rockets (think Kerbal Space Program).

Two projects gathered the most attention and excitement, though. One was a game about driving the Lunar Rover around to pick up your astronaut bros. The other, and the one I worked on, is called Seven Minutes to Heaven. The game is about the time delay involved in communicating with a rover on Mars. While that delay can range from a couple of minutes to nearly half an hour, the name is an allusion to Curiosity’s Seven Minutes of Terror.

The game is played by selecting commands from the control panel’s arrows to drive the rover, a camera to get a better view of the surrounding area, and the drill to take a sample from the surface. The objective is to search for elements of interest (Hydrogen, Helium, Carbon, and Oxygen) within the time limit. The amount of each element in a square is communicated through an emission spectrum. The player can cross-reference this against known spectra to make decisions about where the most productive areas to drill are. It’s a little like Minesweeper, if you had to wait a while for your moves to take effect, the numbers were in code, and you only had until the sun goes down to finish playing. Also it’s on Mars.

Because we only had 48 hours to build the entire game, some features did not make it into the finished product before the end of the jam. With more time, we would have given players specific objectives (for example, find at least 6 units of Carbon and 2 of Helium) and better explained the controls and emission spectra in-game. We also didn’t get in all the art and sound effects produced by our teammates, or have much time for testing and play balance.

Even so, I’m really proud of how complete and polished the game ended up. More than that, I had a great time getting to know and work with a bunch of awesome people.