I've been playing around with a variety of styles for Space Crack. Everything from giant robots to completely abstract shapes to Sanrio-inspired space monkeys.
Assuming for a moment that you have a decent game design, one of the most difficult decisions facing a game is the setting and theme. It is a topic so important that many gamers often mistake the theme of the game with the actual design of the game. You'll hear "I have a great game design. Imagine chickens with chainsaws." This speaks to the heart of the importance of a game's theme. When you think of your ultimate game, you'll almost always gravitate towards a description of the game's theme. A visceral vision of the game will pop into your head, a fantasy involving concrete characters often complete with movie like action. If I wanted to sell you on a game, all I have to do is describe your fantasy game and you'll be slavering for my title in a heartbeat.
A good theme is what causes the player to pick up the game in the first place. It is a hooks that ties into their existing fantasies. If you create a theme for a game that does not resonate with the fantasies of your target audience, they'll never try your title and regardless of the quality of your game design, your title will sit on the shelf.
I remember a wonderful little title called Moon Base Commander. It had delightful game mechanics saddled with a boring as dirt theme. Generic groups battling on a generic lunar landscape. Do you fantasize about being a Moon Base Commander? I don't. There were no doubt other reasons for the title's commercial failure, but the theme was a complete killer.
Searching for a theme Often, a game designer will find themselves in a situation where they have an interesting game mechanic but they then have to come up with a good theme. The original Nintendogs training mechanic was used in a parrot training prototype. It was interesting, but didn't have a theme that would connect with a large population of gamers. Now, tie that parrot training game with a new skin that has you training puppies instead and voila, you have a commercially viable title.
SpaceCrack intentionally started out with a somewhat generic space theme. Sometimes as you are prototyping, interesting game mechanics will pop up and it can be useful to adjust the story to fit the reality of your game. I wanted to bake the game mechanics a bit more before I assigned them a theme.
So now I'm at the point where I need a theme. And I'm stumped. Since I'm an artist, I started doodling, just to see what would happen. After a while, the monkeys started to speak to me.
My thought process for the current Space Crack theme is rather simple. I wish there was more depth behind it, but there isn't.
Monkeys are a popular pop culture icon
If I make monkeys a major theme of my game, everyone who likes monkeys would be tempted to try the title. "It's got monkeys. Sweet! I'll give it a shot."
I personally enjoy monkeys. When your are slaving away on game art at 2AM in the morning, it is good to work on something that you love.
Hope you enjoy the graphics. :-) (When I draw all day long, there tend to not be as many essays.)
What a pleasant surprise. Michael Bayne of Puzzle Pirates fame dropped me a note that mentioned he had created a prototype of Space Crack in his spare time. You can find the Java applet here. He used his game creation system Game Garden, demonstrating once again the benefits of using established middleware in the rapid creation of a prototype.
You'll need a Game Garden user name and a friend to try out the game. The whole thing is in a gloriously raw form so feel free to apply your most creative game critiquing skills. At this stage the designer is doing almost as much designing on the fly as they are polishing. What would it take to improve this prototype and make it enjoyable to play? Some areas of interest when doing early prototyping
User Interface: UI may seem like a polish level detail, but it can have a major impact on the way that the game is played. In essence your UI is concrete implementation of the verbs and feedback loop for your core game mechanic. This is important to get right, especially in games where the 'feel' of the action forms a critical aspect of the core mechanics reward.
Rhythm of the game: Is there an established rhythm of actions and rewards to the game?
Player choice: Are the core mechanics generating interesting strategies and situations that cause the player to make important choices?
Balance: Are the various variables that affect the game adjusted correctly to allow the other major factors a chance to be judged effectively?
The Brain Storm At this early in the prototyping phase, I will often use a simple brainstorming technique as a means of jump starting the accelerated evolutionary design process.
Step 1: Jot down a list of 20 or so problems as I play. Often a simple notebook with a phrase or two per issue is enough to capture the problem areas.
Step 2: Go back and think up simple solutions to each one. Often new game mechanics will emerge that solve multiple problems in one go.
Step 3: Prioritize the list into ‘Big problems’ that represent fundamental game play issues and ‘Problems’ that are annoying details that need to be fixed.
Step 4: Magically implement all the things you’ve jotted down. If you don’t completely rewrite the game from scratch you are either very lucky or you’ve not been nearly critical enough with your first prototype.
Here is the list that I came up with for the Space Crack prototype. I apologize ahead of time if this is stunningly boring. Game design, like it or not, is a process of a thousand details and decisions.
UI issues Big Problem: In the UI, you can either select the space ship or the planet. This leads to some confusing situations where you think you are clicking on the planet, but you are instead clicking on the ship.
Option A: Move the ship icon so that it is adjacent to the planet. This makes it far less likely that you will click on the wrong token.
Option B: Clicking on a planet with a ship automatically highlights the adjacent planets that it can travel to. Clicking on a highlighted world makes the ship travel to that world. Click anywhere on the map to deselect the current planet.
Option C: Drag a ship onto an adjacent planet. This gives you a more tactile interface and also avoids confusion.
Problem 1: Players don't know when they run out of command points
Make command points a much larger counter that sits at the upper middle of the screen.
Problem 2: You don’t realize that you are spending command point.
Create an info bar at the bottom of the screen that tells on roll over how much a particular action is going to cost. For example “Attack enemy: 1 command point.” With a little smart graphic design this could be incorporated into an on screen area that also includes the list of resources.
You can also have a report that says “You cannot afford this action. You are out of command points” This can be spiffed up with more interesting text at a later point.
Problem 3: You don’t know how much a ship costs
The info bar is again useful here. When you roll over a planet that does not have an attack stack display “Click here to build a level X ship for Y crack”
Rhythm Issues Big Problem: The game really feels like an RTS game. I felt like I needed to move very quickly in order to get my moves in. This rushed feeling is not the joy of a turn-based strategy game. There are a couple issues here that I’ll split out in sub-problems.
Problem 1: Turns begin without you knowing. The result is that the game feels like one long drawn out RTS.
Put a dialog box up when a new turn begins. Tell the player specifically who is ahead, how much new cracks you have accumulated and how many command points you have left to spend. The player must click 'okay' in order to go.
Problem 2: It is difficult to tell when your turn has ended. Currently the turn ends automatically when you run out of command points. In theory this is good, but in practice you never know when your turn is over.
When you run out of command points, a button appears on the screen “End Turn”
Clicking the button ends the turn and causes an update phase to occur. We should use this opportunity to include another risk / reward cycle.
When the turn ends, the map highlights all the goodies that you are going to get on the next turn. Numbers appear above all the planets showing your how much crack you’ve gotten. (+3!, +1, etc) Your ships are produced.
In the future, this phase could be quite the extravaganza. The camera could pan from spot to spot with twinkling bonuses appearing one after another. All that potential loot just waiting to be exploited when the next turn starts!
Problem 3: Building ships is easy and not very rewarding. I was quickly clicking to build ships and then not really thinking about where I was building them.
Some of this is due to the pacing problem of the turns. However, the lack of anticipation in getting a new ship is most unfortunate.
Add a new state to ships that is the ‘building’ state. Ships are not built until your turn is ended. When you hit the end turn button, the ship is built in a lovely little sparkle. Or not (since this is a prototype.)
Problem 4: Combat is no fun. You click on an enemy and he dies. There is no anticipation and no retreat if you misjudge.
Combat takes multiple rounds. You can click on an enemy and attack and you both do a certain amount of damage based off the size of your ships. This provides stronger feedback to the player that their actions are having an effect.
The damage done to your ship is shown a little floating numbers.
You can spend additional command points to attack again.
Balance Issues Problem 1: There are too many command points. The player does not value them as the precious resource that they are.
Reduce the number of command points
Create an info bar at the bottom of the screen that tells on roll over how much a particular action is going to cost. For example “Attack enemy: 1 command point.” With a little smart graphic design this could be incorporated into an on screen area that also includes the list of resources.
Problem 2: There are a large number of collisions between players trying to attack similar places at the same time. A lot of this has to do with players being able to do a huge amount in a single turn.
Most of this should be solved by reducing the number of command points.
Problem 3: Players accumulate too much crack. This makes ship buying trivial
Reduce the amount of crack that you get per turn from each ship.
Player Choice Issues Big Problem: The map lacks structure. There are no major points of strategic interest to attack or defend. All paths between planets are open at any one time.
Let’s start experimenting with limiting the path ways between planets. Each planet is randomly connected to 1 to 6 other planets. All planets are connected to the whole. This should give planets a little structure.
Only some planets can build ships. Any planet above a class 6 planet has a different color outline and can build ships. This adds strategic points of interest.
Problem 1: It would be nice to present the player with the decision of whether to explore or defend. Currently a player can take a single ship and travel the entire galaxy.
Let’s take a rule from the Risk handbook. A stack must always leave behind a single defending ship. This reduces the power of the stack by one if the planet has no ships on it.
We end up with two types of stacks. There is an Attack stack, which is any stack with a power of 2 or higher. There is also a defense stack, which is a ship with a power of 1.
Problem 2: The game is limited to two players
Let’s get it working with 2 players first and then we’ll go from there.
Conclusion Many thanks go out to Michael for the great prototype and the opportunity to tear it apart in public. If you haven’t checked out Puzzle Pirates or Game Gardens, I highly recommend that you do so. Here is a fellow who not only is profitably building independent, highly innovative MMOs, but also is opening up his source code to the world so that other developers can get a leg up on the whole situation. Where is that honorary town key when I need one?
Avast, me mateys! Haul yer landlubber arses over to the Space Crack prototype before I make ye my peg boy! Or something of the sort.
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.
Cute or Hardcore? I'm a relatively decent artist. This poses a problem. I have the unholy power to skin Space Crack with an acceptable facsimile of almost any popular art style out there. The result is too many choices. So here's a question for everyone who has been kind enough to read this blog: What art style should Space Crack use? I've got a couple of seed ideas that I've been playing with.
The first is Fifties iPod. This one is very white, with simple retro shapes that harkens back to glory days of early sci-fi. Other than sporting a classic 50's pin-up girl, the designs tend towards more abstract and geometric shapes
The second is Space Cute: Another rather white design, but this one has cartoony characters and highly symbolic graphics. Red hearts, yellow stars, and people with space helmets make an appearance. Think of it as Mario in Space.
Worms shows the way? Someone mentioned how Worms made an incredibly violent game palatable to a wide variety of players. I'd love to do the same thing with the art direction on this game design. I'm not sure if my 50's pinup (as enjoyable as she was to paint) does the trick here. At the same time, I'm curious if the Space Cute style is too generic. Thoughts, opinions and critiques are welcome.
Introduction This is part 13 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we talked about the benefits of plot. This time we'll look at what it takes to design money making capabilities into an online game.
Your kind isn't welcome here In the various financial scenarios I’ve put together, the most glorious TBS game ever concieved (aka Space Crack) reaches break even at 8000 subscribers paying $5 a month. We reach an expansion state at which we can begin building a second title at 13,000 subscribers. To put these numbers in perspective, here are one analyst’s predictions of comparable break even numbers for the mainstream game industry.
“A game on all three consoles would have to sell around 600,000 in its first year, plus another 600,000 over the next couple of years just to break even. A million unit seller isn’t what it used to be.” - Analyst Michael Pachter, Wedbush Morgan (EGM, September 2005)
Ah, such different universes and a rather good summary of why most big publishers will never invest in games like Space Crack. The moment you state “I want to make a casual TBS game that I’m hoping will sell over 13,000 subscriptions!” you’ve effectively killed your title before it even reaches the starting gate.
In order to make a friendly title like Space Crack, we can’t rely on the old “Sell a million copies” business practices. We’ll need to forge new business ground in order to make Space Crack a viable enterprise. In the spirit of launching a new financial adventure, we’ll dig into practical options for making money with the Space Crack game design. There are several viable mechanisms including pay-to-play, micro payments for new content, subscriptions and retail-style pricing. I’m going to tweak and judge these various mechanics in light on two major criteria
Market Needs: Do the financial mechanics fit with the requirements outlined in game anthropology exercise I went through at the beginning of the design? Are these mechanics, as game mechanics, fun?
Financial Needs: Do the financial mechanics allow me to build a viable business?
Balance, Grasshopper The intelligent balance between these two items should result in a game that people enjoy spending money on. It is important to realize that proper mix of financial success and player fun is not an ‘either / or’ situation. You can do both and you can do both well, but it takes a conscious effort.
You cannot simply focus on the art of game design and hope that that miraculous thing called ‘genius’ gains you financial success. Many indie game developers are caught in this trap. Nor can you focus on the financial mechanics and hope that cold-hearted process will yield a critically successful title. Many publishers are caught in this trap (Tomb Raider comes to mind). Hone both skills and success will be yours.
Market Factors The market factors involved in using financial game mechanics are numerous and difficult to navigate. Money has complex social and cultural connotations and even small missteps can result in a dangerous poisoning of Space Crack’s gaming community. Ultimately, a game must provide a fair psychological value to the player in order for them to keep playing and keep purchasing our virtual goods.
Here are some rough guidelines to keep in mind:
Good fit with the game anthropology: Space Crack is a game about spending time with friends. Any mechanics that break this core value proposition hurts the game community. As such, the financial mechanics lean more toward team-based system like “signing up for a bowling league together”, rather than individual mechanics like “buying lots of cards so I can kill the other teenage nerds.”
Meets user expectation of standard features: Given the open-endedness of Financial Mechanics, it is easy to imagine systems like “every time you want to save, pay me $2.” Talk about an instant player rebellion. Focus your efforts on value added features, not expected features.
Fairness (aka Game Balancing): No one likes to play a game that is impossible to win. If you build financial mechanics that give one player a substantial advantage over another, you’ll end up with some frustrated players. This is game balancing 101, but too often game designers let people who spend the most money ruin the game for paying majority. Balance financial mechanics just like you would any other mechanics.
Financial Factors On the other side of the coin are the financial factors.
Viable economic model: The game has to pay for its upkeep and provide the game developers with a reasonable profit. Game developers need to eat and if they make something great, they deserve to be own luxury yachts much like Gene Autry, Cake or other powerful rock stars of yore.
Moral financial practices: I’m a great believer in the power of games to effect human psychology for both good and for ill. Creating a game that ties into a player’s finances increases the potential for harm. In online titles, the game developer is morally obligated to take on the roll of a bartender for those who are obviously over indulging. “Sir, I’m afraid you’ve been investing a bit too much in Space Crack. I’m going to have to cut you off for the night.”
Financial Mechanics are similar to Game mechanics The concept of financial mechanics is based on the risk / reward sequences we have discussed in the past.
Action: The player performs an action in the context of the game. However, this action results in the direct or indirect transfer of money to the developer.
Reward: The player gets some in-game reward
Penalty: The player doesn’t get some in-game reward
The wonderful thing about these mechanics is that they are almost completely open-ended. Any existing game mechanic can be turned into a financial mechanic. All it takes is a bit of imagination and knowing when to stop.
In-game currency A useful method for unleashing the potential of financial game mechanics is to create an alternative in-game currency that behaves like a standard in-game resource. Space Crack users will be able to buy new power ups and other items using ‘Stars.’ This currency is completely artificial and its value is controlled by the game developer.
Players can buy Stars by purchasing them with real world cash. 10 stars might cost $5
Players can earn Stars by performing in game actions such as winning battles, being rated well by other players, etc.
Stars cannot be transferred to other players (except perhaps in the form of gift certificates)
The result is a very simple 'one-way' economy. Players generate Stars by either buying them or earning them. The stars are spent on in-game items. As soon as they are spent, they are effectively removed from the economy. In many ways, this system is not so different than the token system used by casinos and arcades.
Benefits of an in-game currency There are some rather substantial benefits here:
Additional control of use in-game mechanics: Authorizing payments, entering credit card numbers, etc is slow and irritating. It breaks the flow of the game. By having an in-game currency account for each player, you avoid this problem. Everything is pre-purchased so Stars can be treated by the game designer much like any other resource.
Players don’t treat in-game currency like real money: The player is psychologically distanced from the act of spending real money. Since Stars come from a variety of sources it is difficult to evaluate the opportunity cost of making a purchase. This disconnects results in less hesitation when snap purchasing opportunities are made available to the player.
The game developer can print money: Stars become a valuable reward that can be used as part of the standard game play. This can be a powerful incentive that helps the designer guide the player’s actions.
Sunk costs result in more active players: If a player has a bank account of Stars, they feel obligated to play. They’ve paid their cash and it seems a waste to simply ignore the Stars sitting in their account.
Potential Financial Systems in Space Crack The following are potential systems that can be used in Space Crack to bring money into the game. These will have to be play tested extensively before they are implemented.
All financial systems have two stages. The first is a trial stage in which the player gains an appreciation of the mechanic. The second is the purchase stage in which the player spends money in order to take fuller advantage of the mechanic. This two stage approach is important since game mechanics are ultimately a rather abstract systems that are on the surface valueless. We need to get past the learning curve, addict the player and then hit them up for money.
The following systems are all interlinked and offer three paths to encouraging players to spend money on the game.
Purchasing Game Sessions
Purchasing through Retail
Purchasing game sessions Trial: Customers get a fixed number of game sessions. Each user gets 5 free games session by signing up for the trial.
Paid: If they want to play more than 5 games, they can purchase additional games for a fee. A single game is rather inexpensive at 5 stars, but a pack of 5 games might cost 20 Stars. There are a variety of promotional packages that can be put together using this system
Single game session: If they only want to purchase a single game, they can spend 5 stars
Unlimited game sessions per month: 10 Stars. If they want to play an unlimited number of games, they can purchase a package that gives them unlimited games for a set period of time period of time. This purchase acts as a subscription and auto-renews at the end of each month.
Purchase game for a friend: 5 stars
The idea here is that if someone is invited to a game, they can easily sign up for a trial. Or they can make a small one time purchase. Or they can invest heavily in the game and not worry about pricing.
The interface is very important here since complicated sales processes ruin the momentum of the purchase. Items to be purchased are displayed much like a traditional in-game shop keeper. You have:
A list of items to be purchased
The cost of each item in Stars
The number of Stars in your bank account.
A big happy button that says “Buy more Stars?”
When you are out of stars, it is a simple trip to the Star Store to gain some more. Ideally, you never even have to leave the in-game store screen.
Purchasing Stars Trial: During the trial stage, the player is given 10 stars that can be spent on pretty much anything. If they spend their 10 stars, they are given the opportunity to put a credit card on file. Couching the request in a non-threatening manner is critical, since getting the credit card on file allows for streamlined purchasing in the future.
Paid: In order to purchase Stars, click on the ‘Buy more Stars” button on any purchasing screen. A small in-game dialog will pop up with several packaged options
5 stars for $2.49
10 stars for $4.99
25 stars for $9.99 (20% off Sale)
50 stars for $19.99 (20% off Sale!)
100 stars for $34.99 (30% off Sale!)
The credit card is stored online much like how Amazon.com does it. As soon as you select the amount of stars you want, you can select ‘purchase’ using the stored credit card. You can also select a new credit card at this point and tweak your various account options. In general however, purchasing new stars is an in-game activity that happens in two simple clicks.
There is some fun sales psychology that going on here.
With one basic system, we can hit the player at several different price points. Some players will only want to dip their toes in the water. Paying $2.49 is rather painless. Other players are driven by discounts and will go for the bigger packages.
By having smaller purchases, people are less likely to get upset when they review their bank statements. A $4.99 reoccurring cost is likely to go unnoticed.
The money is transferred to the developer as soon as the stars are purchased. Getting cash upfront is an important financial factor for a new business.
Power ups: A brief description Now we come to Power ups, the most risky and potentially the most financially profitable portion of the system. So far, the subscription based system I’ve described has a built in revenue cap per user of $4.99 per month. In order to make a profitable business out of that, I would need 8,000 subscriptions to pay for a staff of 3. (I have a little financial model I used for these calculations that I’ll share in future posts).
This may be a small number for a retail title, but it is large amount for an independent title. The more money I can get per user, easier it will be to break even with a lower number of users. This is where the power up system comes in handy by providing an additional uncapped incremental revenue source.
Power ups are simple tokens that change the game in some way
Aesthetic Power up: These can change the color of your ships, replace the head of your avatar, make flowers come out the exhaust instead of flame, etc. In general they do not affect the game mechanics, but instead act as a social statement by the player.
Meta-game Power up: These change the rules of the game in some fashion. Typically they give players more power or the power to do new things that were previous not possible. Ideally, the player sees value in these because they offer him a strategic advantage. An example of a power up might be a Nuke, which automatically wins one battle, but destroys both the attacking and defending ships.
Purchasing Power Ups Trial: Power ups in Space Crack are somewhat unique in that each player shares their power ups with all the other players in a game session. Remember, we are trying to promote spending time with friends, not competition. The user’s collection of power ups is spread throughout the map (with a higher concentration of their collection located closest to their home planet). Any player in the game may stumble upon another player’s power up and use it if they own that planet. All power ups are tagged with a notice of whose collection it came from.
Thus, even a relatively new player can play a rousing game with even an advanced player. In fact, the system encourages newbies to play with high level players since they get to play with all the various cool toys that the advanced players possess.
Power ups are divided into two categories: Trial and Advanced. If the user is still in the first few games of their trial account and does not have a credit card on record, they can only use the trial power ups. However, as soon as they get make a commitment to the game, they gain access to the universe of advanced power ups.
Paid: Paid power ups are purchased at a store and added to the player’s collection. Power ups can range in cost from a few Stars to several hundreds Stars. We have a variety of ways to increase the joy of buying new power ups
Rarity: Some power ups are rarer than others. How much would you pay for a nuke that you can use twice instead of once? Only 20 exist in the entire game and you friends will be in awe if they find out you own one. Be aware that it will cost you.
Intermittent rewards: Some “mystery power ups” are unlabeled in the store. You only get to see what they are after you purchase. But the joy of paying a small amount for a great item is hard to beat. In short, players can gamble. Also, the store has only certain power ups available for purchase each day. Unless you check in daily, you never know what you might be missing.
Volume discounts: Players who purchase multiple power ups in a day get bonus discounts. Heck, if you spend enough, we might even toss in a couple of uncommon power ups just for fun.
Bundling: Want to buy a 5 pack with one guaranteed rare? Want to buy a pack of fire upgrades? By bundling, we create packages that capture more customer value and increase the unit price of each purchase.
Cost increases with popularity: Costs of power ups increase with their popularity. If everyone and their mother are using nukes, the price of nukes rises proportionately. This way, we make more money from popular items.
Periodic expansion packs: Interest in the game can be renewed by releasing periodic expansion packs that include new sets of power ups.
Purchasing through Retail Most distribution channels still sell packaged goods. In order to reach a large number of potential players, Space Crack will need to form relationships with both online and retail distributors. Both groups expect an executable that provides a valuable experience for a fixed price.
Trial: We provide the online retailers with promotional code and an exe just like any other retail package. They can wrap it in their trial software as desired.
Paid: The promotional codes can only be used once and automatically give an account two months of game play for free and include 25 stars.
Of course, this isn’t just any other retail package. As soon as the Space Crack file is launched, it hooks up to the internet and acts as a full online account. This hybrid model is similar what is used by MMOs and will continue to be a necessity for many years.
Miscellaneous financial systems We are scratching the surface of the purchasing opportunities that can be included in the game.
Bonus purchase opportunities: You can also move purchasing systems directly into the game. For example, some planets could be littered with rare power ups that take Stars to purchase instead of Crack. Not only do you get to add a rare item to your collection, but you also are guaranteed to use it in your current game. These “once in a life time opportunities” play the part of spur of the moment purchases. This isn’t quite as bad as raising the price of Coke on hot days, but the economic theory behind it is similar.
Match Making: Players can purchase advertisements on a central website with a ‘dance card’ that give their vital player statistics and the type of games that they like to play. There would be a standard listing of players, but if you wanted top billing or you wanted to promote a tournament, you could pay a small fee to get a better ad. This may fall under ‘expected’ features and not be a valid financial game mechanic.
In-game advertising: This is another one I’m staying away from. I want to provide a wonderful experience. Being a shill for someone else could easily cheapen the Space Crack experience.
Infrastructure Naturally, none of these systems can be created without first investing in considerable infrastructure. Several core technology elements come to mind:
Maintaining customer data: Customer data is king. Players may not be purchasing physical goods, but they are purchasing electronic goods that are stored on your servers. If you screw up and delete their data, trust with the community is critically damaged. In the worst case scenario, the community will punish you by leaving in droves. An effective and reliable backup system is a must.
Cost of building online store: The whole ecommerce backend must also be in place. This is another large infrastructural item that needs to be budgeted for.
Metrics System: I’m a huge fan of investing in metrics so that you can measure your success or failure in concrete terms. Adding financial mechanics is a very labor intensive activity. As I build out new systems, tracking key metrics helps me figure out if they are feasible or not. Some decent items worth tracking include the total number of active users, the amount of money that each system generates, and the number of players partaking in each system.
Conclusion Goodness, what a brain dump…I apologize for the overuse of bulleted lists. :-) By now you should have a good idea of how multiple financial game mechanics interact to provide the money making structure for an online title.
We are dealing with a far more complex transaction system than you find in packaged goods sales, or even simple subscription models. We are moving away from the “one price for one product” model that has been common with current games and are instead moving towards a flexible gaming experience that provides players with multiple opportunities to purchase additional game play value.
The results are good for both the players and the game developers.
Lower entry barriers: You don’t have to pay $50 up front to play the game
Payment for value: If you like the game a lot, the developer gets a bit more money from you. If you don’t like all that much, they only get a little.
Niche titles are financially viable: A relatively small population of users worldwide can support a niche title. This means that instead of lamenting the loss of dead TBS games of eras long past, gamers get a constantly updated thriving game that suits their highly specialized desires. Developers, in turn get a dedicated community that will financially support their efforts for years, not mere weeks like they must deal with in the retail world.
Till next time, Danc.
PS: Longer posts, such as this one, take longer to write. Feel free to let me know if these would be more palatable split up into multiple essays and posted more frequently.
How I stopped worrying about ludology and learned to love game plots
Introduction This is part 12 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we talked about creating a component bible for all our art assets. Ah, game design 101 is over! This time we'll have a bit of fun looking at the concept of story and how it really fits into a game from a mechanics perspective.
Drama matters Combat is the resolution system that determines what happens when a ship moves onto a planet. This is the most exciting element of the game for the player. The attacker is the protagonist and the defender is the antagonist. A long history of building, scrapping together resources and journeying across a dangerous landscape give each character depth and meaning. Two ships enter, one leaves.
In terms of pure mechanics, the combat code will calculate a resolution based off the properties of the two ships. The statistical engine does its thing and an answer pops out. Everything else is merely drama.
But drama matters and here’s why. Plot: A theoretical underpinning I’ve participated in the debate about whether story or game play is more important to a game. Inevitably there is the Final Fantasy addict mumbling to themselves in the corner, “It’s not a real game unless it has a story. Like FFVII”.
Being a bit bored by the whole discussion, I got my hands dirty and broke apart a bunch of popular games to see how plot was used to enhance the psychological effect of the game. Pretty much every successful title had the same pattern:
Perform an action.
Give the player a dose of story.
Player is emotionally stimulated and wants to find out more.
Now this maps very nicely onto the risk / reward sequences I’ve been using to document various actions within the game. The actions are our verbs and the doses of story are our rewards.
Why we should use plot as a reward mechanism Stories have some rather unique characteristics as a reward mechanism.
Plot is great emotional reward: Plot is one of the few rewards available to game designers that can tweak a wide range of player emotions. Surely it is nice picking up a coin and seeing a pretty sparkle. But this provides a limited emotional response compared to a plot reward like “Hello. My name is Inigo Montoya. You killed my father. Prepare to die.”
Individual elements of a story have a high burn out rate: For example the plot element, “He fell in love with her” can be quite powerful in the appropriate context. But having the next plot reward say the same exact thing is simply annoying, good evidence of burnout. “He fell in love with her.” See…annoying.
Hand crafting stories is expensive: Writing an extensive plot is rather expensive if your game contains hundred of reward moments. It is often not cost effective to use unique elements of plot as a reward for a frequently occurring risk / reward sequence. This expense is why many older games reserve plot only for end of the level rewards. Games that attempt to use plot more frequently (KOTOR and Half Life come to mind) suffer from larger budgets.
Archetypal stories have a lower burnout rate: How many times can you watch an archetypal “Hero’s Journey” before getting burned out? Hundreds, perhaps thousands of times?
Algorithmically Generated Micro Stories I can’t afford to write or animate a unique bit of plot each time someone takes over a planet, but it would be nice to leverage a bit of the emotional zing.
However, instead of writing a static story, we are going to create a system for algorithmically generating micro story. A micro story has all the elements of a static plot and packs a surprising emotion wallop. However, in terms of work, it is a very thin contextual layer on top of our heavy investment in game mechanics.
The techniques are straightforward:
Leverage the existing game systems
Add contextual elements that provide the narrative slant to player actions
Add meta-game mechanics that reinforce the emotional rewards and penalties of the micro story.
One of the best examples of a micro story that I’ve seen is in Strange Adventures in Infinite Space. The designer, Rich Carlson writes “The main idea at the time was to make a very quick-playing game that still felt sort of like watching a couple of seasons of your favorite space adventure series (except that you'd actually fight the space battles)”
Great idea. Let's borrow it for Space Crack. :-)
The Space Opera Space Crack is a miniature space opera.
Imagine a massive character driven drama set against the backdrop of intergalactic war. Young pilots emerge from their home worlds, ready to defend the mother world from imminent alien invasion. One heroic captain, Captain Jack “Planet Killer” McDaddy works his ways up through the ranks. His skills (and his kick ass vessel of massive destruction) are all that stand against complete alien domination of the universe.
This is a Horatio Alger story of a rag tag band of saviors and the turmultuous trials and tribulations that define their epic tale. We've got war, lust, love, deceit, betrayal and sun-shattering explosions. Complete with extra cheese.
The elements of the micro story To pull this off I have to complete the following items:
Define the characters: Who are this characters and what is their history? Is there a protagonist? An antagonist?
Define the conflict: What is the source of character conflict? Are there alliances? What actions stoke the combat?
Illustrate the conflict climax and resolution: How do the character’s meet and resolve their conflict?
Characters: Space Captains! Ships make poor central characters. But a space frigate piloted by the Captain Jack “Master Blaster” McDaddy perks up my ears. We add a simple system for classifying stacks by giving each stack of ships a name.
Rank: Ships start out as Peons and slowly grow to become God Admirals
First Name: Randomly selected from a list. Both male and female. This is a space opera after all.
Nickname: Ships that complete certain tasks get nicknames. Special power ups are associated with each nickname.
Last name: Randomly selected from a list (perhaps players can add their own)
These names are built up over a period of time. You are the grand strategic ruler of your world and don’t have time to worry about the peons in your army. You might learn the last name of a character after his second or third battle. He might get a first name when his ship reaches a certain size. Finally, he’ll prove himself in some dust up and be given a nick name. If stacks are merged, the stronger captain name is always kept.
The idea here is a well equipped stack is more than just a potent game token. It is portrayed as a character. The fact that the player has invested time and thought into keeping this particular ship alive gives each mature Space Captain character emotional significance.
The other player is doing the same with his top ships. This leads to natural protagonist and antagonist relationships. For each player, his Captains are obviously Luke and the enemy who keeps eating your planets is obviously Darth Vader.
This is a fun design idea. Don’t spend time creating a character that strives to be interesting. Watch what the player does and decorate as characters those tokens that matter to them.
Conflict: It's a fricking war out there Conflict is easy since we are building a war game. Your captains are the good guys and the other captains are the bad guys. Rather straight forward, really. We can add a bit more emotional impact to this situation with some meta-mechanics.
Meta Mechanics: Enemies and Lovers In essence, we can add emotional variety to the story line with small bonus quests. If a particular ship completes a task, they get a bonus. Some example quests include
Rivalry: Your top Captain must defeat the top enemy Captain for a bonus.
Save my family: Keep a planet under your control or else the powerful captain from that planet gets a penalty when his family is turned enslaved in the enemy Thorium mines.
Rescue: If a captain’s family world has been captured, he can get a bonus if he personally regains the planet.
Lovers: A captain that emerges from the same planet as an existing captain may be classified as a lover. Both captains get a bonus. If one captain in the pair dies, the other captain gets a large penalty. If the ships are merged, the bonus goes away. There can be different degrees of love, ranging from childhood friend to brotherhood to full on romantic love. These relationship bonuses stack.
Lover’s Vendetta: If a bereaved captain defeats their lover’s killer they get a bonus.
Secret mission: A planet deep within enemy territory has a secret technology. The ship that conquers the planet gets a bonus.
Quest locations can be easily shown as blinking on screen icons whenever a ship is selected. The player really doesn’t have to pay much attention to keeping track of everything since they can easily mouse over items to get an update.
Quests acts as additional risk reward sequences that operate on a slightly longer time scale than our core game mechanic.
Action: Complete the quest goal
Reward: Gain the quest reward. More importantly, gain an emotional reward for helping your character play out his very human desires.
Failure: Lose the quest reward. More importantly, be emotionally punished for killing a character or denying them their personal dreams.
This all may seem melodramatic (and it is), but the truth of the matter is that players will end up identifying with their ships if you build the correct contextual structures. You don’t need a lot of structure to make people really care for those valiant little Captains who are going out and saving the universe.
Final resolution Ultimately, your game must end. Either your ships are vanquished or you are triumphant. The structure of the game is that there is always one final battle in which the last major captain is defeated. The rivalry mechanics will tie into some interesting end of game "conflict accelerators" that I'll be unveiling to make this a literally earth shattering event. The game is over and the credits roll.
In the end, every player ends up with a list of their heroes. These are the brave leaders who fought and will go down in history. Their names are recorded in a data-base and if the player plays again, perhaps some of their favorite heroes will emerge anew.
Conclusion To summarize, I’m finally starting the process of adding context to my game tokens. No longer do we have generic ships and planet. Now if someone asks me what Space Crack is all about, I can say with a completely straight face. "It is an epic space opera set in the midst of intergalactic war. It stars Captain Jack "Alien Duster" McDaddy. He is one hot sexy hero. With a big ship."
This is so much better than coughing and whispering "I'm making a turn-based space strategy game that will involve a 'Go'-like token capturing system." And just in case anyone asks I am indeed painting a 50's style space pin-up girl as a Space Crack promotional poster. Barbarella has nothing on my moon booted femme fatale. (Ray will blush.)
Notice what I’m not doing:
I’m not adding new graphics, elaborate cut scenes or animation.
I’m not writing extensive static plotlines.
I’m not designing static characters with extensive histories.
Instead I’m focusing on the game mechanics, meta-game mechanics, and shallowly contextualized tokens.
I’m focusing on new meta-game mechanics like the quests.
Where I add extra content like the naming system, it has an informational element to it that gives the player feedback.
I use contextual clues to turn abstract rewards into emotional rewards.
Again, the reason I do this is because of the constraints of the design. Micro-story mechanics offer lots of replay at low marginal costs. This design makes the conscious effort to build a reusable system instead of investing piecemeal in low cost, high burnout rewards like plot.
Future directions Adding a setting and the start of a plot does wonders for fleshing out a relatively simple game system. The archetypal setting ensures that we'll have an endless stream of ideas for upgrades, random events, and captain quests. Already my brain is buzzing with ideas for long lost civilizations, alien saucers, evil Admirals, captured nova princesses, grudges from the Space Academy, alien trysts and more.
Introduction This is part 11 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we talked about getting the game ready to prototype. This time I'll create a bloody long list of all the assets we'll be needing. This is more exciting than it sounds.
Breaking the rules of prototyping As many of you may have noticed as you peruse my website, I’m more of an artist than a programmer. One of my goals is to create as much of the artwork for the game up front such that the programming has no bottle necks when full on production begins.
In the ideal world, this is the exact opposite of how you ‘should’ do it. When prototyping the game, it is best to rely on cubes and other primitive graphics so that you can focus on polishing the core game mechanics first.
But I do not have a dedicated programmer at this point in the design process. Sometimes you just have to push on through to the other side, regardless of what resources you may or may not have at your immediate disposal. Persistence is a marvelous quality during the very early stages of a game design. This applies to both big games and small games.
The component bible: A theoretical underpinning I need a way of organizing all the various art resources necessary for Space Crack. A common technique is to have a master list of all assets in the game called the Art Bible. Typically this includes a list of all the art resources required for the game. Since I’m using Anark Studio, I can extend my art bible to include state information in addition to standard items such as models and textures. I want to introduce some basic nomenclature for defining objects, states and sub-states:
Component: A component is a self-contained object that includes a variety of states. For example, the end of game screen might be a component that has states ‘Off’, ‘Intro Animation’, ‘Body’ and ‘Exist Animation’. I’ll denote Components with a ‘*’ character
State: A state is a unique mode of the component. A component can only be in one state at any time. A state can have unique properties, objects, etc compared to an alternate state. I’ll denote States with a ‘-‘ character.
Components can contain other components: For example, our end of game screen might have another component called the ‘Exit Button’ that only displays when the ‘Body’ state is showing.
Each sub-component can contain its own states. This is how sub-states are created. For example, our Exit button might have it’s own states of ‘Normal’, ‘Mouse Over’ and ‘Down.’
With this system, I can define most objects in most games. There’s still a lot of programming left to set up, but with a fully finished set of components, it should be much easier to hook up the final game.
Asset Management A huge undertaking for most commercial companies is asset management. When you have thousands of assets, keeping track of them is a miserable activity. I have less than 50 assets in the game at this point in the design. For small teams a “Naïve Asset Management” system in the form of a simple order list can be remarkably useful. Keep this on a Wiki and you can solve a rather major problem quite simply.
Some “Naïve asset management” Rules:
Components that are finished will be moved in to a separated Finished Section of the Bible
Components are prioritized by importance so that they can be tackled in an iterative manner.
Conclusions In total, I have around 21 components that I’ll need to create for this game. This will grow dramatically in future passes on the game design, but for now it represents a manageable work load.
Take care Danc.
Components left to create
- Launching - Firing - Exploding in devastating ball of flame. (aka The Boom State) - Landing: Conquest - Landing: Merging
- Neutral - Captured - Perimeter World * Player Flag -- Remote Source Flag
* Territory Connector
- Off - Connect Animation - Connected - Detach Animation
Space Crack: Starting the game and ending the game
Introduction This is part 10 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we talked about the use of stub mechanics and how they can be used to create a simple combat system. This time we'll apply some additional stub mechanics and learn an important lesson about iterative game design.
Starting the game and ending the game We are almost done with the basic of the game. I've been designing the game from the middle out by dealing with all the standard midgame elements such as combat, production, etc. There are two elements on the outer edges of the experience left:
Starting the game
Ending the game
A note on process Once these two systems are finished, we'll have described all the initial systems needed to play a simple game of Space Crack. This is when the real fun begins. Everything so far has been game design 101. The result is a passable, but by no means memorable strategy game. Once we have a prototype up and running, I can start adding some lovely meta-game mechanics to our plain-jane core. It is at this point that Space Crack will rapidly evolve into more than just your typical war game.
My goal at in this post is to define quick and dirty stub mechanics for both the start and the end game. The sooner we can get to a prototype, the better. Starting the game: A stub mechanic The start of the game demands a large amount of design. This is the first experience the player has with the game and poor design can ruin the entire experience before they even start to play. For now, IÃm going to create a simple stub mechanic, but be assured that we will revisit this topic in the future.
All games start at a webpage on www.spacecrack.com. The player is presented with a friendly screen that asks them to invite their friends to a quick game of Space Crack. There are three UI elements
Emails: A list box where the game initiator can type in email addresses
Play Time: A time and date gadget for selecting the time at which they will play.
Submit: A submit button that sends the start game request to the central server.
Once the game request is submitted, all players get an email telling them the time to play and the rules of the game. The email contains a unique URL to their particular game.
If the link is clicked before the start time, a clock appears showing the time counting down until the match begins. When the time reaches zero, the game begins.
If the link is clicked after the game is started, the player is added to the middle of the game and their map displays the current status of the game world.
All email addresses and game sessions are also captured in a database for future reference.
Starting the game: What is missing We are naturally missing a lot of elements. I'll record these in a quick list for future notice. One of the distinct 'dangers' of a stub mechanic is that you forget it is just a temporary fix. When we are play testing later, this list can help jog our memory.
Instant start for players with no friends
Favorites list of frequent players.
Ability for players to name their character or have a persistent log-in
Email verification system to ensure a clean database
Game type options
Finishing the game: A stub mechanic Finishing the game also deserves its own section. The end of a multi-player game is where most of the player's decisive impressions of the game are formed. A big goal of the design is to have people play again. If the end game is boring or the reward system at the end punishes players too strongly, the result is often the dreaded phrase,"Well, that was great, but let's play Counter Strike next time."
Our stub mechanic for "winning the game" is rather straight forward. The first player to capture all the planets wins. It is one of the worst winning conditions available, but will work for early prototyping.
When the winning condition is met a message is sent to all players:
"Player X has conquered the galaxy. Well fought! Do you wish to challenge the same group of players to a rematch?"
Clicking yes, sends you to the start game screen with all current emails filled in. You are only allowed to start one game with the same group of people in a 24 hour period. This prevents everyone clicking "yes!" at once.
Finishing the game: What is missing We are naturally missing a lot of elements. A quick list includes
Mechanics that ensure an exciting end-game.
Reward mechanisms that incent players to play again.
User feedback mechanisms, full game instrumentation and logging.
The Ultimate Game Design: A deadly game design sin At this point, some of you are likely asking "Who is this lazy game designer?" On the surface, I've intentionally designed a game that has gaping flaws. In reality, I've rushed towards a design that can be prototyped. And with good reason.
As game designers, the foundational game mechanics can be the least exciting part of a game. The real fun begins when you start imagining what you can do with all these basic systems. My notebook is filled with feverish schemes that add layer upon layer to the original concept, buildinmonstrosityl monstronsity called TheUltimate Game Design. Stellar mechanics, physics, fusion weapons, special encounters, crazy plot twists! Just thinking about it gives me shivers of pure intellectual pleasure. Or something like that.
The natural problem with the Ultimate Game is that it requires infinite resources to create version 1.0. When I hear stories about a game that took 5 years to be released, I cringe. This was a team with poor project management and a fundamental lack of understanding of iterative game development. It happens far too often.
I would argue that death of most indie games is the mismatch between existing resources and ambition. This isn't captured in post-mortems because of the inherent survival bias in such reporting techniques; post mortems only describe the games that got out the door. There are vast quantities of unfinished games lying on hard drives. The start of the ultimate RPG. The laborious FMV intro to the next great shooter. A design document describing the best MMOG (ever). So much work and so few results. There is a better way.
The trick is to use stub mechanics and create a simple, complete set of game mechanics that can be easily prototyped. This development strategy, though not as intellectually stimulating as the Ultimate Game Design, has some solid benefits:
Easier early project approval: If you are relying on others for task such as programming or art, they are much more likely to approve a small time investment than a large one.
Increased chance of completion: By keeping the scope small, you decrease the chance that external factors will disrupt your development.
Shorter feedback cycles: Long design periods result results in complex systems that are difficult to maintain and adapt. A quick prototype will often let you fix your most egregious design errors early on. This dramatically reduces the risk of creating a crappy game that simply isn't fun to play.
Improved marketability of the ultimate design: A design document is the single worst method of selling a game ever devised. A playable game is the single best method of selling a game. By creating a prototype, you are creating a powerful marketing tool that can be used to gain resources for future expansion.
Conclusion We are at a major point in the design where all the design elements are in place to create our first prototype. In the future, my posts are going to split into two categories:
Prototyping existing design mechanics
Discussing the larger vision of the game.
Both of these topics should be a lot of fun. The first should give us some down and dirty insights into how the various rules I've put forth survive impact with real world players. The larger vision of the game builds on the core game mechanic and turns a rather simple design exercise into a highly polished and addictive game that will eat up years of our player's lives.
Here's a taste of some of the vision elements I'll be covering in future posts:
Using story as a meta-mechanics: Adding emotional impact to a game that is currently far too generic to have mass appeal.
The upgrade system: Expanding combat such that it is more interesting for long term players.
Starting the game: A discussion of the game front end from a game mechanics perspective. The front end is the game.
The end game: Adding game systems that make the end game more exciting so that people want to play more often.
On the prototyping front, my goal is to create all the game elements as nicely modeled and animated state machines. This comes down to existing resources. My skills lay primarily on the artist side of things. I'll need to illustrate the various game systems as clearly as possible so that I can give a programmer this design on a silver platter.
Introduction This is part 9 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we talked about ships and the various systems involved with movement and stacking. This time we'll talk about combat and the joys of stub mechanics.
Combat I’m scared to design the combat system in SpaceCrack. All the actions we’ve built up so far are meaningless without a combat system makes these past choices apparent and meaningful. The conflict resolution mechanism needs to embody all past decisions pertaining to the two competing ships.
Players spent a lot of time and energy creating territories. The combat system must give this investment value.
Players spent a lot of thought picking the right planets to focus their ships. This must matter as well.
Players spent a lot of thought picking which ships to merge. Poor ship merging must have an effect on the outcome.
I also have some big design goals. I want to reward the thoughtful player over the action player. Heaven forbid that building the biggest ship fastest wins. I also need the combat to be entertaining for thousands of encounters.
What is a poor designer to do? This is a difficult problem with lots of variables. I have a few vague ideas, but, there is a 99% chance my solution will suck in its first incarnation.
To get me out of this stalemate, I’m going to employ a very tricky and difficult design technique. First, I’m going to admit that I don’t know the perfect answer. Then I’m going to do the simplest thing and evolve the design by iterating on the concept. Evolutionary Game Design: A theoretical underpinning In my dreams, game designers are vastly intelligent creatures who are capable to bringing forth entire worlds verbatim from their foreheads. Like Zeus. Every little detail, every rule is sitting pristinely in our noggins just waiting to be transcribed onto a sheet of clean vellum.
Then I wake up.
The reality is that game design is a messy, miserable process filled with dead ends, convoluted designs that aren’t fun, and long theoretical rants that are ultimately useless. These are complex systems we are dealing with and the best ones have deep, difficult to predict results. Tools like risk / reward sequences and design testing point us in the right direction, but they are ‘steering’ mechanisms, not methods for ‘deriving’ game mechanics.
Ultimately, game design is a heavily iterative process that involves frequent prototyping and an evolution of crude game mechanics into a reasonable form. This is especially true of core game mechanics that differ even slightly from established genre conventions.
Choosing a fundamental activity Let’s follow the rules laid out in my previous essay. First I have to define my fundamental activity. I’ve got a good start:
Collect tokens (ships and upgrades) and move one token collection (a super ship) onto an enemy token collection.
Based off the various properties of the stack of tokens, one token will be destroyed.
This isn’t complete because I haven’t specified either the property of the tokens or rules for determining a winner. At this point, I create a stub mechanic so I can play the game.
The Stub Game Mechanic: A simple, easily implemented placeholder mechanic that fills in holes in the game design and lets you play the game. It is generally not well balanced, nor is it the ultimate desired system. It’s key benefit is that it lets you get a working iteration of the game play up and running quickly.
Stub mechanics are wonderful. In many ways they are the secret to good iterative game design. With stub mechanics, you can lay out a game design in broad strokes and then rapidly implement a trivial set of simulation rules. The game will suck, but you can start immediately getting a feel for the system. At this point, real evolutionary game design begins. Stub mechanics kicks a designer in his philosophical ass and says “Enough waffling and jabbering. Let’s play the damn game.”
Stub mechanic for Space Crack combat In short:
The ship with a higher power rating will defeat the ship with the lower power rating.
The winning ship will lose health equal to 50% of the defending ship’s power.
'Nuff said. Time to move on until we get to play the game.
Conclusion For those of you who get turned on by intricate systems, this is no doubt one of the worst posts of the entire series. Still it contains an important lesson in both humility and process:
You aren’t going to have the best answer all the time.
If you don’t know the perfect game mechanic, try the simplest thing possible.
Play the game and identify problems.
Create variations on the existing mechanic that solve those problems.
Introduction This is part 8 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we extend the concept of player-created environments with the notion of territories. This time we'll talk about ship tokens and try to solve some of the major issues associated with complex unit management in turn-based strategy games.
Space ships! Gotta love 'em I like to think of ships in SpaceCrack as sharp pointy sticks that you toss at your unfortunate enemies. They are horribly beweaponed (a word found in Hitchhiker’s Guide to the Galaxy) and the larger nasty ones can smack into little planets with a satisfying crunch. This visceral level is how I want my players to interact with ships.
Ships are produced at planets.
Ships can be launched at a nearby undefended planet and conquer it.
If the planet is defended, the two ships will fight to the death, with the winner taking all.
The existence of ships at various planets creates another strategically important layer of topography in the game environment.
Attributes of a Ship Ships have the following attributes
Ownership: A ship always belongs to a specific player. There are no independent ships.
Health: A ship has a certain amount of health. When a ship takes damage, its health decreases.
Power: The more power a ship has the more damage it can do.
Ship Upgrades: Ship upgrades float around your ship and give it extra powers.
Common problems One of the most enlightening exercises a designer can go through is trying to explain how a game system works to a new user. I usually start out with the disclaimer, “This is a really easy concept once you’ve played it a few dozen times.” When building effective game system, complexity is easy. Simplicity is hard.
When dealing with attack units such as our lovely ships, TBS games run into three main areas of immense complexity:
Considering our two minute constraint, these systems take too long to learn. It is time to purge the complexity and rebuild them in a simpler fashion.
A Simple Ship Production System Ship production needs to be easy as well. I played around with several methods of building unique ships and it all gets messy quite quickly. One brainstorming technique I use that is often quick productive is to ask “What is the simplest interface that would accomplish this task?”
In this case, there is a single button in the form of a ship platform. Click the platform and a ship is built. The only thing simpler is automatic ship building, but on first pass, it doesn’t seem like it would give the user enough meaningful choices.
If you click on a ship platform, it will create a ship of the same attack power as the planet. More powerful ships are larger on the screen.
A ship is produced instantaneously. No waiting, baby.
The spaceships costs crack and command points to produce. Big ships cost more crack.
Let us summarize ship production as a risk / reward sequence:
Action: Click on a ship platform to build a ship.
Reward: If you have enough resources, you get a ship! This increases the potential player actions and helps them win the game. Sweet.
Failure: Since command points are limited, choosing the wrong location to build a ship presents a substantial opportunity cost.
A Simple Ship Movement System Ships can only travel to adjacent planets. You can move one hop and that is it.
Select the ship by clicking on it.
Selection icons will appear beneath nearby planets that can be traveled to. If the player selects a destination planet, the ship will move to the planet.
I played around a bit with ships being able to take multiple turns to reach a planet. This is a common practice in the TBS genre. However, long travel times goes against the short risk / reward cycles I’m striving for in the game.
By limiting ships to move only one planet at a time, we build a game with pacing is closer to Pac Man than Risk. You build up a big ship and then go a’ conquering, munching up planets by the half dozen each turn. We have a great short term risk / reward sequence:
Action: Click to move a ship to a new planet.
Reward: If the planet is undefended, bing! You get a new planet and more resources your next turn.
Failure: Since command points are limited, moving a ship to a bad location has a large opportunity cost. Also, if you misjudge and attack a planet you can’t beat, then your attack force is decimated.
We also remove an entire set of systems for tracking movement, showing partial player movement that occurred at the beginning of the turn, etc. The system can only care about what is happening right now, not what will happen in the future.
A Simple Stack Management System Stack-based unit control systems irritate me. The typical TBS game gets bogged down in building, tracking, ferrying, redirecting, grouping, splitting, and attacking. In the immortal words of Napoleon Dynamite, “God.”
TBS games love managing large amounts of troops in a complex fashion. Heroes of Might and Magic has a hero system for ferrying troops back and forth. Age of Wonders has a stack system for creating little parties. But I’ve always found grouping to be horribly unintuitive for new players. “Oh, just select the unit, look in the little other window and click on the icon to deselect a sub-unit. Now select a new destination, unless the destination is an existing stack whose total number will be more than 8.”
These extra interface details are too much for a quick and dirty game that I need to teach in less than 2 minutes.
Super Ships! The SpaceCrack solution is a blatant simplification of the problem. The root of stack based systems is the assumption that you have groups of unique units. Let us make our lives easier by throwing that assumption out the door.
Ever planet only ever has one ship.
Ship can only move from planet to planet.
When you move two ships onto the same planet, they merge together into a bigger ship.
When you attack an enemy ship, only one ship survives as the victor.
So you can build a super ship by merging together a bunch of little ships. Upgrade merge in a logical manner. What all this boils down to in the interface is one click to build a ship and one click to move it. You can never split ships apart.
The result is a very simple interface, but deep strategic and tactical implications. Let us summarize stack management as a risk / reward sequence:
Action: Move a friendly ship onto another friendly ship
Reward: You get a bigger ship! This increases the potential player actions and helps them win the game. Sweet. If you merge a ship at the right location, it can form a powerful point of attack or defense.
Failure: - Moving ships around takes command points so there is a strong opportunity cost if your actions have no impact on the world. - Building a powerful ship in the wrong location is can be useless if it is far from the combat zone. - If you merge the wrong ships, you can leave key planets undefended.
Conclusion The ship token design attempts to simplify many traditional aspects of the Space TBS game genre. Simplifying is hard work and I wouldn’t be surprised in the least if these systems end up having multiple revisions before the game is finished. However, we are starting with some good foundations. These are lessons that can be applied to any game design:
Start with the simplest interface possible to accomplish the design goal
Design with risk / reward sequences in mind. Pacing matters.
Don’t be afraid to question the core assumptions of a traditionally complex system
Next up I’ll be looking at Combat. I’ve been building this game design a bit backwards.
Introduction This part 7 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we described the Planet token and its use in player-created environments. This time we'll extend the concept of player-created environments with the notion of territories.
In order to create fully realized player-created environments, we need to define some rules that lead to interesting large scale structures within the environment. Remember that one of our requirements for a successful player-created environment is that it does not converge on a small set of strategies. By introducing larger patterns of environment evolution that emerge from a simple set of rules, we can help ensure that this rule is met.
Territories: A theoretical underpinning Again, I’m going to steal a concept from Go that I’ll call ‘capturing a territory’. You see this same concept in the old arcade game Qix. The idea is simple. Given a large board of tokens, you can create a perimeter that encapsulates a certain number of tokens. Any tokens within the closed perimeter are captured. I could wax philosophical about the beauty of this system for a long while. Larger areas are more valuable, but end up being more risky. Players spend much of their time jockeying for position on the board in an attempt to break the other player’s perimeter. A deftly positioned token can turn the tide of the battle by capturing a large number of tokens instantly. With the addition of a relatively simple rule set, we get loads of game play.
Increasing player involvement through historical context Let’s compare the player-created environments of territories to a typical real-time strategy game. In an RTS, many major strategic elements are determined ahead of time by the designer. A few obvious static elements include the location of the most valuable resources, the positioning of various choke points on the map, and in many single player levels, the ebb and flow of the battle with the scripted introduction of enemies.
With territories, the player builds the major strategic landmarks in the environment one move at a time. These maps are more engrossing than many designer-created maps or randomly generated maps because they have historical context. A particular territory is not important just because of its location on the map.
It is important because it was built with sweat, blood and intent of the player.
They remember building it.
They remember defending it.
They are emotionally involved as the creator of that little sliver of the map.
Heaven forbid that another player try to alter another player’s little bit of paradise.
Implementing Territories using Planets Imagine an array of planets, perhaps 50 or 60 on a 2D plane. When a ship travels from a conquered planet to an unconquered planet, a line is created joining the two planets. This line is the perimeter. Planets that are part of the perimeter are called perimeter worlds.
When the perimeter completely encloses a set of planets, those planets are captured and they become core planets. The perimeter, the perimeter worlds, and the core worlds contained inside the perimeter make up a territory.
So using the simple verbs of building a ship and moving the ship, we’ve created a new complex verb called ‘capturing a territory’. Here is an illustrated example of how capturing works.
The reward you get from capturing a territory
Document note: Every new action must have a meaningful reward. Games are made by layering action / reward pairs. Break this rule and you no longer have a game.
Once you capture a territory, what do you get?
Each ship on the perimeter worlds are immediately given an attack bonus based off the number of core worlds. Bigger territories are worth exponentially more than smaller territories.
You also get a production bonus each turn with bonus Crack flowing into your coffers.
Territories become like M&M’s; a hard candy shell with a tasty inside. Everyone wants to build them since owning a nice territory creates vast wealth for the player. Everyone wants to destroy them since not only do they take away the enemy’s advantage, but if you can break through the perimeter worlds, you can wreak havoc in the interior.
Balancing a new game mechanic Each time you add a new game mechanic, there are inevitably unpleasant effects that ruin the game. It is worth ‘playing the game in your head’ or in a prototype and seeing what major problems occur.
With territories and simultaneous turns, I want to be careful of situations that involve ‘tit for tat’ tactics. Ray captures a planet needed to complete his perimeter and five minutes later, George recaptures it. This encourages micromanagement. Each turn should be decisive and not involve micromanaging your perimeter.
One possible fix:
Temporary immunity for recently captured planets: If a planet was captured in the current turn, it cannot be recaptured.
Conclusion The combination of planets and territories gives our players a wonderfully rich and varied gaming environment. We’ve also described our a major risk / reward sequence.
Action: Conquer a loop of planets.
Reward: There are several. - Production bonus: You gain more resources to spend on expanding your capabilities. - Territory: By creating an easy to defend perimeter, you capture territory and reduce the other player’s options.
Failure: - Since Command Points are scarce, there is a large opportunity cost associated with attempting to create a perimeter. - Also, when you expand without closing off the perimeter, you spread out your forces and make your planets ripe for attack.
Next we need to discuss how planets are captured. This leads us first to Ships, the most kick ass token in the SpaceCrack world.
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.