Building Browsergames

Ryland’s Reviews: Kingdom of Loathing

I’m a relative newcomer to the world of PBBGs. That said, I’m going to be exercising my right to free speech with the magic of the internet and reviewing some of these. Being a newcomer, I asked for some advice on where a good place to start would be, a place to really sink my teeth into. I was suggested to a couple of games, but the one that stuck out the most was Kingdom of Loathing. Since I’d heard of KoL before, I went with the familiar name. I was greeted by a rather sparse page: stickmen with swords and martini glasses, white background, some tables. Fairly standard. No problems registering. Then, without warning, I was introduced headfirst into the madness of this game.

KoL is a class-based game, like most MMORPGs and whatnot. You’ll get new equipment, get new stats, level up, all industry-standard, tried and true boring stuff. Yet KoL is about as unique experience from an RPG as you can get. Replacing wizards? Pastamancers. Replacing thieves? Disco bandits. Awesome. There are 6 classes in KoL, based on the three main statistics of levelling up: Muscle (your attack damage and health stat), Mysticality (the magic stat, increasing MP and magic attack power), and Moxie (your luck stat, determining dodges). The 6 classes are divvied up into the three stats, with 2 classes making use of each stat primarily. It’s a very simple RPG system that lends itself well to the nature of the game; there’s nothing overtly confusing about it. It’s not much deeper than the 3 stats, sadly, but it’s a minor grievance and it barely distracts from the fun of the game.

KoL introduces you to the game in good fashion, establishing the basics through a series of quests. You’re introduced to combat, simple turn-based action, nothing particularly flashy and new about it aside from the fact that you’ll be battling bunny rabbits, cooking trolls, and “bars” which might look like bears but no, it’s just a bar. Grinding involves questing in various areas of the game that you’ll visit, engaging in either a battle, event, or a “choose-your-own-adventure” game where you’ll choose multiple outcomes to arrive at either of the former two ends. Each time you click on an area to grind on, you’ll use one of your “Adventures”, of which are limited (you’ll receive 40 Adventures daily). You can also accumulate Adventures by eating food or drinking booze, until you get too full or too drunk. Choosing where to Adventure is important, as picking a place too high level for you will result in death, giving you a debuff that you’ll likely have to spend some Adventures sleeping at your campground to wear off. Buffs work similarly, in that they last for a certain amount of adventures before wearing off. It’s a rather ingenious system that both penalizes death and promotes strategic gameplay without being too involving.

Which, to be honest, is the main focus point of Kingdom of Loathing. It’s ridiculously laid back. Look at the graphic scheme: stick men, black and white. What’s there is fun to look at not because it’s visually engaging, but because it’s hilarious. It satirizes all the RPG stereotypes while being a rather fun RPG itself. It’s the kind of game that takes a step back from games and just wants to be nothing other than fun. It’s a great game to kick back for a half-hour and just waste some time laughing at the witty dialogue and improving your Seal Clubber’s stats. Really, if you find yourself loathing all the RPG clichés that plague games nowadays, you might fit in playing Kingdom of Loathing.

Tags: kingdom, loathing, of, pbbg, review

Making Quests: Part 1, Design

Quests are an integral part of the single player game experience. In some games, the entire purpose of playing the experience is to fulfill a quest. In many games, quests are filler and are there as a way for players to get accustomed to the game environment or just to give them something to do if they don’t feel like playing with other people.

What role will quests have in my game?

The first part of designing your quest system is to ask yourself “why do I want to have quests in my game? What purpose will the quests serve? How will users utilize quests and what am I hoping users will get out of quests?” These questions are not just nice to have in the back of your mind so you know you are on the right track. You need to come up with concrete answers to these questions and you need to make sure that your quest implementation follows the answers that you came up with.

Like I always do, I will be using my game TerraTanks as the example that we will be following. At the time of me writing this, I do not have a quest system in TerraTanks. I think that the game needs one. So now I will answer my own questions:

Q: Why do I want to have quests in my game?
A: There is a lot of down time in TerraTanks and relatively little to do during that downtime. I think that quests will be a big filler. If you don’t want to fight someone there is even less to do. People are slow to attack someone else because they fear retribution of someone that knows how to play better than them.

Q: What purpose will the quests serve?
A: The quests will give players something to do during slow periods. Quests will give players training and experience in game tasks. Quests will be an alternate route for advancing a player’s character.

Q: How will users utilize quests and what will they get out of quests?
A: Quests will be a non-integral part of play. There will be various benefits including player learning of how the world works and concrete in game rewards like resources or troops. Quests will give the player something to do when they don’t know what else to do.

What is a Quest?

A quest is a state machine where states are changed based on the correct user action. A good quest is significantly dressed up from this, but all quests boil down to this definition. Each quest has several states that it lives in that waits for user interaction to proceed to the next state. The states most often look like this:

1. Quest created - The quest exists and is waiting for a user to accept it.
2. Quest accepted - The user has accepted a quest. New triggers are usually placed in the game world.
3. Quest progresses - Often a quest will have several stages with new triggers being activated. This step can be repeated indefinitely.
4. Quest conclusion - Either the quest is failed or satisfied. The quest should die at this point or get reinstated back to state 1.

Further explanation

Quest is Created - The quest needs to be created without user input on the game. The quest is instantiated in state 1 and put somewhere for a player to find. Usually this means you place an NPC or a button that says “get quests here” for the player to find and interact with.

Quest is Accepted - The quest moves into the second state where the quest is made into a unique instance for the player who accepted it. Appropriate steps are taken to change the world to accommodate completing the quest. You need to decided if these changes are only going to be noticeable by the person on the quest or if they are noticeable by everyone in the game and if the quest is continuously available or just available on a first come first serve basis.

Quest Progresses - When you accept the quest, new triggers are placed into the game world. This could be an enemy that the quest identifies as something that needs to be killed or it could be a location that the player needs to go to or an item the player needs to hold. Part of the design will include how your system will handle quest progression. This will be covered in more detail in a future post.

What kind of quests can I do?

When coming up with quests you will find that many of them fall under the two stale catagories of:

• Delivery quest
• Hitman quest

Unfortunately there is not much you can do about this pig besides put lipstick on it. There are some benefits to these types of quests because they will teach the basics of your game. Once these basics are learned, though, the only thing that will keep players coming back for more are the in game benefits of completing a quest and good story writing. I suggest that you spend a lot of time working on the risk/reward balancing for quests as well as coming up with innovative ways to present the quest. Here are some suggestions on dressing up your quest:

• Make the quest multi-step
• Put time limits on the quest
• Make penalties for not completing quests you are given (making the penalty too stiff is a jerk move. be careful with this one)
• Instead of attack quests, make defense quests
• Think of interesting rewards for quests. What if, instead of money, the player gets to learn a certain research for free or gets attack immunity from a certain faction for a short time. Be creative in the space of your own game.
• Make a quest competitive. When one player gets a quest to make sure something survives, give the next player the quest to go and kill it. Or give several people the same quest to have control over a certain area when time runs out.

In the comments, please feel free to include where you would like this quest series to go.

Sending unknown number of variable parameters to new page in HTML

Before I get started I wanted to say that I am not a web server expert so if you know of a better way to do this, post it in the comments and I will thank you as I implement your knowledge in my game.

When using PHP you eventually come to the realization that your gatekeepers for everything you do and display are HTTP and HTML.  They are both great tools but were designed with a more static implementation in mind. Values passed to new web pages are set up in key->value pairs that are accessed with an associative array using the name of the parameter as the key (ie. $_POST['myParam']).  This post will deal with the issue of how to send an unknown number of parameters which are user set to a new page which can then use those parameters correctly.

My particular implementation is my Mining page in my game TerraTanks.  The mining page allows the user to set the type of mining on each of their planets so that if they are deficient in a particular resource, they can mine it out faster.  I wanted to make sure that this could be changed globally, so the mining page will show all of your planets and each planet will have a set of radio buttons allowing you to change the mining settings.  With these constraints, you cannot know how many planets the user will have and you must write your code to account for any number of parameters.

This is a simplified version of what I have:

$count = 0;
 
// I have the result set for all my mining planets in $result
while ($result && $element = mysql_fetch_object($result))
{
    // code displaying what I need about planet //
 
    echo "<INPUT TYPE=\"radio\" name=\"miner{$count}\" value=\"normal,$element->location\" checked>Normal";
    echo "<INPUT TYPE=\"radio\" name=\"miner{$count}\" value=\"iron,$element->location\">Iron";
    $count++;
}

I am creating the name of the radio button group by appending the value of $count the the word miner and then incrementing count as long as there are planets. Basically, I am hacking together my own array. It should be noted that I am setting the first radio button to the checked state. The web page that will read the input depends on everything that exists having a value so it is necessary to make sure that something is selected. In your work you will want to check what the value is previously set to and make sure the correct radio button is checked when the page loads.

You may also notice that I am shoving a lot of data into the value sent appended by commas. This is a decent way of shoving related data through without having to define a ton of variables.

Now we have to create something on the receiving page that will correctly read in the values that we are sending. This is the code that I am using:

$x = 0;
$indexName = "miner" . $x;
while ($_POST[$indexName])
{
	$miner[$x] = $_POST[$indexName];
	$x++;
	$indexName = "miner" . $x;	
}

If you read the code in English it roughly says, as long as there is a POST value at the index miner{$x} where $x starts at 0 and increments by one then just keep incrementing $x and saving the value into my own array. This is why it was so important that as long as you had a planet you had a value that was passed. If you set a value for planet 0, 1, and 5 but not 2, 3, or 4 then the code would stop at 2, determine there was no value and would never get to 5.

Now instead of creating a second pseudo array with hidden inputs that pointed to the location of the planet, I packed all the information into a comma appended string. When I get the value of $miner[$x] I can use the php function explode to separate out the sub values.

$minerParts[$x] = explode (",", $miner[$x]);
 
// now $minerParts[$x][0] is the mining type and $minerParts[$x][1] is the location

So there is a way to send an unknown number of variables to a new page. Like I said, if you know of a better way make sure you post it in the comments. I don’t claim to be an expert on this subject, it is just how I resolved this problem.

Post Mortem: TerraTanks: Dominion (Part 3) What I did well

This post was surprisingly hard to do. As much as I would like to think I can be a pompous jerk (because they are the ones that get what they want at the expense of others) I am a pretty nice and humble guy. It took me a while to formulate what it was I did well in TerraTanks.

Be very communicative with your player base:

You are definitely not going to get everything right the first time. It is frustrating when the simulation that you run in your head about how fun something is going to be is not how the users end up using it. Make sure they have channels to tell you what they don’t like. In my case I wrote a form that goes on the bottom of all of my pages so the user can post a comment to me. Their comment is stored in my database with their identifier so that I can talk to them in game. I also made a built in reward system so that I could give people things for pointing out my mistakes. A complaining user is so much more valuable than a quitting user. Treat them like a valuable member of your project.

Listen to your players frustrations but remember that you are the game’s architect. Don’t implement a feature just because a user wants it. One of the most valuable lessons I learned in a class about Quality was that the end user, most likely, will not tell you what THE problem is, they will tell you what THEIR problem is. You are the expert of your game and you need to make sure that you are alleviating the pain of the end user while not throwing off the game or compromising what the experience is supposed to be about. A great example of this is that when people started playing the game they were confused about what to do or how to do things and they would ask me specific questions. “Do I need a surveyor to survey a planet before I build? How do I get units from my highliner to the planet?” I asked if the tutorial that I force everyone to go through did not explain it well and usually they just said that they skipped through it and tried to start playing. Throwing up my hands and saying “well it is your fault for not reading the tutorial” is actually not the correct answer. Instead I made a series of video tutorials for the game.

Another way I made communication easier was to include a forum in the game. I am using phpBB, but I integrated it directly into the game by creating the forum account when the user’s game account is created.

Games are interesting when they make sense:

One of the things I strived for when building TerraTanks was that if something happened to you that was unexpected, it would at least make sense. The simple visual presentation belies the depth of cause and effect that goes on in the game. Here are some examples of what I am most proud of:

• In order to find out about enemy locations to attack them you have to use your spies. To keep with the global management theme, you just have one ’spy level’ that is used for your character. When you spy on someone the game compares your spy level with their spy level and you are given spy report based on how you compare. The spy level is only based on how much you are willing to pay in gold every day so while larger players should have a better spy level, they need to play it correctly to do so.
  When you get your spy report on a player, you will find out about all buildings that exist a set distance away from your closest base for every week the building has been around. So if the distance is 25 for every week I will see buildings that are 50 distance if they are 2 weeks old.
  While this system seems complicated, it expands the strategy of the game. New players are harder to find and attack giving them natural setup protection. Building a base in enemy territory becomes a good strategy for scouting. It gives you a reason to keep expanding in new places. It balances old big players with new small players. It makes sense that it would take a while for your spy network to find a newly populated planet.
• Combat is designed to play out more realistically. There are bonuses for different combinations of units that you use. For instance, the APC (armored personnel carrier) will make your foot soldiers and sappers harder to kill. If you have Scout tanks and Behemoth tanks, the scouts will act as spotters and you will destroy more tanks during that attack. Also, battles go more quickly if the forces are lopsided. If you go in with an even number of troops, you will have to slog out several attacks with fewer troops dying on each side. The attacker is charged action points for each attack and he would probably want to use those points on other things. Lopsided battles are over quickly and produce many more casualties on both sides.
• Actions in game frequently require the use of action points. You acquire one action point after some set period of time. It makes sense that as your empire expands it would take longer for you to do things. The refresh rate goes from 15 minutes when you have nothing to 1 hour when your empire is very sizable. This helps new players get set up more quickly.
• Bases are the central hub of your civilization. You put a base on a planet and you can have things up and running very rapidly. As you build on planets further from the base things cost more and take longer to build. This is a common strategy in games but it made sense to the story of the game.
• Moving your ships around in system takes 10 minutes of real time. Systems are spaced 1 hour apart from each other. When thinking about space, solar systems are pretty densely packed when compared to distance from one system to the next.

Thanks for reading all the way to the end of this post-mortem. I would love for you to come and try out my game and let me know what you think!

www.terratanks.com

Post Mortem: TerraTanks: Dominion (Part 2) Need to improve

Really this section could go on forever. I fell into a despair about the game 2 months ago where every week I would make a large update to fix what I thought was the game not being fun and by the end of the week the game was not fun again. This has since dissipated and I have been having a blast with the game.

I want to focus on 2 things that I think need talking about (and one of them is not web page layout). One is something games in general suffer from. The other is something my game uniquely suffers from.

Thing 1: Scope, scope, scope, scope, scope.
Something I have difficulty with is wrapping my brain around just how big something is going to be. While being big is not necessarily a bad thing, being big and empty is a horrible thing. When you create a space, that space needs to be filled out completely. The first game I made (Atlas: The Gift of Aramai) suffered from this. The driving principal of the game was “we want to make it big”. The fallout of this was 5 years creating content to still have the game seem desolate and empty as you character walked for 7 minuets to the next town.

It is amazing how the power of squares can effect the amount of content you have to generate. Filling area is literally X times more time consuming than filling a linear map where X is the length of that map.

When starting a game, think small. When you think of most browser games they occur on one screen. Depth is so much more valuable than breadth. Depth displays the designer’s creativity. Depth in a small game means that you can actually release your game in a time span that doesn’t drive you crazy.

Far be it from me to follow my own advice. TerraTanks is a very large game. I believe it is also a very deep game. It certainly is a complicated game that evaluates actions in a sophisticated way. It took me 2 months to finish the breadth of the game and an additional 8 months to add depth to a state where I am satisfied with my work. (2 months of that was under the public beta). I have a very long list of things to do to add more depth to the game. It is playable and fun as it is, but the oportunity to add depth seems to be expanding and not getting smaller as I create features.

Thing 2: I created an odd way of displaying the map.
This can be prefaced by saying that compared to many of my peers, I think sideways. It is fun to be unique in my problem solving but it is sometimes difficult for me to relate my ideas to the general audience.

This is what I mean. Most people when they want to create a map they will go about creating a cartesian coordinate system grid. People understand the incrementing value and it is easy to calculate distance using the pythagorian theorem. When I went about creating the map I originally thought of how space looked in my head. You have a universe with nested galaxies. Each galaxy had nested stars. Most stars are solar systems with nested planets. The idea of nesting is what stuck with me. What I did from that was to create a system of nested areas which defined my space. My galaxy was a square divided into 4 square quadrants like this:

0 | 1
----
2 | 3

Please note how like any good programmer I start with 0. Each square quadrant was divided into 16 square sectors so in quadrant 0 it would look like:

00 | 01 | 02 | 03
-------------
04 | 05 | 06 | 07
-------------
08 | 09 | 0a | 0b
-------------
0c | 0d | 0e | 0f

Now note that since I have 16 squares I am using hexidecimal notation.

What I end up with is planets that have identifiers that look like 0b23c5 which accurately descirbes the location of the planet in a nested notation. While it makes complete sense, this is really difficult to explain. Most people don’t have a computer science background and even if you do, people don’t view maps as a series of nested grids. While this way of making maps simplified programming in many respects, but it is not good to make your end users learn something like that to understand your game. The other problem is the effort to convert the game to a cartesian map is difficult and pretty much impossible now that people are already playing the game.

Game makers often fall for the old trap of either trying to show how smart they are or treating their audience with contempt for not knowing the minutea of their own passion. Really smart game makers can present difficult concepts in a way that everyone can pick up and understand. You don’t need to spell things out for your audience at every moment, but don’t make them figure you out either.

Most of the remaining issues with my game involve how to efficiently display large amounts of information. This is something I work on every day so I don’t think of it as something that I did wrong in hindsight, but something that is still in progress.

Post Mortem: TerraTanks: Dominion (Part 1)

It is kind of an odd feeling writing a postmortem on a game that I feel is still living, breathing, and growing. I still make updates to the game almost daily and some of them aren’t even bug fixes :). Like the BlackSword postmortem, I don’t think I can really put down everything in one post so I am going to assume this will extend into other posts. I think the place to start is to describe how this game took root.

After completing a single player RPG (Atlas: The Gift of Aramai) on the Mac with a group of friends in college I decided that I wanted to do a 3d Scorched Earth game and I called it TerraTanks. I worked on this game for 3 years cycling through different open source engines and finally got a good way through it using Torque. I had finally reached the end of my list of friends that wanted to work with me. It turns out most people have dreams of their own. The game was too complicated to finish on my own so I started contriving different plans to be a successful game maker. The plan I settled on was to create the third iteration in my TerraTanks anthology which was an MMO. I switched my thinking towards making it a low tech browser platform game that I could surely finish on my own.

I actually did not approach this project with an “I saw this other game and I can do better” mentality. I had played very little of very few browser or MMO games. I came in wanting to fulfill a couple of feelings through a game experience. I wanted to create a feeling of vast empires and colossal battles, and I wanted to create a feeling of non-tied down community. The real breakthrough came when I discussed with a friend a system where you are put on a team that automatically groups you with your teammates and periodically you vote to see who becomes your leader. Later in the postmortem I will discuss how the great ideas that start a project often become lackluster at the end.

I finished my prototype in two months and sent it to friends to see what they thought. It sucked but there were some really good ideas in it that just had to be extended. I had basically created a sandbox where things could happen, but there was no driving force and no way to tell what you were supposed to be doing. It is not enough to give people tools. People are aware that the environment is set up with a system of rules and they want a general idea of how to best navigate inside that confine.

It took another 6 months to fix and change a lot of my prototype and give the game a sense of direction. I “released” the game and that turned into more of an open beta. I don’t know how many times I have heard it said, I am still in complete awe of how helpful it is to have other people play your game with you. They have uncovered enough issues and suggested enough head slapping improvements to make me embarrassed about the first iteration I released.

In future posts, I will talk about things I think really went well with the project and things that I should have done better. For now I will leave you with a synopsis:

TerraTanks: Dominion - a PBBG where you take over and mine planets in a vast galaxy inhabited by enemies you are sworn to make war upon.

• over 2 million planets
• real time and turn limited play integrated together
• real time travel across galaxy (trust me this actually works well in game)
• research that is global to the player and not local to a planet
• sophisticated combat calculations that allow you to combine your troops with your team’s troops
• simple voting system to move up in rank
• tax system to reward you for moving up in rank
• auction for regulating resource economy
• planet auctions to allow you to speculate in real estate
• in game messaging
• integrated forum