The Kernels Paradigm - Part One
In this series of posts, I will lay out the game design paradigm I conceived early this past fall, called the “Kernels” theory. It was used as the groundwork for the creation of Cowboy Cave, the group project developed last quarter for which I served as lead. These posts are intended to be an open forum–I encourage and invite any and all to comment and criticize the paradigm; after all, the intent is to strengthen the theory, not brag about it 
The paradigm gets its name from its function: simply put, the Kernels theory states:
- The game core is derived from a defined set of single gameplay mechanics or principles, each one called a “kernel.” These kernels are intended to be simple, small, immediate, and abstract—they should be applicable to virtually any kind of game or genre. For example, the kernels used in Cowboy Cave were:
- Simplicity
- Speed
- Low-level Persistence
- Rewarding Player Individuality
- Tactical Character Construction
- These kernels form the core of the game, and are the building blocks of all fundamental mechanics.
- All complex and high-level mechanics are constructed from combinations of fundamental mechanics, using the kernels as guides.
- Through this “building block”-style mechanic creation process, the kernels persist at every level of the game and ensure both cohesiveness and flexibility of design.
I think of the Kernels theory as a recipe to produce a game that is constructed like an organism. We all learned in high school biology that cells make up tissues, tissues make up organs, and organs make up systems. That is a perfect metaphor for the Kernels paradigm (or vice versa, of course). The kernels are the cells, the low-level mechanics are the tissues and organs, and the high-level mechanics are the systems.
The Kernels theory came from playing games, as you might expect, but most notably from the work of one indie company in San Francisco, whose games embody both the substance and the appearance of the kind of games I’d like to make. That company is ThreeRings, and their top titles are Yohoho! Puzzle Pirates, and Bang! Howdy. I’ll leave the majority of the description and pitch for these games to them, and deal only with how their structure influences my design.
Puzzle Pirates (PP) is self-defined as a “MMOC”—a massively multiplayer online casual game. The entirety of the gameplay is based, at the fundamental level, on casual puzzle games. Nothing fancy, few real innovations, but just simple, effective, consistently fun puzzle games. No matter how long you play the game, at whatever level, and in whatever capacity, you are still playing casual puzzle games.
What is remarkable is the way the makers have built a rich, dynamic, engaging metagame on top of these puzzle games. PP features a fully persistent world, complete with digital economy and political structure. All puzzling is cooperative—players band together into crews and take up all the “duty stations” (each one a different type of puzzle) to crew the ship, sail it around, and attack and plunder other players’ ships. From their success with these newbie puzzles, players can upgrade their character, acquire digital wealth and status, even come to own a ship of their own, onto which they can hire other puzzlers to play with them. Advanced status unlocks advanced puzzles, including a full range of crafting puzzles that feed the virtual economy. At the highest levels of the metagame, players can own entire islands and fleets of ships that sail under their flag, and they can wage war with other commodores and governors on an ocean-size scale. It is a remarkable achievement… and all from a handful of simple puzzle games.
As it was the inspiration for the theory, let us examine Puzzle Pirates from a reverse-engineering-via-Kernels perspective. The kernels of PP can be said to be:
- Casual
- Low Cost of Entry
- Short Game Length
- Cooperative Team Play
- Multi-level Persistence
In PP, the puzzles are the fundamental mechanics, obviously, and every puzzle is built directly on these principles. Each puzzle is casual, as in it is easy learn and quick to master… more or less. Obviously puzzle games come more easily to some than others, but it is much easier to master a “Match 3 Colors” pattern than, say, Civilization. Each puzzle has a low cost of entry, meaning it can be played and enjoyed without proportion to how long the player has been playing PP. Each puzzle is short—very important in a casual game! Players can come and go as they please, committing however much or little time they choose. Each puzzle is cooperative—not each instance of the puzzle, naturally, but there are no puzzles that are designed to be played by a solo pirate. All puzzles in the game fit into some sort of team framework, where players play puzzles in tandem as part of a collective effort. And of course, each puzzle has some low-level persistence, in this case a “reputation” system that tracks your performance over time at that particular puzzle and awards your pirate a persistent rank based on your ability.
The next level of mechanics includes team play and mid-level persistence. Players puzzle as part of a crew on board a ship, and the collective efforts of all the puzzlers on the ship result in the success or failure of the raids that ship makes. Since this system is built directly on the puzzles, it is also indirectly built on the kernels. Things like the advanced duty stations (advanced, unlockable puzzles), customizing and improving your appearance and your house, joining a crew (i.e. guild), even owning your own ship and recruiting newbies to sail with you—these semi-complex mechanics are in service to the fundamental mechanics (the puzzles) and in a range defined by the kernels: they maintain their speed, their approachability, their ease of use, their emphasis on teamwork and cooperation, and their persistence. In some cases they are simply combinations of puzzles, as in the case of team puzzling as part of a ship’s crew. Some may not directly implement the kernels, and that’s ok: because they are built on and around the fundamental mechanics, they are formed to fit a kernels-driven design core. Thus, the kernels persist, strengthening and solidifying the whole design architecture.
Puzzle Pirates was not designed with the Kernels theory (though I think it’s clear it’s the product of a similar philosophy), so I’ll leave the example here and let you make up your own mind. In the next couple sections of this discussion, I’ll be relating Kernels to the Agile and Cerny methods of design. I hope to show how Kernels can fit into any production method and work well. After that, I’ll try to put my money where my mouth is and set up a small example design process, detailed and explained from start to finish. As always, I invite people to respond and criticize (kindly, please :)) at their leisure. Thanks, and watch this space!
Interesting!
This sort of applies, but in a slightly different way, to what I was going to eventually write about the development process of a sport me and some friends invented back when I was in high school (and, as it was several years before I had a specific interest in game development/design as a career, the game wasn’t made with any specific design methodology in mind)
The methodology that instead evolved over the course of the sport’s iterations is not unlike your kernels method.
However, it was like your methodology but almost backwards. It differed highly as my sport started out with no kernels, and whenever an iteration needed to be designed, a precedent (kernel) may then be set.
This difference lead to the interesting phenomena of kernels evolving, producing OTHER kernels.
As they evolved naturally, the kernels never conflicted with one another, or earlier parts of the game, either.
Granted, for professional game development - your method is likely better. You know - when real money is on the line.
It is indeed a powerful sounding tool for designers to codify the experience of the final game.
And given Cowboy Cave’s success (congrats again on the postmortem article up on gamecareerguide, btw!) clearly there’s something to your kernels method.
That said, you might want to keep your mind open to this kernel creation on-the-fly / evolutionary kernel type stuff for more experimental projects, as honestly, it lead to some of wackier, most fun, and noteworthy elements of our sport.
Creating them on the fly may be more risky, but has its own brand of dynamic qualities and flexibility.
When I do write up the article on the development of this sport for my (still upcoming) blog, I’ll link you to it, if interested.
An excellent point! What you describe sounds very much like the philosophy of the Cerny method—just go and try it out and see what works. Pure experimentation, which is very cool and can lead to some spectacular results. To that end, I don’t see the kernels method as being separate and exclusive from experimental game design. Kernels can be anything, including abstract concepts like “Colorful” and “Tense.” With broader, more ideological kernels driving your project, you can still strike out onto unexplored paths and search for that wacky, unheard-of nugget of fun, while still traveling in the general direction of the game you want to make. I’ll talk more about this in Part Two, so look for that, and thanks for the critique
[…] I read the post I was put in mind of the Kernels paradigm I developed last quarter. The Kernels theory holds that single, self-contained “seeding […]