The Rules of Programming

Conclusion: Making the Rules Your Own

The Rules, as I’ve laid them out in this book, distill the lessons we’ve learned at Sucker Punch over the quarter-century of its existence. They’re specific to our experience. They reflect the things that we think are important—our programming culture. And that programming culture reflects the specific constraints and characteristics of creating the sorts of video games that Sucker Punch makes.

You’ve read a lot of Rules at this point. I’d guess that you immediately saw how some of the Rules apply to the work you do, while others feel more loosely connected to your experience. That’s not a surprise! If the programming work you do is radically different from the work we do, then some of our Rules may not make sense for you.

So what makes writing video games like ours different—and how does that affect the Rules?

• First of all, our projects are long. Our last game, Ghost of Tsushima, took about six years to create. And we weren’t starting from scratch—most of the code in Ghost is an evolution (or just a direct copy) of code that ran in earlier Sucker Punch games. We place a premium on long-term code quality because we have to—the code we write today has a good chance of still running ten years from now.

• The coding team is big, with 30-odd full-time coders currently on staff. Depending on your own situation, that may seem tiny or huge. Personally, I’d define a “small” programming team as one where one person can know all the details of all ...