Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
A Mini-Postmortem Roundup
View All     RSS
February 27, 2021
arrowPress Releases
February 27, 2021
Games Press
View All     RSS

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


A Mini-Postmortem Roundup

April 29, 2013 Article Start Previous Page 7 of 8 Next

Console: Dyad

By Shawn McGrath

Developing Dyad was a long and difficult process.

It all started when I was playing a lot of Kenta Cho games; I liked rRootage and Parsec 47, but Torus Trooper wasn't doing it for me. So Pekko Koskinen and I dithat ssected Torus Trooper, along with some other racing games, discovered a few design issues most racing games had in common, and decided to make a game that fixed those issues. We wanted to make a game that encouraged you to think tactically, instead of forcing you to rely solely on reflexes and muscle memory as the game got faster, but we didn't want to complicate the controls unnecessarily.

We figured we'd solve these problems and make Dyad in a year. We were wrong. Pekko eventually left the project, and I continued on for over three years trying to solve seemingly unsolvable problems. I worked 10-16 hours a day, six or seven days a week, for three years straight. It was worth it.

What Went Right

1. I'm Too Picky

Before making Dyad, I heard stories of Miyamoto's ability to discard months of work if it wasn't working out, and thought it'd be easy to do the same. It isn't. I threw away 90-95 percent of all the work I did on Dyad. I spent nine months on a mechanic that followed and replaced zip lines called "gates." Gates contained more variation and interesting gameplay than the rest of the game combined, but the mechanic was completely unteachable. I couldn't even teach my wife how they worked after several hours of one-on-one tutoring (and she's very good at Dyad), so I scrapped them. I created over 200 other levels, and I threw all of it away except for the very best stuff. As it is, the game is longer than I'd like, but I can't cut any more of it.

2. Doing (Almost) Everything Myself

In 2010 I showed the game to several publishers, and three showed serious interest. We negotiated getting funding and staffing up. I called it all off and decided to pay for it myself by living as cheaply as possible and draining my life savings. That way, I could make the game I wanted with as much time as I needed.

I did all the programming, game design, and graphics essentially by myself, except for some help with the PS3 version and a part-time co-designer for the first year of development. By programming my own engine, I was able to get the load times down to <1 second, and I was able to use low-level graphic effects and experiment with a wide variety of new graphics techniques. I used one monitor for Photoshop, one for code, and one for the game, which let me change the graphics and the code and see the changes instantly. Without this, I wouldn't have been able to come up with the visuals in Dyad, and without the live code update, I wouldn't have been able to test out nearly as many game design ideas.

I also did all my own promotion and advertising. This started when I built a large motorized chair ("THE MACHINE") that tilts and rotates to match the player's in-game actions, and went to PAX East in 2011 with the disassembled chair packed into my Chevy Impala. Jason DeGroot and I spent two days assembling it before I showed Dyad for the first time to a large audience with THE MACHINE. I received a lot of positive press from PAX East, so I decided at that point to do all the marketing myself. Even though it was very time-consuming I wouldn't have done it any other way.

3. Music collaboration with David Kanaga

David Kanaga really pushed what's possible with Dyad's reactive music system. We worked for four months on the first track: He was in Oakland, I was in Toronto. He'd send me stems of the song he made for the level, complete with chord changes and interaction event sounds, and he'd explain to me how he wanted it mixed and how different game elements should change the mix. I'd send him a video of me playing the game with his system. We did this back and forth for four months until he was able to fly out to Toronto where we worked on the first 15 levels or so. He went back to Oakland, this time with a computer capable of playing the game, and sketched out the final 12 levels, then came back to Toronto to finish everything.

Most people don't believe me when I tell them the music was added last in the game. The game was essentially done with no music, and David was able to create unique music rules for each level to match the game rules, and write 27 unique songs! 

Article Start Previous Page 7 of 8 Next

Related Jobs

Bitwise Alchemy
Bitwise Alchemy — Austin, Texas, United States

Senior Software Engineer (Remote)
DigiPen Institute of Technology
DigiPen Institute of Technology — Redmond, Washington, United States

Curriculum Developer in Visual Effects for Real-Time Engines
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Tools and Pipeline Programmer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Senior or Lead Tools and Engine Programmer

Loading Comments

loader image