Archive for the ‘Lost Garden’ Category

Bunni Sneak Peek

I had an immensely good time collaborating with Andre on Fishing Girl earlier this year.  He was looking for a new project and so we started idly chatting about random ideas. One thing led to another and he is now nearing the finish line on a new Flash game called Bunni.  I thought Andre might enjoy a little bit of public encouragement as he enters the final stretch.  
I’ve been wracking my brain and I don’t know of another game out there that is quite like Bunni.  Imagine if Animal Crossing had a long lost mutant sibling that coalesced out of a creative flurry in a mere four months.  There is no clever twist on shooting, block stacking, or 2D platforming. It is not an innovative music game.  Nor does it involve playing with time or bizarro spacial dimensions.  If there are any puzzles, I apologize since they weren’t intentional. In fact, it isn’t a very hard game. I’ve yet to find a single hidden object, probably because there aren’t any.  Despite lacking all these critical things, play tests end up lasting for hours. 
I don’t want to give away too much about the game, but I can share a single, mildly cluttered screen shot.  Yes, that is a pirate bunni.  And no you can’t have one unless you are very, very special. 
Bunni: First Screenshot. Likely to change in inexplicable ways. 
Oh, and as a bonus, here are some t-shirt designs. Let me know which ones you like the best.  (I tossed together a storefront as well just for fun.  The internet is so awesome.)
Broken Hearted
Bounce
In Love
Long road to love
take care
Danc. 

Go to Source

Game design in 2020

My short essay on future games was selected to be part of the recent Gamasutra ‘Games of 2020′ feature. The treatment is tongue in cheek and I owe anyone I photoshopped a free beer.
You can read the whole thing here:
The result of all this is that I am now able to attend this year’s GDC. If anyone wants to meet up in San Franciso (March 23rd to March 27th), drop me a note at danc [at] lostgarden [dot] com.
take care
Danc.

Go to Source

Danc’s Miraculously Flexible Game Prototyping Graphics for Small Worlds

Don’t you think it is time for some new free graphics?

The originals
The original set of miraculously flexible prototyping graphics have been out there for a couple of years now. In that time, they’ve been used in mini-MMO’s, shooters, RPGs, platformers and dozens of various projects that lurk in the dark squishy nooks of the ever fermenting, communal indie mash.

However, they had some issues.

  • They were in a format that wasn’t readily accessible to most users. In particular Flash games didn’t make as wide a use of them as I would have liked.
  • They required a rather tricky placement system that most tile based engines had difficulty handling.
  • Very few games used the shadows system and without the shadows, they tend not to look very good.
There were also a couple other areas I wanted to explore.
  • HD pixel art: There is an emerging artistic style that showed you could keep the intricate iconic style found in pixel art, but modernize it in such a way to take advantage of the crispness found in modern high resolution displays. The result found in games like Pixel Junk Monsters, Patapon, and Loco Rocco is distinctly game art. It tends to be 2D and highly evocative. But is also is information dense and full of distinct iconic symbols that have meaning during game play. When there is a trade off between realism and functionality, functionality wins.
  • Vector art: I’ve done immense amounts of raster art over the years, but lately I’ve been playing with more vector art. The tools have gotten to the point where you can do some pretty nice stuff rather rapidly without needing to ever go to bitmaps. They are rendered natively in Flash or Silverlight and you can play with scaling without worrying about loss of detail.
  • Arbitrary placement: Once upon a time, you needed to use little square tiles for everything. Nowadays, there is no real need to make a tile based 2D engine. With arbitrary images with full alpha and lots of fill rate, you can put together a game like a sticker book. Drop down your graphics at arbitrary positions and layer like a madman. Games like Aquaria look great and tiles are nowhere to be seen. There’s a good tutorial on the topic here: http://gametuto.com/in-game-c-map-editor-tutorial-with-indielib-engine-that-dosent-use-tiles-but-pieced-images-like-in-braid-or-aquaria-games/


Small World

So I started a new graphics set that took all these into account. The theme I chose was the ‘Small World’, an intimate place of green trees and blue ocean seen from above. For ages I’ve been fascinated by tiny worlds that you could imagine keeping like a bonsai garden on a table top.

What types of games can the Small World graphics be used for?
  • Turn-based strategy games
  • Real time strategy games
  • RPG’s
  • God and Sim games
  • Tower defense (the original inspiration for this set was Pixel Junk Monsters)
  • Crazy innovative games that will shock and amaze the world.

What does the set include?

  • 70 high quality sprites
  • The original Illustrator CS4 .AI file
  • The exported Flash CS4 .FLA file
  • The exported Flash CS3 .FLA file
  • The exported Flash 10 .SWF file (with linkages)
  • Land
  • Forests
  • Buildings
  • Dialogs and buttons

Having the source files allows you to easily manipulate and edit the graphics so you can make variations or combine pieces together. You should have enough pieces to easily prototype attractive little worlds full of forests, fields and cities.

What doesn’t this set include?

  • I have some characters that fit this set, but those will be coming along at a later point.
  • I haven’t had time to cut out all the bitmaps. This is coming shortly unless someone else cuts them out first.
  • Other formats: In general there are a billion minor formats that all have their passionate proponents. Convert at will. :-)

The License
Much of the email I get involves questions about how various graphics can be used. Though I love hearing from you, it has become apparent that the license needs to be clarified so that I can spend more time making stuff for you and less time writing back about the legal issues.

A second issue is that there have been some unfortunate incidents where players have taken talented developers publicy to task for ‘stealing’ my artwork or ‘copying’ game designs. ‘Open source game designs’ are admittedly a cutting edge concept in our IP-clutching world, so there is some education to be done.

As of today, I’ve created a separate Lost Garden Licensing page that outlines the license for these graphics. If you plan on using these graphics, be sure to read it. The basics are that they are free to use in both commercial and hobby projects under a standard Creative Commons Attribution license.

The goods
So what are you waiting for?

I’ll be releasing some prototyping challenges that make use of these graphics in the future, but for now just have fun and give them a shot. They were a blast to make.

take care
Danc.

PS: I also included graphics that allow you to make arbitrarily sized islands composed of splotches of land stuck together. This is a tricky technique that only advanced users will undertake. First lay down the water. Then lay down all the Land-Bottom graphics. Then lay down all the Land-Mid graphics. Finally draw all the Land-Top graphics. By layering the graphics in this order, you can create islands that merge together visually.


Go to Source

What is your game design style?


I was about to ask a friend what sort of games she liked to make and I realized that I didn’t even know how to frame that question in an intelligent manner. I’ve noticed that games have distinct styles. These are not visual styles. Nor are they styles associated with prefered process of development. Instead, they are unique styles of game design, how you mix and match mechanics, story, player agency and feedback. What do you emphasize? What aspects of the the player’s experience do you highlight with your design choices?

A spectrum of game design styles
It is a broad topic, so I’ll just jump right in. Here are some styles that I’ve noticed. You can think of these categories as pieces of a spectrum that cover all major aspects of the final game design that the player experiences. Though they are all present, each style is emphasized to varying degrees in a particular title.

  1. Copycat: make a game like another game that is interesting.
  2. Experience: Make a distinct moment of game play that looks and feels interesting.
  3. Narrative: Make a story that is interesting
  4. World: Make a place or world that is interesting
  5. Systems: Make systems and objects that are interesting.
  6. Player Skills: Make verbs for the player that are interesting.
Let’s give a brief description of each of these styles and how I’ve seen them work.
Copycat

A copycat designer takes an existing game genre and builds a new work within it. The term ‘copycat’ is descriptive and not derisive. I personally steal with great gusto from other games and consider an elegantly pulled off theft to be an essential skill for any practicing designer.
  • Copycats borrow liberally from the best elements of past works and mix them together with minor design innovations to create the new flavor of the month.
  • If design problems arise, a good solution is often readily available in a historical product in the same genre. The best copycat designers have encyclopedic knowledge of other games in their genre.
  • The goal is almost always to make something better or ‘more correct’ than what has been on the market previously.
Most working designers are copycat designers. On the supply side, there exists a natural urge for a player who deeply loves a particular genre to attempt to do a better job. This provides a constant wellspring of new copycat designers. On the demand side, the market’s lust for sequels ensures a wide range of jobs that need good copycat designs. Helping this dynamic is the fact that it is quite easy to learn to be a copycat designer. Find a game you like and copy it. You don’t need to know theory or have a strong philosophy of design. Over many years of labor you’ll likely get quite good at making polished variations on the initial blueprint.

Limitations

  • Competition is intense. Most of the time you are fighting over market share in a crowded genre. You can avoid the competition by building a strong established brand (which costs lots of money) or you can be first to a popular new platform (which requires technical resources and the ability to predict future markets)
  • Costs are high. All the polish required results in long development cycles with large teams and large marketing budgets.
  • Risk aversion dominates: Both copycat players and developers are risk averse. Players want their comfortable fix and developers don’t want to introduce undue design risk in an already financially risky project. This often leads to bigger titles that are not always better.
Experience

An experience designer has a vision in their head of how the game will eventually look, feel and sound. They seek to create an emotional moment for the player that matches their vision.
  • Experience designers start with a mental image of the game. It could be a still shot. It could be a scene. The scene is laden with strong emotional and evocative detail.
  • Everything in the game exists to serve and bring to life that vision.
When I think of games that demonstrate the Experience style, I immediately think of Flow and Flower. Graveyard is also a good example. Starting with a target experience has a lot of benefits. You can change your art, mechanics, story and other game elements to match the experience. Experience designs have the added benefit of making the original designer valuable and nearly irreplaceable. The vision resides primarily in their head and they can act as the final arbiter of whether or not the actual product meets their vision.
Limitations:
  • Designs based on a vision are difficult to communicate. On larger teams, communication mistakes can multiply and bog down the project.
  • Teams can wander down dozens of different paths and still not reach the ephemeral vision in the designer’s noggin.
  • Occasionally other game play elements are poorly fleshed out. You can easily end up with something that is pretty, but isn’t all that fun to play.
Narrative

A story designer has a tale, usually a linear sequence of evocative events (or graph of such events), that they wish to tell. Games are the stage upon which the story is performed.
  • The game is conceived as a narrative arc and gameplay is often relegated to mini-game set pieces strung together to support the creation of the arc.
  • Design efforts focus on the use of symbols and pacing to evoke emotion. When the designer kills or removes a character and there is nothing the player could have done, you know you are dealing with a Story Designer.
  • The game is a success if players react strongly to the story that has been woven for them over the course of their play.

Story designers are quite common in larger scale games. Many AAA titles sports a very specific ‘roller coaster ride’ structure that has narrative design at it’s heart. Examples of games built by Story Designers are everywhere. Choose your own adventures are the classic case, but I’d be curious if even a game like Passage was ultimately conceived as a tale with fixed endings (albeit one where authorial intent was enforced by a predestined algorithm).

Limitations
  • Most story-based games can only be played once or twice before they are no longer interesting. They deliver their tale and then their value is spent.
  • Every little bit of must-see narrative steals a smidgen of agency away from the player. Instead of letting the player author their own story, the designer steps in and forces their own narrative upon the player. This limits the player’s ability to try and learn new things.
  • Failure is rarely an option, or at least not a serious one. After all, there is a story that must be told. Many times players are shunted from plot point to plot point with minimal gaming fuss.
World

A world designer begins by envisioning an imaginary space. They picture how it might be if they escaped into it as a player.
  • Place is a critical organizing concept. Items, people, organizations lives in specific places and their spatial relationships give meaning to the world. It is quite common for world designers to think in terms of maps, architecture, towns, races, guilds, districts etc.
  • Much of the flavor of the place is created through the use of historical detail. The underlying assumption is that the world existed when the player was gone and it will exist when the player leaves.
  • World designer will often lean heavily on fresh content in the form of new vistas to create a sensation of being in the world. They will often use the same game mechanics throughout, but delight the player by varying the setting from location to location.
The classic example of a World Designer is found in the paper RPG world. A GM will start with a map of continents and flesh out civilizations, races and alliances. This creates a playground for imaginative adventures. Games like Ultima, Oblivion and World of Warcraft also have a strong World style.
Limitations
  • World designs can often result in bloated games. There is so much stuff in the ever evolving world in your head that it is hard to know when to stop adding. New systems and verbs are created to support the exploration of every nook and cranny and few mechanics interconnect in crisp manner.
  • World designs are usually an immense amount of work. It is far easier to make a single scene or a situation than it is to flesh out an entire world.
  • Designers can focus so much on building the space that they forget to fill it with interesting things for the player to do. The result is mechanical place that feels lifeless.

Systems
Systems designers begin with a curious and intriguing set of rules that interact in unexpected ways.
  • Designs often begin with a set of objects, properties and interesting ways that the objects interact.
  • Common sources of inspiration include probability, combinatorics, spacial relationships, physics, timing and economic game theory.
  • The goal is to create a challenge for the player, be it a short term challenge in the form of a puzzle or a long term challenge in the form of a deep possibility space.
  • Truly deep systems often lay bare their mechanics in order to provide advanced players with absolutely clarity on their inner workings. The result is less room for details like narrative or world building.
Many of the industry’s most original forms of gameplay were conceived by people inspired by systems. With simpler rule sets, you find games like Tetris. Complex systems yield creations like SimCity or Populous.

Limitations

  • You’ll often end up with a system that is fascinating to the designer, but not that enjoyable to the player.
  • Many systems oriented designs come across to players as overly abstract. There isn’t a clear entry point into the design for new users in the form of a friendly metaphor or setting.
  • Systems can be quite difficult to balance due to all the various emergent interactions.
Player skills

Designers that focus on player skills create a set of actions (or ‘verbs’ in Chris Crawford lingo) for the player to perform. Then they create systems that help them learn those skills.
  • You start by writing out the type of verbs that you want the player to perform.
  • Then you figure out systems to go with those verbs
  • You figure out what additional skills are discovered when the systems are put in front of players.
  • Finally you figure out the right feedback systems to teach people those skills in an enjoyable manner.
Miyamoto is a good example of a designer inspired by player actions. When developing games he tends to focus on what the player is doing. Mario was originally named Jumpman after the key action you performed in the game. WiiFit came about by asking what sort of game could be built around the joy of weighing yourself. Mario 64 started as a playtest bed where all you could do is run around a small room and exercise the basic verbs of the game.

Limitations

  • Game play occasionally devolves into a series of disconnected mini-games when designers grab the easiest system available to represent a particular action. For example, in FishingGirl, I used a Frogger-style mechanic to represent fishing. As a simulation it was quite limited and was barely connected to the other mini-games associated with of casting and purchasing lures. In something like God of War, they turn the action “Kill boss monster” into the simplistic mini-game “Simon”.
  • After coming up with a set of fun actions, narrative and world are applied as a skin to the results. The result are surreal worlds involving mushrooms, exploding barrel graphics and other videogame-isms.

Rising design styles
The following styles are starting to appear within a few pockets of game design community.

Social: Designers that focus on encouraging particular types of interactions between multiple people. They have skills of event coordinators or party planners and focus on atmosphere, breaking the ice, moving people from activity to activity as well as efficient build up and take down of the event. Important organizing concepts include ‘Events’ and ‘Social spaces’. MMOs, Party games, and social networking games tend to attract Social designers. It is my believe that the next generation of great designers will be social designers.

Business: Design that focus on business try to squeeze as much money out of players as possible. I meet designers operating in online games and gambling games with this design slant. Typically, you encounter it in ex-designers who have moved onto publishing roles. It is an extremely powerful perspective that is unfortunately rather rare. As free-to-play becomes more popular, gameplay and business model will become even more interwoven.

Product Utility: Designers that focus on player value first identifies some form of utility that the product bring to the player. Product Utility designers often come from a more traditional product design background and focus on creating innovative solutions to observed problems. Yahoo, Amazon, Iminlikewithyou, and numerous web 2.0 companies a busy using the motivational aspects of games for utilitarian purposes. In short, this is social engineering with a purpose.

Pick your style!
Most designers tend to mix a couple major styles together. For example someone who enjoys working on licenses might start with a world style and do a deep dive to understand the world of the license. Then they augment that with a copycat design. Or someone who works on art games could mix a strong narrative with a systems oriented set of mechanics.

My suspicion is that most designers will have trouble applying all these styles to a game equally. First, each style can easily take years of intense labor to master. Secondly, games need focus in order to clearly convey their intended value. Too many dominant ingredients fighting for the player’s time can weaken the end result. It is a bit like cooking. :-)

As an exercise, take a look at various games out on the market and see if you can figure out the handful of styles they’ve stirred together. Halo is classic Copycat with a heavy coating of Narrative to make it seem like something bigger than your typical game. Desktop Tower Defense a straight Verb and System game, barely seasoned with any other styles. Ian Bogost refers to Jason Rohrer’s work at ‘Proceduralism’. I see a fascinating mix of Narrative and System styles.

So pick two or three styles for each game you build. Prioritize one as primary and others as secondary (in case there is a conflict at some point later in the design.) Don’t ignore the remaining styles since you’ll certainly need dashes of them to make the game function. However, be conscious of the dominant style of game you are making and make the hard decisions on what to focus on up front.

Understanding design styles to reduce team conflict
Inevitably there will be people on your team or in your audience who are fans of the other styles of game design. I regularly run into good people working in the game industry who passionately want to tell the sort of emotional stories that they see in movies. Story and Experience are paramount to them. However, any sort of Systems conversation inevitably devolves into a muddled Copycat discussion.

You can use the game design styles above much like how personality tests are used to resolve conflicts between people with different work styles.

  1. Identify your personal style. Which of those styles above do you love? Which ones do you find dull or unpleasant?
  2. Identify the style of the game you are working on right now. It is very common for this to be something different than your personal style. Publicly declare the style of game you are making so the entire team can agree upon the game’s direction.
  3. See if you can understand the preferred style of other people around you that tend to hold forth passionately on game design.
  4. Realize that having people on the team who are passionate about a variety of different styles is a good thing. Just because you occasionally feel the other person is coming from a bizarre and alien perspective doesn’t mean that they don’t have something valuable to contribute.
  5. When the opportunity comes to up to add in a dash of ‘spice’ in an area outside your personal style, see if you can tap into the passion of someone who prefers that style. We can’t lead all the time in all areas, nor is it a good idea to try.
My style
I almost always approach a new design from a Systems perspective. I find an interesting set of objects that interact with one another in interesting ways and then attempt to build a game around it. My typical process is to try lots and lots of systems, throw them at kleenex testers and see which ones are ‘fun’. This is labor intensive, but you can keep the costs down by using small agile teams and simple prototypes. It yields games that are lower on the copycat factor. However, they also have a bit of a surreal aspect to them since experience, story and world tend to be re-imagined on the spot to fit the latest mechanics.

Lately, I’ve been moving more in the direction of a Verb style. With Systems, I’ll often end up creating a game that is fun to design, but not fun to play. By focusing on the verbs and how the systems help the player learn to manipulate the system, my prototypes “find the fun” more often. If games create pleasure through exploratory learning, it makes sense that focusing on verbs and skills are one of the more direct paths towards creating engaging game play.

Narrative is my main weak point and something I should work on.

Conclusion
One thing I get out of this exercise is that there is not one True style of game design. For every Miyamoto and Will Wright creation there is a game like Monkey Island or Full Throttle pushing story and experience. People love all these games. Game design style, like style in almost any consumer market is a matter of taste. The good news is that now I can name the various styles and discuss them in a less vague fashion.

I also realize that I’ve been leaving certain powerful perspectives out of my palette of game design tools. When I was younger (and driven more strongly by raging hormones), experience-driven games mattered immensely. I vividly remember working on a game about sickness and trying to convince my fellow teammates that it was of utmost importance that black cancerous growths fall off the player and scuttle away on their own. As I aged, I’ve moved onto more intellectual and less emotional designs. It might be fun to bring that side of my design back one day.

Of course, this list of game design styles is a work in progress. So I’ll end with some questions.

  • What style of game designer are you? Do you fit into one of these approaches?
  • Is there another design style that is missing from this list? Can it be expressed by a combination of the other styles?
Take care,
Danc.

Go to Source

Review of "The Art of Game Design" by Jesse Schell

Recently I wrote a review for Jesse Schell’s new game design book. You can read it up on Gamasutra.

Here’s a brief except:

Though the elements of game design are well described, practicing designers won’t find a lot of new insights that haven’t been covered elsewhere. Luckily, the book also includes some more utilitarian tools in the form of 100 “lenses”, or questions that help you iterate on your current design.

A designer’s job often consists of asking questions. Almost as soon as you start building a game, you need to ask “what should be improved?” There are nearly an infinite number of questions one could ask and often finding the right question to ask is key to coming up with the right solution.

The 100 Lenses are a set of time-tested questions that you can ask about your game. Are you using your elements elegantly? Could your pacing be made a bit more interesting by using interest curves? What is the balance of long term and short term goals for the player? One of my favorites is Lens #69, The Lens of the Weirdest Thing:

“Having weird things in your story can help give meaning to unusual game mechanics — it can capture the interest of the player, and it can make your world seem special. Too many things that are too weird, though, will render your story puzzling and inaccessible. To make sure your story is the good kind of weird, ask yourself these questions:

What’s the weirdest thing in my story?

  • How can I make sure that the weirdest thing doesn’t confuse or alienate the player?
  • If there are multiple weird things, should I maybe get rid of, or coalesce some of them?
  • If there is nothing weird in my story, is the story still interesting?”
  • These are the sort of questions that get me looking at my game designs from a new perspective and can really jolt the creative juices. Not all of the questions will be useful.

However, somewhere in the list are at least two or three questions that even the most experienced designer wished they had asked sooner. By having the questions at your fingertips, you can ask them earlier.

Thoughtful writing on game design always get my brain churning in interesting new directions. With Jesse’s book, I was reminded what a broad ranges of disciplines that game design ultimately includes. I have taken a narrower route and spent the last couple of years focused on a rather specific set of tools related to rapid iteration and skill atoms. Yet there are dozens of fascinating nooks and crevices in our evolving craft that one could profitably invest their life exploring.

take care
Danc.

Go to Source

Project Horseshoe: Multiplayer Game Atoms

The 2008 Project Horseshoe reports are up! We wrote about how to diagram multiplayer games using skill atoms. Truly a brilliant weekend. The discussion was quite wide ranging and as a result the write up became a bit…long. However, the results should spark a few brain cells. Let me know what you think! :-)
Best wishes,
Danc.
PS: There are some great reports up this year so be sure to browse around a bit.

Go to Source

Fishing Girl Prototype results


Here is a story about a fellow named Andre, who created a Lostgarden game prototype, sold it for $4000 and started down the path to a new career in game development.

Andre lives down in a rural section of Australia. Due to the limited infrastructure in the region, he makes due with a gimpy modem that sputters along, randomly disconnecting at the worst possible moment. There aren’t very many tech jobs in the area, but he is unable to move due to family obligations.

Early on in life he dabbled with art, graphics programming and games, but there isn’t much call for such things locally. To make ends meet, he grinds away, year after year, developing website after website.

Andre is the sort of smart, industrious fellow that has immense potential. He dreams of creating amazing and wonderful games. Every email I receive from him is bursting with ideas and
snippets of working games that he jotted down in his spare time. Yet the ‘traditional’ path into games is closed to him.

When opportunities are limited, people often settle for limited opportunities. I grew up in a rural area and I’ve seen many bright wonderful people end up in dead end jobs due to the emptiness of their environment. It can be hard for people raised in areas of plenty to understand, but if no one else ever talks about what is possible or open a door to new ideas, you can go through life bound by invisible cultural blinders.

Prototyping challenges are opportunities
I created the prototyping challenges on Lostgarden.com as an onramp for new game developers. There are no excuses. The art is free. The design, though never perfect, is enough to get you moving in the right direction. There are dozens of free game engines for you to use. All this, combined with the internet (even accessed on a gimpy modem) opens all sorts of doors. All you need to do is make a game.

Over the past month or so, Andre built a version of Fishing Girl in Flash. He quickly built out the original design and then iterated upon it until he had something playable. A bit of data:

The best bit of news is that Andre was able to sell the Fishing Girl game for $4000 + a performance bonus. Yes, you can sell Lostgarden prototyping challenges for cold cash. I highly encourage it since A) people should be paid for their hard work and B) the lessons you learn by finishing a game for the public are invaluable.

Now Andre has a little bit of income and a lot of validation to feed the development of his next game. These days when I talk to Andre, he has big plans for a whole career doing what he loves. That is pretty darned cool.

Gold medal (1st ever)

Andre gets my first gold prototyping award. He earned a score of 77% (103 out of 134 points). Here is what he did to earn it:

  • 15 minutes of fun: The rule of thumb for a gold medal game is that you need to make about 15 minutes of fun. Most prototypes barely get to the 5 minute mark. Many people are playing through Andre’s FishingGirl twice and spending upwards of an hour on a single play through.
  • Found and extended the fun in the design: In order to build 15 minutes of fun, he iterated on the basic design and added his own touches like lure-seeking fish and wonderfully animated endings.He realized that a game design is not a blue print. It is a starting point for practicing the iterative process of design.
  • Made a complete experience: There is a strong narrative arc throughout Andre’s Fishing Girl. You fish, you advance, you discover something surprising and you save the little boy. It is a game you can start and then feel good about finishing. The vast majority of people who say they want to make games start building them but never finish them. The act of making a polished game that players can finish teaches you more about game design than any number of incomplete engines or piles of features.

Silver medals
Folks have been working away like busy bees on this design. I expected to give out mostly bronze medals, but there were three prototypes that were recently updated, each of which kept me interested for five minutes.

There is still opportunity for each of these to reach for a gold medal. I’d love to see some more variations on the Fishing Girl game. If Andre’s Fishing Girl is the equivalent of Asteroids, who is going to make Galaga?

  • Eric (65%): http://ericw.ca/files/FishingGirl/setup.exe. A great last minute entry that has delightful Fish AI and an innovative combo system for catching fish.
  • Ben (46%): http://sites.google.com/site/walkersoftwareprojects/files. Ben has a simple game here that still managed to get me to try to fish up all the little fishies. The mechanics are lacking a bit of juiciness, but basics are there.
  • Shade (41%): http://www.exodia.org/og/?p=24. Shade has some interesting line physics here. To riff a bit , with this type of system and line collision, you could do some wonderful things with obstacles in the sea. Players would need to drape the line perfectly over different objects to get to a particular spot in the ocean to catch a rare fish. This protoype has the ‘juiciest’ of the game mechanics, but it needs a bit of tuning so that it doesn’t feel quite so loose.

Bronze medals
There were also a couple of solid technology experiments.

  • Dale and Greg: http://beta.sharendipity.com/assets/1900/: The good folks over at Sharendipity put together the basic fishing mechanics and it is running on their new Flash client. (Woot!) They initially implemented casting and fish swimming as two separate apps. As a side note, this prototyping path can be tricky to gain useful feedback from since the most exciting gameplay opportunities often come from the interaction of the combined systems. It is often better to integrate early, but keep each system simple so that you don’t need to deal with undue complexity. You can always add complexity to a system if you identify enjoyable skills that are worth investing further in.
  • Pete: http://blois.us/FishingGirl/ Our first prototype in Silverlight. Sweetness. He has a tight casting mechanism.

Areas of improvement
Every time you build a game, you learn lessons that let you build it better the next time. If anyone wants to create a better version of Fishing Girl, here are a couple things you might be able to improve. These comments uses Andre’s game as a starting point.

Problems: The following are problems that kept users from enjoying the game fully.

  • The floating shops are a pain: You constantly end up hitting them with your lure. Having a single floating store that is inside the distance of your longest cast may help. The position prevents you from hitting it unless you try. Instead of selling one item, the store would have a rotating list of things that you can buy. Once you hit the store, it reappears elsewhere. The alternative is to let the player go to the store at any point, but this removes some of the fun of trying to cast at a specific distance.
  • It is hard to aim exactly with the rod: Slowing down the rod might be one way of improving accuracy. Speeding up the ‘boring’ parts of the swing the beginning and end might be another way of giving the casting a better feel.
  • Less repetitive music: People get bored of the music rather quickly.
  • The later portions of the game become boring: Try having fish reproduce at a certain rate if they get below a certain population threshold or make the larger fish more interesting to catch. I’d still like to keep the possibility of ‘fishing out’ the area so that an extinction ending is possible.

Opportunities: The following are glimmers of fun that could be accentuated in a future version.

  • There should be more things in the ocean: There is immense opportunity for bonus objects to be hidden in the ocean. For example: Treasure chests, Glowing orbs that spawn rare fish or deadly fish, Temporary lure or rod power ups that only last a certain amount of time
  • A fish collection: Imagine that every time you collected a new fish, you got a stamp for that fish in a collection album. It is a like butterfly collecting, except with fish. Some people would need to “catch ‘em all’ which would extend gameplay. With a bit of color cycling or special effects, you could easily create dozens of different fish with different costs and rarities.
  • More fish movement: The fish have generally simplistic movement. Fish that dart at a lure or that move very quickly or very slowly might add some interesting texture. It is worthwhile to see if the catching of a single large fish can be made more interesting.
  • More lure types: The types of lure could be expanded up on. For example: Lures that only work on fish of particular colors, Lures that are more or less bite resistant, Lures that attract some fish and repel others. , Lures that upgrade some fish into more valuable fish, Lures that allow you to capture multiple fish or a set of fish in a row.
  • More levels: There is a single level. It could be interesting to have the girl jump on a boat and travel to a new island with more fish. An alternative progression is for the sea to evolve over time. Once you collect certain fish or reach a certain amount of money, kelp can slide aside or a cave entrance can be blown up that introduces new fish and new treasure.
  • Fog of war: One of the exciting bits of fun that emerged from the prototyping was a sense of discovery as you are able to fish out further and further. A feature that should add even more mystery to game is fog of war system similar to those found in RTS games. The area around the lure could show you the fish nearby. Areas that you hadn’t explored would be opaque. Areas that you had explored would show markers or partially transparent versions of fish you had seen. Combined with ‘rare’ fish that could only be found in certain areas, this would give players a much stronger sense of ‘exploring’ the ocean.
  • Add a serious ending: One of the key endings in the original design is the ability to cause all the fish to become extinct. It adds an interesting twist to what would otherwise be a mindless game. The system is built so that users slowly fish out the small fish and eventually gain new technology that allows them to fish out the larger deeper fish. This systems-based narrative parallels the pattern of fishing in the real world and seeks to teach a small lesson. The dynamics could be augmented by systems that catch large numbers of fish at once so that it becomes quite easy to overfish. The addition of a ‘save’ system that lets you come back later to harvest fish (and score) for long periods of time would encourage manageable fishing tactics.

Conclusion
I hope everyone enjoyed this prototyping challenge. These challenges are evergreen, so just because I’ve given out the first round of awards doesn’t mean you should stop developing! Keep going. I would like nothing better than to give out another gold medal. If you update your project and want me to take a look, just drop me an email at danc[at]lostgarden.com. I can be a bit slow at responding, but I will write eventually.

As the years go past and my hairline continues to recede, I find that I have a debt that I am obligated to pay back. Very few of the current generation of game developers started from scratch. We’ve all looked at tutorials or snagged bits of free code. We’ve built upon tools like Flash or engines like Quake or Source. We’ve been inspired by existing designs or read books that have opened our eyes. Once upon a time, I too was in Andre’s shoes and it was only due to the opening of an unexpected opportunity that I’ve arrived at where I’m at today. If these prototype challenges ease another eager game developer’s path in even a small way then my time on this blog is well spent.

Happy holidays. Go make some great games!
Danc.

References and notes

  • The original FishingGirl challenge: http://lostgarden.com/2008/11/fishing-girl-game-prototyping-challenge.html
  • Percentage values: The percentage scores may come across as somewhat low, but try not to interpret them from perspective of the inflated grading system used in schools.
  • Notes on Awards: If you won an award, feel free to post the appropriate award image and link back to this post. You should be proud of your efforts!
  • Scoring spreadsheet: Fishing%20Girl%20Results.xlsx. Here is how entries were scored.

Go to Source

Post-it note design docs


I happen to fall into the artist-designer skill set, so I often find myself trying to prototype ideas on teams rich with programmers. As such, I’m always looking for better game development techniques that work well for this particular team mix.

Here is a very lightweight prototyping process using Post-it notes that I quite enjoy.

  1. Initial idea: I sit down with an available programmer (and artist/UI designer depending on the system) and we chat about how to test out a new bit of gameplay. Usually this is an idea that has been bubbling about since the night or week before.
  2. Post-it note design: I jot down a quick bulleted list summarizing our discussion on a single post-it note. We go over it one last time so there everything is clear. The list isn’t very detailed. Mostly it serves as something to jog our memories if we forget what we were talking about.
  3. Build it: The programmer and artist go off and build the items on the list. It might take 2 hours or two days. They are encouraged to solve problems creatively and they can always just give me a shout if something doesn’t make sense.
  4. Play test: When most of the items on the Post-it note are playable, I get called over and we play test it the experiment together. If the results are comprehensible by mere humans, we pull in some play testers for 3-4 minutes to observe some real players interacting with the mechanic for the first time.
  5. Review: Afterwards, we discuss our observations and write up another Post-it note worth of improvements.
  6. Repeat or Stop?: The process repeats until we run out of time or give up. Sometimes we give ourselves a day per experiment, sometimes two days. In the land of Scrum, we treat the experiment like a time boxed task.
  7. Rate: At the end, the gameplay experiment is rated according the scale below.
  8. Save: The code is saved off, a few choice notes are recorded in a doc containing our ‘list of experiments’ and we move on. Bits of code, even from failed prototypes, are often reused in future gameplay experiments.

Rating system
The rating system is delightfully crude. The goal is to triage experiments quickly.

  1. “A”: These experiments were obviously fun. Players laughed, smiled and generally exhibited the emotions we were looking for. If in doubt, ask “Was this fun? How so?”
  2. “B”: These experiments showed a hint of fun if you knew what you were looking for. However, it is going to take more effort to expose the fun in a manner that is visible to the players.
  3. “C”: There wasn’t any fun. The experiment fails.

A portfolio of fun
One of my favorite aspects of this method is that you end up with a mini-portfolio of game design ideas. Instead of putting all the design risk in a project on one or two unproven mechanic, the team now has a half dozen or more proven bits of fun to build upon. If some don’t fit into the game or get abandoned for other reasons, that’s alright. You can afford to lose a few and the end product will still be fun. Think of it as designing from a position of plenty.

Contrast this with a prescriptive ‘design doc’ approach where you are forced to pick, without much evidence, a main mechanics for production. Even for the most experienced designer, 50% to 80% of your ‘educated’ selections are going to be complete dogs. Every unproven mechanic you polish ends up being a massive drain on your budget and your reputation as a designer. You might hear gentle comments like, “We spent 3 months of dev time on this lump of an idea and it isn’t fun?”

It doesn’t take very many expensive failures for the project’s perceived ‘design risk’ to blossom to the point where conservative minds seek to kill the project. I think of this as designing from a position of sudden death.

Some basic observations
Here’s a quick list of things I’ve observed when prototyping.

  • Failed experiments happen a lot. Don’t be surprised if C-rated experiments occur 50% to 80% of the time. Everyone on the team has to be aware that not every experiment is going to be a success, but the learning process is still worthwhile.
  • Designing on your feet is a critical skill: Each consultation and analysis might last only 10 to 20 minutes and you need to leave folks with that all important sticky note filled with impactful, yet inexpensive changes. It pays to have lots of ideas and a deep understanding of game mechanics so you can quickly pull together a list of incisive comments. If you can’t, you likely are not suited to be performing the designer role.
  • Listening matters. The designer doesn’t need to come up with all the solutions. Everyone on the team is bright and has great ideas. As a designer, your role is to herd all ideas (yours and others) into something that serves the next step in the prototype.
  • You need programmers: If there aren’t programmers dedicated to prototyping, the prototyping isn’t going to happen. You can drop down to paper prototyping, but it usually doesn’t prove out many types of mechanics (especially ones involving timing and interfaces.)

Advanced observations
These are some notes that are a bit geekier, but can save you large amounts of pain.

  • Meta game mechanics are harder to prototype: The systems that link together the various gameplay experiments are harder to playtest. They operate on longer time spans (hours instead of minutes) and often require that the core gameplay is already fun.
  • Build a meta-game architecture that allows for loose coupling of gameplay experiments: Most successful games have an architecture that allows the team to plug in new bits of fun as they are found. The linear ‘level-story-level’ pattern used by most FPS is one example. The ‘hub with many sub levels” used by Mario 64 is another. Any of these allow you to plug in a new experiment independently of the other gameplay experiments. If you don’t have a modular architecture, you run into situations where a fun new system breaks many of the other bits of fun you’ve already discovered.
  • Integrating tightly coupled gameplay experiments is a pain: If I independently find a fun new type of weapon and an interesting enemy AI, the combination of the two is often a non-trivial issue. The new weapon many work with an old AI, but be completely useless with the new one. Integration yields a whole new set of experiments. Plan for time to rediscover the fun all over again.

Benefits
There are some interesting benefits to the Post-it note design method:

  • Scales nicely to large prototyping efforts: One designer can serve multiple programmers. This works nicely on teams where there are more programmers than designers and you need to get a lot of prototyping done quickly.
  • Failing quickly is fun and educational. You learn a lot with each failure and can move onto the next experiment with a much better idea of what doesn’t work.
  • Provides a quick death for bad pet ideas. It is much harder to resurrect pet ideas when you have concrete, playable proof that it won’t work. Finding out early which one of my favorite ideas is idiotic saves me a lot of political pain.
  • Fun prototypes are quite convincing: A fun, playable crazy idea works a lot better for winning over other team members than any amount of hand waving or documentation.
  • An easier team to assemble: Finding a competent game designer and a competent programmer can often be easier than finding a competent programmer-designer. Well developed hybrid skill sets are very valuable, but can be quite rare. A side benefit of having a team is that you end up cross training your designers and programmers. You create designers who can speak to programmers and programmers who can riff on some of the design.

The value of dime-a-dozen designs (A brief aside)
One often hears the negative comment that game designs are a dime-a-dozen. And in a waterfall design process, an incessant stream of ideas is indeed a problem. If you attempt to squeeze all those ideas into a typical waterfall development process, you end up with an immense amount of waste. Each designs need documentation, concepting, implementation, testing and bug fixes. In response, project owners will often ask for just one good idea.

There is another path. A lightweight prototyping method takes your flurry of crazy ideas and converts them at moderate cost into a well sorted portfolio of working designs. All those ideas are not, in fact, worthless or wasteful; they are the essential fuel that feeds a good prototyping process. Each idea either teaches you something or provides you with a success.

The way to make the process work without getting gunked up is to make prototyping incredibly lightweight. Other than our focused conversations, I spend my time on a total of two design docs: The first is the brief list of rated prototypes and the second is a set of discardable, temporary Post-it notes. Design waste in the form of unnecessary artifacts is minimal. Most of the ‘programming waste’ is better classified as low cost learning.

Those wild flocks of churning, swirling ideas end up not being worthless at all. They simply need to be funneled into the project with the right process for their value to be realized.

Conclusion
The “Post-it note design process” has likely been reinvented in one form or another hundreds of times across the history of game development. It is so basic that it feels odd to even write it up in any sort of formal fashion.

If you have a designer and a programmer, give it a shot. It is certainly a good functional alternative to the popular process of sticking a lone programmer-designer in a room and asking them to ‘find the fun’. Both can produce great games. Pick the one that works best for your current team composition.

This process does have an cost since you need to devote at least two people to finding the fun instead of putting all decisions on the head of the designer. However, the end result is well worth it. After all, it is far smarter to spend team time uncovering a portfolio of the right mechanics than it is to ‘save your programmers’ so they can be off running really fast in the wrong direction.

In the end it really isn’t about programmers, designers, design documents or features. It is about the team working together to make the right product. Everything else is just ego and waste. And for some reason, it is quite difficult to invest much ego or waste in a little disposable Post-it note.

take care
Danc,
Post-it note fanboy

Go to Source

Project Horseshoe 2008: There and back again


I’m writing this on the long flight back from Project Horseshoe 2008. The last bittersweet night, we stayed up till five AM playing games and talking about games. The conversation shifted from the slow death of games as we knew them, to fresh games that will change the world, to the little tips we use to thrive each day. There is something distinctly surreal about chatting quietly with such an intimate knowledgeable group during the wee hours of the morning, there on a lonely porch in the uncharted depths of Texas. And yes, there were indeed baby racoons.
This year, I took a risk. If you’ve been following this blog for a bit, you know that I’ve been working on skill atom techniques for modeling gameplay. I’ve written about it. I’ve used it myself. There has even been a talk or two. Yet, aside from a few furtive emails with other happy heretics, I’ve never had a chance to do the following:
  1. Explain the model to a crowd of natural skeptics, working designers who have been successfully building games for years.
  2. Get them to tear it apart.

The cautionary tale of the secret paint formula
I’m reminded of a story that Norman Rockwell used to tell. He once became good friends with a fellow painter who was famous for his rendering of luminescent, sensual skin tones. The painter used a secret formula for his paint and he guarded it jealously from potential imitators. When the painter died, he willed his greatest gift, his secret paint formula to Rockwell.

Rockwell excitedly tried out the formula, but ultimately found it disappointing. The paint was too slick and difficult to control, so he gave up on it and instead fell back on his own preferred techniques. The real secret had never been the paint formula. It was just one little piece of the painter’s vast organic, highly individual process. The real secret was the intuitive wisdom that comes from making a thousand paintings. Sadly, such a thing is not transferable to others. When he died, his specific way of creating paintings died with him.

Are skill atoms the same thing as the secret paint formula? Are they a glossy coat of theoretical hand waving that only works for the people who invented it? Many people I’ve talked with see ‘game grammar’ as nothing more than a time wasting intellectualization of a fundamentally intuitive activity. I went into the weekend with this thought very much at the forefront of my mind.

Why stop there?
If all we had done was validate or invalidate the skill atom model for simple games, it would have been a useful weekend. But by god, this is Project Horseshoe and people are nothing if not psychotically ambitious. To up the ante, our group decided to apply skill atoms to multiplayer games. I’ve never done this.

How do you model a deeply psychological behavior like bluffing? Gifting? Competition? Collaboration? Goodness! I didn’t have a lot of answers prepared for this topic and honestly expected that the skill atom model would immediately collapse under the weight of all the crazy things that happen as soon as you add two or more players to a game design. All it would have taken is one smart designer to raise a single counter example and my fragile model would burst apart, defeated by reality.

Some questions that I had included:

  • Could we even begin to talk about multiplayer with skill atoms? The alternative is that this is a model that is limited to only single player experiences. That would be like coming up with a model of physics that worked for one ball in a vacuum, but wasn’t useful for something useful like say…building bridges.
  • Would the system scale to complex systems? Often when you use a diagramming technique (like UML or state diagrams) to understand real world projects, the resulting diagrams becomes so convoluted that the model does more to confuse than to illuminate.
  • Would the system be useful to designers during every day work? It is much easier to come up with a academic system of analyzing games that works best if you are an ivory tower dweller who can devote hundreds of hours to breaking down each interaction into pretty diagrams filled with obscure invented lingo. However, I’m looking for utilitarian tools that can be applied in that critical 10-minute gap between playing a prototype and deciding what to try next.
  • Can this system be taught to other designers? Like the secret paint formula, most game models I run across are only useful to their inventors. If I can’t observe other designers applying the model successfully without my intervention there is something horribly wrong with the approach.

We ripped the skill atoms apart. We analyzed multiplayer M.U.L.E. We looked at charades and then took on football and buffing in MMOs. We used skill atoms to prototype a new multiplayer game about gifting using a bag of plastic Indians. At some point, not so long from now, our group will come out with a report. In that report, we’ll be blunt about what we found. What worked? What was flawed? The results are fascinating.

Our team’s report will be one of several reports to come out of Project Horseshoe by groups of game designers just as crazy and inspired as we were. If any one of these reports starts gaining momentum, the world of gaming as we know will change. It turns out that moving our industry forward isn’t about complaining. It is about getting smart people together where they have the time and the space to think. Grab a beer (Aventinus Double Bock, no less), join the mind meld and use the vast pool of centuries (!) of game design experience to come up with real solutions. Then follow up again and again and again.

In that spirit, I can’t wait to share our final report with everyone.

Time for some much needed sleep, chock full of dreams.
Danc.

PS: Warm kudos to George, Linda and Teresa for putting Project Horseshoe on. It is obviously a labor of love and is utterly unique compared to the other events and conferences I’ve attended. If you ever get an invite, don’t hesitate to go.

Go to Source

Tidbits from the garden

A few odds and ends have collected in my inbox lately.

Video of the Princess Saving Application is up!
All the videos from the night are posted up on OfficeLabs.com. My talk starts 10 minutes into the first video and lasts approximately 30 minutes. There’s also a bit of Q &A after all the talks finish up. You can get the original slides here.

<a href=”http://video.msn.com/?mkt=en-US&playlist=videoByUuids:uuids:d0cabdcc-97bc-4799-a579-4da3b73f865b&showPlaylist=true&from=msnvideo” target=”_new” title=”Microsoft Office Labs & Engineering Excellence IxDA Event Part I Daniel Cook”>Video: Microsoft Office Labs & Engineering Excellence IxDA Event Part I Daniel Cook</a>

FishingGirl update
I’ve seen some sneak peeks of the FishingGirl prototypes and people are making great progress. It will be possible for someone to win a gold medal this time around. If you’ve started a prototype, finish it! There is solid fun lurking in that design and you still have a couple of weeks left to build something wonderful.

Some observations:

  • The store and the acquisition of the various rods adds a great sense of exploration and progression to the game.
  • The gameplay improves substantially if you give your fish a small dash of intelligence so that they move towards your lure if it is in their sight.
  • Making the game winnable. There is a story arc to the game and it feels incomplete if you don’t let the player finish.

Skill atoms in action
Tex, over at the delightfully titled Tin Man Tex’s Slap Dang Blog, put together skill chain describing his mod. I liked how he intuitively started writing down skill atoms and then only later began connecting them together in a skill chain. Analyzing a game using skill atoms has an element of mind mapping to it that is pleasantly organic. Check it out. I hope to see more such examples in the future.

Other prototyping notes
BuschnicK created a nicely fleshed out version of Play with your Peas. It is a faithful implementation of the game and deserves a very solid silver reward. However, I still think the fun hasn’t been completely uncovered.

At this point, we’ve had some reasonable implementations of the original concept. I suspect that the design may require some big changes to make it work. So here is a question: Why isn’t Play with your Peas mind-thunderingly fun and what could be done to improve it?

Best wishes and may you have a sinfully glorious Thanksgiving.
Danc.

Go to Source

Special Offers
Blogroll

Categories
Pages
Tags