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.
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.
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?
I just got out of the packed keynote for MIX 07 in the surreal universe that is Las Vegas. The event was set in an enormous hall at the Venetian with four cinema sized screens dominating the stage. You could see individual pores on each speaker. A band on raised stage was rocking out to sweet accordion music set to what appears to be lyrics about pickles. All around me are masses of developers, designers and Microsoft folks gabbing about art, Macs and revolutionary new technologies. Wait, where was the chatter about black helicopters and the joys of pragmatic Outlook maintenance? Cultural dissonance rocks my world.
The big news of the event is that Silverlight will have will have full .NET support. Silverlight, for those who haven’t been following the glorious web technology soap opera, is a cute little browser plug-in that allows you to build rich internet applications. I think technologies like this are good for game developers. More on that in a bit.
Expression Design is released My product, Expression Design also went live Monday morning and I picked up a boxed copy at the event. To say the release process is like giving birth is perhaps extreme, but I’m very proud of my team. They’ve waded through swamps of vipers to get this product out the door and are already rearing to work on the next version.
Version 1.0 graphics tool are rather rare and mysterious creatures that few software developers get a chance to work on. I’ve been blessed with the opportunity to design three in my career and have come to realize that their promise is greatest even when their features are most limited. The next few years will be a rush.
SpaceCute supports Silverlight If anyone is interested in dabbling with either Silverlight or Expression Design, it just so happens that all the SpaceCute graphics were built with these technologies in mind. To squeeze the delightful XAML marrow out of the SpaceCute files just follow the steps below:
Import the .design file in the zip into Expression Design
Click File > Export in the menu.
Select XAML as your file export type
Voila, you have a lovely chunk of XAML assets for messing about with Silverlight. You can now make a sexy, zippy, web-based version of SpaceCute that runs on both the Mac and the PC in Firefox or Internet Explorer. Here are links to all the files.
Why web-based technologies are desirable for games I’ve devoted most of my professional life to making complex game technologies more approachable and accessible for creative people. Silverlight and Expression Design are just a couple more steps along that path. I’m a big fan of runtime technologies like Flash and Silverlight because they offer two important advantages to small game developers.
Simple install: A massive percentage of (often upwards of 50%) downloads never make it onto the customer’s machine. That translates directly into lost sales for those starving indies of the world. A single click install where the player has instant access to your game allows you to capture player interest immediately. Once you’ve hooked them, you can stream in additional levels, cut scenes etc at your leisure. When you increase your initial conversion rate, you increase your revenue. It is simple math, but a bloody hard technological problem to solve well.
Reliability: Custom engines run well on the developer’s machine, but often fail in horrendous ways on a multitude of customer configurations. A mass market runtime backed by a company whose biggest value proposition is a great experience on the widest number of machines means you shouldn’t have to worry. The number of support calls a Flash developer fields regarding video drivers crashing their customers computers is substantially lower than the number fielded by folks who build a custom engine.
Areas for improvement Obviously, not all game developers use Flash or Silverlight. If you look at top titles like Bejeweled, Peggle, or Aveyond they still use old school downloadable installers. In the past few years, there have been big obstacles to using browsers plugins as your primary platform for casual and indie game development. The good news is that these problems are slowly, but steadily being eradicated.
This is the area that Silverlight addresses. The addition of a full-fledged language like C# should not be underestimated. You’ll start seeing more complex games with more intricate behavior. You’ll be able to easily create scalable, robust architectures using familiar tools. This advances us beyond ‘house of cards’ applications and opens up rich clients to the classically trained master programmers of the world. I am a great believer in their creative powers to blow our minds and change the rules of the game in the process.
Speed: Traditionally, web-based engines have been slow. Users are subjected to slow framerates, small number of objects on the screen and wimpy dynamics. It is not really surprising, given these limitations, that the majority of Flash games are simple action games or point and click adventures. Our runtime technology is barely capable of running games that were popular in the early days of DOS. With technology limitations, come genre limitations.
Local storage: The biggest reason that folks are using downloadable applications is that many users still play offline. Ideally, we could cache 20 megs of data plus a 2 meg save game file on your hard drive and allow you to use the application when the internet is disconnected. This is exceedingly difficult with current technology.
Some of the technologies that Adobe is working on looks promising here and I hope to see more from Microsoft in the future. When game developers gain control over their caching and local storage, the silly distinction between online and offline starts to disappear. This blocker hasn’t been solved yet, but there is hope.
Future of mixed cloud/client games What really excites me is the mixed world of applications that sit halfway in the cloud and halfway on the client. As these become easier to develop, more people will get into the market and they will innovate in order to differentiate their products. Casual game developers are just starting to dip their toes into this universe, but with time expect a flood of interest. Occasional connectivity + instant downloads is a huge and exciting opportunity to create entirely new genres.
Shared user created content: As users create content and upload it to a universal cloud, you open the world of massively single player games. Imagine Spore as a web-based RPG or platformer with a single click install.
Multiplayer experiences: Little Big World shows a little bit of what can happen when you mix an traditional platformer with online capabilities. Imagine if most web-games had this level of multi-player mechanics.
New revenue models: The retail model of paying 19.95 for a mess of levels is due for a shakeup. Micropayments in casual games are a natural fit for cloud/client games. The cloud provides the persistence and the payment system. The client provides the rich interactivity that captures the player and provides the compelling context necessary to encourage them to invest monetarily in the game.
Stats: Great games are well-balanced games. Well-balanced games are created through the massive amounts of user feedback. Internet enabled games offer a natural way of collecting copious amounts of player data in a transparent manner. Imagine if all games had Valve-level diagnostics built in. If websites can do it, so can games.
Ending thoughts I’m excited about Silverlight, not necessarily because it solves all the problems facing game developer or because it provides all the solutions. I’m excited because it adds a serious jolt of competition that is bound to drive rapid advancements. The improved tools and more robust runtime platforms that result from competition are huge wins for game developers. They allow us to focus on making great immersive games, not on rewriting our game engines for the 57th time.
For at least the next five years, the casual and indie games marketplace is going to be a crazy ride. The ‘typical’ genres of point and click Flash adventures, shooters and downloadable Bejeweled clones is going to replaced by instant install, rich applications that cover a much broader range of game genres. Developers will have the power. They just need to use it to make something amazing.
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:
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.
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.
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.
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.
Once upon a time there was a game design known as SpaceCrack. The setting, with its cool white iPod-inspired theme was a bit too niche. Here are some sketches of a SpaceCute theme. In SpaceCute, solar systems are delightful gardens filled with animals quite extraordinary. Anyone think that this is worth turning into a set of graphics?
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.