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!
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.
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.
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.
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.
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.
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.
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.
Pea falling physics: In order to do the pea falling correctly, you need a simple physics engine that deals with balls and planes.
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.
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.
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.
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.
Yesterday morning I woke up from one of those startlingly lucid dreams where I was playing a completed game design. I tell my wife that odd ideas are like exotic fruit and if you fail to jot them down, they will rot away, never to be tasted again. So here are my quickly captured notes of what is, literally, a dream game of mine. :-)
Imagine, if you will, a space strategy game. You start out with a single planet surrounded by hostile enemy planets. Your goal is to clear the map of enemies and create a galaxy spanning civilization. All pretty standard stuff.
The difference is that you fight and grow using music that you compose by building your empire. This is where it gets trippy.
Planets as sequencers Watch this movie clip of a multi-touch music creation tool. It is wonderfully bizarre.
The basic gist, multi-touch madness aside, is that smart objects positioned on a flat screen can be used to create music. Link them together using a directed graph and you have a pretty competent music sequencer and sound effects generator.
The game design leap is that these objects can also be planets in a strategy game. Each planet has a different effect.
Forest planets are sources for sound effects
Water planets are filters for distorting a sound.
Cities planets are sequencers for taking a sound stream and playing it out over time.
Throughout the design, you’ll see that every element can be seen in two ways. One is as an element of a song. Two is as part of a game.
Linking planets Each planet has a space port. You can drag a space lane from a space port to another nearby planet.
In the process, you connect a sound source to a sound processor. In very short order, just by linking up space lanes, you can create a giant sequenced sound machine. At the same time, you are directing trade and setting up your space empire. Setting properties on planets Each planet is a fanciful user interface that lets you adjust the properties of the filter.
Planets have a sun. You can adjust the time it takes for the sun to go around the planet in order to adjust the timing of how long a sound plays. In the game this is described as planetary engineering
Distance from the other planets effect the volume of the source sound effect.
City planets allow you to adjust the height of the cities, thus allowing you to adjust how you sequence a sound source.
Music = culture = resource Each planet produces a sound. Some generate sounds. Others take in sounds and modify them. The stream of sounds produced by your planets is what most folks would call music. It also represents ‘culture’ in the game. Culture is the resource that makes everything in the game work.
Culture pools in planets that are the final destination of sound streams. They collect it in real time. Culture can be spent on upgrading your planets and creating war ships, defending against attacks.
The enemy does not sleep You are not alone in the universe. There are other planets on the fringes of your empire. They send ships to destroy your civilized worlds and knock them back into desolate husks. They’ll disturb your carefully calculated rhythms, disrupt trade routes and generally cause your empire to devolve into chaos, then silence.
If a planet is attacked enough, it will be turned into a dead world, devoid of music.
Spending culture Luckily, you can use your culture to both defend, fight back and ultimately conquer the enemy planets.
Some planets have industrial complexes. An activated industrial complex sucks in culture and converts it into ones of three main types of ships
Defenses: The planet builds a shield for fending off enemy attacks. It can take X damage per second. Defenses tend to beat equally matched ships.
Attack ships: The planet can send out a stream of attack ships. If the planet is poorly defended, the planet is slowly bombed into the stone age and reduced to a simple forest planet.
Ambassadors: Ambassadors convert dead planets into player planets.
At first you defend against attacks. Then you fight back. Eventually you conquer the enemies and make their worlds yours.
The benefits of conquest Conquest is great. Capturing new worlds allow you to build more complex sequences of sound. This means more interesting songs. It also means that culture accumulates faster and allows you to expand your empire further.
Some planets have tidbits of plot, mysteries, single use powerups, treasures and other rewards. Conquest advances the player in the game.
Culture is multiplied by audience appreciation An empire is a song. As a song it can be shared with your friends outside of the game. At any point, you can send a link to your empire to a friend. They can check it out and simply by the act of listening to your song, your empire gains marvelous bonuses.
If they like, your friends can rate the song. This gives you even more bonus culture. If they like the style of your songs, they can subscribe to your various empires. This gives you even more bonus. By sharing your creations with the outside world, you gain resources that let you advance your single player game.
A game that encourages the creation of great songs The game is balanced to encourage this. During the early stages of creating your empire, there is enough culture in random combinations of planets to conquer a fair portion of the map. Eventually, you start running out of culture. You’ll come across powerful enemies that you cannot defeat unless you start sharing your songs with others.
Good songs, as judged by an audience of your peers, will gain you greater rewards than random garbled messes of sound. Judging music is hard for a computer. However, it is easyier for people. The design harnesses your friends as our AI judgment algorithm to encourage and reward the user to become a great composer.
Some maps can be explored and beaten if the player creates songs that are enjoyed by one or two people. Other maps require that the player create songs that are loved by hundreds.
The enemy as a tutorial The map creation for the game is tricky since it serves two purposes. The first is to provide a challenge to the player. This is pretty straight forward level design and deals with choke points, resources, power ups etc.
The second, more devious goal, is to teach the player compositional structures. The enemy worlds are a nodal graph of a song just like the player’s worlds are a graph of a song. The level designer composes the enemy empire as a song.
All the various tricks of making a song are there for the player to see. The way that you distort a basic sound into something intensely cool. The way that you use a sequencer plus a snare sample to create the beat. All of it is visually laid out as a working model for the player.
When the player conquers the enemy worlds, they are essentially deconstructing the level designer’s song filter node by filter node. The player is then asked to put their newly acquired node to use. The easiest thing would be to replicate what was already done.
What we have is an experiential lesson in music composition masquerading as a game.
The player observes a functional model.
They dissect the model to understand its parts
They are required to reassemble the model and make it work again.
They are rewarded for making something better than the original.
Conclusion I finally got around to reading Rules of Play by Katie Salen and Eric Zimmerman. The tome repeatedly emphasizes that you can analyze a single game through multiple perspectives. Celestial Music is a game that is two things simultaneously. It is a strategy and it is a music creation tool. It is also, by the fact that is both of these things, a system for exploring and learning music in a user friendly manner.
Games lubricate experiential learning about a system. Plunk an inexperienced person down in front of a piano and some sheet music and they will become frustrated. Sit that same person down in front of a game like Celestial Music and they will slowly learn. The result may not be Mozart, but it will certainly be music.
As I awoke groggily from my dream yesterday, I was left with the amazing memory of playing this quirky game. Sound and visuals flowed throughout the screen like some clockwork instrument pulse with life. There was no real distinction between building something beautiful and playing an enthralling game. Delightful.
Take care Danc.
References
Human computation Humans are far better at some activities than computers. Luis von Ahn is a computer scientist at Carnegie Mellon that studies how to tap into the abilities of people to solve hard problems like image recognition or human identification. He uses games as his medium. The fact that people are better than computers at determining what is meaningful music is leveraged in the Celestial Music design. http://video.google.com/videoplay?docid=-8246463980976635143
I've been filling notebooks with extensive sketches of worlds built out of a single homegrown tree. Houses, monuments, clouds, vines and more, drooping, draping and bursting forth in a blossom of growth.
Last night I had a chance to jot down some of the graphics in Painter. My few hours of effort resulted in a basic tree trunk, some foliage and a little girl. Overall, I suspect this would be a pretty easy game concept to get up and running.
Further implementation thoughts Harold stopped by last week and we brainstormed a little on the Tree Story idea.
Collision detection: The foliage uses 1/2 circles as a the collision detection zone instead of the typical rectangles you find in most platform games. This should give the worlds a bit more of an organic feel and results in some simple controls. For folks that have been playing with the Space Cute graphics, you may be able to reuse your existing collision detection systems.
Bundling to create platforms: By overlapping a few simple foliage brushes, you can create interesting and realistic trees.
Blurry parallax layer for depth: You can create a feeling of depth by putting blurred foliage on a parallax layer behind the main action. Scroll this layer at a slower pace than the main layer that the player is on and it will seem like the scene has perspective.
If anyone is interested in playing with some of the graphics, let me know and I can upload a few in a more reasonable form. Before implementing images, I'd recommend first creating two simple prototypes:
Movement prototype with primitive half circles for terrain and a blob for the player to test out movement and the 'fun factor' of the design.
Tree prototype: Use long rectangles and half circles to see if you can auto-generate interesting trees.
Hope you are well on this rainy Seattle sunday afternoon. :-) I think it is time for a bit of tea.
I just wanted to share a quick design that occurred to me this morning. This isn't a design challenge since I don't have new graphics for it. We watched My Neighbor Totororecently and my brain has been quite inspired by the scene where Totoro grows a giant tree from a seedling. I imagine that with a sufficient level of polish, this game might inspire some of the same feelings of delight and awe.
So I present to you Tree Story, a platform game where you grow trees in order to collect all the pieces of your broken heart.
The Tale One upon a time, a young girl in love sang a most beautiful melody. A Bird of Fate, called by her song, blew through the window and struck her full upon the chest. Her heart shattered and she could love no more. Full of sorrow, she left her lover behind and began wandering the earth. She sits now alone on a land that borders a distance sea. All around her is emptiness. The only thing she owns is a single seed. If she plants it, it will grow into a tree. Perhaps, if she is strong enough, she can regrow her world and rediscover the pieces of her heart. Only then can she love again.
Movement You control a character that sits in the middle of a scrolling screen. On the screen is a simple scape made of branches and foliage. At the bottom of the screen is the sea. You start on a small island in the middle of the sea.
When you press left and right, you can walk around the circumference of the tree foliage until it becomes completely vertical. Your character is always oriented relative to the normal of the foliage.
You can jump using the jump button (the up arrow)
When you jump, you jump straight out from the normal of the foliage. However, gravity points downward.
You have some slight air control when in the middle of a jump using the left and right arrow keys.
If you hit another bit of foliage, you grab on and reorient yourself to the new foliage.
Objects There are many objects that are strewn about the world. You can interact with them in a variety of ways.
Picking up a seed: If you happen across a seed object, you can pick it up by running into it. You can only have 1 seed at a time, so if you run into another one, you will ignore it.
Using a seed: You can plant a seed by pressing the action button. When the seed is planted it will sprout into a tiny branch with a new bit of foliage. This slowly grows on its own until it reach a small fixed size.
Picking up flowers: If you happen across a flower object, you can pick it up by running into it. You can have as many flowers as you want at a time.
Growing a branch: If you stand at the base of a branch, you can feed it flowers in order to make it grow. By standing at the base of a branch, a HUD appears that instructs you how to perform the basic growing action. Hold down the action key and press up. Your flower count will decrease and the branch will grow. I can imagine turning this into a simple rhythm game, but for initial prototyping it is okay to keep it simple.
Bending a branch: You can also bend a branch. Stand at the base of a branch. Hold down the action button and press left or right. Your flower count will decrease and the branch and its foliage will grow. Branches can only be bent so much.
Chopping off a branch: You can remove a branch. Stand at the base of a branch. Hold down the action button and press down. A meter builds up and you give the base a mighty blow. The branch and any attached branches will be turned back into seeds that fall to the ground.
Picking up a star: Stars hang in the sky. Most of them you cannot reach. However, if you grow a tree, you can climb upon it and reach a star. When you catch a star, it pops and spits out a random prize. The prize could be a branch seed or it could be a dozen flower seeds. The prize falls down and rests upon whatever foliage it hits. Flowers seeds immediately blossom into flowers when they hit foliage.
Picking up a heart: If you happen across a piece of the young girl's heart, you can pick it up. Collect enough pieces and the girl is able to love again.
The basic game play You start with a single seed that grows into a tree. You climb upon the tree and reach new stars. When you collect them they sprout into seeds and flowers. When you collect the seeds and flowers, you can grow new branches off your old tree. This in turn allows you to reach more stars and grow more branches. Eventually, you collect all the hearts and win the game.
Advanced game There are numerous types of seeds, each of which creates a different branch.
Tall branches
Fat branches
Branches that sprout extra flowers all on their own.
Branches that sprout a specific type of seed if you feed them flowers.
Branches that are homes for little creatures. They tell you hints, bits of story and give you goodies. Give them a seed of the desired type and they may give you a rarer seed in return.
Branches that teleport you to another sister branch
Branches that sprout powerups that give you temporary flight or super jumps or double the number of goodies that you get from stars.
When night falls, more stars appear. When day comes, more flowers sprout and trees grow larger. There is a natural rhythm to the game world, despite its simplicity.
Winning the game There is only one level in the game. This is not a puzzle game where you beat carefully designed levels. It is a playground game where you build and build and see how far you can get. The more hearts you get, the closer the girl becomes to achieving true love. Players who win will have built hundreds of branches and their tree will cover the entire map.
The game can be won, but it can't really be lost. If you come back to your saved game later, new flowers will have sprouted and new stars will have appeared. The little creatures on the map will have new trades and they'll let you know that they missed you.
So there you have it. There is a dash of Animal Crossing mixed with a hint of Knytt and a whiff of Little Big World. And of course, the spirit of Totoro. In my head, at least, it all seems like a pleasing way to spend an afternoon. :-)
Update (6/6/07) Ezin has made the source to his delightful Flash-based prototype available. If you want a jump start on how tile layout and shadows work, this is a great starting place. Thanks, Ezin!
Folks have been busy! The PlanetCute prototypes got off to a great start last week and there is still some great work being done with the SpaceCute concept. I count 11 glorious links to check out and analyze. If I missed any, let me know. Big kudos to everyone who has participated so far.
Think of these as inspiration for your next iteration. The challenge goes on. Each example here was done in a few stolen hours over the course of a week or two, so the challenge has proven itself to be quite feasible. For those with little time, I find it heartening to realize that the real trick to making a game is simple. Consciously set aside a few hours each week and create something.
As promised, here they are...
Sokoban, baby Kev over at cokeandcode.com built this wonderfully polished sokoban game that add the additional madness of height to the puzzle. I still can't get by level 2, but the first level had me grinning. :-)
My Game Builder: Web-based game editor The creative team over at Jolly Good Idea is using PlanetCute tiles in their amazingly extensive online game building tool. This is a great example of Flex in action. It was created by one programmer in his spare time over the course of half a year. There is a full on pixel editor, mapping tool and system of setting up basic game mechanics.
Quarry game Brwn 2.0 (aka Ahad L. Amdani) posted a game of his that used a similar stacking mechanic. It is a good source of inspiration and shows how stacking can be combined with cute little semi-autonomous agents.
PlanetCute in 3D! n.n. listened to the feedback about the perspective and height and wondered what the game would be like in full 3D. I can't wait to see where this goes.
Terrain effects and patterns in GodCute Ezin is closing in on getting the core mechanic working. He has the terrain moving up and running. The shadow system is in place. He's added a wonderful set of terrain rules that result in grass growing over exposed dirt and stones sinking into water.
The first case of pattern matching is working, but there is no reward or feedback system for completing patterns. Enjoyment level is low. I'd recommend adding a scoring system temporarily to encourage the player to have a reason for completing patterns.
Shadows and vertical tile movement in GodCute Corsix extended his wonderful little editor to include some of the concept of moving tiles around. He also implemented the shadow system to great effect. In particular, we see the inclusion tiles moving up and down independent of the grid. This is an effect that I suspect can be quite useful as we move forward in the prototyping. Just because the tiles are blocks doesn't mean that all mechanics need to take place on a grid.
Corsix also improved on his map generation algorithm to create smoother, more visually appealing maps.
Phage: Game demo Matt came up with an interesting variation on Every Extend. He says "The object of Bacteriophage is to kill as many bacteria with each available Phage as you can. You begin with 10 Phages. Simply move your Phage to the place of your choice on the screen, preferably near large numbers of bacteria, and left-click to blow it up. Right click to randomize the field for better shot looks. Your phage will detonate and expand for a brief time before vanishing, killing any bacteria that overlap or come too near it. You get increasing numbers of phages as bonuses for "fighting off" a series of bacterial infections each 5 levels, so use your phages wisely."
Why shadows matter (and first prototype!) Bjoernke started things off with this great demonstration of how hard it is to correctly interpet height when the shadows tiles aren't used. Perspective is confusing Hunty came to a similar conclusion with his Flash-based demo. He raises the very interesting point that perhaps the perspective is inherently flawed. This point spawns some good discussion and leads to improved shadows, better map generation and how the limitations of the perspective can be used to benefit the game.
SpaceCute lives! And Thrives! And last, but certainly not least, Scooter over at 2bitarcade.com produced a very polished SpaceCute prototype. Love the stars and the bounciness when you hit something.
Till the next crop... Wow. You are all amazingly creative and productive. Remember however, this is just the beginning. Once the basic engines are up and running, that is when the real fun begins. I'm looking forward to seeing more experiments with the basic mechanics of the game. The core activitity of moving blocks is remarkably enjoyable by itself. Now is the time to wrap a game around that. Just ask the following questions:
What does the player do?
What is the feedback (reward or punishment) for doing that action?
How do they use the skills, resources or tools gained from successfully mastering the action to do something new or better?
It is once again time for a prototyping challenge! The rules are the same. You are an elite programmer that wants to make something fun without spending ten years in art school learning how to draw stick figures. I provide some easy-to-use graphics and an intriguing game design for you to riff upon. Send me the links to your masterpieces and I'll post them for folks to enjoy and critique.
This time, we are tackling an ancient, yet still fascinating, genre that is long overdue resurrection: The God Game.
Back in the day, there was a game call Populous where you played a god. You mucked about with the land, zotted unbelievers and created a verdant landscape populated with bustling villages and happy followers. This week's design, CuteGod is a god game on a smaller, more casual scale. I've reworked the mechanics to be more prototyping friendly, but the spirit is the same. You play a simple village god who seeks to make his people happy by fulfilling their heartfelt prayers.
I've divided the challenge up into two sections. The first is the core mechanic and the second challenge adds a bit of depth to the game. We are using the PlanetCute prototyping tiles and the set has been updated with 20 new objects in preparation for the challenge. You can download them from the resource section of the post.
Challenge Part I: Core Mechanics Have you ever experienced the simple joy of sorting your Legos? This is a broadly enjoyed activity for many folks whether they express it through a love of beading or shopping at Organized Living shops in the mall. The core mechanic in CuteGod is one of sorting tiles and completing simple patterns.
As with all mechanics, the written design is a starting point. Prototype, experiment and see what works. The idea is to create an activity that is intrinsically pleasurable and can act as a foundational activity for other game mechanics.
The map The land starts out with randomly sorted PlanetCute prototyping tiles, piled up to five levels deep. Tiles can stack up on one another to form hills and valleys.
There are several types of tiles:
Basic tiles: There are a few basic tiles, grass, dirt, water.
Rare tiles: Each basic tile has a rare analogue such as emerald, ruby or sapphire. There may be a handful of these tiles in the entire level and are used to create advanced patterns or increase the completion bonus of existing patterns.
Immovable tiles. These stone tiles create the foundation of the level.
Player action You can drag tiles around. Tiles can be dragged on top of other visible tiles. By dragging tiles, you rearrange the map to Your liking.
Picking a tile plays a cool sound effect and the tile is sucked up into the air.
An indicator shows where you can drop a tile. As long as you can touch it with your cursor, you can drop a tile there.
Dropping a tile has a quality clunking noise. The tile drops into place with a small bounce.
The villagers Sad villagers wander about the map looking for a place to live. If you click on them, a thought bubble appears showing you a pattern of tiles they need in order to build a happy home. This pattern is known as a prayer and acts as a mini-mission. It is your job as a god to do something about such heartfelt desires. Clicking on the thought bubble automatically accepts the prayer.
Finding villagers and accepting their prayers gives you a small amount of points. A small animated heart floats up from the villager to let you know this is a good action.
The prayer pattern flies over into the prayer list.
Patterns Patterns are a set of tiles in a prearranged order. For example, a simple pattern might be a grid of 4 dirt blocks arranged in a square all at the same level. Completing a pattern builds a structure and gives the player points.
Prayer list Along the side of window is a list of patterns that various villagers want you to build. This helps you keep track of all the requests.
Partially completing a prayer As you build out the pattern, the tiles glow when they are assembled in partial patterns. The appropriate prayer pattern also glows. This intermediary feedback lets the player know that they are progressing along the right path.
Completing a prayer When you complete particular pattern, the tiles glow, the villager smiles and bounces over to location of the pattern. Blocks rain down from the sky and assemble the house. For each block that falls, you get points. When the house is complete, particles go off and flower spring up around the house.
The finished house will pop out the villager upon completion. He will be happy.
Some advanced patterns will also pop out a treasure box upon completion.
Simple levels and winning conditions CuteGod is about playing in a sandbox, not so much about winning. However, it is easy to add levels to the game to give the prototype a sense of completion.
Each level is a new initial configuration of tiles and patterns that the user needs to build.
Each level has an overall goal of reaching X points, where X is might be 10,000, etc.
When the goal is reached, a 'win' message is shown.
Challenge Part 2: Treasures and Spells Once you have the basic engine running and the gameplay feels good, here are some additional mechanics that should improve the rhythm and addictiveness of the game.
Buried Treasures As you dig about, you’ll discover buried treasures. These are magic chests that contain a variety of interesting and useful things.
Click on the box to open it. The box fades out in a glorious burst of particles and the item inside pops out.
Buried mana Some treasure boxes simply have bonuses of buried mana. Bonus points increase the user score for no additional work.
Buried spirits You can also uncover buried spirits in treasure boxes. These are ancient villagers from ages past that require truly opulent homes. They give you a new mission and extra bonus points if you bring them back to life.
Buried Spells You can find spells in treasure boxes. These are special actions that give you useful tools for manipulating the environment.
If you click on a spell icon on the map, it activates. If it requires targeting, your cursor turns into the appropriate spell. Click on the spell again to cancel. If it does not require targeting it becomes active immediately.
Boom: You can blast a house to pieces. This allows you to build it again for more points, or you can get to the stuff underneath. All the house pieces disappear. You can also use the boom spell quickly dig through a hill.
Find Tile: Finds a block of a specific type. For example, ‘Find Grass’ would cause the top level tiles wherever buried grass tiles are located to glow.
Find Rare: Highlights any rare tiles.
Bonus: Increases the bonus that you get from completing houses in a particular amount of time.
Future ideas If the core mechanic is interesting, we can introduce additional layers of complexity and rewards. The future ideas section is a brainstorming list to get your creative design juices flowing.
Economy: Points are really money. :-) As you gather them, you gain the ability to purchase more land, more villagers, visits to other maps, tiles, rare patterns, clothes for your villagers, etc.
Additional prayers: Some villagers will become unhappy again, even after they get a house. They request gardens, bath houses, etc. You get loads of bonus point if you assemble these touching their existing abode.
Marriage: If you put a man and woman’s house next to one another, they will fall in love and you’ll get a marriage bonus. If you wait long enough, they’ll have a small child who can request a house of his own.
Stacking objects on villagers: You can stack tiles on a person. This allows you to keep track of the tiles that a particular villager requires and gets the tiles out of your way.
Complex patterns: Advanced patterns can be quite complex. We’ll have to see if this is an enjoyable avenue of advancement.
Fast completion bonuses: If you complete a pattern quickly after receiving the prayer, you get a bonus.
Minimum number of moves bonus: If you complete a pattern within some number of moves, you get a bonus.
Time sensitive prayers: Instead of prayers just waiting for you to click on them, a prayer starts floating up in the sky. If you don't catch it in time, the prayer is lost and the little villager is unhappy.
Scrolling maps: Larger scrolling maps gives the user more things to think about.
Water: You can drag water onto crops to soak them. This will cause some to grow and yield new treats like mana or spells.
Pests: Pest come through and damage crops and buildings. You can drop rocks on them or pick them up and drown them in water.
Player on the map: It would be possible to add the player as a character on the map. This gives the player someone to identify with and adds more gameplay possibilities. It also gives a focus point for scrolling. To move, just drag your avatar to a new location and the screen scrolls accordingly.
Web-based play: It would be great if this was an online game with instant access and no install. Other players could come visit your realms and chat.
Long term vision CuteGod is a paintbox game. Ultimately, the user should be able to organize and paint the world that they desire. By carefully managing their tiles, collecting the right patterns and spending wisely, they can create a little living world that is their personal space.
Conclusion This challenge is an interesting exercise because you get to see the craziness that happens when you prototype an original design. In my limited knowledge of games, the dragging and arranging of tile patterns to satisfy the prayers of little villagers is an uncommon mechanic. There aren't a lot of example to fall back on when something isn't working.
That means much of your prototyping time will be spent balancing and exploring with the new game system. Build the initial game, but don't be afraid to take in new directions if you discover interesting sources of fun. If you end up with something that is truly, horribly unenjoyable, certainly share it! Everyone will learn from both the dead ends and the successes.
For those of you who wonder why there aren't more original games, this can be a great learning experience. The first lesson is that original design isn't usually constrained by technology. I've intentionally kept the engine requirements rather low tech. Instead, the biggest challenge becomes the mental shift from 'implementing a spec' to 'finding the fun in a new game system.' These are two very different skills. If you merely implement an original design, you'll often end up with unplayable garbage. Instead you have to dig for the fun.
In today's risk adverse game development culture that focuses on rapid implementation of a spec, many game developers never master or know how to manage the process of finding the fun in a new game design. It is a process that requires slack time in the schedule to experiment and balance your game. It requires tight collaboration between design and development usually in small groups, not large silos. It requires the ability to try out multiple things at once and pick the best option, not the only option you have time for.
So here is an opportunity that only a few commercial game developers get a chance to regularly engage in. Have fun. :-) I'm very much looking forward to see what you make!
take care Danc.
Prototyping Resources Download the PlanetCute tiles: I've added over 20 more tiles and objects. The shadow system is improved, you can build full houses and there are hearts, gems and stars.
Shadow Tile Placement: One of the first problems that prototypers run into is that their lovely work doesn't look like my mockups. This is because my mockups use the miraculous height improving power of the shadow tiles. I updated them in the latest .zip to be even more effective. If you haven't downloaded the PNGs lately, I recommend you do so since some of the graphics and some of the tile names have changed.
Use the diagram below to write your clever algorithm for automatically placing shadow tiles appropriately. (It is an endearing puzzle all by itself)
Tile A is on level 1
Tile B and C are above Tile A on level 2
For each of the 8 directions of the compass, tile B will cast a shadow on tile A. In order to simulate this effect, I've created 8 shadow graphics. If you are Tile A, check the rules. If a rule is true, place the appropriate shadow tile. You can have multiple shadow graphics on top of the same tile.
Special case A: When two tiles are on the same level in the diagonal pattern shown below, you need to place Shadow Side West.
Special case B: When a tile is at the very top of the stack and there is nothing north of it, you can reused the Shadow South graphic to give the edge more emphasis.
Populous: The original God Game. This genre eventually morphed into more mundane sim and building games, but the fire and brimstone original concept has rarely been revisited. This game was a formative part of my youth. The mechanics of CuteGod are slightly different, but the setting remains an homage to one of histories great original game designs.
Instructions To install: Extract all files, make sure DX9 is intalled To run: Double click EXE To use:
Arrow keys: Move active character
b: Change active character
1 though 6: Load premade levels
To manipulate the terrain: Click on terrain in top left, click one of the blocks across the top to select it, click on a block in the level to set it to that block. Click and hold a block, and drag up/down to move the block up/down.
To manipulate objects: Click on objects in top left, click one of the objects across the top to select it, click somewhere in the level to place it. Only one object can be present on each block. To delete an object, select the object across the top then click on the object in the level. To manipulate people: Click on people in the top left, works same as objects.
Thoughts This is exactly the type of project I was hoping someone would build. Once you get a hang of the editor, it is easy to build interesting levels rather quickly. Be sure to check of the prepackaged levels. Though simple, each one is actually a rather enjoyable exercise in finding keys and delivering gems to the princess.
I'm impressed that Corsix even figured out the shadow system, probably the most complex part of the set.
I find that my initial tiles usually go through several iterations before I settle on a final look and feel. Having seen them in action there are still a couple of rough spots.
Displaying vertical height: This is still a bit tricky. There are a few simple shadow tricks I can play. A simple trick that can be played on the programming side is to increase the brightness of each layer by 10%. This makes the top blocks lighter and the bottom blocks darker given a nice bit of depth perception to the whole thing.
Noise in the base tiles: The basic floor tiles are a bit high contrast. This gives the playfield a much noisier feel than I would like. I'll tone that back.
Lack of objects: It is obvious that some basic objects are missing. Vertical doors, conversation bubbles, ramp corners and better buildings all come to mind. Any others that seem missing?
One of my dreams while making this set was to one day see an online RPG maker similar to Little Big World. The player wanders about a series of realms, but they have the ability cast spells and mold the terrain like a giant art canvas. Think Populous, writ small.
There is one nearly idiot proof input gesture at the heart of SpaceCute. You drag and release. One would imagine that such limited input leads to limited game play. In fact, when I originally came up with the idea, I was imagining how a simple casual game mechanic might be extended to create an interaction model nearly as complex as something like NetHack.
It should be possible to build a SpaceCute prototype that extends the game mechanics with additional verbs that use the same core gesture. I've provided a few examples to spark the brain.
Elegant controls In physics there is a concept of 'elegance', which can be loosely paraphrased "What is the simplest model possible that explains the most robust set of phenomena?" The concept of elegance can be applied to games as well. An elegant control mechanism gives the user a rich user experience with the smallest (but no smaller) set of inputs. Go, for example, has a highly elegant interface. Steel Battalion, with its gigantic uber controller, does not.
Elegant control designs often possess the following benefits:
They are easier for new users to pick up.
They can be ported to a wide variety of different platforms
You can easily extend simple gestures into a highly diverse and expressive set of verbs. Hunty's SpaceUgly is a great example of how adding just a couple more verbs such as 'collect' and 'spawn' beyond move and attack can help create a far richer play field. Kudos to him for making that conceptual leap. He's got designer blood. (Though hopefully in his veins, not a plastic jar in the cupboard)
As a demonstration of this technique, I'm going to list out a plethora of possible verbs that could be derived from our base mechanics.
Move We started with a rather expressive basic verb that can convey both direction and force. By itself, it is rather boring since there are few opportunities to link it into more complex systems. Here is how some common game specific verbs map onto 'move'
Move in a particular direction.
Move a short distance
Move a long distance
Cancel a move (Have a small buffer zone at the beginning of the drag that acts as a 'cancel')
Collide With collision we introduce a simple event that lets us know that we've interacted with another object. Now the computer knows "I've got object A, object B, and a force vector" You can now write any game mechanics that takes those variables as input. This alone opens up much of the world of gameplay. Here's how some common game specific verbs map onto 'collide'
Bounce: You can move another token by bouncing into it.
Bumper: When you hit this token, it imparts a greater reactive force to your object. Think of this as the bumpers in pinball.
Barrier: You can block an area or create a tactical terrain obstacle with an object that just sits in the middle of the screen. With this we've introduced the beginnings of static level design. Planets work like this.
Damage an enemy ship: Hurt someone! Not surprisingly, most game designs go here first.
Heal a friendly ship: Really, we are just changing a number. You can just as easily heal someone.
Steal resources: If you can give, you can also take. Think vampirism.
Gain experience points: A unit can earn resource points simply for causing a change to occur to another unit.
Combo: Hitting multiple objects in a single move gives some additional reward
Transfer an object that is being held to another ship: If object A has a powerup or item, it can hand this off to object B when the two collide.
Change the state of either object. For example, one object could become 'mad' which boost hits points and make it move more quickly.
Collide with force: Since move implies a force, large velocity collision can cause more damage than soft collision. In fact any change of state that has a continuous key variable can map that variable onto the collision force. What happens if you linked the collision force to the radius of the object? Now you have an object that temporarily blows up like a balloon when hit hard and leaves a trail of mayhem in its path.
Collect A subset of collide is collecting. Instead of bouncing off an object, you pass over an object and perform some action that removes an object from the board.
Grab a resource: The stars in Hunty's game are an example of resources. When you pass over a star it is removed from the board and added to your resource counter for use at a later date.
Grab a powerup: You can also grab a new ability that is applied to your individual ship
Grab a meta-powerup: You could grab a new ability that changes the rules of the board. For example you might collect the 'molasses' powerup that causes the next player's to be bogged down by high friction for a turn or two.
Collect a warp token: Once you go meta, you can never go back. It is easy to imagine a series of levels, each with collections of unique powerups, units and resources. In every level there would be a warp token or two that takes you to another level. Now you can create entire SpaceCute universes.
Area blast Another natural outgrowth of collision are area effects. When a unit comes to a stop, it creates a blast that is wider than itself. This introduces the ability to affect multiple objects in a tactically interesting manner.
Collide style interactions: Many of the collision interaction work for area blasts as well. You can imagine group heal, group damage, stealing resources and changing states work quite well.
Group push: You can use your physics to push units caught in the blast away.
Group pull: You could also pull units caught in the blast inwards. This is a great setup for massive collision combos aka "pack 'em and smack 'em"
Flow So far we've been dealing with simple properties of self contained objects. Adding features to the terrain is also interesting. A vector field pulls an object in a particular direction as it moves over the field.
Hills and valleys: A ring of vectors pointing towards its center does a rather convincing simulation of a hill. The reverse creates a valley.
Rollercoasters: You can create interesting currents the pull ships from one location to the next.
Flock You can also implement some more advanced simulation in which an object effects another object's position at a distance.
Gravity: Objects attract one another. A popular feature though it adds a bit of randomness.
Repulsion: Objects repel one another.
Fear: When you apply repulsion to individual objects, you can simulate a unit fearfully running away or retreating. By setting a min velocity that triggers the fear behavior, you can enable sneaking tactics.
Flocking: With almost every game design I end up asking "How would I turn this into a sheep herding game?" It is a personal quirk and is only peripherally related to flocking. Units that follow a particular unit can add a dash of personality to the game. They can be companions, predators, chattering crowds of worshipful children, etc. Or perhaps even sheep. If that is your thing.
Sensor If flocking physics are too complex (or chaotic), you can create remarkably rich level design with stationary sensors that trigger state changes.
Word bubbles: Imagine that you have a character on the screen. As your unit zips past, the character pops up a word bubble. An entire RPG-style conversation system could be built with this technique alone.
Mines: If you get too close to a mine token, it goes 'boom'. Combine this with an Area effect for hours of pleasure.
Spawn Units that spawn new units adds an incredible amount of depth to the game, especially when combined with a resource model. Now the player can build the level as they play.
Fighter factory: A base can launch ships.
Mine seeder: A ship can leave mine behind as it goes on its merry way.
Powerup launcher: You can launch powerups or health bonuses at friendly ships
Missle: A missile station launches small missles that explode on impact.
Multi-spawn An extension of spawning is the multi-spawn object. This allows you to have a single object that can perform multiple tasks. It can move by dragging on the main body. It can also perform individual actions by dragging on one of the attached nodes.
Mother ship: A mother ship might have the ability to launch a missle at attacker or build a new attack ship or fir
Self replicating missle station: A missile station might produce very low cost missle out of one bay. Out of another bay, it can launch a new missile station for a much higher resource cost.
Combining game mechanics All these verbs can be combined to create more complex systems. For example, when you combine 'transfer' is combined with 'collection', you can readily build either a basic inventory system, the ability to purchase items, or of course, capture the flag. Word bubbles + simple combat + warp gates gives us an exploration-based RPG.
The combinatorics are quite dizzying. We've expanded the possibility space beyond the simple core mechanics into a much more complex and interesting realm.
The point We could go on inventing verbs like this for quite some time. I suspect you can come up with quite a few more that I've missed. :-) Pick a few and prototype them. Be sure to create a complete game mechanic with a verb, system of effects and clear feedback to the player. The best mechanics will give tools to the player that help them manipulate your gamespace in order to reach their higher level goals.
The big lesson in this exercise is that that a simple input gesture in SpaceCute can lead quite naturally to massively deep game play on par with many mainstream genres. You do not need a complex control scheme to build an intricate and involving user experience. So what if some random controller has more buttons. Give a competent designer a simple control scheme and they can build up an entire world of wonderful experiences.
I find that it is easy to build up some rather fascinating toys at this stage of prototyping. If anyone feels to urge to try some of these ideas out, I'll be happy to post whatever your experiments yield.
SpaceCute: First round of prototypes and new graphics
The initial round of SpaceCute prototypes are in and results are encouraging. Both basic movement and some initial combat was prototyped. Each one of these guys is a prototyping superstar. It is educational to see all their different interpretations of the starting concept. You can download their glorious efforts here:
Hunty:http://www.studiohunty.com/spacecute/ This is a full fledged, 2-player strategy game, complete with home bases, interesting combos and a resource model.
New graphics
I've also provided a new set of graphics that include more 'cute' faces and one new ship (inspired by Vorlons.) You can mix and match hair and and accessories to get the look you desire. Download the latest set, complete with PNG and original .design files here:
Answering the big questions You can think of prototyping as a pseudo-scientific process of experimentation. For each prototype, you are looking for the following:
What is the main question the prototype is seeking to answer? Often you'll think you have a good game mechanic, but you don't actually know until you try it. Postulate a question that you hope your prototype will answer. For example "I think using mini-golf game mechanics will make movement in a strategy game more enjoyable and interesting. Is movement fun?"
Did the prototype succeed? Test the prototype and answer your initial question! These should be simple Yes or No answers. One of the most common problems with design is that we come up with intricate theories and then fail to test them until the very end of production. Play test early and play test often.
Lessons learned: In reality, prototypes goes through dozens of iterations and the designer tests out many different ideas. These lesson help you understand what to keep and what to kill.
Opportunities: Were there any interesting opportunities that emerge that cause you to want to make more prototypes and test addition issues? Games mechanics are almost always complex systems that operate on the fuzzy boundary of our limited human ability to predict their behavior. If an unexpected behavior of your prototyped system delights you, it will likely delight players if wrapped in a proper set of feedback and rewards.
With this framework in mind, let's look at the prototypes. Our two big questions are "Is moving fun?" and "Is combat fun?"
Is moving fun? I think the answer is yes. I spent far too much time flinging space craft around the board despite there being little reason. This is one of our lowest level game mechanics so it is important to get it right.
Moving lessons
Harold added sound to the movement. This increased the pleasure of flinging ships about quite nicely. Multi-channel feedback is good for increasing the impact of feedback.
Short pull distances that result in long throws were more enjoyable than long pull distances with short launches. It adds a bit of unexpectedness to the actions.
Dragging small amounts hides the cursor under the character. Making the ship semi-opaque fixes the problem. So does setting the 0 point past some initial distance from the center of the ship.
Opportunities Based off the various prototypes, it feels like movement is pretty solid. There was one interesting variation suggested:
Pulling back vs. pulling forward. I hear that Bonder is working on a sample to try this out. I'm looking forward to seeing it. This also would solve the hidden cursor problem. You should watch out to see if there are problems interacting with walls.
Is combat fun? In general, combat is only mildly fun. Ships bonk into one another and slug it out, but player choices don't seem all that interesting. Combat suffers from a typical problem that strikes almost all prototypes at some point:
Outcomes are highly predictable
Player choices are limited.
Lessons
Riad's simple AI is quite vicious. It pursues you and whacks you at full force. It is a good stub for now. Harold implemented a variation where a random ship is chosen to move each turn. This avoids some of the dogged bash fests that occur when the AI select only the closest ship.
Mutually assured destruction isn't fun. When both tokens are hurt in a collision, the optimal strategy is to let the other guy bash himself against the planet. :-) In Ben's model, you don't take damage if you attack. This feels better.
Momentum transfer: Harold has also been playing a bit with the elasticity of collision so that when an attacker rams into a ship, you stop and the defender gets most of the momentum. This has promise for creating chain reactions.
Planning complex collisions is also hard. You can't see exactly where pieces are likely to collide. I may need to reworks the graphics so that this is more obvious. Ben implements a nice transparent circle that could highlight on those tokens within reach of the selected ship.
Folks are using 100% thrust most of the time: There is no reward for using subtly
Opportunities The obvious step for most of the prototypes is to make combat enjoyable. Folks are building up some lovely engines that are capable of all the basics such as collision, movement and state changes. This is where the engine programmers get seperated from the game programmers since most of the upcoming work deals with very little technology and a whole lot of tweaking of game systems.
I chose the following opportunities for combat based of these two criteria:
Give the players interesting choices
Introduce surprising complexity into the outcomes.
Add a turn button: I perhaps simplified the initial design too much. It is worth prototyping up a turn button that allows you to move all or some of your units during your turn. Does the players strategic options increase dramatically?
Collisions need a little pizazz: Currently collisions don't let you know that something interesting happened. Having the unit flash red (and fade back to normal) or having particle spit out of the collision point could help. Mordraks particle effects or Ben's floating heart are great ideas that could be extended to the collision feedback. The sound effects help immensely. Is collision feedback delightful? Every Extend style explosions: Let's introduce a new type of ship that explodes when it comes to a complete stop. The explosion expands in a radius and damages ships caught within. If the bomb ship hits another ship, the explosion will fizzle. If the bomb ship hits a planet or wall, the explosion does not fizzle. Are skilled placement of shots, including bank shots, useful?
For the explosion, you can use a simple expanding circle with particle effect. Be sure to make the ships give the user feedback when they are hit. Woot, unit type number 2.
Resources and Powerups: One common technique to make a mechanic interesting is to tie mastery to the acquisition of a tool or resource. Imagine that ships spit out stars when smacked. These stars are sucked up by close by attacker ships and act as resources. Get enough resources and one of your ships randomly gets a powerup for a turn or two. Simple powerups include "super mass" that sends enemy ships (and planets!) flying, or perhaps "Astroglide" that lets you zoom extra long distances.
Now we have an interesting opportunity for rewarding combos. When players do multiple points of damage, they get star multipliers. When a ship finally loses all its hearts, it bursts into an explosion of stars. That means more powerups and more interesting choices.
Other notes
Folks feel violent combat doesn't quite fit the SpaceCute setting. I was imagining combat in the Mario sense of the word. Stars fly out, not blood. There are some conversation and questing meta-mechanics I'd like to see, but those are or much, much later.
The use of a text file for storing all variables was of great use in rapidly testing different configurations. The XML based file used by Riad was particularly promising since it allowed quick and rapid iteration of map design as well. This allowed me to test a 10 enemy scenario with relative ease.
I'm sure you have other ingenious ideas. Go for it! Post them in these threads. If you haven't submitted your prototype yet, no worries. Steal the best ideas from the other guys and try your own twist on the concept. There are tons of options that haven't been tried. And above all, play the prototypes...it is a great opportunity to give some real critiques of games in progress.
As a side note, SpaceCute didn't exist as a search term a little while ago. Now Google has 308 references. I figure I'll just keep making graphics and pimping your prototypes as they come in. My hope is that overtime SpaceCute is only going to get bigger and more pervasive. (Isn't this is a lot of fun? :-)
The weekend is here and it is time for a short prototyping challenge! Over and over again, I've heard the sad tale that there are talented programmers lacking sexy graphics. I, on the other hand, can't program a lick. So here's a thought: I'll provide some quality graphics and a seed of a design idea. All you need to provide is a working prototype of the core game mechanic. :-)
For each prototype I receive, I'll post it up on the website and the learned folks who lurk here can discuss its pros, cons and opportunities for improvement. It should be a good learning experience all around. As we go, I'll add more graphics and we'll see where it all leads. Continue reading to grab the graphics and read the seed idea.
Core mechanic The core mechanic of SpaceCute is a single player casual turn based strategy game. It borrows the control mechanism from the familiar mini golf games that have been around since the early 90's. The goal is to add a low burnout skill-based mechanic to the shortest interaction cycle in the game. Is the act of just moving units fun?
To move a ship, you drag a line out from the ship.
The ship is launch in the direction of line.
The ship's velocity is dependent on the length of the line. The line has a max length.
Physics, baby! Objects in the game are modeled as circles. They can bounce into one another like simple billiard balls. The goal is to add a bit of juiciness and nuance to the often mechanical act of attacking another unit. Does the act of attacking a unit feel satisfying?
The ship does damage to opponents when it smacks into them during the player's turn. The feedback to the player when two ships collide is a great area to invest some time in getting the 'feel' correct. If we make this interaction visceral through sound, explosions and flying bits, we can enthrall players from their earliest interactions.
Friction is relatively high compared to a billiards game so most pieces only travel a short distance when flung. This is still a strategy game and we don't want chaos to reign after a single turn.
Are there any interesting combination collisions that occur that we could accentuate with future layers of mechanics? I'd love to build a combo-hit system into the combat.
Turn structure During each turn, the player can move one ship. The results of the various collisions are displayed. The turn ends immediately and the computer moves. This is very similar to the turn structure of chess or checkers. The goal is to create a fast paced game that eliminates the need for the typical 'end turn' button found in many turn-based strategy games.
Setup The board is a single screen with 5 or 6 units from each team.
What distances between players result in immediately interesting combat?
Are there any initial configurations that cause the players to think deeply about their moves?
Tokens As the game grows, we'll be adding lots of interesting ships with special abilities. For now, we just need some basic ones to experiment on.
Basic attack ship: This is the basic ship used by both the player and the enemy. Balancing max velocity, friction, hull radius, damage and health for this unit are all interesting areas for rapid iteration and play testing.
Planet: Heavy obstacle that is used to define space on the map.
Enemy AI A randomly selected enemy units moves towards the closest player at full speed. This is a simple stub algorithm that will be replaced if more interesting behavior is required.
AI should execute rapidly (less than .5 second) This is a casual game and waiting for the AI doesn't add much to the experience.
Winning conditions Let's add a simple stub winning condition that the player wins when all the enemies are destroyed. Pop up a little text screen to let the player know they've completed the game and give them the option to play again.
Prototyping basics Unit stats and level design is handled with a single text file (perhaps XML). Changing various variable in the world physics, unit stats or initial token positions should be a simple matter of editing the text file and running the game again. Important questions to consider Here are some common questions that any one should ask of their initial prototype.
Is any portion of the play fun? There is roughly a 95% chance that your first stabs at this design won't be all that enjoyable. Finding the fun and magnifying it over several iteration of experimentation is critical.
What is the pacing of the game? Is the player receiving interesting feedback at steady intervals? Do they have interesting choices at the beginning, middle and end of the game?
What actions could use better feedback? Often an interaction fails not because it isn't interesting, but because we fail to properly help the player build mental models of what is happening.
How do other players react to the game? We, of course, can post the prototype here and get comments, but it is worth while watching someone in person play the game. Grab your roomie or sister. What does she think? Where does she stumble?
Conclusion You'll notice that there are almost as many questions as there are specs to this challenge. Such is the way of prototyping. In these initial stages of development, expect rapid iteration and rapid learning.
There are naturally dozens of ideas stored away for various ships types and more complex interactions between objects. Ice zones with low friction, units that explode Every Extend-style when they reach their destination, factories, resources, powerups...SpaceCute, the massively single player SRPG! Woot. Any designer worth his salt can generate webs upon webs of dreamy meta-game mechanics. However, unless the core mechanic is solid and enjoyable, these really aren't worth wasting time on at the moment. More importantly, they will evolve substantially once we start figuring out the fun in the core mechanics.
So who is up for some quick prototyping fun?
take care Danc.
Resources Graphics: Here are the source graphics for the prototype. Use and abuse as desired. Again, if you come up with something interesting, drop me a note at danc [at] lostgarden [dot] com. For this challenge I'm happy to post both wacky failures and successes. It is the learning that matters.
SpaceCute-Prototype.zip: This file contains both .PNG and the original vector .Design files. Download it here (777k).
Stub: A simple system that will typically become replaced by a more complex system in future versions. Most prototypes have a few stubs since your goal is not to build a complete game, but to test a theory.
Many of the emails I receive ask questions about licensing my designs and artwork. In order to clear up any issues (and save me some emailing!) I've created this licensing page. When you see reference to the Lost Garden License, it refers to the items listed below.
Basic License All licensed items use the Creative Commons Attribution 3.0 License. In short, you can use and modify any images and design covered by this license provided that you attribute the original source materials to me. I chose this license because
I want as many people as possible to use the materials I've provided.
I want to spare developer the accusations of theft that sometimes occur when people recognize my materials. Many of the graphics and designs are widely known at this point. The best solution is educating your users on the source of the original inspiration. That way they can move past yelling 'Thief" and start appreciating the variations on the theme that you have created.
We have entered a brave new world of open source game designs. This is a rather exciting experiment since in the past, users have been trained that the publisher acts as the singular inspired creator who makes all games associated with a particular IP. If a player liked the first Guitar Hero, they trust that the next Guitar Hero will be driven by the same creative vision. Of course all this is a lie. Sequels and expansion packs are only occasionally made by the original creators. They are usually copies and clones created by contracted teams that have only a minor connection to the original artists.
Open source game designs remove the false facade of the sole inspired creator that has been pushed and marketed by publishers and IP managers. Open source designs publicly declare that game designs are systems that can be implemented in dozens of subtle ways by dozens of different teams. If we believe that sequels are valid experiences, then the products created from open source designs are also valid.
The difference is that with an open source design, you know who contributed what. My designs are readily available. You can see what I added to each project. Everything else was done by the team that made the game. There is no slight of hand promoting a fake brand while nameless creative folks are shuffled about like interchangable cogs behind the scenes. Honesty is the better policy.
Game design attributions If you use a game design from Lost Garden, please include following attribution in your game credits.
"Game Design Title" design by Daniel Cook (Lostgarden.com)
When possible link to the original game design. For example, the Fishing Girl design would be: "Fishing Girl" design by Daniel Cook (Lostgarden.com)
Art attributions If you use art from one of my free game art collections, please include the following attribution in a visible location along with any other credits.
"Art Collection Title" art by Daniel Cook (Lostgarden.com)
When possible link to blog post that discusses the original art collection. For example, the Space Cute collection would be "Space Cute" art by Daniel Cook (Lostgarden.com)
Frequently asked question What game designs and art assets are currently covered under the Lost Garden License?
Can I use the assets or designs covered by the Lost Garden License in a commercial project? Absolutely. I encourage it! The best way to learn about game development is to finish a project and try to sell it.
Why are you doing this? I hope, in some small way, to help cultivate the next generation of great game developers and designers. By removing small road blocks like graphics and design, perhaps a few more people will be encouraged to stop just dreaming and starting making games. Everyone in this industry is here because we stand on the shoulders of past developers. We use their tools, their techniques and their ideas. Giving back to the community is a natural way to repay that great and much appreciated debt.
Is all art on the website covered by the Lost Garden License? For example, are your drawings and paintings free as well? Only those assets that are specifically called out on the associated blog post as being licensed under the Lost Garden License are free to use. There will be a clear link to this page. All other drawings and artwork are protected under standard copyright laws.
Can I archive assets and designs on other sites? Sure. If you archive assets elsewhere, be sure to display a prominent link back to the source page so that other game developers have an opportunity to discover this site.
Can I donate to Lost Garden? Even when graphics and designs are released as free, some kind souls want to give back (especially if they've just received a check in the mail).
How much is appropriate to donate? A common fee for both an initial design + graphics might be 10%-20% of final revenues. However, the decision is yours. Any money I receive via the PayPal link below will be set aside for A) improving Lostgarden.com and B) promoting the advancement of game design. take care Danc.
Joel Davis sent me an email presenting a classic design challenge. Your job is to teach players important cooperative skills as an alternative to beating the pulp out of another. The twist is that you can not force collaboration upon the player.
The game must be clearly competitive in nature and should slowly wean the players off their ‘defeat the enemy’ strategies.
The game is only a success if the player has an ‘aha moment’ where they figure out that collaboration is the better way to go despite their initial understanding of the problem.
Oh, and it needs to be both fun and easy-to-play by 10-year olds.
There are many possible solutions to the challenge and I’d love to hear your take on the topic. Here is what I came up with while doodling at the coffee shop waiting for my wife.
A brief aside: Seldon Games I’ve briefly mentioned ‘social engineering’ or ‘Seldon’ games in the past that influence the behavior of players through the manipulation of systems instead of directly telling or forcing the player down a path. The player makes a series of logical, rational choices based off the game system at hand. Eventually, they maneuver themselves into a situation that provides them with unexpected insight. It is a very indirect form of authorial control that is quite different than that found in movies or many linear games. The player is always in full control of their environment, yet just beyond the scope of their cognitive reach there is deeper order behavior at work.
A classic example of this is the ecology in Alpha Centauri. The player naively ends up polluting the environment as they expand their base and end up triggering a massive onslaught of alien worms. This wasn’t the game designer making an arbitrary plot driven exception. It was a natural outcome of how the ecological model in the game worked. The next time they play through a map, there is a much greater awareness of pollution and its impact on the ecology.
I’m attempting a similar progression in this design.
Cooperation War overview Winter is rapidly approaching and your tribe must gather up enough food to survive. Unfortunately, crops are scarce and the other tribes are hungry as well. What will you do to survive?
Cooperation War is a simple Flash multiplayer RTS game for 2 to 4 players. It is played on a single screen with a mouse. You can chat using a keyboard. In earlier levels, players can rely on force to grab resources for their tribe. In later levels, as resources become rarer, only those who collaborate will prosper.
Each map takes 10 minutes and replay is encouraged through the tracking of individual and group scores.
The basic progression
Resources (wheat, sheep, and fruit) litter the landscape initially.
Gatherers from the tribe collect resources and carry them to a new location.
Builders convert resources into basic foods
Builders convert basic foods of different types into advanced foods that feed more people.
When the winter comes, the tribe gathers around their leader and feasts on the nearby food that has been prepared.
If there is not enough food, the tribe slowly dies off.
If there is more than enough food, the tribe emerges from the winter stronger than ever.
Early in the game, players will rush to gather food. As food is processed and begins to accumulate, its value begins to increase. Players will be tempted to create warriors to protect their bounty or steal the bounty of others. Tension builds as the clock runs down. In the last moments of the game, the player will want to position their leader near the largest cache of food around and hope they played the game well enough to survive the coming winter.
Basic units Players start the game with 4 to 5 units. There are three main types of units in the game
Gatherers
Builders
Warriors
Changing between units You can convert any unit into any other unit.
Click on the unit.
Click on the alternative unit you wish to convert to.
Conversion takes a few seconds during which the unit is immobile. We show the progress bar during this conversion. This delay exists to prevent wacky micromanagement of unit switching.
The leader One of your units is flagged as the leader. When winter arrives, the player should place their leader near the largest pile of food they can find. During winter, any food within the radius of the leader will be consumed by the tribe. If the current leader unit is killed, the flag is assigned automatically to another one of your units.
Gatherers Gatherers pick up items from one area and drop them down in another location. Once a Gatherer has delivered an item, they will go back for more. If there is nothing for them to move they will wait for further instructions. (How much AI do we want here?)
A Gather’s interface is a line connecting their resource and their destination.
Click on the Gatherer to select it.
Drag their gathering target to a location. This target is a medium sized area from which they will be gathering items.
Drag their drop point target to a location. This target is a pinpoint location at which they will be dropping off items.
Alternatively, you can drag a line from the source to the destination. This is likely to be a lot less fiddly.
Builders Builders convert nearby resources into basic food and basic food into advanced food. Conversion takes time. Builders that have access to multiple types of resources, say Grain, Sheep and Fruit produce exponentially more food than those that have access to one resource.
A builder’s interface is a draggable circle.
Click on a builder.
Drag their conversion target to a location. They will convert anything within the radius into it most valuable form.
Multiple builders working on the same production step speed up the time it takes to finish.
Warriors Warriors attempt to kill units from other tribes within their guard radius. Gathers and Builders die after a few seconds. Warriors will fight for a very long time and tie one another up. Eventually both will die.
Click on a Warrior
Drag their guard circle to a location. They will move towards this location and begin patrolling.
Chatting Communication is key to any collaborative exercise. The player can type a message at any time and it will appear above their leader’s head. With only 2 to 4 players and a single screen, everyone will see everything. We aren’t teaching backstabbing explicitly so there is no need to include private channels in the communication system.
Note that the interface is intentionally designed so that an experienced player could set up their units in the first 20 seconds of the game and harvesting and production would occur successfully without any further interaction. There needs to be space in the rhythm of the game for communication to occur.
Conversion of resources into meals When a gather is within range of a resource such as a bundle of wheat, they will convert it into a meal. You can convert simple meals into more nourishing meals if you have access to a wider range of resources. At the higher levels, we want to encourage extreme resource crunches where it is highly unlikely that all players have all the components necessary for success.
1 resource yields 10 meals
2 different resources yields 50 meals
3 different resources yields 100 meals
Winter Each game last 10 minutes and a little animated clock shows the countdown of the timer until winter begins. In the last 30 seconds of the game, the first frost arrives and the players are prompted to gather around their units around their leader in preparation for winter.
Any food within the leader’s radius is considered fair game for the tribe to consume. When winter hits, this number starts to slowly count down. Each unit is represents 10 tribes man. Each tribesman consumes a meal a day and winter lasts a variable number of days. When there is not enough food, 5 tribes people die per day.
If you end the winter with enough food, bonus babies are born!
Scoring Once winter is over, you get 1 point for each person outside your tribe and 2 points for each person inside your tribe. Bonus babies are scored as a tribe member.
Individual high scores are recorded and each player is shown their rank relative to how others have played in the past.
A group high score (the sum of all player scores) is also recorded and shown relative to how others have played in the past. This is a good opportunity for the interjection of value statements to clue players in on what is rewarded. For example: “Advanced civilization” vs. “Brutish rabble.” We should always display the scores attained by cooperating as a possible goal. Players will wonder how such high scores are humanly possible and this will clue them into the potential that they might want to explore other strategies.
Thoughts on balancing and message The game mechanics as they stand are stripped of any message. The game can be played in a genocidal fashion or a purely collaborative fashion. Any message we desire must come from how the game systems are balanced and what strategies provide the player with the most desirable payoff. Here are some quick balancing techniques.
Converting resources is expensive: In the later levels, it should take most of your tribes efforts as gathers and builders to produce enough food for the winter.
Give fighting a cost: When you escalate the violence and fight, you kill valuable people who could have contributed to gathering and producing more food. There is often a short term tactical gain, but long term, you put everyone at risk.
Differentiated resources: It become difficult to go it alone because other people have what you need. This encourages collaboration.
Strategies we should enable The following competitive strategies should all be possible once the game is balanced
Genocide: Players can band together to wipe out an opposing team. There is a large opportunity cost to this activity.
Stealing: Gatherers can rush another player’s stock pile and steal finished good and bring them back to their own stock pile.
Defense: Warriors can be placed in defensive positions to prevent any enemy gatherers from stealing.
The following collaborative strategies should also be possible
Gifting: It should be possible for a gatherer to give a specific resource to another player.
Sharing of stock piles: Multiple players should be able to build one large stockpile that helps them all get through the winter. Just place both leaders on the same stockpile and everyone will share.
Communication: Players should be able to negotiate and discuss shared goals.
Level progression In early levels, resources are readily available so that the ‘obvious’ strategy of defense and attack are quite viable. However, in later levels, resources become more limited so that cooperation becomes the more viable strategy.
Learning notes Learning comes when people experiment with new behavior in old situations. Many of the harder levels should be played multiple times by the same group. Initially, all teams will do poorly. After they make the switch to collaborative strategies, they’ll do much better, but expect this to take several attempts.
Learning also tends to occur upon review, not during play. People often need to tell stories about their experience in order to understand it. Keep each game to 10 minutes and build in a logging system. Allow people to watch their first attempt at playing the game and compare it to their later attempts. This can also be used in classroom situations to review decisions and explore them in more depth.
Help Hag I’m tempted to add an old woman for each tribe. She eats food during the winter and cannot be used as a gatherer, warrior or builder. However, if you click on her, she will give you tips on how to play the game. You could, if you wished, send her off to her death if you desire. However, the players who listens to her wisdom will gain insight into advanced strategies sooner.
The whole technique of clicking on a unit to get tips is a fun one. Warriors can chime in advice on killing the enemy faster. Gatherers in the presence of warriors can talk about making runs to steal enemy goods. Each introduces players to potential strategies. By suggestioning options, you guide the player’s attention along paths that designer wishes them to explore without forcing the player down a hard coded path.
Prototyping questions There are all sorts of questions that need to be answered through prototyping in order to ensure that this is a fun game. Here is the first round.
What is the best interface for ordering around the gatherers? Specifying the source and destination seems like it could be a bit clunky for new users.
What setting should we use? The current one is a bit bland.
How many resources should we use? Does one present enough strategic complexity? Does 2? Is 3 too complex?
What is the scale of the units on the screen? I think this can work nicely for 2 players each with 4 or 5 units. 8 players with 5 units on a single screen may get a bit hectic.
What is the learning curve? There is some worry that the learning curve will be too steep. This can be handled with simple intro levels and the use of the help hag.
What are the right constants? I can guarantee that the numbers in this document will produce a game that is completely unplayable. Messing about with constants is one of the more enjoyable aspects of prototyping. :-)
Conclusion I love Joel's design challenge because it points out how you can use the dynamics of the system to guide the player’s actions. One of my greatest pet peeves about many modern games is how authorial intent is enforced though arbitrary exceptions rammed into the heart of an interesting game system. The designer strips away your weapons or causes you to lose a battle on a whim. There is no lesson to be learned, no skills to master. The opportunity to profoundly delight or educate the player is traded for a cheap narrative thrill.
Instead, we should learn the fine art and science of influencing the player without their knowledge. The player must make all their own choices in an open and flexible game world. However, due to the larger order within the systems, there is a high likelihood that they will maneuver themselves into making a series of rich personal decisions. We design this progression even though we cannot control each individual detail.
Because the player is making their own choices of their own free will, the learning experience will ring true. It is the fundamental difference between:
Reading about someone not pulling the trigger
Deciding for yourself, despite all that has led you to this spot, that you should not pull the trigger.
Here is a little social comic creation game that just occurred to me as I was day dreaming in the shower. I loved Tadhg’s recent post about interviewing game design candidates with a test and it got me thinking. Unfortunately, If I actually was in a real interview, it appears I would have to rush off to a shower in order to do my best work. Wet candidates…part of the trials and tribulations of interviewing game designers.
This board game design is very small riff off the last Viki post. It is probably closest to Pictionary, but without the requirement that people know how to draw. Honestly I meant to write about e3 instead this morning. C’est la vie.
I should note that I haven’t played this yet, so it is at the untested prototype stage. That means it is highly unlikely to work the first play through and will need major tweaking. Still, I’ll toss it out there. Overview 3 - 4 players. You have a series of faces, word bubbles and interesting props. You goal is to make a hilarious comic with your friends.
Tokens
A set of 30 faces, word bubbles and interesting stamps. Some are blank and can be drawn on. The stamps are made out of dry erase board.
Erasable markers
3 minute timer
4 1 point cards
4 2 point cards
4 3 point cards
A score card
A small paper tiara
Setup
All stamps are spread out face up on the table.
Each player is dealt 1 of each type of voting card. They should end up with three cards with values of 1, 2 and 3 points.
Turn Structure A turn is split into three phases
Picking Phase
Placing Phase
Voting Phase
Picking phase: We go
Players pick up two stamps.
They get to write on the stamps with an erasable marker (or pencil in the prototype) if they wish to customize them.
There is a timer such that all players can take no more than 3 minutes.
Placing phase: I go, you go
The players then go around the room clockwise and place their stamps
The person in last place gets to place first. If it is the first turn, the player who most recently had a birthday goes first during the placing phase.
Players are encouraged to laugh.
Voting phase: We go
Players get several voting cards ranging from 1 to 3 points. If there are three players, they get three cards. If there are four players, they get four cards.
They give out voting cards face down to each one of their opponents.
All voting cards are turned over simultaneously. The players count up their score and place it on the score board next to their name.
Voting cards are re-dealt to people.
The turn ends and starts anew.
How long the game lasts
The game continues for 4 turns
Determining the winner
The simplest solution is to just add up all the points and declare a winner.
The winner gets to wear the little paper tiara until the next game or until the game is put away. They are not allowed to take the tiara home or go to bed with it. Unless this is the sort of social gathering that promotes such naughty behavior.
Optional rule: The Goomber
Many games have a goomber. They are that one person who will not play because they are busy or they don’t like games. They sit on the couch and read or fiddle about in the kitchen when everyone else is having a great time. Sometimes they are mothers. Other times, they are little brothers.
The Goomber has an important roll to play. If a Goomber exists, they are brought in at the end of the game. They are required to judge what the funniest portion of the picture. No player is allows to tell them who placed what.
Who ever placed this portion of the picture gets 12 bonus points. If more than one person participated, the points are split evenly.
Optional rule: Drinking rules
Each turn, the person with the lowest score for that turn takes a drink. They can specify one other person to drink with them in order to share the joy of drinking.
The standard amount that is consumed per drink is up to the team and is determined at the beginning of the game. A half shot per turn seems reasonable.
If anyone gets to try this game out, let me know. I'm thinking that the 'stamps' can mostly be just little smiley faces and word bubbles. Perhaps I'd also have a duck or an unfortunately drawn stalk of asparagus to spice things up. For prototyping the first version, I was just going to use index cards, a pencil and some scissors.
Remember when you were a young and you drew epic images on giant rolls of butcher paper? The little boys would draw cool spaceships and army men battling one another in landscape full of tunnels, fortresses and lots of explosions. The little girls, with their surprisingly superior sense of color, drew fish, rainbows, and people. You didn’t worry about your drawing skills. You just doodled for the fun of it.
The best part was either a study hall or perhaps when you had one of your friends over. You’d grab a whole sheet of paper and you’d each start doodling on part of it. He’d draw some massive star destroyer that was about to take out your very nifty fighting ship. Naturally, you’d unleash your fighter’s super powerful “Mega-Zapo-Cannon” which would result in a giant explosion. You told your story and mashed it all up with your friend’s story. Half the fun was making up nifty scenes with ninjas, robots, spaceships and more. The other half was seeing what your friend managed to think up.
These paper mashups were a quirky upwelling of that primordial communal artistic pulse that lies within all of us. At a very basic human level, it is joyful to create cool intricately detailed images and share them with your friends.
Viki is a design for a communal art mash up that riffs upon those simple butcher paper drawing sessions from long ago. It is a game design and community site that can be made by anyone with some solid AJAX skills.
Web 2.0 games I’m a big fan of modern software development tools, especially ones like the Web 2.0 technologies or Flash that allow rapid development of web applications without a heavy investment in expensive infrastructure. Server space is cheap and the tools are free or very low cost. More importantly, the mechanisms for communication and collaboration are built into the basic infrastructure of the platform. With a bit of brains, a lot of hard work and a very solid sense of marketing, there are oodles of opportunities for upcoming game developers.
The trick, however, is not about trying to replicate Space Invaders or Doom. Instead we need to create game designs that take advantage of the unique characteristics of the platform. Here is a hypothetical design exercise. Imagine you’ve been handed a piece of rope, three sticks and a duck. Your goal is to make a game out of this arbitrary collection of technologies and capabilities. If you try to replicate Doom, I guarantee that you’ll fail.
If you work within the constraints of the platform, some genius will create a game that is surprisingly addicting. It turns out that there are lots of things you can do with a duck.
The challenge with the web is the same story with different pieces. When you are developing for a new platform, you need to toss out the old genres and improvise some new ones.
What is a Viki? A Viki in its most basic incarnation is a visual wiki. Instead of creating pages of words that are hyper linked together, the users create pages of images that are hyperlinked together. Think of it as the ultimate sticker book mash up.
You start with a set of stamps. Some of these are primitives like squares and circles. Others are text boxes. Others are clip art of spaceships, aliens, castle walls, and oddly attractive cucumbers. You can place and arrange any of these stamps on a canvas. This canvas is your very first, very personal page.
You can create more pages by selecting an object and saying that it is a link. Viki will ask you if you want to create a new page or link to an existing one. If you type in the name of a new page, voila…you have a new page that you can navigate to and start filling up.
Now the cool thing is that each page generates a thumbnail that is added to your stamp collection. Simply by creating new pages, you end up creating new stamps.
Viki is communal A viki is a communal space. Anyone can go to a page and edit it provided that they have the correct permissions. Most folks claim that they can’t draw to save their life. However, if we provide easy-to-use tools and we provide strong social rewards to people for being creative, all sorts of creative sparks are bound to flourish. A little admitted lesson that many artists understand is that creativity is dramatically enhanced by peer pressure.
In addition to the communal reward systems, Viki also has a full suite of wiki features such as version control, recent changes and comments on changes. This helps people manage the Viki quite nicely.
Technology The entire application runs in a browser with the data stored asynchronously on the server. For the user, there are very low barriers to entry since there is no install and no heavy download. Even the interface is simplified. Users don’t have to know Photoshop or Illustrator. They don’t need to spend years mastering the art of placing a line on paper. They browse to a URL and start creating.
There are also some nice bits for the developer here. Since we are using very simple technology, the prototype could be whipped up in a few nights of programming by an intermediate skill AJAX coder. Can you place a transparent gif with a CSS div and store it in a database? My friend Harold mocked up a basic proof of concept in a night of playing with Ruby on Rails.
Some of the more complex features such as thumbnail generation require server side image processing. This is not rocket science, merely work.
Someone I know once claimed that art programs will never make it onto the web. I call BS on this dinosaur thinking. :-) The trick is finding an application that benefits from web technology instead of attempting to shoehorn Photoshop into a web browser.
The game So far, I’ve described an interesting toy, but not a game. Instead of laboriously iterating through potential design specs, I want to tell you a story about this design. It is an attempt to capture the feeling of playing the game. This provides a starting vision for the next stage of creating a new core mechanic through intensive iterative prototyping.
There are five main stages to our tale.
Discovery: How the player finds the world.
The Hook: Why makes the player want to dig further into the game?
The Feedback: What are the feedback systems that encourage deeper play?
The Store: How does this title make money?
The Source of Content: How do we provide the player with new content so they stay?
The Discovery Harvey, an avid MySpace user discovers the NinjaGarden.com while browsing around looking for something ‘cool.’ Harvey is a rather normal kid of about 14 who enjoys doodling in his notebooks. He isn’t the best artist in the world, but that has never stopped him. He thinks the name is hilarious and the artwork on the site is rather fun.
There are dozens of very interesting stories on the site and he becomes enthralled in a particularly fascinating one about Mickey Mouse as a blood thirsty master ninja. The fact that someone took a worn out icon and made it authentic and edgy rocks his world.
The Hook As Harvey digs deeper into the stories, he hits a wall that encourages him to register. Once he is registered, he has his own account that gives him energy points. He can keep reading until he runs out of energy points. The only way to get more energy points is to rank pages or start a story of his own.
He spies a story thread that he really like and creates a link off of one of the main scenes.
A new canvas opens up and he starts plunking down some of the basic elements in the basic collection. There are ninja cats, giant robots and naturally retro spaceships with fricking laser beams. And you can type rude things.
The Feedback Other people start viewing Harvey’s new page. They dig it and offer comments. He is feeling popular and making new friends who appreciate what his creation. Reading stories is fun, but social interaction with real people is intoxicating.
Whenever someone visit or ranks his page, they leave energy points behind. These boost Harvey’s points which lets him read more. They also encourage him to create new pages. As Harvey’s page gets more readers who rank and comment on his work, he gains a reputation.
Some of the really popular pages make it to onto the “Garden of the Day” list. This means thousands of users are likely to check it out. Harvey begins to dream of one day reaching such heights.
The Store The original set of stamps is rather limited. It turns out that there are lots more out there that you can buy using extra energy. Some of them are quite rare and a few you need to buy with a combination of energy and real money.
Harvey buys a set or two of professionally drawn Mickey images. They only cost him a five or six bucks and they let him create much more in-depth scenes.
The Source of New Content It turns out that the stamps of Mickey and friends are created by a lass named Aya. At age 17, she is an excellent illustrator and delights in seeing what people create with her artwork.
She gets half the money that Harvey spends. There are two hundred other people that also bought her work and she just received a check for $150. That will pay for a very cute pairs of shoes. More importantly, she is famous. Her online reputation is reflected directly in the reputation of the pages that are created with her artwork. Perhaps it is only on one site with a small group of people. But it feels good to have people respect her and her art. She would not give that feeling up for the world.
Now the circle of content is completed. The few highly creative people provide a seed that encourages others to be creative. The result is an explosion of content that acts as a magnet for additional potential customers.
Is this a game? You’ll notice that this is not a traditional electronic game where you shoot things. Some traditionalists might argue that it is not a game at all. On the surface, it has more in common with Wikipedia or Slashdot than your typical first person shooter.
Yet all the basic pieces are in place for a rousing social game. You have user created worlds where the act of consuming stories and creating stories are the game play verbs. You have a robust feedback system complete with strong goals for players to strive towards.
Viki is to traditional games as Charades is to Chess. It is a social sandbox game played by creative people.
Future Extensions This is just a sketch of the basic Viki system. In the future, there are numerous styles of play that you can support with the same engine:
Living world: By building logic into the stamps, you can have a world that grows as you play. Logic can take into account the position of stamps and their time on the canvas. Trees can grow, characters can change facial expressions, etc. Drawing becomes a more involved act similar to gardening.
Combat: With the addition of basic Javascript-based collision detection, you can add a turn based system where players place object that attack one another. The pace of the game is such that the collisions only need to be detected one per click and can be calculated offline if necessary. The goal of the game is to build the coolest image while damaging the other side’s pieces.
Comic creator: Any time people put down images and text, they tell stories. Wouldn’t it be enjoyable to let people subscribe to a particular author’s canvas and encourage them to create a series of online comics. Think of it as a comic blog (a clog?).
Product design: With a viki, we have a system where larger numbers of people collaborate on complex multi-dimensional designs. Imagine a dozen participants with the best ideas percolating to the surface due to the built-in ranking system. Suppose that you are dealing with a design for a three hundred page website. A viki becomes your essential sketch pad and its contents are sorted by the wisdom of the masses.
Conclusion I have several more of these ‘alternative’ game designs lurking in notebooks and half finished essays. I’m sharing them for two reasons.
First, most of the designs I’ll suggest are pretty inexpensive to implement and some folks may enjoy noodling with them as projects. To this end, I’m providing all source files from my mockups. Use and abuse as you desire as long as you include my name and a link back to this article. I'd be happy to publicize any fun experiments on this website. Click here to download the source images (1.2 MB)
Second, I want to encourage folks to think outside of the box when it comes to game designs. Not all casual web games need to be Match Three variants. There is an infinite universe of fascinating social games that have barely been explored. Some smart cookie is going to create an amazing entertainment phenomenon using tools that have been readily available to millions. They’ll be willing to try something new and when they do, everyone else will wonder why they failed to think of it first.
take care Danc.
References The quote that inspired the game “My top five favorite things to do as a kid: 5) Play army 4) Walk the rail road tracks and explore wilderness. 3) Make weapons. 2) Build stuff with Legos. 1) Draw epic spaceship battles on 100 feet stretches of computer paper.” - Robert 'Apache' Howarth on VoodooExtreme http://ve3dboards.ign.com/Message.aspx?topic=23127087
Note on Legal Issues: In any title that has user created content played by minors, there are legal issues. Luckily, other sites have been dealing with these for many years so the solutions are straight forward.
Collection of data from children under 18
Report problematic images. Quite likely these are tagged with a nudity tag and then just culled from under 18 imagery and searches.
Harold whipped together some sweet prototypes of SLOA this weekend. He agreed to let me post them as an educational example of how prototyping works. Think of this exercise as speed dating mixed with the post mortems that you find in the back of Game Developer magazine.
Version 1 The first version of SLOA sported the core game mechanic, a simple conversation system. There were two token, the drab and asexual Suburbanites and the dapper green Spies. There really isn't any game here, just a technical demonstration of a basic gameplay system.
What went right:
Primitive graphics: I'm very proud of Harold's graphics composed entirely of cones and spheres. It took him substantially less than an hour to put these together and that is as it should be. Time spent on creating pretty graphics during the prototyping stage is time misspent.
No UFO: Prototyping is as much about what to leave out as it is about what you build. In the design, the UFO, the main character of the entire fricking game, is really just a mouse pointer when you come right down to it. The system mouse pointer is good enough.
Smallest possible step to feedback: Even though there is no game here, there was still enough to make some comments that dramatically improved the next version.
What went wrong:
Getting hung up on graphics: There was in fact a prototype-0 of SLOA. Harold spent a good hour trying to get the antennae to smoothly animate out of the head of the spy. But there was a bug someplace and a few minutes turned into an hour of frustration. He was focusing on making it pretty instead of making it work.
Colors: The green of the spies was too light and they blended into background. Even at this early stage it was possible to get feedback on the game's information design.
Complexity: The conversation behavior was too simple. With so few characters there wasn't much interesting happening.
Version 2 Version 2 fixed a couple of problems with version 1. The colors were brighter on the spies and there were a lot more spies on the screen at once. Everything was peachy keen. Except for one little detail... What went wrong:
Conflict: There was a desperate need for some sort of conflict and challenge. It turns out that conversation alone is boring. This is a wonderful discovery since it shows us that we can't use the conversation mechanic as our core game mechanic. It is best to discover these things early on in a game design. :-)
Version 3 Version 3 sought to augment the basic mechanics with some classic conflict. Harold went all out and added in Agents and the detection score. The agents had sun glasses and black suits. MIB of the most classic sort, baby. They also had health meters so you couldn't just rapidly click-massacre a dozen agents in a millisecond. What went right:
The game was born: There was actually a challenging little game evident in this prototype. The conflict escalated, agents wandered about, your score increased. After a decent 5 minute playing session, the frantic clicking all came crashing down and the game ended. People were comparing high scores and improving their scores with each play. When people play your dismal prototype more than once, you know you are onto something.
A recognizable setting: People grokked the alien-themed setting. The agents added the necessary burst of context that helped initial players feel like they were doing more than just clicking on random icons.
What went wrong:
Weak connection between action and reward: The score in the game would go up and you'd kill agents, but there wasn't a clear connection between what you are doing and the rewards. A good game should be like an instrument. You swing the stick, hit the drum and it makes an enjoyable sound. Swing, boom. Simple enough. Version 3 didn't that rhythmic clearly delineated musical response. It was more like one of those little rain sticks that you turn upside down and you get a long tinkling noise. Pleasant, but not addictive.
No focal point: Another problem was that little guys were wandering all over the place and you had literally 20 different things to worry about all at once. Successful games with lots of moving objects on the screen tend to have one or two focal points that the player can watch. In most shooters and action games, there is a central location that must be protected and then the player zones out and lets their peripheral vision take in all the various threats. Version 3 lacked this focus and the result was a game that felt more stressful than fun.
Killing agents wasn't fun: To continue with the music analogy, when you hit a drum, there is a satisfying physicality to the action. Most decent interfaces, be they simple buttons or complex game mechanics, have this tactile element. The interface for killing agents involved a slow and steady draining of their life force. It made sense when you described it on paper, but holding down a mouse button didn't feel exciting. Combine this with bad collision detection and killing agents was another frustrating experience.
Version 4 In version 4 we finally had a robust enough system to start playing with the game balance. We added several mechanics that improved the feeling of direct control in the hopes of reducing the risk / reward cycle time.
What went right:
Control over individual spies: We had talked about being able to drag a spy in a direction in order to reorient them. This would let the player be more tactical in their position of the spies and hopefully result in their feeling more control over the board. The implementation was a qualified success. The game immediately became more interesting and a wide variety of strategies came into existence. The 'wild spy' was born. This was a spy that ran about the screen like a lunatic at high speed, talking to every suburbanite in existence. He was hard to keep from whacking into agents, but he gathered a lot of points. Also, the 'slow spy' was born as well. This was a spy that basically was stopped in his tracks. He didn't get a lot of points, but he was much easier to defend.
Collecting Agent bodies: When you kill lots of agents, their bodies pile up. We thought we could include a 'coin collecting' activity by letting the player click on bodies and gain points. This worked slightly, but wasn't a great addition.
One spy at a time: This isn't either good or bad, but when players started learning to beat the game they began adopting the tactic of only having one active spy at a time. The game was too confusing to play well, so players reduced the complexity of the game until it was manageable. This demonstrated clearly the important of building focal points into the game.
What went wrong:
Physics for the sake of physics: In the initial implementation of dragging spies in a direction, your motion took into account the spy's current momentum. On paper this was a great idea that sought to add that 'tactile' element to the verb. In practice, the dragging felt sluggish. Spies were harder to control than necessary. One possible solution was to remove the momentum factor and see if it improved the feel of the dragging action.
No short term penalty for failure: If a spy was caught, the abstract evidence meter went up but that didn't really affect things much. Also, a spy could blast through several agents in a second making agent encounters rather hectic.
Coin collecting had no risk element: You could leave the agent bodies on the ground forever and collect them when you got a spare moment. A better solution would be to have them fade out after a period of time so that there is some risk of not getting the points.
Version 5 With version 5, we finally are at a game where players can demonstrate mastery. It is horribly unbalanced and still need some major additional systems. However, I can sit down and happily play for 5 minutes without feeling frustrated.
What went right:
Removing unnecessary physics improved the tactile feel of dragging: One variable tweak later, the control of the spies became much more responsive.
New strategies that improved the focus of the game appeared: The surprising side effect of improved dragging was that the 'slow spy' technique became the dominant way to own the game. By clicking on a spy twice, you could stop it dead in its tracks. Gather enough little spies up in the corner of the screen and you had a highly defensible position against the wandering agents. Also, you ended up being able to farm major info points by clustering so many spies and suburbanites in close proximity. Finally, we were starting to get away from a series of random events towards a player created environment that had interesting strategic implications.
Agents convert spies: When an agent runs into a spy, the spy is converted back into a suburbanite. This makes the player feel that they 'lost' a spy. We can augment this in the future by given the player a limited number of spies. The first benefit here is that there is now a more immediate result associated with the player letting a spy and an agent interact. This tightens the risk / reward cycle. The second benefit is that focus is improved. A spy that gets in trouble is lost and the player can move onto a new activity. This clearer definition of the beginning of an activity and the end of an activity helps clarify the game play.
What went wrong: With vesion 5, the gameplay is starting to open up and we have easily a dozen different paths that we could go down to actually make the game fun. This is typical of a prototype. We add and add and add until the game becomes quite interesting. At a certain point, we need to ask 'What elements are the most fun?' and trim back the various gameplay experiments to focus on those items. A prototype should naturally grow and shrink in complexity as you try a bunch of things and then boil the gameplay down to the essentials.
Long term level structure is non-existent: Levels never end. We need to add in some meta game mechanics that govern longer term risk / reward sequences. We can set up goals for each level and start sequencing challenges. This will give the player a feeling of progression.
The evidence meter is bogus: Though it was in the original design, the evidence meter doesn't seem to add to the game play. Each evidence level should effect the map in some way and the player should be able to manage the evidence level.
Obvious player tactics need to be countered: If the clustering of slow spies is a fun technique, we should make it challenging. What if agents targeted your 'base' with more intelligence?
Support for focused gameplay: The base is a fun concept that really focuses the gameplay. However, it is one that emerges from the core mechanics. Should we build this concept into the game so that it is supported and more obvious to new players?
The tactile feeling of the game could be improved: Dragging still doesn't feel perfect. This could be improved with some better dragging code. Also, we can't forget to improve the Agent killing mechanic.
Iterative design in action SLOA is by no means fun quite yet, but we are getting there. Every iteration (some of which take no more than 5 minutes to create) demonstrates the same basic methodology.
We create a theoretically enjoyable prototype.
We play the game
We record what works and has potential
We record what doesn't work
We propose some changes and implement a new prototype. Wash, rinse, repeat.
We are still only a few iterations into prototyping SLOA. We could put in a dozen more before the gameplay gels enough to start building out content. Even then, the game won't be polished until close to release. Game development is a fundamentally iterative process where the game design is just the beginning.
I'd like thank Harold for all his hard work. I like to say that a game design is like a movie script. It only shines in the hand of a great director. For SLOA, Harold is acting as the director of the game development and the real genius of the final product will be the result of his inspired implementation decisions. It is a wonderful process to observe.
How to make the stupidest game possible Several years ago I designed a casual game called The Secret Life of Aliens (SLOA). The player starred as an alien UFO whose job it was to explore earth and return with news about the natives. You could implant various alien probes and turn happy suburban dads into alien spies. Evil trench coat wearing Agents (modeled after Scully from the X-Files) were constantly snooping about trying to gather evidence of a diabolical alien conspiracy.
The longer you went undetected, the more delightful information you could gather about the natives. This made your overlords back at the university on Sigma Prime very happy. On the other hand, if the Agents gathered enough evidence of your existence, they nuked the entire town from orbit in order to 'cleanse' the alien invasion. Think of this as having a high Grand Theft Auto alert level except the cops are armed with nuclear armaments.
SLOA was intended to be casual action RTS set on a single screen. I drew some test graphics and a friend of mine (Phil Carlisle of Worms fame) took the design and made a prototype.
And it sucked. Here is why. What went wrong I was playing with fire in the original SLOA design. The core mechanic of the game was a highly experimental gossip simulation system. The little AI characters wandered merrily about and stopped to chat with anyone who wandered by. They would exchange information about various topics and then go and chat about their freshly collected news with the next person that wandered by. Agents collected evidence by talking to people who had talked to someone who had seen an alien.
It was all quite elegant and very original. I had come across the idea talking to a professor from MIT and was convinced that it was dying to be made into a game design. After all, if a game managed to model a fully working social ecosystem, it must be fun. Sometimes I imagine that a similar thought process led to such glorious experiments as Sim Earth.
Here are some reasons why it wasn't fun:
The cause and effect mechanics were not transparent to the user: The little people talked, but you never really knew the internal state of their minds. They might have two or three topics in their heads and as the player, you had no idea. You did something and then something random happened. This is distinctly not fun.
The core risk reward schedule was too long: In many games you click a button for 2 or 3 seconds and you get a cool result. In the original version of SLOA, you clicked on something and 20 seconds later some number would change. There was no steady drip of candy treats to hook the player.
The lesson I got from all this is that being original and intellectually satisfying does not guarantee that you will create an enjoyable game. A worthy thought, but one that I'm sure to ignore in the future.
Another attempt: The Stupidest Game Possible Most failed game designs are worth tossing at this point and I did indeed shelf SLOA for quite some time. However, I love the setting and am convinced that there is a fun game lurking someplace in my original design. Other than the recent "Destroy all Humans" there is a remarkable dearth of casual alien probing games on the market.
I have a bag of tricks that I pull out in cases such as this. One of my favorites is an exercise called the"Stupidest Game Possible." Inevitably a game designers will be presented at some point in their career with a sketch of a monstrously complex game design. My eyes tend to glaze over and images of slogging away on the same game for decades fill my brain.
"Wait!" I cry, "What is the stupidest game possible that captures the essence of your idea? Reduce this superbly detailed MMORPG with excellent public housing algorithms to something can be completed by an average programmer in a day or two."
Done correctly, this is a great exercise that really helps boil a concept down to its essentials. The goal is to identify the 10 seconds of enjoyable gameplay that serves as the core of your title. Admittedly, I've seen two distinct responses. The first is absolute disgust in my obviously simple minded dismissal of the wonderfully detailed work of art that has been laid before me. The second response is a gleeful smile that comes from the realization that they can complete their dream game in a mere 2 days. :-)
The real win here is that in a month of creating stupid games, you'll kill 9 prototypes that suck and find 1 worth pursuing. This is far better than spending a year or more on 1 prototype that has a 90% chance of sucking. I performed this magical shrinking exercise on SLOA with some very interesting results.
The Secret Life of Aliens: The Stupid Version I reduced the game design to my three components: tokens, rules, and verbs. First I defined a minimal number of tokens (3 tokens and 2 resources):
Suburbanite: The standard person. Usually there's 10 to 20 of these folks wandering on the screen.
Agent: The classic MIB character. These pop onto the screen at a steady rate.
Spy: The player can convert Suburbanites into Spys.
UFO: This is really just a mouse cursor.
Evidence meter: This tracks how much evidence the Agents have collected against you.
Info Score: This tracks how much information you have collected.
Rules: The next thing that went was the original gossip system. It wasn't enjoyable and needed to be dramatically simplified. In the new version, people bounce around the map slowly like billiard balls and only talk when they get within range of one another. There is no complex AI or meme-based conversations. Instead, you have the following clearly defined cause and effects rules:
If a Normal Person gets near a Normal Person, nothing happens.
If an Alien Spy gets near a Normal Person, your Info score goes up.
If an Agent gets near a Normal Person, nother happens
If an Agent gets near an Alien Spy, the evidence alert level goes up.
Verbs: Adding short term risk rewards sequences You can convert a normal person into a spy by click on them with your UFO beam. They stay converted for 20 seconds and then change back into a normal person.
Action: Click on a Suburbanite and they turn into a Spy
Reward: Spys talk to Suburbanites and increase your Info score.
Risk: If you turn too many Suburbanites into Spies, you won't have enough Suburbanites to talk to and your score will increase only slowly. If you don't convert enough, you also won't increase your score fast enough. The player needs to constantly manage the correct ratio of Spies to Suburbanites to get the highest score.
The next verb I added was a more direct method of interacting with the world Clicking on an Agent for a second or two burns them into ash. Probes are nice and all, but everyone knows that Death Rays are where it is at.
Action: Click on an Agent to burn them into ash.
Reward: Frying agents lets you collect information with less hassle.
Risk: As evidence mounts, more agents start spewing out of predefined emitter locations. You need to make a simple guns and butter choice. Should you kill the rapidly approaching agents or should you build more spys to boost your score?
I'm rather happy with how basic this game design has become. The original design was 13 pages long. This is a little over a page. It still captures the spirit of the original gameplay and might solve some of the basic problems that plagued the last prototype.
Another less obvious benefit is that with fewer moving parts, it is less likely that the design will be unsalvagable. If the first prototype fails to be fun, we can make dramatic changes with relatively little effort. Once the infrastructure is in place with a prototype, a simple design can go through a half dozen major changes in an afternoon. Simple game designs can be rapidly evolved at a much lower cost than complex game designs. Again, the benefit is that you are far more likely to end up with an enjoyable set of core mechanics.
Next Steps I've been chatting with a charming and talented fellow (Harold Hausman of Whack-a-Ninja fame) who it going to attempt to create the entire SLOA prototype in a weekend using Anark Studio. The graphics will be simple primitives, but the core gameplay should all be there. If the end result is enjoyable, then steps can be taken to add additional layers of game mechanics in order to hone the addictive experiance even further. If it isn't enjoyable, c'est la vie. :-) Very little time was lost and many lessons will no doubt be learned.
There is a freedom in creating small prototypes that is quite joyful. Most games still rely on a perfected core that spans a mere 10 seconds of gameplay. Get the right core game mechanics and you've captured 80% of the magic that makes a classic game. Once you've captured that magic in a prototype, you have the freedom to make the next great epic or the next elegant haiku. Doom, Splintercell, Mario 64, Civilization, etc all started out as small test beds, where judged as successes, and only then were evolved into the great games we know and love. Their originality and core gameplay were baked in while they were barely more than an implementation of the 1-page design you are reading today. I firmly believe that a successful prototyping process holds the key to original engaging gameplay.
With this in mind, may we all go forth and make the stupidest games possible. ;-)
This weekend I had a chance to put together a little test rig for a revised interface I'm trying out. I had two goals. First I wanted to rectify some of the complaints about my first interface. Second, I was playing with some of the artistic bits based on the comments folks had in the earlier art thread.
The Test Rig I'm following the list laid out in my component bible. You quickly end up with lots of objects that all can be in any of a half dozen different states. Rather confusing to be honest. To keep everything straight, I whipped together a primitive menu that lets me sort through the components as I finish them.
Left and right arrows switch between components. The large text tells you the name of the component.
Clicking on the down arrow in the center cycles through the states of the selected component. (You can get things in some odd states if you switch between components when you are in the middle of the cycle. Click enough times and it all seems to come back to normal. It's a test rig, not a polished application. :-)
Fixing the UI: The second pass I had several issues with my first UI attempt.
Remove unnecessary hierarchy: First, I tried a pie menu for selecting between multiple upgrades, but it was a pain to use. This time I made the rule that ever powerup gets one button. If you can see it, you can click on it and something wonderful will happen immediately. Sometimes I wish all UI's followed that philosophy. :-)
Restrict the UI to the tasks at hand: Early on I thought it would be fun to have a planet that could be spun around. Unfortunately, allowing dragging in multiple directions was too much freedom. Half the time, the planet ended up at some odd unusable angle and the rest of the time the 3D rotation algorithm reversed up and down. There's no point in requiring users to master crazy 3D rotation concepts just to play the game. This time I constrained the planet rotation to a single axis. I also placed the powerup buttons above the equator so that players can always see them. Much simpler and it is still viscerally enjoyable to spin the earth like a top.
The Art Style The art should look at lot like the previous test exe. Really the only new model is the space ship. I tried to make something a bit sleeker than the Space Cute design, but still having a prominent character element that I felt was lacking in the 50's iPod style.
I'm rather excited about the ability to use simple texture maps to change the look of the ships quite easily. There are two images, one for the helmet and one for the ship. By swapping these out, players should be able to get a huge range of different 'team flags'. I need to spend some time cranking out some skins.
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:
