Directory of All Essays

Saturday, December 20, 2008

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

Labels: , ,


Read more!

Saturday, November 01, 2008

Fishing Girl: Game Prototyping Challenge



Earlier this summer, I mentioned that I was starting up a Mystery Project for local Seattle weekend coders. Summer has turned into Fall and the Mystery Project is still going strong. So we decided to kick off a Winter session of the Mystery Project!

In this post, I wanted to do two things:
  • Extend an invitation to any Seattle developers who would like to participate directly in the Mystery Project.
  • Share some Mystery Project graphics that we’ve made this summer part of yet another delightful Prototyping Challenge.


Winter Mystery Project
The Mystery Project is an innovative small Flash MMO that experiments with many of the design concepts I’ve been writing about on this blog. We meet up every Sunday at a local coffee shop and share what we’ve done and what we’ve learned. The project is the main focus, but I put a big emphasis on helping everyone on the team develop new skills and explore exciting ideas. If you are in Seattle, our meet up has become a rather unique opportunity to explore true next generation game design.

The team is pretty solid, but I’m looking for at least one additional, talented programmer. The project is in Flash/Flex with the server-side game logic written in Java.

Being part of the team means a serious time commitment. Expect to put in at least 10-15 hours a week. Making games needs to be your hobby and your passion.

If you have solid Flash/Flex/Java programming skills and you live around Seattle, drop me a note at danc@lostgarden.com. Ze Mystery Project lives (at least for the winter)!

Fishing Girl Prototype Challenge!
Due to the ‘coffee-shop mentoring’ model I’ve got set up for the Mystery Project, there are dozens of talented programmers who live outside of Seattle who can’t participate in our weekly chats. This makes me sad. So I decided to share some of our graphics as part of a brand spanking new game prototyping challenge. Free graphics + new game prototyping challenge = Happiness.

Fishing Girl is a simple fishing game played with one button. It illustrates a design pattern called sequentially linked mechanics. Often when you try to simulate a complex exercise like fishing, you can’t easily create a single game mechanic that captures the entire experience. Instead, you string together a series of activities. Each activity is simplistic by itself, but in sequence yields a good approximation of the complex experience. The fishing game is split into the following activities:
  1. Casting
  2. Positioning the lure
  3. Hooking a fish
  4. Reeling in the fish
  5. Scoring the fish
  6. Buying new equipment.
Each section should take 1-3 evenings to prototype in Flash. String them all together and you have a fishing game. The nice thing about this challenge is that it is all about bite sized chunks that are easy to build and iterate on.

The Wife Test (How Prototypes are scored)
My wife, as I mentioned in previous posts, is quite ill and I’ve wanted to do something nice for her. She absolutely adores fishing games, so Fishing Girl is designed for her. Any prototypes that someone is kind enough to make will be played by my wife with me watching her reactions intently. Luckily, she doesn’t find this overly irritating. :-)

In order to capture her casual gamer feedback, I’ve added a simple scoring system for this challenge. Each section of the game is worth a number of points. 50% of the score for each section will be whether or not my Bejeweled/WiiFit-playing wife finds the prototype to be ‘fun’. This is Miyamoto’s “Wife Test” applied in a quite literal fashion.

I’ll still be giving out the LostGarden Medals and still, no one has won the epic Gold Medal. It sits out there, tempting and shiny, just waiting for the right prototype to provide 15 minutes of fun. This challenge will last two months. But if something comes in later, I’m always happy to take a look and offer comments. Just list a link to any prototype in the comments section of this post.

The setup (10 points)
The player is a small bear-like creature, the Fishing Girl who sits at the edge of the ocean. She has a fishing pole, a glowing lure on the end of the pole, a money count and that is about it. In the ocean are numerous fish of various sizes that swim back and forth, but we’ll get to those later.

Casting (10 points)
Casting the lure out into the ocean involves two clicks:
  1. If you click your button once, the girl will pull back her pole to cast.
  2. If you do nothing, the pole will return to the default position.
  3. However, if you press a second time in the middle of her swing, she will cast the lure outward into the ocean.
  4. The closer the second click is to the peak of the swing the further the lure travels.
  5. When the lure hits, a number is placed at on spot on the ocean where it lands. This records the distance and lets you know exactly how far you cast.
Casting acts as a simple timing mini-game.

Help text (Bonus!)
  • Click to start casting
  • Cast!
Positioning the lure (20 points)


Positioning the lure in the water is the centerpiece of the game. You'll be spending a lot of your prototyping time here. :-)
  • When the lure hits the water, it starts to sink downward in an arc. When it starts out, it sinks almost straight downward. The tension on the rope pulls it inward towards the player, hence the arc. We don’t have time to model the complex line physics, so instead we say that the lure moves along an arc of a circle whose radius is defined by the distance from the tip of the pole to the point at which the lure hit the water.
  • Holding down the button reels in the lure. This changes the radius of our arc, but does not change rate at which the lure is moving along the arc.
  • The empty lure, unencumbered by fish reels in quite quickly. Using this system, we can now place the lure at any point within the sea.
Positioning the lure acts as a timing and spatial skill mini-game.

Hooking a Fish (25 points)
In the ocean there are fish. In order to hook a fish, you must place the lure in front of the fish’s mouth. The fish will lunge forward and become hooked. The entire time, you are carefully timing the slow downward arc of your lure. There are three pieces to this mini-game.
  1. The Fish
  2. The Lunge
  3. The Lure
The Fish (10 points)
Fish are objects in the sea that move back and forth in predictable patterns. Fish come in different sizes, rarity and movement patterns.
  • Movement: Back and forth. There are others patterns such as circles or swarms, but that would be extra.
  • Size: Small, Medium, Large, Extra large.
  • Rarity: Common, uncommon, Rare, Very Rare. This is used during “Scoring the Fish”
Fish are spread throughout the water with more valuable fish located further from shore. Try to have a good mix of big fish and small fish. You can start testing with one fish, but ultimately, you should have 10 to 20 or else the game won’t be very interesting.

The Lunge (10 points)
Now that you have your fish floating about, you can implement catching them.
  • Each fish has a collision box in front of its mouth.
  • If the lure enters the collision box, the fish will move forward towards the lure and attempt to become hooked.
The Lure (5 points)
Lures come in different sizes: Small, Medium, Large. The size determines which size fish you can catch:
  • If the lure is too small, it will be snapped and the cast is over.
  • If the lure is too big, it will be ignored.
  • If the lure is just right, the fish will be automatically hooked.
Help Text (Bonus)
We display help text at the appropriate moments
  • Position lure in front of fish!
  • That fish was too big for this lure!
  • That fish was too small for this lure!
  • You hooked it!
  • Reel in!
Choosing which fish to hook acts as simple tactical choice where the player is asked to pick the most optimal outcome. The time pressure of the moving fish and lure makes this choice interesting.

Reeling in a fish (20 points)
Once you’ve caught the fish, you need to get it back to the surface. Reeling in the lure works the same as before but the larger the fish, the slower it comes back up. Reeling in the fish is an exercise in keeping your fish away from other, larger fish that will happily eat your fish if it comes their way.
  • Fish still go for your fish if it appears in front of their mouth.
  • If they latch on, they take a bite out of your fish.
  • Three bites and you lose your fish. Each bite also reduces the value of your fish.
  • If your fish makes it to the surface of the water, you’ve caught the fish!
  • Reeling in the fish successfully acts as a timing and spatial skill mini-game.
Everything up to this point has been training for the player. Expect to spend considerable time here balancing, iterating and making this section feel good.

Reward for catching the fish. (5 points)
When you catch the fish, a small celebration animation plays that shows you the fish that you caught. There are several pieces to this segment.
  • Revealing rarity
  • Awarding Money
Revealing rarity (2 points)
When the fish is held up by the fisherman, the fish that you’ve been reeling in is revealed to be either a common (1), uncommon (2), rare (3) or very rare fish (4). Each type of fish has a distinct image associated with it.
  • The rarer the fish the less likely it is to appear.
  • A text label appears that say the name of the fish and the rarity. For example “Ancient Shoefish (Uncommon)”
  • Bonus!: If you want to get really fancy, you can display a simple text modifier to each fish that also modifies it's value. For example "ancient" increases value by 50% while "skanky" reduces value by 20%.
Awarding money (3 points)
  • The value of the fish is also displayed. A simple scoring equation might be size * rarity * modifier * 10. Feel free to play with the values to get the right balance.
  • The amount of money the fish is worth is then added to the piggy bank counter that has been sitting on the screen this entire time.
The revealing of the modifier acts as a gambling element that keeps the outcome interesting of each cast exciting until the very last second.

The store (10 points)
Floating out in the sea are various markers that represent item upgrades. If you hit the marker exactly with your cast and you have enough money, you will purchase them. Otherwise, your lure will bounce off and sink as expected. These artifacts do the following:
  • Bronze rod: Your basic rod. It casts a short distance off shore.
  • Silver rod: Cast further
  • Gold rod: Cast even further
  • Legendary Rod: Cast far and reel in heavy fish quickly.
  • Small Lure: Catch small fish.
  • Medium Lure: Catch medium fish.
  • Large Lure: Catch large fish. Note that there is no extra large lure, so there are always larger fish that pose as obstacles.
  • Bomb lure: Explodes and kills the first fish that touches it. Even if it is a very large fish.
  • Boy: Far on the edge of ocean is a Boy. He is inordinately expensive. This is how you win the game. And for the record, he is indeed, quite the catch. (What happens when you use an explosive lure on the Boy is up to your discretion...perhaps this is another way of winning.)
Bonus: You start with three small lures. When a large fish breaks your line or steals your fish, the lure is lost. At this point, you need to either buy more lures (which are expensive) or stop playing for the day. If you want to get fancy, you have some method of switching between lures. Otherwise, you can simply replace your current item with the most recent acquisition.

The store acts as a simple meta-game that encourages you to keep fishing in order to advance.

Progression (Bonus!)
As you catch more fish, the ocean gets more and more empty. This adds to the difficulty of finding fish. Fish always stay in approximately the same area until caught. Players will note where fish are located and be able to maneuver into position on subsequent casts.

If you wait long enough, more will respawn. If you fish out all the fish, there are no more fish left and you get a simple message “There are no more fish left in the ocean. There will never be any ever again.”

Design notes
The game is about spotting a high value fish, maneuvering your lure into position while avoiding the bigger fish and finally maneuvering your fish back through the landmines of larger fish.

In essence, Fishing Girl is Frogger using a polar coordinate system, a frog that insists on drifting to the left and only the ability to move forward.

Conclusion
So those are the rules! I've created this graphics this time in Illustrator and I've taken pains to make them appealing to Flash developers. Let me know if I've got the formatting right. I'd love to see some Prototypes of Fishing Girl playing in a browser.

So download the graphics and have fun! As with all prototyping challenges, this is a grand exploration of a new play space and there will be all sorts of interesting surprises along the way.
  • Download Flash Project (.FLA CS3): This is an import from Illustrator into Flash. There are no animations, but this might be useful if you don't have access to Illustrator.
  • Download Adobe Illustrator (.AI CS3): This has the original artwork. From here you can go to .XAML for Silverlight or bitmap.
  • Download FishingGirlPNG.zip: Bitmaps versions of all the images used.
  • Download FishingGirl.swf: A swf export of all the vectors. This is good if you don't have CS3. You may have to dig a little to find what you need, but everything should be in there.
Best of luck! If you are intrigued by these graphics, you'll love what the Mystery Project is turning into.

take care
Danc.

Update 11/1/2008: Added bitmaps and swf of all images.

Labels: , ,


Read more!

Thursday, August 21, 2008

Shade: Prototyping Challenge results

It is time to give out awards to the Shade Prototyping challenge!

Every prototyping challenge I release is a grand exploration of a particular gaming system. The concept often sounds coherent on paper, but in reality it is composed of a series of small experiments involving movement, pacing, emergence and more. After every prototype, it is worth sorting through the experiments and seeing which ones are worth investing in further and which ones should be left behind.

Game design is a process, not a bolt of lightening from the blue. You build an experiment, reinvest in the things that work and try to fix the things that are broken. After iteration upon iteration, the game emerges. In this spirit, these awards are not the end of the Shade project, but instead are an opportunity to identify the next steps.

Even in these simple prototypes, Shade shows promise as a game concept. It just needs pass upon pass of polish to turn into something glorious.


Bronze awards

First, the bronze awards. These go out to the wonderful souls that made a game.

Of great interest was the fact that most people attempted 2D implementations of the concept. This makes sense considering the wide availability of 2D tools and skills on the market. Now that I have a better understanding of the dynamics of the game, I may release an updated version of the challenge in the future that includes a set of 2D graphics and a tweaked design that allows for an easier 2D implementation.


Silver award
We had one Silver award this time around.


The silver goes to Aras Pranckevicius for his lovely 3D implementation of Shade using Unity. I got a solid 5 minutes of fun out of his prototype and lots of ideas on what to do next. You can play it here:
Without further ado, let's get into a critique of the game as it stands now. I'll be use Aras's prototype as the baseline since it include a large number of interesting experiments in action.

Moments of genuine fun
First we'll start with the elements that were distinctly enjoyable. These are seeds that can be extended much further. You always want to try to identify these dynamics early since they can act as a focal point that guides the project. When you start cutting experiments, knowing where the core fun lies can help prioritize your culling.

1) Searching for the perfect mushroom is exciting: I had a surprisingly enjoyable time finding a good sized mushroom to take back to the drop point. Scarcity emerged as a major theme of the game. Potential improvements that can focus in on this include:
  • Increase the types and varieties of mushrooms. The act of finding something valuable in the scarce wilderness has all the hallmarks of a hugely addicting activity.
  • Create different growing cycles: Have some rare ones grow slowly or only grow quickly in the presence of other plants. If the player harvests them all at once, they are gone. This adds a resource management element to the game the reinforces the sense of scarcity and value.
2) The dynamically changing world is exciting. I didn't know where a mushroom might appear. In an early prototype, mushrooms would grow in the shadow of other mushrooms. The fact that the world was living and growing was immensely satisfying.
  • Implement Munchers and Bushes: These will add immensely to the gameplay by creating a dynamic ecosystem.
  • AI Seed transporters: Add simple AI driven characters that pick up seeds and move them to new locations will very quickly create amazing patterns. For example, one type of seed transporter might move small mushrooms 2 feet away from any other mushroom. Another might move seeds into the shadow of a smaller object. These simple rules will create all sorts of interesting patterns.
  • Vary the sizes of elements: Have some objects the grow very large. These will dynamically change the landscape over time and in turn create a wildly varying shadowscape.
  • Add more elements that grow in the shadows: The patterns that came about from mushrooms growing in the shadow of mushrooms was one of the more interesting emergent properties of the simulation. It was cool! Combined with a moving sun, all sorts of interesting hedges should pop up.
Moments of potential fun
The following elements were intellectually interesting, but didn't quite leave me as entertained as I was hoping. This is quite common and just means that you need to invest a little further in the idea.

3) Jumping from shadow to shadow
: It was interesting picking my way back through the 'shadowscape' of the level. A journey back to home base where I needed to precisely plan my movements gave the mushroom hunting experience a nice tension. However, in the prototype level there were a lot of sunlit areas and relatively small obstacles. As such the decisions made on the return journey weren't that interesting. Some improvements
  • Bigger, more maze like obstacles: I notice that when I'm walking around outside, I often have to make a distinct choice: should I got left around a large building sitting in my path or right? I rarely remember the future shadow terrain on each side of the building so I end up making a short term decision to reach the easiest shade. This often hurts me in the long run.

    By adding bigger obstacles that take time to navigate and that block off other options, the player is asked to make movement decisions that have a cost. In the best of worlds, players will find themselves jumping from shadow to shadow only to end up further and further from their goal. Some will heroically find their way back. Others will remember their failure and carefully plot out the terrain the next time around. Either way, it creates more meaningful decisions.
  • More contiguous areas of shadow: Taller objects would help as would objects that are skinny at the base and bulbous on top like trees. The amount of shadows is something you'll need to balance for.
  • Hungry monsters: The tension can be ramped up by including shambling monsters that move towards you when you have a mushroom in tow. Normally, they can be quite docile and may not even move. But as soon as you get a mushroom, they turn red and make their way towards you. One touch and your mushroom loses extra power. This adds some tactical and time-based pressure to your shadow picking steps.
4) Mini Map
The minimap solves an important problem: How do I find my way back home. However, it also removes a bit of the tension that comes from wandering and finding new paths.
  • Use a beacon system instead: Instead of a mini-map, a directional highlight like the ones used in Shadow of the Colossus or Knytt would do the trick quite nicely. A little glow at the edge of the screen or a compass that always points towards home help orient the player, but don't give away the terrain.
Things that didn't quite pan out
The following are things that didn't quite work and I don't see useful ways of making them a key part of the experience.

5) Gathering long strings of mushrooms: Once you start gathering long strings of mushrooms it becomes hard to keep them out of the sunlight. I noticed that as soon as I gathered more than one mushroom, I would simply zip to the goal as fast as humanly possible and ignore all tactical decisions. This is an example of a fun idea that actually reduces the complexity of the rest of the game.

Conclusion
The prototyping challenge doesn't really end until someone creates a game worthy of a gold award. So far gold is still within reach. There are some extremely promising mechanics at play in the shade prototype and I'm open to discussing and iterating on further tweaks if anyone wants to take the design further. Feel free to post to this thread if you come up with something cool. Who is going to grab the first ever gold award in Lost Garden history?

For inspiration, I leave you with this simple game that also uses some of the growing ecosystem elements we see hints of in successful Shade prototypes. It was built in 48 hours and easily has more than 15 minutes of game play. If this fellow can find hours of fun in a short prototyping exercise, I'm convinced that you can take your existing Shade prototypes and turn them into something wonderful.
Best wishes,
Danc.

Labels: ,


Read more!

Saturday, June 28, 2008

Shade: A game prototyping challenge


As a redhead, there's a little game that I play every day in summertime called "Stay in the Shade". The rules are simple: make it to my destination as quickly as possible while avoiding all possible sunlight. This involves hopping from shade patch to shade patch. The cost of failure is the dread Irish Tan. These bizarre antics were inspiration for a game design called Shade.

As with any of the designs you find on this site, I heartily encourage you to prototype it and use it as a learning project. I know that there is a group of you itching to try out the latest 3D engines with sex-a-licious real-time shadows. This is your chance to finally use the technology in a way that produces meaningful game play.

I'll give out the much coveted Bronze, Silver, and Gold Lost Garden badges to anyone who creates a worthy prototype.




Basic gameplay
You play the part of a rugged mushroom rancher who must collect adorable sentient mushrooms living in the shade. All you need to do is run up to a planted mushroom and touch it. It will pop out of the ground and start following you around. Lead it back to the start location and you'll be awarded multiple point based off its size.

Unfortunately, it is a scorchingly hot day. You can meander about the landscape of giant grassy blocks with impunity due to your meglo-awesome wide brimmed hat, but the mushrooms wilt quickly in sunlight. To lead them back successfully, you'll need to keep to the shadows and plot the optimal path home.


Basic Elements
  • Player: The player can move about on a 2D plane using the arrow keys or a joystick.
  • Blocks: Strewn about the landscape are blocks that cast shadows.
  • Planted mushrooms: In the shadows of the blocks, planted mushrooms will slowly spawn over time. If left alone they will slowly grow in size.
  • Mushrooms: If the player runs into a Planted Mushroom, it will pop out of the ground and start following the player's motions exactly. If multiple mushrooms are collected, they will follow in a line behind the player. A mushroom can last in direct sunlight about a second before they expire. This amount of time is cumulative and is shown by slowly shrinking the mushroom as it is exposed to more sunlight.
  • Homebase: This is a spot on the ground that you need to lead the mushrooms back to in order for them to be counted.
  • Mushroom score: In the upper right hand corner of the screen is the HUD. The most important element is the Mushroom score that shows you how many mushrooms you've collected so far today.
  • Day timer: The day slowly progresses from morning to evening over 15 minutes. The shadows change position as the day progresses.
Winning the game
The game is over at the end of the day. Total mushrooms collected is entered into a highscore table.

Technology

We've had lovely real time shadows for quite some time, but very few designs take advantage of the technology. Luckily there are an immense number of cheap 3D engines that can pump out real-time shadows. Some options:
Not so long ago, this tech was the exclusive domain of techsperts like id and Epic. But now there are no excuses. And the very clever folks will figure that you can make this game in a 2D engine with a little finagling.

Art

Since this design is likely a 3D game, I'm not providing art assets. I recommend that you use cubes and other primitives for the various elements in the scene. They are inexpensive, highly effective and can always be replaced at a later point with more advanced models once you've proven out the gameplay.

With this type of game, a good amount of pleasure will come from the motion of the mushrooms following the player and the movement of the shadows over time. Slick graphics can enhance this, but they aren't necessary to find the fun. Again, no excuses.

Advanced gameplay
Once the basic gameplay is in place, there are immense opportunities for more interesting variations.
  • Movable blocks: Blocks that you can push around allow you to create optimal paths for harvesting mushrooms.
  • Muncher: Once a planted mushroom grows to a certain size and it is hit by the sun, it turns into an AI driven creature called a muncher. Munchers find a nearby green block (also known as a bush) and start munching on it. This reduces the size of the block and therefore the amount of shade it provides. Munchers can be stunned and killed by running into them repeatedly.
  • Bush seed: A dead muncher turns into a Bush seed. A bush seed is an object that can be collected by running over it with the character. If you press a button, the bush seed is planted on that location and begins to grow.
  • Multiple days in a row: What happens to the landscape if you let the world run for multiple days? With the inclusion of bushes and munchers, we have a self balancing ecosystem. As you plant more bushes, there is a greater chance that mushrooms will turn into munchers, which in turn reduce the bushes. Can you turn a simple landscape into a mushroom plantation?
Balancing
This is the sort of game that lives or dies based on balancing all the various elements. There are a number of variables that you'll need to mess about with
  • Size of the blocks
  • Number of blocks and shadow area
  • Spawning rate of mushrooms
  • Size of mushrooms
  • Amount of sunlight to kill a mushroom.
  • Speed of the character
  • Size of the map.
  • Size of the viewport onto the map.
I don't have the answers. You'll get the answers by iterating on the basic design dozens, if not hundreds of times. Keep me updated and I'm happy to provide feedback on works in progress.

The Lost Garden Awards
Once again I'm giving out the always desirable Lost Garden badges for any prototypes that result.

  • Bronze Medal: You built an interesting software toy. If you make an attempt at a design and it is interesting to futz about with, you get the Bronze Medal. Most people never get a Bronze medal due to the simple fact that they prefer to sit around and think rather than make something. Simply by doing (instead of not doing), you join an elite club.
  • Silver Medal: You found the fun. You've iterated on your design and have identified a few key elements that make the game enjoyable. There is at least 5 minutes of interesting play. It likely isn't polished and some of the higher order reward loops are broken, but the core is there. If past challenges are any indication, I'll give out only a handful of Silver Medals per challenge.
  • Gold Medal: You made the fun repeatable. The game that you've built is entertaining enough that I'm willing to play it for 15 to 20 minutes. This is a hard level to reach and it is only populated by the most elite cadre of weekend warriors. An entire production team could be seeded by your efforts. To reach this level, you've made some critical design steps beyond the initial concept and built unique and sustainable gameplay based off dozens of game play iterations. To this day, no one has won a Gold Medal. You could be the first.

You need to post a public, playable version in order to be eligible. I'll issue the rewards about one month after the initial challenge is posted. If something comes in after the original deadline has passed, I'll add it retroactively to the award post. If you win a Bronze or Silver, you can still come back later and make an attempt at the Gold. Anyone who gets a Gold medal is an automatic rock star in my book.

What do you get if you win? First off, you get the right to post a snazzy LostGarden medal on your website. Most importantly, you get that warm fuzzy feeling in your tippy-tip toes that stems from a job well done.

Conclusion
Shade is an interesting game design to me for the following reasons
  • Exploration-based play: The joy is in exploring the ever changing landscape and finding mushrooms and interesting paths back home. It is more strategic than action oriented.
  • Simple controls: All you need to play are directional controls and one button. It should be pretty easy to pickup.
  • Non-violent: In general there is very little combat. I like this. I can imagine the title having a very meditative feel.
  • Uses real-time shadows for some unique gameplay. Real-time shadows have been used for sneaking games, but little else. Surely it is time to expand the number of games that use this fascinating technology.
Enjoy! If anyone makes something and puts it online, I'm happy to discuss it on the website in a follow up post.

take care
Danc.

Past challenges
Mockup


Labels: , ,


Read more!

Tuesday, May 27, 2008

Lostgarden looking for brilliant programmer in Seattle

a mystery project

Summer project time! I've got an intriguing new design that is best explored by the sort of in-person rapid prototyping that I love. To that end, I'm looking to team up with a talented programmer or two from Seattle/Redmond. It's a bit like getting a band together.

My dream is to meet up every Sunday at a local coffee shop, riff about what we've done that week and come away energized and ready to build some more.
  • Location: Seattle/Puget Sound area is a must. (Otherwise, it is hard to do the coffee shop thing)
  • Skills: Solid Flash, Flex or Silverlight skills. Previous experience with Java, C++, or C# is great as long as you are willing to learn Flex. Back end skills are also helpful. The project is 'technically interesting' and is best tackled by someone who is more of a programmer than a scripter.
  • Time commitment: 10 hours a week for about three months. Anything less I've found doesn't make it worth your time.
I'd contribute art, design and Cheetos (organic or radioactive). If you are interested, drop me a note at Danc [at] Lostgarden [dot] com. Send along a portolio if you've got one and tell me a little bit about yourself.

Take care,
Danc.

Labels: , , , , , ,


Read more!

Saturday, March 15, 2008

The Randomly Reinforced Lost Garden Prototyping Awards

What a whirlwind of a month it has been. GDC was crazy fun, the latest beta of Expression Design came out at MIX, and I decided to take a leap and start in a new position at work. In the meantime, some great games were created in the last prototyping challenge.


Let's reward awesome developers

You know what? I think it is time for an award ceremony. I've been meaning to do this for a while, but never got around to it with the previous prototyping challenges. Here are the awards and how they are handed out:
  • Bronze Medal: You built an interesting software toy. If you make an attempt at a design and it is interesting to futz about with, you get the Bronze Medal. Most people never get a Bronze medal due to the simple fact that they prefer to sit around and think rather than make something. Simply by doing (instead of not doing), you join an elite club.
  • Silver Medal: You found the fun. You've iterated on your design and have identified a few key elements that make the game enjoyable. There is at least 5 minutes of interesting play. It likely isn't polished and some of the higher order reward loops are broken, but the core is there. If past challenges are any indication, I'll give out only a handful of Silver Medals per challenge.
  • Gold Medal: You made the fun repeatable. The game that you've built is entertaining enough that I'm willing to play it for 15 to 20 minutes. This is a hard level to reach and it is only populated by the most elite cadre of weekend warriors. An entire production team could be seeded by your efforts. To reach this level, you've made some critical design steps beyond the initial concept and built unique and sustainable gameplay based off dozens of game play iterations.


You need to post a public, playable version in order to be eligible. I'll issue the rewards about one month after the initial challenge is posted. If something comes in after the original deadline has passed, I'll add it retroactively to the award post. If you win a Bronze or Silver, you can still come back later and make an attempt at the Gold. Anyone who gets a Gold medal is an automatic rock star in my book.

What do you get if you win? First off, you get the right to post a snazzy LostGarden medal on your website. Most importantly, you get that warm fuzzy feeling in your tippy-tip toes that stems from a job well done. This is a geeky challenge done for lurve of the game.

The Results
In my mind, the entire point of the Player with Your Peas exercise was to take a complex design with some potentially messy rat holes (user created levels, physics, path finding, oh my!) and see if you could quickly find the fun. Let's see how folks did:

Bronze Medals

All the prototypes were enjoyable for a couple of core reasons. First, building a world out of little blocks seems to be pleasant at a very simple level. Second, for those who implemented pathfinding, there is something inherently interesting about watching little creatures navigate your world on their own.


Silver Medals

Richard Sims' prototype came closest to capturing the fun. He focused on the falling peas portion of the design and managed to add in a solid pass at the combo scoring system. This moved his prototype beyond being merely an intriguing software toy to the point where one could imagine there being a real game. I played with it for more than five minutes.
Some lessons from Richard's prototype that are worth noting:
  • Focus on prototyping the important gameplay, not the tech: What was nice about Richard's prototype is that he skimped on much of the climbing and jumping portions of the design. Those weren't key to the 'fun' of the design so they could be done later. Knowing what to test first out of your usually exhaustive brainstorming session is a great skill to hone. Just because something is hard (like the pea pathfinding) doesn't mean it is the first thing to tackle.
  • Answer at least Three Why's: Richard's game links together several game atoms together in a sequence. Simple actions have meaning within the game. Most of the other prototypes only had isolated game atoms. There was very little reason for doing things. Here's a little description of the Three Why's that illustrate how they are used:
    • Action: First ask"What is your player's core action?" In this case, it is building blocks.
    • Why? Now ask "Why?" The answer is to give something for the peas to bounce against.
    • Why? Ask "Why?" again. The answer is because the peas generate combo points if they hits lots of blocks.
    • Why? Ask "Why should I care?" once more. Because combo points increase your main score and you need to get as big of a score as possible.
    • Good enough! At this point, the player who is clicking to add blocks probably has lost interest in asking why he should be building blocks. There are enough overlapping reasons that the justification circuitry in his brain is satiated. He'll keep building blocks until all the subsequent game atoms are exhausted.

Gold Medals

No one captured the Gold Medal on this challenge! Doh. This award remains wide open until someone submits an amazing prototype with 15 solid minutes of play. Hmm...I wonder who can make a Gold Medal version of Play with Your Peas...

There were several others folks that worked on the game, but I didn't have public links to all the playable versions. If you have some more, send them my way (danc [at] lostgarden [dot] com) and I'll add them to this post. Yes, Harold, I'm looking at you.

Woot! That was fun. Now I feel like Jon Stewart. Except less witty. Or famous.
Danc.

Labels: , ,


Read more!

Wednesday, February 06, 2008

Play With Your Peas: A game prototyping challenge


Oh la la! It is time for another game prototyping challenge. As has become the tradition around here, you provide the brilliant code and I provide you with a complete set of free graphics that help make you look spiffy.

This game design stems from a peculiar fetish of mine. I don't normally talk about this in public, but...how to say this. I have a thing for casual building games filled with adorable little creatures. Late at night, when the rest of the world is busy sleeping, you'll find me fantasizing about the lurid offspring of Lemmings and SimGolf. For a moment, close your eyes and savor the sweet thought of DMA's DNA all mixed up with Will and Sid's unappreciated love child. Oh yes.

The game idea inspired by these questionable thoughts is called Play With Your Peas. Here are the basics:
  • Peas: You have a bunch of fun loving sentient peas that like to climb tall objects and jump off of them. They think they are ninjas. You know they are suicidal.
  • Happy points: If the peas land safely, they generate happy points. The more things that they bounce off of on the way down, the more points you get. Think of a successful pea landing like scoring a combo in Tony Hawk.
  • What you do: Here's the trick. You can't manipulate the peas. You can only add blocks to the landscape. Add a soft landing spot and your falling peas won't splat. Add a spring in the right spot and they'll fly up into the air. Can you build a brilliant playground that delights your peas?
  • Score: Your score is the time it takes you to reach 20 million points. If you want to simply play with your peas, go for it. If you want to beat the high scores, you must be Elite and build your landscape with great efficiency so that you maximize your pea combos.
Many thanks to Axcho for dredging up this ancient design from the dusty storage shed of my past.


Game Tokens
There are only a few types of elements on the screen
  • Peas: Little AI characters that run around the environment. You can't interact with them directly.
  • Plate: All action takes place in a box that bounds the sides and bottoms of the screen. No objects can exist outside of the screen.
  • Blocks: The user can place blocks on the screen. There are multiple types of blocks such as platforms, springs, jello and more.
  • Flags: These mark the spots where peas have lept from in the past.
  • Tools: A sidebar of tools that lets you choose the type of block to place.
  • Happy Score: A counter that tells you how many happy points you've collected so far.
  • Time: A counter that tells you how much time has elapsed since the beginning of the level.
Basic Pea AI
Peas have three main modes:
  • Navigating the environment: In its primary mode, the pea navigates the environment in an attempt to reach a jumping spot.
  • Falling: When a pea is falling, it is treated like a simple bouncy ball interacting with the world.
  • Being scored: Once a falling pea comes to a rest, it is scored.
Navigating the environment
The peas traverse the environment in search of ledges to jump off. This is the hard part of building this particular game design. I'll describe the high level behavior, but I leave the implementation as an exercise for the mad programmers of the world.
  • Look for a ledge: After a pea is scored, it immediately looks for a nearby ledge to jump from.
  • Wander: If there is no ledge nearby, the peas wanders in a particular direction, slowly climbing over obstacles and working its way up as high as possible.
  • Calculate path to ledge: When it finds the ledge, it calculates a rapid path to the ledge.
Moving smoothly across a complex environment can be broken down into a series of movement segments.


  • Walk on a flat surface:
  • Climb a block wall: Some blocks can be climbed, others cannot.
  • Climb up a ramp: Some ramps can be climbed.
  • Jump a gap: If there is a 1 square gap, a pea can jump over it. Remember they think they are ninjas.
  • Wall jump: Peas can also jump onto a wall that is 1 square above their head to the left or the right. Think of this like moving how a knight in chess moves.
Jumping spots.
A block surrounded by space has two default jumping spots, one on the left side and one on the right side. Once a pea reaches a jumping spot, he will jump. A couple things happen at this point.
  • A flag is automatically planted at the jumping spot.
  • The pea jumps and his AI switches from navigating the landscape to being a simple bouncing ball.
The flag tracks several things
  • How many peas have jumped from the jumping spot. As the number gets closer to 100%, the flag slowly rises to the top of the pole.
  • If a peas spots multiple jumping spots, they will always head towards the jumping spot that has the highest completion percentage. This ensures that the user is focusing on one or two jumping spots, not a half dozen.
  • When the flag reaches 100%, the jumping spot becomes inactive and no other peas can jump from this location. The user gets a large bonus for having a completed jumping point.
  • Peas remember which jumping spots they've jumped from and will not jump from that point again.
The flag also serves an important balancing role. Once a flag is planted, several building limitations come into play.
  • The user cannot place another block on the square occupied by the flag.
  • The user cannot remove the block under the flag.
These rules prevent the user from recycling jumping locations and they also slowly eat up the space on the board so that the user needs to work around the detritus of their previous efforts.

Bouncing
When your pea falls, it bounces off of blocks that get in its way. Some blocks, such as gelatin, slow you down. Others, like springs, give you an additional boost. However, your pea is not indestructible.
  • If you land on a standard block after falling a distance more than two blocks, you pea will die. A dead pea means less opportunity to score.
The skill of the game is building environments that yield the maximum number of bounces while still managing to land your peas safely in the end.

It is possible for the player to create cul-de-sacs where the pea will bounce indefinitely. One potential balancing feature is to add in a counter that keeps track of how many times specific blocks have been hit. If the hit count on single block gets too high, the pea yells out 'It's a trap!' Even if a trapped pea is released, you get no points.

Scoring
When a peas finally comes to a stop and it survives it's journey, it gets a happy score.
  • Happy score = Total bounces * (Spring Bounces * Spring Value + Normal Bounces * Normal value + Gel bounces * Gel Value + Successful Landing)
The pea's happy score is added to the player's total score. This is a moment of grand celebration. If you have a particle system, this is a great time to use it. I've provided graphics so that a happy pea can yell out "Ninja!", his career aspirations finally complete. Once the peas is scored, he moves on and starts looking for a new jumping spot to leap from.

Building blocks
Okay! Now we have some cute little characters that jump about the screen in some logical manner. Finally, it is time to talk about building your world.

Along the left side of the screen is a toolbox that contains the blocks you can use in the level. To select a block, click on it and it will highlight.

To place the block, click on an empty square. The blocks aren't added immediately since they have a build sequence they must follow.
  • Initial delay: We want to prevent users from micromanaging the flow of their peas by quickly placing blocks. In order to do this, blocks stay ghosted for a short period of time before they fade into solidity.
  • Check for peas in the square: While the block is ghosted, any peas that are in the space can move out of the square without colliding with the new block. This helps us avoid accidentally squishing peas.
  • Block peas moving into the square: New peas that try to move into the square are collided with using the collision rules associated with that block type.
  • You can place other blocks while a block is in the process of being built.
Deleting blocks
You can remove blocks as well.
  • First click on the delete tool.
  • Your cursor will turn into the red delete cursor. Feel the power!
  • Click on the block you wish to delete. As you mouse over the block
  • The block will become ghosted. There is a short delay before the block is removed.
  • After the delay is over, the block finally fades away. During the exit animation, peas will pass through the block as if it isn't there.
  • You can delete other blocks while a block is in the process of being deleted.
Remember, you can't delete a block that has a flag attached.

Standard Blocks
  • Climbing: Peas can climb the sides of the block.
  • Walking: Peas move across the surface of the block at full speed.
  • Collision with top: Falling peas stop when they land on the top of the block. If the fall is greater than 2 blocks in height, the pea dies.
  • Collision with side: Falling peas bounce off the side
Spring Blocks
  • Climbing: Peas can't climb the sides of the block.
  • Walking: Peas move across the surface of the block at full speed.
  • Collision with top: Falling peas are launched upward with greater velocity if they fall on the top of the block. Angle of incidence equals angle of reflection.
  • Collision with side: Falling peas bounce off the side
Gelatin Blocks
  • Climbing: Peas can't climb the sides of the block.
  • Walking: Peas move across the surface of gelatin at 1/2 speed.
  • Collision with top: Falling peas stop when they land on the top of the block. Gelatin provides a safe landing spot for high jumpers.
  • Collision with side: Falling peas bounce off the side
Ramp Blocks
  • Climbing: Peas can climb the backside of the ramp.
  • Walking: Peas climb up or down the ramp at full speed.
  • Collision with top: Falling peas bounce off the sides of the ramp at an angle and lose a little velocity. If they hit the ramp from a height larger than 3 blocks, they die.
  • Collision with side: Falling peas bounce off the side
Winning
In order to win a Play With Your Peas session, you need to complete certain goals on a level, much like Tony Hawk. The simplest is "Reach X number of points". Your final score is the time that it takes you to reach the goal. A new player might take 10 minutes to reach 10,000,000 points. An expert player, skilled in crazy combos, might take 2 minutes.

My hope is that casual players will have fun figuring out the system, setting up interesting combos. They'll generally ignore the clock. Eventually, they'll reach the goal and feel good about 'beating the game'. Their score is then compared against a number of other times in a high score list.

More driven players will feel a natural urge to compete by replaying the level for a better time. To facilitate this, we should have "Try Again" button on the high score screen.

Areas to prototype
Even though this design has a relatively small number of moving parts, the emergent behavior should be complex. There are three distinct areas that well are worth prototyping. I've listed them in order of priority.
  1. Pea falling physics: In order to do the pea falling correctly, you need a simple physics engine that deals with balls and planes.
  2. Block and scoring balancing: Balancing the size, properties and scoring of each block is a classic balancing problem. This is an area that will likely take hours to get right.
  3. Pea navigation: If you can get peas traversing a series of blocks in a smooth and believable fashion, you are halfway through the design. This involves some tricky path finding. If you want to stub this behavior out, spawn peas at a jumping flag and remove them once they are scored.
Some design notes
One problem that is common to AI-driven systems is that most of the behaviors go on underneath the cover, away from the player's eyes. It is very easy to fall into the trap of creating an intricate AI that 'plays itself' but is completely incomprehensible to the player.

Instead of asking how you might make the most realistic AI system, I prefer to steal a page from Nintendo's playbook. Instead ask "What is the simplest system that drives forward the player experience?"

Peas climb. Peas fall. Peas get scored. All of these activities are very apparent to the user. Instead of complex internal logic, the design focuses on explicit external behaviors. Any internal logic such as the path finding system exists only to the minimum degree necessary to support the external behavior. We won't build SkyNet using these sort of AI techniques, but we can make more enjoyable games.

Conclusion
If you create something inspired by this prototyping challenge, send it this way! I'll post it on the website for everyone to check out and comment on. Take shortcuts, mangle the design, find the fun.

Enjoy!
Danc.

Assets
I've provide the graphics for PlayWithYourPeas in two versions. First, all the graphics have been saved out as PNGs. I also included the Expression Design source file so you can make modifications to the original vectors.
References
Updated 2-11-2008: I added in the Block-Place-Normal.png to the zip that was previously missing. I also fixed some of the file names.

Updated 2-14-2008: I renamed the Ramp tools so that they follow the same naming convention as the blocks. The pea shadow is now seperated out. The single pixel alignment errors on the tools and the normal block are now fixed.


Labels: , , ,


Read more!

Saturday, September 15, 2007

Tree Story wireframes


I've been dabbling with quick wireframes to explain the design of Tree Story. There are two common ways you can look at a spec.
  • One is that of the blueprint, a plan that will be rigorously followed by production workers in order to achieve the end result. In this model, the team members are followers who are expected to implement a list of fixed details, not innovate.
  • The other is that of a communication tool. As a communication tool, you are trying to seed key concepts in your team so that they can take ownership and run with the idea during implementation. In this model, the team members are ultimate owners of the final design and the 'designer' is more of a facilitator of the process. Any spec exists only to spark conversation so that the team can build up a shared understanding of the feature's goals.



I've found that text is rather horrible as a communication tool, especially with small teams. It takes too long to iterate on and starts bogging down as soon as there is more than one person editing the document. Even worse, text fails horribly when describing anything visual or tactile.

Instead, I'm a big believer in using storyboards augmented by multiple discussions around a whiteboard, especially for early discussions. The story boards / paper prototypes can be quite concrete, but they are still visual and tactile enough for two or three people to stand around and comment on.

The iteration process is straight forward:
  • Whip up a quick storyboard. Limit yourself to spending 30 minutes to an hour on it. Make it very rough.
  • Print your latest 'official' wireframe on the biggest paper you can lay your hands on,
  • Tape it to a whiteboard and nab the first person you spot on your list of influencers.
  • Brainstorm around the idea. The taped version acts as a starting point for the conversation and an anchor if the conversation gets lost.
  • Immediately update the wireframe with the new thoughts.
  • Rehang it on the wall. Ideally look for a spot with a lot of traffic.
  • Rinse and repeat.
Within a short period of time, you have a design that:
  • Is easily understood in a glance.
  • Is understood by multiple team members. The story board acts as quick reference to your indepth conversations.
  • Is up-to-date.
  • Is a conversation starter for the rest of the team. I've had the best results when my desk is positioned near where the drawings are hung and I can leap out and chat with people wandering by.
Example wireframes
Here's a stab at some wireframes for Tree story. Sorry that we don't have a good white board built into this blog. Someone needs to fix that. :-)

The basics of communication
In Tree Story there are NPCs you can chat with. Here is how.













Picking up objects
You can also pick up objects and drop them where you desire.
















Planting seeds
A special type of object is a seed. It lets you grow new platforms in the world.








Each seed creates a different type of tree. Use different sized
trees to reach different areas or grow interesting fruit.




These were done in a vector drawing tool because I find wireframes use a lot of objects that are the same. I personally prefer to copy and paste instead of spending time redrawing. However, they could just as easily been done by hand. They are likely a bit more detailed than necessary, but I'm compensating for the rather low bandwidth nature of a blog.

take care
Danc.

Weather system
PS: Here are some additional wireframes that describe how a sunlight and weather system might work. This could be used with Clint's idea for the weather trees and machines.






Labels: , ,


Read more!