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:
My wife played it and she likes it. It passed the Wife Test.
Played by about 280,000 people...100,000 in the last day.
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?
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.
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!
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.
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.
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.
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.
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.
Review: Afterwards, we discuss our observations and write up another Post-it note worth of improvements.
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.
Rate: At the end, the gameplay experiment is rated according the scale below.
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.
"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?"
"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.
"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.
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?
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:
Explain the model to a crowd of natural skeptics, working designers who have been successfully building games for years.
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.
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:
Casting
Positioning the lure
Hooking a fish
Reeling in the fish
Scoring the fish
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:
If you click your button once, the girl will pull back her pole to cast.
If you do nothing, the pole will return to the default position.
However, if you press a second time in the middle of her swing, she will cast the lure outward into the ocean.
The closer the second click is to the peak of the swing the further the lure travels.
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.
The Fish
The Lunge
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 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.
This site is about art and game design. You'll find galleries of my latest illustrations. Also, I have extensive ramblings on a wide variety of game design topics.
Why people read this site
"[...] probably the most interesting article I've ever read." Tycho from Penny Arcade on the Nintendo Innovation Strategy article
I've been a game designer, pixel artist, painter, tools designer, product manager and marketing guy. I got my first job while in college working on a shooter called Tyrian at a little company called Epic Megagames. These days, I'm designing games deep in the forests of the North West.
I remain, to this day, not a chickadee plucker. Despite the rumors.
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:
