We intend to create a world where everyone will enjoy our games without exception.


Redesigning Vikingr

Filed under: Vikingr — Tags: , , , @ 16:59

Today, I changed the project description on Vikingr!. These alterations to the project’s mission occurred in the week before the winter show, and they go deep. Months of local optimization on the problem of making a fun game about Vikings had failed to produce an enjoyable experience, so at my wife’s behest I undertook a challenge: Use this final week to start from scratch and make something enjoyable that addressed the whole scope of Viking life.

I’m very glad I did. I threw out the notion of producing a “Dwarf Fortress, but with Vikings and social play” and focused on moment-to-moment pleasures: busy hands in home life (no more setting up situations and waiting for things to happen), sailing with multitouch controls, raiding without complex strategy and micromanagement. I went to a side view with simple sprites (except for the Mode 7-style sailing, inspired by Final Fantasy VI) rather than the isometric projection. I switched to Unity3D so I could get things going quickly and discourage myself from over-reliance on native user interface elements (or, indeed, from fiddling with them to no end). These changes dramatically improved my project’s forward velocity, people enjoyed playing my game more, and I was in a better position to put more social interactions into gameplay.

It seems counter-intuitive that moving towards simple and superficial could make the rich social exchanges I had hoped for more feasible, but it boiled down to the observation my wife had made: If I had spent six months working on home life and farming in such exquisite(-ly boring) detail, there were simply not enough months until May to do the same for sailing, raiding, and social life. I had over-modeled one portion of my game—and not even the important portion, at that! Now that my world signals simplicity, I can employ much simpler types of social exchange without causing inconsistencies in player experience.

So, that’s where Vikingr stands right now. I am currently fleshing it out and extending it with additional social exchanges—not trying to cram sociality into an asocial design.


GDC 2011: Confirming the New Dumb Hypothesis

Filed under: Thoughts — Tags: , @ 20:59

GDC 2011: This past week, a sizable (though sadly incomplete) contingent of Universal Happymakers spread their probing tendrils into the warm light of the Game Developers’ Conference. Each of us saw our own successes, had our own stumbles, and learned our own lessons. This series explores the Happymakers’ reactions to this peerless event.

The New Dumb philosophy came out of the Happymakers’ own experiences in making games. While the advice seems obvious—to focus on player experience rather than simulation fidelity, to favor selective visibility of internal systems over hidden complexity—it can prove hard to follow in practice as one’s specialist and perfectionist instincts override the simple desire to make a fun game. At this GDC, we took heart when we learned that the problems we cited may be nearly universal among independent game developers. Therefore, one at a time, we take the main concepts of The New Dumb and see how they were affirmed during the past week. We also add two new features to New Dumb Theory: Sennott’s Corollary (that the love put into making a game has little to do with the love perceived by a game player) and a warning against design by default (seeing a game as a set of features to be implemented).

The problem of motivation was a major theme in this year’s GDC talks. Spyeart’s Michael Todd bravely explored the problem of depression for game designers, and offered concrete advice to avoid the death spiral of dwindling productivity and depression: to get straight to gameplay, to avoid perfectionism, and to work on games that were playable progressively (mechanics building atop one another) rather than in the gestalt (requiring nearly all rules and systems in place before playtesting). In Todd’s view, one must build as much of the game as possible during the brief period of intense passion for the idea. Andy Schatz (Pocketwatch Games) prototyped Monaco as an attempt to recover his dwindling motivation for a different project, and maintained his interest in Monaco by implementing one cool thing every day, avoiding features that took more than a day, and ensuring that every day ended with a playable build.

Front-to-back design is a core tenet of the New Dumb, and has its roots as far back as Crawford’s First Law of Game Design (“What does the player do?”). Schatz also considered this concept and selected how best to apply his limited resources: rather than aim for visual realism (and approach the uncanny valley), he chose to use extremely realistic recorded audio for the game’s sound effects. This gave him an immersive benefit at an extremely low cost, showing that front-to-back design doesn’t only apply to programming problems. Patrick Redding (of Ubisoft Montreal) mentioned how Splinter Cell: Conviction‘s multiplayer maps were lit in reverse order to its single-player ones, beginning with designer-placed light areas and ending with artist-refined diegetic lighting.

Two concepts that saw little specific treatment at GDC were the myth of replayability and content is important. This may have been a function of the specific talks I attended and the speakers I heard, but just because they were not mentioned does not mean that they are not real.

A difficult thing for a programmer to learn is that a game is not its source code. At least four talks specifically cited the danger of a programmer’s mindset in game development. Chris Hecker (designer of Spy Party, in his speech at the Failure Sessions) described five years of technological ratholing for a mountain-climbing game, burying his nose in research and development on constraint solvers, integrators, physics models, tech demos, and the like, without contributing to gameplay in any way. His new policy is that any new feature must be playable on the same day. Brian Provinciano (VBLANK Entertainment), in the same session, spoke of his seven years of development on Retro City Rampage and its predecessor, an NES demake of Grand Theft Auto 3. He built a macro assembler, a custom NES development kit, and a huge variety of tools, but none of it took him closer to making a fun game. Peter Molyneux re-contextualized Populous as a series of workarounds for poor technical ability: the raising and lowering of terrain was a way around shoddy pathfinding, the transforming of characters on flat land into buildings was a way to relieve strain on slow AI code, and the papal magnet that drew followers to specific locations was implemented instead of improving the AI agents’ cleverness! Radiangames’ Luke Schneider, who worked at a pace of a game per month, suggested that we “build games, not engines” and never to start from scratch—going so far as to copy and paste the past month’s game code when starting a new project.

Two related ideas inhabit the feedback loop between player and game: Games should be dumber than people and show your work. Dajana Dimovska (Knapnok Games) and the Copenhagen Game Collective of which she is a part leveraged people as adjudicators and input devices for their social games like IGF nominee B.U.T.T.O.N. Will Wright supported the latter point by confessing that Raid on Bungeling Bay‘s inner simulation—an AI-driven resource acquisition and defense construction cycle that formed the game’s progressive difficulty system—was invisible and unknowable to basically any player. This was a mistake he would not repeat with data-visualization-rich SimCity and The Sims.

Game jams are a central aspect of New Dumb’s suggestion to adopt more constraints. Needless to say, they are quite popular with independent game developers, with Kyle Pulver (of Retro Affect) agitating for the two-hour game jam as a crucible of extreme pressure and constraints leading to fearless creativity, and Chris DeLeon encouraging developers to “game jam outside of Game Jams”—to explore, rather than to impress.

Of the two new elements to New Dumb Theory emerging from this Game Developers’ Conference, Sennott’s Corollary is the most painful: The sense of love engendered by playing a game bears no relationship to the actual love and tears put into developing a game. This was hinted at in several talks, but phrased most clearly by Schatz’s advice that everything put into a game should make it feel more awesome. This was reinforced during the keynote, when Satoru Iwata (president of Nintendo) said that a game’s “central appeal must be immediately visible”. This is an important metric related to front-to-back design, but deserves its own entry for its intense emotional risks.

Finally, many developers—especially those from a programming background—warned against the abdication of game design responsibility. This may best be put as the maxim don’t design by default. Chris DeLeon forbade designers from using existing genres or game references when describing their designs to other people; Michael Todd encouraged them to design games for their own abilities and interests. Games are not merely bullet-pointed feature lists: 2D Boy’s Kyle Gray, Flashbang’s Matthew Wegner, and the aforementioned Chris Hecker and Brian Provinciano all had horror stories of months and years wasted going through the motions of game development without original ideas: art flair in place of long-term gameplay; “HD” as a way to make a game more, but not better; years spent in R&D for games that weren’t fun in the first place (avoidable if these designers had built prototypes instead of products). Technology development should not be a way to hide from game design! In the same vein, Andy Schatz suggested that developers avoid prototyping in engines that presume certain types of games. Will Wright also revealed how Raid on Bungeling Bay‘s map editor—technology that Wright had lying around already—morphed and mutated into SimCity. This echoes a talk that Raigan Burns (Metanet, developer of N) gave in 2008 which explained the value of controlling all of the programmatic knobs—that designers should design their own unique games from the ground up.

New Dumb as such is not a well-known theory, but the problems it approaches and the spirit it carries seem to be universal among game developers. It is our hope as Happymakers that someone might read this who feels these problems (but has been unable to specifically recognize or express them) may by understanding them begin to overcome them.

The New Dumb Manifesto

Filed under: Thoughts — Tags: @ 15:39

Late last year, three of us Happymakers developed a theory of game-making that forced us to confront our own unique problems and propensities. Our work in the past had suffered from technological ratholing, over-simulation, and other ills. We also wanted to situate this theory within a context: the early history of video games, the indies of the 1980s, the bedroom programmers. This manifesto can be seen as a companion piece to a yet-unpublished paper written by Joe that relates sculptural and painterly minimalism—specifically the viewer’s involvement in meaning-making—to procedural abstraction in games.

The New Dumb Manifesto

Or: How to Be Dumb When You Are Smart

A Helpful Lobotomy in Five Acts

David Mershon, Joe Osborn, Mike Sennott

I. Consider this Riddle of the Ages

“If a tree falls in the forest and no player sees it, did it need to fall?”

II. The Rise of the Smart

Until recently, games could not exceed a certain level of complexity. Board games, card games, and sports that rely on human arbitration needed easily comprehensible rules that could be evaluated while playing. Early digital game designers bound by primitive hardware and memory constraints faced similar limitations. Digital games in the arcade era were developed in mere months by handfuls of creators (or fewer!), and many became enduring classics.

From the early 1990s onwards, development teams ballooned to dozens, then hundreds of specialists. The aesthetic of game programming shifted, too: where programmers once had to relentlessly optimize for fun per byte, they now valued extensibility, readability, reusability, and robustness. Designers, insulated from the constraints of hardware, proposed games based on complex simulations, hiding the underlying mechanisms from players in the name of immersion. Modern games take many times longer to make, but are not many times more fun.

A strong independent game-making scene is now emerging. These small-scale creators have inherited the limitations of their 8-bit predecessors, but they often fail to see how those limitations can help them focus their efforts on what really matters. If independent game developers wish to seize the burning torch of innovation from the festering corpse of a decadent and stagnant industry, they will have to rediscover the power of the dumb.

III. The New Dumb

New Dumb is a movement to design games from the outside in. The game that the player sees and responds to is the only game that matters, and behind-the-scenes complexity is likely to be overlooked and unappreciated. The new dumb philosophy can be practiced by observing the following principles:

Front-to-back design.
Begin by thinking about inputs and outputs and do only what is necessary to connect them. Add complexity to a simulation only if player experience proves it necessary. Start with a placebo, then make a simulation.
The myth of replayability.
Ask yourself: “Will this game be played more than once?” If so, how many times? How long is each playthrough? Replayability does not always require robust simulation, and limited choices can be easier to author than generative processes. Even if replayability is a future goal, one-off prototypes can help designers avoid costly and time-consuming cul-de-sacs.
The game is not the source code.
Games should be fun to play, not to program. Don’t be afraid to write bad code. The only purpose of the program is to support the game—any aesthetics or functionality beyond that is meaningless.
Games should be dumber than people.
Paper prototyping encourages us to omit excessive complexity and be dumber: if the rules are too complex for a person to arbitrate they may be to complicated for a player to perceive.
Adopt more constraints.
Game Jams help us reclaim the helpful limitations of early digital games. They are ideal for kinesthetic games which may not respond well to paper prototyping.
Content is important.
Even a process-heavy game contains writing and potentially art and sound, and those pieces of content can be good or bad. Infinite boring content is worse than finite, interesting content.
Show your work.
Agency requires that a simulation supports a decision and that the player understands a choice is available. Emphasize the latter, not the former. Guide players from cause to effect—if a pattern is too complex, it will seem random.
IV. The Benefits of Being Dumb

Motivation has a brief half-life. From the moment she thinks of a game idea, the skeptical designer’s enthusiasm wanes. The interest of peers and early implementation successes can stave off the inevitable for a time, but one or two weeks without player feedback can turn excitement into despair. The designer is sick of her game. A half-working new economic system rendered shops useless for a week; three days of collision bugs stymied playtesting of vehicles; four days were spent writing, then throwing away a system for generating trees on-the-fly.

Smart simulations are difficult to design. Even worse: before they are finished these systems often produce nonsense or prevent the game from running. The relentless pursuit of correctness and emergence can lead a designer down a rabbit hole for days or weeks, only to throw away the system when tests show that it lacks appeal or interest for players. If our designer had hard-coded initial economic values and activities, she could have tested player responses the same day. If vehicle behaviors were not physically modeled, the collision code could be far simpler. If an artist made a few trees, the designer could have scattered them about and seen if players noticed the difference.

A New Dumb developer will make more games faster. Some will be good and some will be bad, but none will be over-engineered. Since players can only understand a game through its reactions to their inputs, players can’t easily tell if a game is dumb or smart; this is the strongest argument imaginable for writing dumber games.