Joe Osborn

A designmaker and codemaker, Joe hopes to invent new ways for games to bring people together.

  1. crystal

    Crystal

    Previsualization and blocking for the G-Speak gestural interface.

    Ken Huffman, Joe Osborn, Damon Stea, Andy Uehara, Laura Yilmaz

  2. cyclyc

    CyclyC

    "Try your best for maximum best!"

    Teddy Diefenbach, Joe Osborn, Mike Sennott, Samantha Vick

  3. dearmoon

    Dear Moon

    One-button lunar guardianship of an imperiled tree.

    Teddy Diefenbach, Kyla Gorman, Joe Osborn, Mike Sennott

  4. dng

    Dungeoneering

    One game! One pen! One controller! Two players! One screen!

    Jacob Boyle, Joe Osborn, Dai Yun

  5. Ensemble Logo

    Ensemble

    Formalized, integrated backstories for game characters.

    Joe Osborn, Mike Sennott

  6. mix

    MixUpp

    Multitouch audio mixing on the Microsoft Surface. Funded by an Annenberg Fellowship.

    Joe Osborn

  7. ff

    The FILTH and the FURY!!

    New Music Journalism in old Narciso Catastrophe.

    David Mershon, Joe Osborn

  8. stamp-transparent

    Vikingr

    A Viking lifestyle simulator; an asynchronous social game on iOS.

    Joe Osborn

2011/06/11

Vikingr: A game about medieval accountants?

Filed under: Vikingr — Tags: , @ 21:39

Originally, I designed Vikingr as a sort of “Viking Wars”—a turn-based, asynchronous social game in the vein of BBS or text-heavy web games (e.g. Legend of the Red Dragon, Archmage) or, more recently, hybridized graphical games like Mafia Wars. This would progress at a pace of one year per day, granting players 52 turns per day, and subject characters to the ravages of age and permanent death so that players would move on to a new character roughly once per month. I would also introduce additional limitations to emphasize the quotidian nature of most of Viking life: For example, raiding and long-distance trade expeditions had to be conducted when little could be done at home, so activities like farming would be performed during springtime turns and the expeditions would take place in summer.

My goal was to take the above, sprinkle in some social mechanics, and play up the fact that everyone was contributing to one massive shared history with their gameplay actions. By giving players a little context for these histories, we could be off to the races with a novel web-game that doesn’t just permit player-generated stories to emerge but acknowledges them and incorporates them into its gameplay.

Unfortunately for me, when I started prototyping all this—a website, a server in my programming language of choice, a bunch of equations and formulae, decisions made for scalability’s sake, research into hosting and APIs and this and that, lists of features to implement—I realized that I was thinking like an engineer, not a game designer. So I went to paper and did a sort of simulation RPG about budgeting one’s time between preparing for raids and going on them. This felt far more like accountancy or event planning than viking, so it forced me to reexamine my base assumptions.

Ultimately, I came to an inescapable conclusion: “Take a new technology and apply it to an existing genre in an uncommon fictional context” is an incremental way of thinking. There’s a time and a place for incremental improvement, but a 12-month MFA thesis is emphatically not it. So I went back to the drawing board: If I wanted players to create and share stories about being Vikings (and to use my game and my technology to do it), what must I help them to feel? The answer to that had to merge historical reality with literary fantasy.

2011/06/10

Acknowledging Player-Generated Stories

Filed under: Ensemble,Vikingr — Tags: , @ 21:26

The specific social, combat, and economic mechanics at the core of Vikingr were all selected for their narratively interesting and universal nature as well as their appearance in source materials such as the Icelandic family sagas. Rather than merely adapt, say, Njálssaga to a video game, I wanted to capture the rules and systems that were behind all of the sagas of the Icelanders. My process involves going through the sagas, identifying patterns that recur across a variety of stories, and formalizing them in such a way that a computer could identify them in gameplay terms.

Initially, I thought that teaching Vikingr to comprehend these half-mechanical, half-narrative concepts was a necessary step on the way to a holy grail: the generation of new story content based on player-character backgrounds and histories. After my first round of prototypes, I have realized that the key thing is not generating new randomized content from templates and Bayesian belief networks—it’s simply recognizing and acknowledging the narrative freight with which players load their characters and play sessions. Some of this can be specified a priori (players can customize a Viking’s appearance, or assert that a particular family member had an earlier career as a brewer), and some can be easily inferred based on a player’s habits (a Viking who never wears a shield can be labeled with the title “The Reckless”; two Vikings that always travel together can be hit with performance penalties when separated).

Quests and achievements are both powerful tools for maintaining player engagement. I suspect that this is because the former express narrative events in terms of game events and the latter transform game events into tellable narrative accomplishments. Vikingr represents two main advances beyond these mechanisms: first, its equivalent of “achievements” are reintegrated into the game design, providing concrete player outcomes (either mechanical or aesthetic) besides sitting in a list in a menu somewhere; second, the game can examine a player’s activity and automatically provide a relevant “quest”-like structure that is in keeping or in competition with the inferred goals of the player. This would benefit from an example.

Let’s say that game-year after game-year, the player does not go on any Viking raids and instead farms and hunts year-round. The game might notice this and perform the following actions:

  1. First, acknowledge his intentions by calling him a “farmer” and giving him a boost to production and perhaps a deficit to combat skills;
  2. Second, encourage him to diversify by exerting pressure on these food supplies: freeloading relatives could come by and demand hospitality, for example. Refusing to provide it could lead to a new title: “stingy”.

To sum up:

  1. Ensemble permits the storage of complex relationships and data at an arbitrary level of detail and specificity;
  2. Vikingr employs the data from (1) to calculate and administer “achievements” based on game-inferred and player-specified goals, recognizing the stories players carry in their heads (all this according to an extensible suite of designer-provided rules);
  3. Vikingr may then trigger simple quests to encourage or discourage player behaviors based on (2). In a sense, this represents a move from a “quest tree” to a “quest forest”, with context-appropriate objectives for players’ personal goals (and an emphasis on socially-motivated quests rather than pre-authored narrative dumps).

Vikingr does not attack problems of text or story generation. Instead, it primes players to interpret possibly-unrelated game events as related ones by recognizing just enough of their intention and input to suggest that connections are the norm rather than the exception. It should provide experiences that vary widely between players, since content is recombined based on player activity decoupled from game progress. The real “content” of this game consists of rules for recognizing player intentions, player-specifiable goals, and triggered quests, narrative, and game events.

About Vikingr

Filed under: Vikingr — Tags: , @ 10:55

At one point, I had planned to produce several games for my thesis to conduct a few experiments about the Ensemble computer-aided storytelling system. In the interest of providing a more complete experience and having a stronger presentation at the winter and summer shows, however, I chose to focus on a single project. To validate the hypothesis that Ensemble is worth designing around, Vikingr will be tested in two variants: One with a direct causal relationship via the Ensemble system between gameplay and narrative outcomes, and one with a weaker or even arbitrary link between the two.

So, what is Vikingr? The word is from Old Norse and means what you’d expect: a raider of the Viking sort. The topic has always interested me—not in a Wagnerian noble savage way, and certainly not in a video game-y mead-drinking hammer-swinging barbarian way—especially since learning that viking is an activity; used as a noun (vikingr) it means “someone who viks”. It denotes a profession, not an ethnic group, and a part-time profession at that: viking is a get-rich-quick scheme, a way to raid or trade in far-off markets to boost one’s income and prestige while waiting for the crops to grow in early summer or mid-fall.

Vikingr is a narrative-driven social game where players compete to accumulate wealth and renown by farming, crafting, trading and raiding. Players form bonds with each other through marriage, the fostering of children, and exchanges of gifts, and such alliances represent important obligations. Players may opt to provide additional narrative details about their characters using Ensemble, and these will be merged with the narrative facts and events that emerge during play—for example, a character who frequently tells stories to entertain guests at parties may be considered a skald, a sort of poet; another who is skilled at battle could be called “war-wise”; a Viking skilled at both would earn the title “warrior-poet”.

This emphasis on the individuality of specific player-controlled characters is an attempt to evoke the so-called X-Com Effect, where randomly-generated characters can become narratively significant to the player due to small differences in appearance and statistics and the player’s personal history with using those characters. Vikingr hopes to go even further by systematically recognizing these gameplay histories (and thus the likely player-defined goals and stories behind these characters) using an achievements-like mechanism that feeds back into further aesthetic and game-mechanical systems.

2011/03/06

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.

« Newer PostsOlder Posts »