Game Engineering

Creating an iPhone Ad Hoc Distribution

2011-03-07T12:49:00.000-08:00

There's always some step here that I forget, so here's my checklist of things to do in order to get a working distribution build for your iOS project:

Make sure you have Default.png and Icon.png added to project
go to developer.apple.com, create App ID (this is the "bundle ID")
go to developer.apple.com, create distribution provisioning profile
download distribution profile
drag profile from Finder into XCode Organizer's "Profiles" window. This is critical.
optional: add profile to the project. Sometimes this helps.
optional: quit xcode & restart. Sometimes this helps.
app target info, properties tab: edit Identifier to match App ID
target info, build tab, configurations popup: choose "Edit Configurations..."
duplicate Release config, rename "MyApp adhoc"
build settings for adhoc, Code Signing: choose the adhoc profile
build settings, "Packaging" section: edit "Product Name" to be what you want
choose Adhoc / Device as your build target
build

And you're done!

To distribute this app, you'll have to mail both the app (MyApp/build/MyApp adhoc-iphoneos/MyApp.app) and the provisioning profile to your users. If they have macs, they can use the iPhone Configuration Utility to install onto their device. Windows people need special zips (.IPA?) which you can find detailed elsewhere.

libAdMob.a missing from iPhone project

2010-07-27T09:44:00.000-07:00

Did you check out someone's iPhone project (or sample code) from SVN and get a "library not found, -lAdMob" error?

That's because some SVN clients are set up to ignore .a files, which is how the AdMob library is distributed. What you'll need to do is to contact the person who checked in the project and get them to add the .a file (it's about 2MB) to the SVN repository. Or, you can download it yourself.

To download libAdMob.a, go to admob.com, sign up, create a new App for them, and THEN it will let you download the SDK code. No, you can't just download the SDK, the AdMob developers are a bunch of stupid cunts that don't want to let you have an easy day; they'd rather force you to sign up and create an app you'll never actually ship, instead. They *want* the clutter. They *want* to hassle you, one of their developers. That's because (and I hate to repeat myself) they are a bunch of stupid cunts.

Sharing to Facebook from an iPhone App

2010-07-24T10:23:00.000-07:00

First, let me say that the sample code provided by Facebook and others is teh suck. Some of the top hits when you search for stuff are broken samples. Be careful out there!

Second, the documentation itself is crap.

So I'm here to go over the flow that I used to share to facebook. If you're developing an iPhone app and want a "Share on facebook!" sort of thing, then start by perusing the readme: http://wiki.developers.facebook.com/index.php/Facebook_iPhone_SDK That's nice and all, but it's not shippable.

Background #1: Facebook updates. The 'stories' that appear on your wall, and are shared to your friends' home pages, are all little text doodads with links to content stored elsewhere. Adding a story to a user's wall is the simplest thing, and it's what most of those Facebook games do. There are status updates and then there are other stories; a status update is what happens when you don't include an actionable item (a 'call to action' type link). Mostly you just pull some key/value pairs together (see Facebook's list of attachments) then make a request.

Background #2: You can't upload images to a wall, only to your photo album, for example. Developers making utilities, games, and entertainment want to add a story that contains a custom image. You might note that most facebook games don't do that; they use a generic image instead, like a picture of a cow or sheep or barn as FarmVille does. Uploading a custom image is tricky. If you want a wall story with a custom picture, you have to either (a) first upload the image to the user's photo album (the default one has a limit of 500 photos, one dedicated to your app will have a 1000-photo limit), which means that two stories will appear back-to-back on the user's wall, or (b) store the image somewhere else instead and link to that.

What you wanna do:
0) First, allow the Facebook Developer application. Go to http://www.facebook.com/developers and 'Allow' it.

1) Create an application (see the image on the right). Yes, you might need to make your application page pretty.
2) Go to XCode. Create your own facebook helper class. I called mine FacebookHelper, cuz I'm creative like that. The point of creating this class is to not mix facebook delegates and dialog handlers and all that crap into your other classes. Posting isn't just one function call (there can be three or more callbacks involved), so partitioning it all into a separate class will help.
3) Add an entry point to this class. I haven't yet refactored this out; right now, I copy-n-paste the class into a new project and edit the implementation. So my entry point isn't

- (void) Share:(NSString*)shareText;

blah blah blah, but just

- (void) Share;

4) That entry point will look roughly like this:

{

if (self.session==nil || !self.session.isConnected)

 [self ShowLogin];

else if (!havePermission)

 [self AskPermission];

else

 [self PostToWall];

}
5) Write the FB login code and delegates. This means creating an FBLoginDialog and show'ing it.
6) If you need extended permissions of any type, create & show an FBPermissionDialog. Note that your FBDialog delegate callbacks will need to differentiate the type of dialog shown. I did this by sticking an enum in the dialog's "tag" field, and switching on it in the dialog:didFailWithError, dialogDidSucceed:, and dialogDidCancel: callbacks.
7) Finally, post to the wall. Do this by creating an FBStreamDialog, add an attachment string with all your parameters, like so:

 "name":"My App Name","message":"User enters this text, this is placeholder","caption":"etc"

These key-value pairs will include a link to your app and a link to the image to use in the post.
7b) If you're uploading an image to one of the user's albums, you use an FBRequest instead of showing an FBStreamDialog.

{

 NSMutableDictionary* args = [[[NSMutableDictionary alloc]init]autorelease];

 [args setObject:@"my caption" forKey:@"caption"];

 FBRequest* request = [FBRequest requestWithDelegate:self];

 [request call:@"photos.upload" params:args dataParam:image];

}

Later on I'll upload the entirety of the class so that you can see it all in process. Plus I'll probably clean this post up, too... meanwhile, I've got to run.

some notes on learning

2010-07-10T16:36:00.000-07:00

The best teacher will show you theory, give you both good & bad examples, explain why the bad examples don't work, then watch you try it and give you feedback. The lower the time lapse between trying something and getting feedback, the faster you'll learn.

If you don't have the spare $50k laying about to hire a personal instructor for your desired task, you're stuck searching and finding this stuff on your own.

Programmers

What if you're a programmer? The best place to go for theory is textbooks. Usually they're thick with theory but light on practice, and some of their theory will only work in the toy examples that academics are used to. But that's fine; you're here for the theory.

Good & bad examples are somewhat easy to google for. "Best practices" and "horror stories" are good keywords. Look for people that suggest bad experiences and ask them to expand on it.

Newbs tend to have bad habits, but finding out what those are and why they're bad is difficult. Books and didactic websites are again your best bets here.

The hard part is feedback. For that you need a coding buddy; someone (and I would suggest someone you don't work with) to serve as a sounding board, and will develop their own library of best practices, bad habits, and good feedback. You can give yourself feedback by (as I mentioned early) refactoring your own code shortly after you write it. Go back and rewrite the last app/utility/website you built! Might seem like "a waste," but it's amazing what you'll learn in the process.

Gamers

Game theory is woefully light. Good luck with that.

Good examples are easy to find; there's tons of videos of good players and really bad players. The hard part is figuring out why the good players succeed. Sorry. Good luck with that.

The easiest way to get better, actually, is to study mistakes. Look at people that get crushed and try to figure out what they did wrong. Fraps your own play and study it. A lot of people just hate doing that. Suck it up, cowboy. You'll learn fastest that way.

Three Steps to Being a Better Programmer

2010-07-10T16:28:00.000-07:00

How to Be an Awesome Programmer in three easy steps:
1) Practice
2) Study the experts
3) Learn from your mistakes

Practice is by far the easiest thing to do. As I've mentioned before, I think the great lesson of Gladwell's Outliers: The Story of Success is that one gets better at something by practicing. In anything competitive, by practicing against better players (that's #2). But time on the field isn't enough; you actually have to learn something.

I've been thinking about playing Warcraft again, and in preparation I've watched a few Arena videos to get me motivated. That lead to watching some Quake videos, and that reminded me of my old days playing Quake. Obviously, the top players (at any online game) have played a lot. But time on the battlefield isn't enough; being smart by itself isn't enough.

I also read a number of "how to get better at Arena/Quake/Whatever" articles, and that led me back to Gladwell, a bunch of other articles and books, and eventually to the pickup community. A lot of people go to coaches for learning. This mostly gives the student a chance to find out who the masters are, so that he can study what they do. It's difficult to get better when you're around people that are as good as you; you're forced to learn everything yourself. Coaches will tell you what to practice, and they'll show you better players, too.

But learning that way is still pretty much learning by yourself. You just have better examples to teach you.

The better way to learn is to have a teacher. The teacher will look at your performance and suggest what to do different. They'll point out your mistakes.

That's the hardest part of getting better

Most people don't like to go back and revisit old work, but it's potentially the most instructive. And watching the pros at work isn't enough; a good teacher will point out what they're doing.

The the pickup community, "instructors" either "teach by example" (which is really doing what they do and then hoping that you figure it out on your own) or stick to mechanical skills (like body language).

In online games, there are no coaches; everyone learns by themselves. In this sort of community, the best thing to do is to play with the best.

In programming, the cost of practice is extreme; there's a plethora of experts; and they all say different things. About the easiest way to improve your programming is to refactor.

The best way to be a better programmer

The easiest way to improve is to try different tools, languages, and platforms. Until you try a decent interface builder, you'll probably think the one you're using is good enough. Until you try a functional language, you'll think your OO skills are all you need. Until you use a modern compiler, you might think the crap you have to do to satisfy your current compiler are acceptable.

Theory is nice. Where's the practice?

One of the things I learned while working on my other blog is just saying "try a new platform" is vague. Are there any that I could name that would be good?

Why, yes. Yes there are.

1) F#. Try building little Windows utility apps using it. Dive into the community to find better ways of doing it. Read a book or two and pick up the common wisdom.
2) iPhone dev. This is a great place to learn from other's mistakes, because the platform and tools are such utter shite. Seriously. The rest of the world is using modern compilers and tools that work. (OK, honestly, this entry is a bit of a joke, but you will learn message-passing.)
3) Find an open-source project using Perl or Python. Diving into one of these languages is the best way to learn them.
4) Website dev using C# and ASP.NET. Modern compilers & tools are an amazing thing.

I'm sure there's better examples out there; use these suggestions as a start.

Four Things Good Programmers Do

2010-07-07T19:59:00.000-07:00

After a five-month ski vacation I'm back in civilization job-hunting. The interview process is interesting from the interviewee side, to see what many companies think that they want. To me, a good programmer isn't someone that's spent seven years with Technology X; in that much time one learns a lot of tricks, but good programmers don't just know tricks - they're supposed to be writing code.

#1 Ship

Good programmers finish what they're working on. I think being left in a cubicle by yourself makes it easy to succumb to creeping featuritis. To get caught up in 'perfecting' a system which might have a minor role in the finished product. Good programmers ship. They get things in shape to release, and they release. The more things you release, the more you learn about what customers want. And you also learn how to release better software faster.

To me the lesson of Outliers is that everyone learns by doing. The more you do something, the better you get at it. The people that are really good at stuff - from major-league sports players, to Bill Gates, to writers and artists - are good because they have had a lot of practice.

Spinning your wheels polishing bad code is practice polishing, not practice shipping. If you want to hire a good coder, you want someone that's had practice turning a working prototype into a professional, shippable product.

#2 Working

It a similar vein, good programmers write working code. I've worked with too many coders that write buggy code that barely works - or doesn't work at all. You'd think they wouldn't still have jobs programming, but the interview process is pretty damn flawed. It's like a first date. The interview I had today was mostly feel-good; a guy on the team liked talking about Agile and I could talk the talk. Walking wasn't really part of the discussion.

I'm surprised when I see someone check stuff in that doesn't actually work. It suggests that the programmer has bad habits and doesn't test what they write. To them, programming is something you do in the editor. As soon as their code compiles, they check it in and move on. Yes, I've actually worked with coders like that. They think they're gods; they think they don't make mistakes.

The good programmers on your team, the ones you want to keep and promote, are those that actually get stuff working. When a web page is supposed to do something, when a class is supposed to commit a transaction or pull data, it should do so. Some guys get 90% of the way there, and other coders step in and turn a code checkin into a working feature.

Mr. 90% won't be able to ship software. He might write a lot of code, but the stuff he checks in doesn't actually work. Ask your coders; they'll be able to tell you who on the team is Mr 90%. Fire Mr 90%.

#3 Robust

There's a lot of work that goes into the "foundation" of a feature. Some of it is gruntwork; creating the class, getting headers & dependencies set up; building the UI using a design tool. This is mostly monkey-work, and that's why bad programmers can get to 90%. Getting stuff working is the last 10% of the code that's written, but it's an essentially important 10%.

But once a feature works doesn't mean the work is done. Debugging typically doesn't add lines of code. Refactoring to get stuff working is likely to reduce lines of code. Good coders don't just run their code to see if it works; they test it, too. And they know how to write software that passes tests, and how to write tests that go after edge cases and corner cases.

Going after those edge cases is a mindset. Some programmers have, in the back of their mind, a demon that thinks of malicious calling code. What's the worst that can happen? What if they give me bad data? What sort of bad data is there? Are there possible race conditions that could screw up this process? Good coders have that demon.

"Agile" has turned into a buzzword that many software managers think they need to have. They think writing tests will remove all bugs. But if your tests don't test the right stuff, then your product will still have bugs - it will just take live testing by a QA group to find them. There's good practices in agile testing, but TDD won't get rid of bad programmers or make them irrelevant. The guys you want on your team write robust code the first time. That doesn't mean no bugs but it does mean they, as a habit, look for edge cases.

#4 Features

I think somehow it has become verboten to discuss intelligence. Yet software is one of the few areas where intelligence has a very strong effect on productivity. Smart programmers get more done. They are good at solving problems, and they can keep track of several things at a time. If they need to keep that "what if" demon running in the back of their mind, the smarter guy will have an easier time at it.

Good programmers get features done faster. Per week, they get more features done.

It's grossly difficult to schedule software development. Agile development, in part, is a response to that. Instead of making up a list of features and then committing to a length of time to get that done, Agile commits to shipping something at a point in time. Some features are easier than others. It's hard to actually measure programmer productivity - but still true that good programmers are more productive.

Shipping Feature-Rich, Robust Software

Software development is about shipping. Guys in academia and research departments can fart around for decades and you can call it good work, but out here in the real world we need to ship software. The more features you have, the better your market position. The more robust your software, the happier your customers will be.

Good programmers make that happen. They write the code, it works when they check it in, and they know how to go after bugs. And they do it all quickly.

Hire those guys; they'll make you rich. :)

The Thousand-Hour Sim, Part 1

2010-06-11T22:25:00.000-07:00

One of the ideas I mentioned yesterday was that there's only a few genres where a large number of players (10,000 or more) will be willing to spend multiple hundreds of hours playing the game. There's a lot of games were a good chunk of the audience will spend around 100 hours. Many single-player RPGs have that much content, and a lot of multiplayer games will keep players busy for 100 hours.

But take a game like WoW - there are millions of people that put in hundreds of hours every year, and probably millions that have put in over a thousand hours over the six years since the game has come out. Some of the friends that I worked with averaged six hours a day - usually spending a dozen hours on the weekends and a few during the week. That works out over 2000 hours a year. Even if they burned out in six months, that's a thousand hours right there.

Competitive games, like Starcraft and Counter-Strike, are another genre where thousands of people might spend thousands of hours.

What would you have to do to make a sim that could keep at least tens of thousands of players occupied for a thousand hours?

Summary of the FMMORPG Argument

There were eight factors I mentioned when I described Fantasy MMORPGs as the ultimate genre. They are:

environment variety
tangible, human-scale environment
non-trivial gameplay
opponent complexity
opponent personality
solo and group gameplay
inspiration
open end-game

The first factor means having a wide range of environments. The second suggests using an environment that can be rich. Gameplay needs to be complex, and getting to a really rich complexity means not just having a complex puzzle but introducing AI units into the game that introduce complexity, keeping the game fresh. The fifth factor, opponent personality, is like the second: it puts a face to the game world that players can relate to; an environment that produces stories. The sixth factor is about allowing players to play whenever they want, while also giving them team goals, where they can work towards goals larger than one player. Inspiration (and something I didn't mention, commitment) are ways of giving players long-term goals to keep them coming back. The final factor says that the game can't end after a hundred hours; allowing players to stay in the same game world for the entire duration of their play-time can keep them there.

The factors can be broken down into a few threads. I'll probably redo this list at some point. Obviously, this list isn't definitive; I'm building a model for game design and there are surely many other models just as suitable. Anyway, the points I'll cover today will be:

Gameplay needs to be rich
The game world needs to be rich
The game has to enable stories and emotional moments
It should allow the player to play, and make progress, whenever they want
The game should provide large goals, requiring time and/or teamwork
The game should have an anchor that commits players to the game

Some of these feel essential to me, others feel like caveats.

Positive Attributes

I think some of the attributes should influence the core game design. The game should be built around these principles. These are the things you should be trying to do when you design the game. The negative attributes, which I mention later, are a list of things you link at and think, is there something in this design that will drive away players? I think the negative attributes can be tweaked - that once the core game mechanics are nailed down, the next step is to go through a list of "gotchas" and make sure there's nothing there that would piss off players.

First I'll tackle the attributes core to game design.

Gameplay needs to be rich. This is the single most important attribute. Without rich gameplay, the game becomes rote quickly, and play-time becomes boring. I've talked about the essence of fun before, and my theses on boredom is that it happens when the player doesn't have to think about gameplay; if the time the player spends thinking about decisions is too small. As complex as the game might be, if the player has mastered the game rules then there's nothing more for him to learn.

Take a game like Halo. They introduce new mechanics throughout the game and, by the end, you've explored all of those mechanics. Once you've beaten a level, there's no reason to go back and play it again, except maybe to find a few hidden secrets or complete it faster. New sequels really just introduce a larger game world; they don't add new gameplay elements. Players spend 20-40 hours playing through the game, and then wait two years for the sequel, then spend another 20-40 hours.

Compare this to Grand Theft Auto. The worlds are about as large, but there's a richer variety of things to do. As a result, players can spend 100 hours in the world. There's only about 100 hours of "quests" in the game, though. If they added more quests, would you keep playing? Probably not, because without more mechanics, execution of those quests becomes easier and easier. As you play through the game, you pick up new weapons and learn new game skills - but you exhaust those skills by the time the game's done. That's what I mean by new mechanics: there'd have to not just be a new place to play (ie a larger world, such as in the expansion packs) but new ways to play.

The game world needs to be rich. I touched on this above. The world shouldn't just be large, but provide new environments. There are over sixty different zones in the world, and each one has many different sub-areas. Plus well over 100 different dungeons. The starter zones can be plowed through in under an hour, but by level 50, there's at least five hours of quests in each zone. The dungeons provide a couple hours of gameplay but can be replayed, too. Each of those zones and dungeons has its own creatures; usually dozens in each zone, and each creature type (like, say, furbolg) has several variants (such as warrior and shaman).

That means a lot of art assets, of course, but that's what "rich world" means! Players can easily spend ten hours in Stranglethorn Vale. Although the whole zone is jungle, the land ranges from the beach, to the river, to hills, to villages, to caves. Creatures include pirates, goblins, trolls, panthers, tigers, raptors, basilisks, and ... much more. Each little area has its own story (told through the quests) and there's a few greater storylines that take players through the zone.

Worlds are rich because of the variety of their assets and they stories they tell. Speaking of which...

The game has to enable strong emotional moments. Stories are a player retelling of emotional moments. The strongest emotions are fear, anger, and love. WoW doesn't really want to anger its playerbase, but anger does have a greater place competition-driven games (and therefore in the PvP aspect of WoW). Fear is the most common, but it's not often remembered as such. The most memorable moments for me in WoW were when I was running in fear from high-level enemy players, or in instances when our tank died and I was panicking trying to keep the group alive (I played a healer!), or close calls when I got attacked by several creatures and was running for my life. When these encounters ended well, that fear turned to extreme relief. I wanted to tell everyone I knew about what just happened, and the story got retold the next day at work, too.

Strong emotional moments make the game into a larger part of the players' lives. When we take those stories to work the next day, to the pub, into our dreams, its more than just a way to pass the time. Am I going to tell stories about that one time in FarmVille when I planted some corn? Ugh. We hate the boring coworkers that tell that kind of dumb story. NO. Yeah, sometimes those WoW stories are the same - but not always.

Players can feel love, or something similar, in these games, too. Probably a bit more common is respect, and dedication. Players in guilds might feel commitment to their guildmates, and want to show up on raid night not just because the raid will be fun but because they want to help their guild out. It's really cool to have a good tank in the group, or to have a great healer behind you, or an awesome DPS guy that is super-great about handling adds. I really respect those players and their skill with the game, and that generates stories that I want to tell, too. (But god I hope that raid is fun, too. See section one: gameplay should be rich.)

Curiosity can also be a strong motivator. Curiosity drives suspense novels and thriller flicks. It's usually not something that the designer would want to drag out for dozens of hours, but there are a lot of cases where a bit of curiosity keeps me playing for an hour, or to keep coming back to a quest line for an hour of play every so often. Some quest text can introduce a mystery, and either dole out new bits of story in each quest or give the player a chance to go exploring and find out the solution for themselves. This is a kind of meta-game; the game proper is combat, but if you've got a player hooked on a mystery they'll play through the combat to find out who done it! Yet another way of making gameplay richer, and in this case it works because of the emotions that the game makes players feel.

The final "core principal" is: The game should provide large goals. One of the things I've bitched about with browser games is that they don't feel like there's a larger goal. Travian actually has one, and it's a very appealing goal to me, but they did a crappy job of advertising that long goal. I played Lord of Ultima for about a week but quit mostly because I felt like I had no goals. Sure I can sit there building my city up, but who cares? Compare that to Nile Online, which I'm still playing: the goal is to get to a high enough level that you can "retire". When you do, you get a pyramid built and named after you! At that point, the game is "over" and one can leave the game, but at least it's a motivation to keep playing.

MMOs provide many large goals. To get to max level, to get into a raiding guild, to get to the hardest raid instance, to get awesome gear. Even just to complete the easiest end-game raid instances is a large goal, taking weeks of play to prepare and attempt. Single boss fights used to last a half hour or more though these days they tend to be 10-15 minutes. Each fight might take a few attempts to master, and there's around ten bosses in each raid. Throw in trash encounters (which can be tricky to master as well) and "raid night" is several hours of gameplay each week.

Accomplishing large goals tends to drive other gameplay. Preparing for raid night might mean running dailies to get cash to buy a new piece of armor, or to get enough faction to be allowed to buy a new piece of armor. Hopefully those dailies are fun and don't get too repetitive, one of the few places where I think WoW falls down. But consider this like curiosity: players will engage in hours of gameplay (hopefully fun by itself!) in order to achieve a meta-goal. They're not in combat to kill the creature, they're not killing the creature to gain rep, they're not gaining rep to buy new armor -- they're buying armor to make more progress on raid night. And they're doing that for bragging rights and to support their friends.

Non-Essential (Negative) Attributes

One can probably come up with a huge list of rules saying "don't fuck up your game by doing X". I happened to extract two from my previous post; there's dozens more that I've thought of since (another post?) but I'll cover these two in some detail to explain what I mean.

Players should be allowed to play whenever they want. If your basic game mechanic is combat, then what would keep them from playing when they want? I heard EQ basically couldn't be played solo - which meant, if you wanted to play, you've got to wait around to find a group to join. One of the things that I think made WoW wildly successful is that it doesn't have this restriction. If you log in and want to play, there's always, always some solo task you could do. You can hop into a PvP battleground, go on a solo quest, do a daily, farm some crafting resources, or find a PUG instance to run.

This principle is better expressed in the negative: don't add anything to your game that would prevent players from playing when they want to. Not being able to play is frustrating, and one of the things in browser games that piss me off. I'd enjoy them a lot more if I could play at my own leisure. Having the game say "sorry, go away, we don't want you" makes me feel bad things towards the game and that's a great way to lose players before they hit the 1000 hour mark. And it kind of means that they can't hit 1000 hours. It's basically admitting that you don't even have 1000 hours of stuff for them to do!

I'm probably going to play Nile Online til I get into the top 100 (and then retire), but there's no way I'll put 1000 hours into it - it just won't let me. It would take me years of play to get that far, and I'm far more likely to find something else to do. If I can retire after six months, what's to keep me coming back again and again? Hence:

Players should feel committed to the game. One thing that kept many players subscribed to Ultima Online was their houses. They had a lot invested in their house, and they didn't want to give it up. This is a great example because a lot of those subscribed players didn't even play! They'd log in once or twice a week to prevent their house from falling apart, but they wouldn't actually play. Imagine how many more players they could have kept around if there was something else to do?

But really my point is that commitment itself is strong enough to keep players subscribed.

Summary

So I didn't even talk about sims at all in this post, and I've been hacking away at this post for hours. In part two, I'll explore how to apply these rules to the sim genre and see what I come up with.

Meanwhile, I'm gonna go pass out... zzzz

Gameplay Complexity and Opponents

2010-06-10T12:37:00.000-07:00

Yesterday in my praise of the fantasy MMORPG as the ultimate genre, I touched on the notion that a game that involves human-like opponents has a lot of natural potential for rich gameplay. Today I want to expand on that a bit.

Game genres range from racing to shooters to RPGs to slot-machines to sims to platformers and on. Multiplayer games obviously pit you against other humans. Some of them have single-player variants, where the part of the enemy is played by AI that tries to act as close to human; ie, the opponents have the same range of actions and strategies as humans do. Others pit you against a puzzle, or simplified enemies with very constrained actions.

Puzzles - No Opponent

I'll start with the last. Puzzle games like Tetris don't have "opponents". It's just you against the puzzle. Simulations, including games like SimCity and Roller Coaster Tycoon, pit you against a complex puzzle. Simple puzzle games have simple mechanics; the complexity of the game is how the rules fit together. Some such games are like skill games - gameplay at the higher levels of Tetris require the player to have internalized the gameplay rules effectively to the point that it's like a sport, and where reflexes and the ability to think a few moves ahead are important.

Skill games are rarely complex. Coding their game rules is simple. Design can be difficult, however; the process of coming up with rules that are amenable to skill is tricky. Back during the golden decade of the FPS (the 1990s), many game companies tried to make competition-worthy FPS games, but most fared poorly. For a single-player game, something that's going to provide 15-40 hours of gameplay, the game mechanics don't need to be very rich. Elements that would lend themselves to longevity as a skill-based competition are hard to design in, and the economics of the game industry often mean that the people that would have experience with competition-style gameplay aren't the ones that are chosen to lead game design. It's one thing to say "we want a lively online community" and another to actually spend money and effort finding a designer that can do that well. There's a rich discussion there but I'll skip it for now.

Because my point is: the complexity of these games is usually the intricate ways in which a small set of game rules combine.

Could you turn a sim into something players would spend a thousand hours playing? How long could you play Roller Coaster Tycoon before you exhausted the whole game? Do you think you could convince a million players to each put a thousand hours into it? These games (on the PC) are lucky to sell a million copies. Most of those players might put less than a dozen hours in.

What would it take to make a sim or puzzle game that players spend that much time on? It feels silly to even think it's possible, since one hundred hours is a stretch for these games. Maybe there's some diehard fanatics that put that much time in (the Transport Tycoon community is one such example), but that's a tiny community. That's maybe a thousand players - not a million. I'd like to explore this idea further... and indeed I do in this followup post on the thousand-hour sim.

Platformers - Fake Opponents

Platformers have opponents, but they aren't anything like human players. Enemies such as the goombas in Mario follow very rigid rules. They don't even try to behave like human players. That's not the point; these are effectively puzzle games where part of the puzzle is an AI-controlled "humanoid" character with simplistic, predictable rules.

Usually there's not a lot of richness to these games. They're exploration and achievement games, with a little bit of skill thrown in. Gameplay is fun, but that's driven in part by the environments, not the opponents. The human (or sentient) appearance of the opponents just fills out the game world; makes it seem like a real place and less like an abstraction.

Recent Mario games (such as Mario Galaxy) do wind up being somewhat rich, but not too much. Most of the richness is in carefully timed execution of special moves. In other words, they are skill games. Puzzles are straightforward, the interactions of gameplay elements are rare, and the focus of the game is more on exploration than anything else.

Head-to-Head Action and Strategy Games

Whereas there's no real "opponent" in puzzle or sim games, and simplified opponents in platformers, other action games have real humans as the opponent. RTS games like Starcraft and FPS games like Counter-Strike fit this model. Even when you're playing against the AI, that AI is trying to act as human as possible.

Both you and your opponent have the same range of abilities. Chess is a simplified version of this model, where both players have exactly the same units at their disposal. FPS games are similar; often skill games (see above), but the richness in the game comes from the fact that the opponent is truly human and so not only has a huge bag of tricks but can also learn new tricks as time goes on.

RTS games rely heavily on the humanness of your opponent, but they often twist gameplay by allowing players to choose different "races." Starcraft is the standout in this model. Most Starcraft games are played by players of different races; Terran, Zerg, or Protoss. They are all basically doing the same thing - placing buildings, recruiting soldiers and ships, and sending them off to attack. Yet the units that they have are different, and their overall approach to winning is different as well.

The richness in FPS games comes primarily from the human opponent. The fine balance of rules can make the game more or less balanced; more or less random. Yet it's the humans that make them great.

RTS games, however, add much more. There's a lot more strategy to RTS games. Choices made early - not just single actions, but choices to develop in one way or another - define the game. Do you try to tech up? Rush? Expand early? Press to aerial units? Fake one build but go another way? Where FPS games often have rich tactical fights, RTS games also have strategic fights.

RPGs

RPGs are a bit like RTS games, in that you are facing human-like opponents with skills and actions similar to your own, but with a different strategic twist. In Starcraft you have Protoss vs Zerg, in WoW you'll have a Rogue against a Warlock.

Humans provide the richest opponents. Some are better than others; in RPGs, you might face someone that doesn't know their class very well at all. But most of those that engage in PvP know what they're doing. Competition ladders help great players find similar opponents, while allowing the crappy players a chance to win every know and again against other new (or... well, crappy) players.

RPGs add more to the single-player experience, however, by having a much longer stretch of new abilities. In an RTS, you'll become familiar with all of the units and buildings at your disposal over the 30 hours or so in the single-player campaign. In an MMORPG, there can be hundreds of hours of advancement before you've gotten to the top of the ability tree, learning new spells or abilities every few levels.

Instead of giving you a small set of tools with rich interactions, like chess, RPGs have a much larger set of tools, each with its own special purpose. The trick isn't to learn how the abilities interact, but usually which ability to use when; how to fight against certain types of opponents. The huge array of possible opponents is what makes the RPG rich.

Human-like Opponents with Different Tactical and Strategic Choices

My goal here was to explore the game design choices that produce a game that players could enjoy for hundreds of hours. Leaving aside the diehard fanatics that might stick to their favorite title long past when the majority of the market has gotten bored, we're left with three major avenues.

The first approach is to build a game that requires player skill, whether solo or competitive. Players spend their time getting better at those skills. Games like Counter-Strike and Tetris are the best examples, but even then they point out the weakness: although both have audiences larger than (say) Transport Tycoon, these are still relatively niche titles. Lots of people love them and (relatively) lots put in over a hundred hours playing the game, but there are bigger genres out there.

The second approach is to create simple mechanics with extremely complex interactions. Chess is the canonical example. Players have a chance to learn ever more complex interactions. Every time they play, they probably learn another new trick. The success of this genre depends on the size of the market, however. There can't be hundred of Chess-like games, because the complexity of interaction depends on the size of the market. Not everyone has the talent to be a grandmaster, and in order to even get grandmasters, you need enough people to push the curve that far.

The third approach is pitting player versus player. Whether you've got a skill-based game, one with simple rules but complex interactions, or complex rules, pitting humans against each other means that rich gameplay will evolve. You'll either need to do a whole lot of playtesting and balancing or be willing to tune the game after it ships, but with PvP, humans will figure out complex strategies.

Personally, I think the two richest game genres are the RTS and the RPG. The best, longest-lived games in both genres have PvP (sometimes simulated), complex gameplay interactions, and a measure of player skill. If you want to create a game that pulls in players for hundreds of paid hours, you'll need more than one of the approaches.

Most Awesomest Game Genre Ever

2010-06-09T14:11:00.000-07:00

WoW is tremendously popular, and it's easy to see why. One can play solo, so you don't have to wait for your friends to show up or get online. Your accomplishments can be witnessed by a wide variety of players, so the game's achievements are very rewarding. Team encounters give players a chance to show their team spirit & coordination. It has a ton of content and actually has an end-game, so you can play forever. It's very approachable, unlike many other MMOs.

But it's also the most awesomest game genre ever.

A friend an I were brainstorming game ideas for the iPhone, and I spent some time after that going through a bunch of game ideas, fleshing them out, and thinking about how to make the game more appealing. At the pinnacle of game development is something like an MMORGP, which requires complex technology, precision game design, and tons of content. But more than that, there are elements to the design of WoW that place, in my mind, the fantasy MMO as the ideal genre.

I tried to think of ways to design a game that was smaller than an MMO that had many of the same benefits. In the process, I came up with a whole bunch of factors that make the fantasy MMORPG genre appealing.

Environment Variety

Games like Tetris take place in one screen. It's a skill game, like many sports and first-person-shooters, and so that doesn't matter that much - but it's just one screen. Achievement and exploration games tend to have a lot of environment variety, and it's one of the driving forces behind platformer design (as I love to mention). Give the player a new environment every 15 minutes!

A Tale in the Desert (ATITD) is an interesting game for many reasons. It's an MMO but the environment is very dry. It's 99% desert. 99% boring, flat, monochromatic fucking desert. It's a great exercise to play the game and see how one can take one environment type (hint: desert) and make landmarks and environments that feel different. Yet the exercise reminds me of the pointless toy problems and artificial domains I studied in school. It might be an interesting exercise but it has little practical value.

Take a look at WoW: every zone isn't just yet another area using the same brown and desaturated green color palette; they're very different. It's not just forest, mountain, plain. The forests are hugely varied -- from the dark, Halloween-ish Darkshore to the mystical Ashenvale Forest to diseased Felwood and Plaguelands. Feralas feels kind of generic - but I had to hunt around for an exception. Elwynn Forest is an ideal example - a larger-than-life fantasy setting. You can't mistake Grizzly Hills for any of these other areas, and Silverpine, although sharing the same kind of haunted feel as Darkshore, is obviously distinct too.

Coming up with different environments is easy; making them look good is hard. Getting the art assets is expensive. But it adds a huge amount to the game. Where ATITD is able to take "desert" and vary it, WoW does the same thing -- within each zone. But then it adds another 50 zone types! Like console platformers, there's always some neat new zone to go explore.

First-person shooters like Doom have a hard time coming up with different environments; they're all variations on the "near-future industrial/research building" theme. But put people outdoors and the variety explodes.

I guess it doesn't need to be that way. You could make an FPS that takes place all indoors and still has the variety that WoW does, but you'd have to try for it. That's kind of my point with this post - I think games are better when they have these qualities. Half Life, as fun and varied as it was, was stuck with being realistic. Which means that there's not much variation between levels. City Level 1 looks just like City Level 2. You could throw Viking Village and Alien City and Native American Pueblo in there, but it loses its believability. Fantasy games like WoW have a huge variety in environments that's enabled by the willingness to say "forget realism, we want cool environments." Like Mario platformers, WoW throws away foolish adherence to realism in the name of fun.

Tangible Environment

But zones aren't just different - they're also meaningful to humans. What's space but a bunch of rocks, stars, and the occasional planet? You can make varied star backgrounds and different-looking planets, but they feel like meaningless decoration. Earth means something to us. Running around on the ground is meaningful. Even the abstract game world of 1980s arcade games took to this: Donkey Kong takes place in a factory (and/or construction site) - it feels like a place. It's not just naked gameplay, it's a part of a world.

I was thinking of bringing up games like chess here, but then I thought: Abstract games tend to be skill games. Either your game is about the gameplay mechanisms themselves, like chess or first-person shooters or sports, or it's a game that puts the player into an avatar and says, "go play in this world!" In that case, the world itself is one of your characters and it needs to be interesting!

I think that's one of the reasons why "space" and "sci-fi" are considered niche genres for games. You can make starfields and tetris blocks look different and varied, but they don't mean anything human to us. They don't resonate with everyday experience. We can perceive the subtlest changes in human faces because that's how we evolved; give us a bunch of subtly-different alien faces and the distinctions aren't noticed. The work that you put into it is wasted. They all look the same to us.

Lesson: Familiar environments can be rich. Novel, alien environments are cool because they're new, but you can't take that very far. Because they're just new; they don't make sense to us.

Gameplay

Same games have rich gameplay, some are like slot machines. I bitched a few days ago about browser games (especially the popular Facebook games) and how they're basically slot machines. What gameplay? Click click click, win a random prize! Compared to RPGs, there's no mechanism, no learning, to strategy. Strategy makes for a richer game.

Some people have addictive personalities. Give them a slot machine and sell them rolls of tokens and you can keep them occupied and make a lot of money. I don't think you're really making those sorts of people happy; you're just feeding off of their addiction. Encouraging that addiction. I think many people hate their addictions - but they're still addicted. Intellectually, they want to quit smoking, stop gambling, but they feel compelled.

To me the more interesting challenge, and the more rewarding pursuit, is making compelling games, not compelling slot machines.

If you want rich gameplay, WoW has it. The core gameplay element is combat but each class has its own take on it, and that take changes as the character levels up and specializes. The addition of mechanics like fleeing, rooting, rage, and combos add to MMORPG staples like aggro, pets, and mana burn. I'm not sure if there's any novel mechanic in WoW (one could take the Lorite approach here) but it does have the kitchen sink. Action games - including platformers - work with a far smaller set of gameplay mechanics. An MMO means hundreds (or thousands) of hours of gameplay, and that means an extremely rich set of mechanics.

Opponent Complexity

One of the things that started me thinking about this post was, how can I make a crafting-based MMO like ATITD? Crafting in WoW is "click a button and wait 20 seconds," but ATITD and Puzzle Pirates are two games that turn "crafting" into much more.

But there's no "opponent" in these games. The combat mechanism of RPGs is rich not just because of the variety of options that the player has, but because you pit those mechanisms against a parallel set - everything that the enemy can do. WoW players have to worry about enemy casters, archers, and fighters; melee opponents with quick attacks (hard to cast long spells!) and those with big, slow attacks; abilities like fleeing and calling for help; healers and high-DPS dudes. Multiple opponents. Not knowing what "class" an opponent is until you're in combat.

How do you make a crafting game like that? WoW combat isn't just a minigame - it's huge. And part of that is that it's set up like a competition; it's not just X choices versus a random-number-generator; it's your X against his X. This is definitely something I'd like to explore more, but for now I just want to throw out there:

Whereas most games have X options, RPGs are X squared.

Opponent Personality

Not only does your opponent have a range of actions he can choose, but he also has personality. Who here hates murlocs? Raise your hands!

There's casters and healers, crocs and raptors, those pesky crocolisks and the goofy owlbeasts. Evil trolls and neutral zhevras that will be happy to ignore you if you ignore them. They each have their own attacks, idle animations, and deaths. It's not "simple combat opponents 1 through 47", they have shapes & sounds & animations. They have personality.

How can you do that with, say, a blacksmithing minigame?

Many other game genres do have opponents with personality, though. Action games from platformers to first-person shooters give you different opponents. Even shoot-em-ups like Galaga give you varied opponents. So this trait - opponent personality - isn't exclusive to Fantasy MMORPGs, but it is one thing that makes it a richer game genre.

Solo & Group Gameplay

I think good browser games are team games. Travian, for example, has a good bit of solo gameplay, but it's really a team game, and I think it's all the richer for that.

Skill games have both. One typically works on their own skills but measures themself against other players, either playing directly against other players or in parallel with them. FPS games tend to be against human or human-like opponents, including team variants like Counter Strike and Rainbow Six. I think those team variants are the richest.

And that's one thing that makes Fantasy MMORPGs a great genre - solo gameplay, so players can play whenever they want, but also rich, team-based objectives that they pursue with their friends.

Inspiration

I talked about inspiration a few days ago. Many games have it, and I think it's an important component. MMOs, though, have a great built-in mechanism for adding it. They don't all do a good job of it, but the opportunity is there; a low-hanging fruit.

Open End-Game

I've talked about how good games are entertainment that's powerful enough that players are willing to pay for it. I think there's a 1:1 correlation between profit and fun. (Addiction games would be an exception to this rule.)

Open-ended games are a huge profit center. Once you get a player to try your game, you can continue drawing revenue from them for years. Any game or sport that players enjoy going back to means a huge potential revenue stream. There's tons of tennis racquets, climbing shoes, skis, and other sports gear available and tons sell each year. WoW pulls in 9 figures every month.

Compare this to a console platformer. The player spends $60 and gets fifteen hours of gameplay. Kind of expensive (hence the huge aftermarket for used games), but cheaper than going out to the movies. It definitely keeps a lot of game development studios alive.

But with a long gameplay curve and a chance for play to continue for hundreds of hours, MMOs are like sports - in that players continue investing money in playing, year after year. A customer isn't a one-of-thing; you aren't selling a one-size-fits-all product. Some players pay their $60 and leave, others pay $15 a month for years. With microtransactions, some MMOs pull in over $1000 a year from certain players. That's the sort of market depth that sporting-goods retailers have: the people that really love your game can give you more than just $5 in profit! And they're paying all that extra money because they love your product; because you have an end-game, and one that's constantly being extended and improved.

Summary

WoW is the most lucrative computer game of all time. I think a lot of that has to do with the type of game it is - a fantasy MMORPG.

Stick an MMORPG in space and the opponents and environments get dull. Sure, Eve is doing well, but it's not doing 9 figures monthly. A game like Eve has, I think, a better opportunity of pulling in more revenue via microtransaction-like addons, but ... well, space is boring.

An MMO means team gameplay, inspiration from elder players, and socialization. You don't get a community for a game like Tetris.

And RPGs bring huge amounts of possible gameplay. I didn't even get into various metagames, like loot and set collections.

I think we, as game designers, can learn to make our non-FMMORPG games richer by looking at games like this, and seeing what richness we can pull from it to put into our own projects.

The Purpose of Games

2010-06-04T12:16:00.000-07:00

What's the point of any game? Entertainment. We do it because it's fun and/or rewarding. I've talked about happiness as the achievement of value - that's reward. In that same point, I talked about fun.
Purpose

But what's the point? What's the purpose of games? What does it all mean?

Nothing. There is no point. Games are entertainment. You can play with friends and enjoy socializing, make new friends, that kind of stuff -- but games are an end in themselves. They're entertainment; that's what entertainment means.

Even sports are just entertainment.Will a high free-throw percentage help you avoid car accidents? Pay for your kids' college education? They can improve fitness, but a half hour in the gym with a high-intensity or Tabeta-protocol workout will have the same effect. Sports are entertainment, too.

What's the purpose of life?

Is it to knock some chick up then spend your days slaving away to feed her and the kids, make sure the kid doesn't die before you kick him out of the house and go back to what you were doing (and enjoying) before the kid came along? Is your purpose to produce more and more humans until the planet can't support them any longer? (Never mind the argument that it can't support us now.) Is your entire purpose in life to invent for yourself a purpose and then proclaim to your neighbors how totally awesome you are for inventing that purpose? Are you here merely to serve as a guardian and provider for others, a slave to their whims and desires? Does it matter that you're genetically related to them? If so, are you saying that adoption and orphanages are evil? If not, does it matter if you were the one that knocked up the chick or if it was the UPS guy?

Or are kids fun and rewarding? In which case, you knocked up that chick because it was fun not because you had a grand purpose in mind.

Is your purpose "to make the world a better place"? For whom? Your neighbors? People with the same skin color? People born in your state? What arbitrary subgroup of humans are you 'obligated' to provide for? Are you just saying that because you want to believe that you have a purpose and haven't discovered any of the arguments that suggest that you should find your own purpose?

The easy answer is "all of the above." That's a cop-out. That's saying that you don't want to choose a purpose; you'd rather just stumble into one.

Games

Oh, right. Games. I was talking about games.

Games are entertainment. We play them because they're fun and rewarding. Good games are fun and rewarding. Bad games aren't fun or rewarding.

Bad games are like work. They make you do stuff you don't want to do - like set your alarm for the middle of the night so that you can help your team defeat an enemy. If you don't buy into the goal at the end, then the whole process loses meaning.

Many games (and sports) are fun because we learn a skill; we get better at the game. Many people like that learning process. Others like it when the other guy loses; some like it when their performance gets better.

Some of the most fun I had playing first-person shooters was playing a heads-up competition against a guy that was way better than me. I was losing but I was learning. I could see myself every day getting better. That was a real rush. Some people can't stand losing; their goal is to win. They don't want to get better, they don't want to be a good player - they just want to win.

This comes from ego. How do you define yourself? Is it important to you that other people say that you are right? Or would you rather be right? Many times, people that feel that they are without power in their lives, without control over their own lives, seek an outlet where they can exert power and control over others. Some of those people become abusive cops or angry security guards; the rest cheat in online games to crush their enemies. They don't want to be good, they don't want to win - they want to crush.

Where does the desire for power and control come from? I'd posit it comes from having an imbalanced life. Many people have imbalanced lives. American high school seems to be the epitome; hence all the teenage ratfucks in online games that want nothing more than to crush their opponents.

The rest of us grow up, find balance, and look for games that are fun and rewarding. We try to get better at games, look for opportunities to learn, and judge our mastery by how often we do win.

But Maybe...

It could be that the purpose of your life is only to serve as a warning to others.

http://www.despair.com/mis24x30prin.html

Players as Inspiration in Browser/Web Games

2010-05-28T10:25:00.000-07:00

I've talked about powerful players before, and about status (or score) as a game mechanic. Playing multiplayer browser-games recently got me thinking about the mechanic from a different light.

The Facebook games I played are built around having a persistent play-space (diorama) that you can customize, and then asking other players to stop by your space to do a little something that gives you (and them) some in-game benefit. This mechanic gives you an opportunity to see what other players have done with their space, and gives you a chance to show off what you've accomplished.

A Note on Dioramas

By 'diorama' I mean your farm in FarmVille, home island in TreasureIsle or Island Life, personal kingdom in Fantasy Kingdoms, and the like. Treasure Isle is probably the best example, because there is no gameplay there, whereas in most of the other games you need to build not just for aesthetics but game mechanics, too.

Artistic Ability

Building a nice-looking space is difficult. It requires some artistic talent, plus persistence to acquire the in-game tokens to build it the way you'd like. But the better and more complex the art assets, the easier it is to build a themed level. I remember some of the amazing hotels that people built with Roller Coaster Tycoon - which seems weird, but that game had very small elements; little boards of various colors. They were extremely flexible, which meant people could express a lot of creativity in building complex and interesting structures. Facebook games, on the other hand, deal with very large art assets with little flexibility. Your choice is basically what to put in each tile - which is a small bit of real estate. In RCT, one could stack tile on top of tile, creating layers and multi-storied buildings. Facebook games lack that.

Which means, actually, that it's easy to make a good-looking diorama in a facebook game - assuming you have access to the parts you want. Say, within a given game, there are several art themes, like architectural styles for buildings. Art deco, modern, classic, brownstone, castle, wooden - whatever. Building a themed level just means buying a bunch of items in the same style and then arranging them. This is a much lower artistic threshold than RCT; something almost everyone could do. Throw in a little bit of extra flexibility, and even average joe has a chance to build a cool-looking diorama.

But... that doesn't happen. The parts are grossly expensive. The only way to build a nice themed diorama is to play for a year, or drop $100 or more. Bleh?

Lego vs Duplo

One way to resolve this is to reserve the small, creative pieces for paying customers, and give the big, bulky, pretty-art but low-personal-creativity elements away for free. Give everyone Duplo blocks, and make them pay for the Lego. If they want to get fancy, they can pay for it. This can work because:

Inspiration

Others players are inspiration. When you go visit their play-space, if they've done something cool, you want to do it yourself. Some people thrive on an empty canvas, but I've found more people are inspired by seeing something cool and wanting to make something like it. It's the rare individual that wants to be given not just a blank canvas but a huge sack of tools to decide which tools to use. Give them acrylics and a bunch of landscape scenes and they might be inspired; charcoal and portraits, and they'll run off looking for a model. Show them a cool crafted item in Warcraft, and they'll want to be a crafter. Show them Ulduar loot and they'll want to go raiding. Show them a bunch of Lego spaceships, and they'll want to buy some pieces and build their own.

It's also motivation for them to work on their own dioramas / loot / whatever. Not only is it inspiring to see something awesome created by a friend (or even a stranger), but it can be motivation for them to put pen to paper themselves - or to play the game more.

Profit

And that's where we come in. We game developers give them the tools.

The model I've seen so far in Facebook games is to charge for the "cool" Duplo blocks, but to only provide (say) red and blue blocks, and only in a few weird sizes. I don't have the flexibility to be really expressive, but I also don't have access to enough blocks to build a single theme. If I could put together a skeleton of a cool diorama, I might be tempted to pay for the really cool bits that will make it distinctive. If the option is "pay or don't be cool," then ... well, do I even want to keep playing this game? What's the point of playing a slot machine if it doesn't give any prizes?

Fancy ads can draw players into your game, but so can user-created content. If your game already has some amount of user-created content, providing the tools to make it easier for that content to be inspirational improves user fun and thereby developer profit.

Ranting Conclusion

I wish I could play with my diorama. I want to build a piratey hideout in Treasure Isle, but (1) I've got to play for another six months maybe, (2) spend $100 buying the parts, and (3) I don't really have access to the parts I want anyway. Fuck that. Plus the game is a slot machine.

I really want that game to (A) have some measure of strategy to the play so that playing it isn't a grind, (B) give me the option of pursuing the parts I want, eg digging in Pirate islands for Pirate goods, (C) and gave me basic stuff for free, so that I'm not stuck with an empty island for months.

Things I Hate About Web Games

2010-05-27T14:29:00.000-07:00

I'm coding again, and somehow that also means doing "research" - playing new games for a bit. A friend suggested I check out Lord of Ultima, since I like Ultima and also played Travian for a year. I also wound up playing some Facebook games, and checking out some of the other online, browser-based RTS games, including Ikariam and Nile Online. I've played Evony before, and I checked into a few other real-time strategy multiplayer browser-based games, like NationStates and Monopoly City Streets.

I've got a few major complaints against these games. The time element tends to suck in these games. The facebook games are spam-based. Help and tutorials tend to be abysmal, and goals are rarely well defined. Tack on some obsessive play-to-pay rules and I don't wonder that they're not all making bank.

Time Element

The worst sin is the time element; you can't log in and play. Log in, hang out for a bit, watch, scroll around the map, contemplate your navel - then 10 minutes later you make a move. Great! Now wait another 10 minutes before you can move again. Most people play games because they want to play games; stuff like Lord of Ultima and Travian both are centered around a mechanic where you can't make any moves for hours. I'm on my fourth day of LoU and I have to tell myself not to play, because it's a waste of time. Come back in three hours.

Nile Online does this a bit worse, because the first thing you do is stare at the map trying to figure out wtf is going on. I'll get to that later, but when you finally do read the primer, it's basically "click some stuff for about 3-4 minutes, then go get caffeine. Come back in 20 minutes cuz you won't be able to do shit for 20 minutes." You read about it, looks like fun, sign up, play for 5 minutes -- then you're done. Quit. Go do something else now, please!

They like to compare themselves to a garden or other sort of tend-it-here-and-there activity. But if you wanted to, you could go out to your garden and weed & plant & water & fertilize & fence for hours, for a whole day. And if you run out of stuff, it's easy to leave for a day, because it's not a game. You can't really tend a real garden every 10 minutes, but these virtual gardens want you to do just that. Games are fun, and can be addictive - but an addiction that you can't feed is lame. Stupid. Why do you make me hate you?

The thing to do is to log in and chat with your buddies, possibly spending your evenings chatting - while occasionally making a move or two. That's what I did in Travian, and that game did tons of things right to make such socializing possible. Coordinating with other players is a big part of the game, and it's easy to make friends there. The stuff you have to do can be done in batches, once or twice a day, so it's easy to log in and putter around for a couple hours, chatting while you wait. Raiding, especially, is something that you can kind-of-actively do: send out some raids, wait twenty minutes for them to come back and chat while you wait. Poke around your other villages.

It sucks if you're lonely. One thing WoW did very right was to allow solo gameplay. Want to log in and play for a bit? Sure! There's quests, farming, crafting, the auction house - tons of stuff to do. If you're not max level, questing solo is cake! The game is made for it. These browser-based games? Bzz! Sorry, you're not wanted! Give your money to someone else, please.

spam

Facebook games are a bit better in the time-wasting department. They can be played in 20-30 minute chunks, then you run out of energy or mana or whatever. That's a great model; 20-30 minutes of constant fun, no waiting, and then a clear indicator that I should go do something else for four hours.

Nile Online was offensive with its 5 minutes of initial gameplay. After playing it for a week, I'm a bit more at ease with the 5-minutes-here, 5-minutes-there model, but it's not really a game. It feels like the tend-me-occasionally garden that it wants to be - but it's not really a garden. Guh. I'm not really drawn into that gameplay model. Maybe you'd like it, there's others out there that seem to like it, but I think my time with that game is over. Not my cup of tea, but at least I'm not saying it's a cup of piss.

Anyway, back to spam.

The big downside to the facebook games is that they're asking me to spam all my friends with a half-dozen or more posts in my 30-minute play session. Optimum play requires being one of those boring jerks that spams all their friends with crap. And I'm not going to be that guy; most of my facebook friends don't play these games. I'm not going to crap on their wall with what are, effectively, ads. Multiple times a day. In sets of 5+ posts.

Which doesn't address the fact that all of the facebook games I've tried so far are slot machines. I ranted a bit about that when I talked about designing fun, so I'll leave it alone for today. A slot machine that asks me to piss off my friends? Fuck you.

Help and Tutorials

Mostly these games seem to be built by companies that get the idea to clone someone else's popular game, shove it out the door, then start collecting money. Game design? We've got artists to make the pixels, that's game design, right?

Tutorials are essential in complex games. They're a way of taking what can be a forbidding mess and make it appealing to new players. Another alternative is to start with a simple, obvious game and gradually add complexity to it. One of my favorite city-building games, the Settlers series, does this great. It's the gameplan for PC-based RTS games: start the player off with a few tools, let him learn to use them through the play of a scenario, then add another tool or two in the second scenario. Somehow the makers of all these browser-games never learned that lesson, or didn't bother to apply it. They throw every single tool at you in the first five minutes. Confusing = lost = bored = quit = zero revenue. Negative revenue, after including the costs of hosting that player's little play session.

Nile Online has a Primer, not an in-game tutorial. It got me started, but it didn't mention the heart of the game: upgrade stuff, balance your workers, and upgrade your palace to get more workers. That's its core gameplay. Yeah, sure, you eventually choose a specialty good and make your mark in the world that way - but that's not what you do.

Games should explain what you do as well as what you strive for. They tend, generally, to put the shine on the game's goals, how the game can be fun, but don't teach players how to play the game. That's a great way to lose players! Someone went through the work and commitment to try your game out, create an account, and start playing - keep them playing! Show them the light!

Some of the games do have good tutorials, not all are necessarily bad. The worst documentation is reserved for the goals (see next section), but I wanted to split that out so I could talk about it more. Travian, Lord of Ultima, and Ikeriam all have decent tutorial/quest chains that get you started. They don't tell you where you're going, but they do tell you how to look busy.

Goals

Some games define their goals well (like Nile Online), others have good tutorials. The most popular games, though, feel like time-wasters because they don't explain their goals. Lord of Ultima seems to be grossly negligent in this way, mostly because it doesn't actually have a goal. The "goal", if any, is to "win" the game - apparently by being Rank 1 when it ends. Maybe it doesn't end? Maybe the server keeps going? Who knows? They apparently don't. So why are you playing?

"To have fun!" Ugh. These aren't games, they're toys - but competitive toys. Someone can come into your sandbox and kick over all your castles. That's one reason why people hate Travian and quit. It markets itself as a sort of multiplayer sim-city, but that's not what it is at all. That's a fucking lie. It's a competitive game. The goal is to help your alliance build up enough members, cities, armies, and allies to grab some plans, build a world wonder, and defend it against the other alliances. It's a team game! It's a fun team game! (One that just happens to have really bad time-demand issues.) Travian really should push what it's about. It doesn't. It does something really well, and they should brag about it. That's what I mean by goals: tell everybody what they're goal is! Tell them how they, too, can be great!

"Do whatever you want!" I don't want to do whatever. I'm looking for a game - something with a goal, a way to win. What's your way to win? Nile Online does this somewhat well; it doesn't have a "win" condition per se, but it does lay out the promise of being a notable player. Everyone it the game has their own specialty; everyone can be special. That's a great promise, especially since everyone wants to be special and well-known.

To be clear: I'm saying it's a bad thing to refuse to specify goals. There's games, then there's toys - sandboxes. Trying to do both tends to piss off players; doing both well is extremely difficult, such that I seriously recommend not trying. Especially if you're gonna half-ass your way through the design process. Lord of Ultima is kinda bizarre in this respect, until you figure out what must have happened. Some suit must have said "Travian is popular, Ultima is IP that we want to make money from, throw a bunch of money at this!" They then refused to hire an experienced designer (or to listen to the one they hired) and built a pile of shit.

Play-to-pay

The idea of microtransactions is to give players some cool little doodad that they can buy with just a wee bit of money. Make it optional, so that people can still play your game for free (or cheap), but allow the guys willing to spend money a chance to set themselves apart.

Travian does this well. For about $5 a month, you can double your monthly growth. You only buy a small percent increase in production, but because the game basically runs on compounded growth, a small percent each day translates into integer multiples in strength each month. But if you don't pay, you can still contribute to your team's success. Plus, by spending a bit more over that, you can jump around a bunch of other restrictions.

The last is probably the worst microtransaction model. You don't want to make gameplay annoying, and then offer to make it less annoying for a small fee. The correct response by a player to that offer is "fuck you, I'm gonna go play a different game." This is one reason why WoW has gradually reduced the level when you get horses. Travel is a pain in WoW. At low levels, it doesn't matter too much because everything you do is right there. But at some point, you have "enough to do" in the game world that you want to travel further - and getting there by foot sucks.

But browser games often commit worse microtransaction sins. The thing you buy with money is the actual game itself. The facebook games I've tried are all like this. The game that you play for free is a slot machine version of Progress Quest: pull the handle, get your chips, and brag to all you friends about how many times you pulled the handle. (WoW is kinda this game, in that you get to brag about your level, but there's strategy to killing mobs; it's not just a button-press.)

Alternately, a player can spend $50 and get a sandcastle where they can build a cool little diorama to show to their friends! Now that sounds like fun. Give me some cool diorama parts, let me find (or better yet, quest for) some rare parts, and let me create something cool. Plus, show me other people's cool dioramas, so that I can be encouraged and inspired to create my own!

but wait! You gotta pay for that!

Ugh. It's bait-n-switch. It looks like a treasure-hunting game, or a farm sim, or somesuch - but it's actually a very expensive dollhouse. Why not just get rid of the slot machine? Or, better yet, let me choose to go questing for the parts I want? And replace the 'slot machine' with something that requires strategy?

-conclusion-

Yeah, in conclusion: that last paragraph. I don't mind microtransactions. Some games, I am willing to pay a bit to be stronger, to get something cool. Others are diversions I don't enjoy enough to pay for - which really means they're sucky games.

A cool browser game would be one that's (1) not a slot machine, but requires some strategy in its play, (2) allows players to specialize the way in which they're awesome, and (3) lets me play in meaty chunks. Tell me (4) how to play, and (5) what my goal is.

Game audiences are a stochastic thing. Some people are willing to pay for the diorama. Others get caught up in building their little world and don't mind paying a bit extra for it. Others have addictive personalities and get sucked in by slot machines. And others are too stupid to realize that there are better games out there.

Like WoW. Bye, Treasure Isle / Lord of Ultima / Nile Online, time for me to start getting ready for Cataclysm.

Game Design: Fun Challenges

2010-05-25T13:49:00.000-07:00

Fun & Happiness
Happiness is the emotion resulting from the achievement (or preservation) of values. Accomplishing something you don't value doesn't feel rewarding. Players are happy when they achieve something meaningful. That could be game-defined goals, player-defined goals, or even just learning.

What's the difference between fun and happiness? Grammar, for one: one "has fun" but "is happy". Does happiness come from having fun? Generally our culture views happiness as a longer-term thing, but I don't think that necessarily applies to game design -- I think players can achieve happiness from playing their game of choice. I also think that being happy isn't the same thing as having fun.

Fun is amazement, curiosity, bewilderment, happiness, laughter, vengeance, and a host of other emotions. I've talked about boring before: if you don't have anything to think about, you get bored. But being occupied isn't the same as fun. I remember working at a fast-food joint during rush hour. I didn't have time to get bored, but I wasn't having fun, either. Generally stuff that's safe (ie doesn't threaten any values) and produces a non-negative emotional response is fun. There was nothing emotional about slinging fries, but interacting with customers (especially the cute kind) was sometimes fun.

The two main groups of fun emotions are those responding to new stimuli, and those responding to positive values (happiness-related). Achieving a goal that you planned for and expected to win isn't as much fun as an unexpected victory; the emotion in the latter is stronger. I also think seeing new wonders - whether it's high-level gear or foes in Warcraft, or funky new buildings in SimCity or Travian - is stronger than happiness-related fun.

I've heard (and frequently repeated) that designers of platformers like to put players into new environments every 15 minutes. Warcraft follows a similar model (tho the time delta is hours not minutes), and RTSes and the like put players into new environments every 30-60 minutes. Players also like new games, new graphics, new expansions, etc. They want something new, because new is fun. These players are explorers, and I think it's the dominant type of players generally.

I love new stuff, new areas, exploring game mechanics, exploring the nooks and crannies of game worlds, new graphics, all that stuff - but I can also sit down and grind through some resource gathering. I turn that into a game: how quickly can I pave through this set of creatures and take their drops? How many can I kill in an hour? That's a self-created achievement goal. Some people are good at that, but most people aren't. I'm tempted to call it autistic-spectrum (the ability to focus on a narrow goal), but I actually think it's just a reframing skill.

This is achievement again. Many Asian MMOs are very grindy; players in that market are used to this type of reframing. They view the grind as an achievement path, and they can focus on maximizing their achievement performance. To them it's fun. American players, by contrast, tend to be the "fun fun fun" type that want distractions and new, shiny trinkets.

Difficulty, Perceived Difficulty, and Choice

If happiness comes from achieving meaningful value, then how does one quantify "meaningfulness?"

I think one really has to scrape the bottom of the barrel to get game challenges that aren't meaningful. It's a continuum, obviously, and I think it's related to perceived difficulty. Not actual difficulty; rather, how difficult the challenge is perceived to be by the player.

The Facebook games I've played are basically slot machines. There is no challenge; very little strategy. Do you dig in the open areas first, or go for the plants (which require more energy), or open up the gates (which require no energy and give some XP)? Ultimately you're gonna click every damn little grid square that you can. Whether you click them "smart" or not is maybe a 5% change in effectiveness. These games win on two fronts: the user can perceive some kind of magical ESP or mental brilliance in what they're doing, which is great for the vast majority of players that are fucking morons. (They play slot machines and farmville, after all.) And they get random rewards.

The two are really related. The human brain is wired to see patterns; we look for patterns, because they help us survive. Sights, sounds, tastes, smells, and even touch came into play for survival. Should I eat these berries, or wait til they change color? Does that sound mean a jungle cat is about to rip my spleen out, or is it just a harmless forest critter? Give a player a bunch of random stimulus and he'll think he sees patterns in it.

It requires a lot of discipline to avoid latching onto that perceived pattern - plus the experience to know that your brain plays these kinds of tricks, and that you need to do something other than sit there with your jaw slack and let the emotions roll across your brain. But that discipline is only useful when there's an actual pattern to be perceived. That is, in a slot-machine game, all the patterns you think you see will be fake. In Facebook games, there might be one real pattern in a hundred.

One might say "good games have real patterns for players to discover," but I'm not sure how much that's true. (It depends on what you mean by 'good' game, of course.) The facebook games are popular, even though they're just slot machines and epeen displays. I do think if you want people to pay money for your game that you need to get them to want it, to have some emotional pull to the game more than just what you get from a slot machine. (Though people do dump a lot of money both in casinos and facebook microtransactions.)

Facebook games have choice, but it's a shallow, meaningless choice. Even perceived difficulty is low.

I think perceived difficulty is better than actual difficulty. Games that are actually difficult can produce failure, and that leads to bad emotions. But without evil there can be no good: people value achievements that came with high cost. It's one of the reasons why hazing is still popular - paying dearly for something, even a gym membership, leads the human brain to bias more value.

Too many apparently difficult choices that are actually trivial can burn the player out to the point where they realize how pointless their choices are. I think I burned out of WoW once because of that. When a player realizes that all their clever strategizing was meaningless, they can shut off like a switch.

That marks your boundaries: make the difficulty too real and players give up in frustration; make it too much of a smokescreen and you risk players finding out and feeling like they've wasted their time on your game.

Challenge and Accomplishment

I want to say "the best games have some real challenge, some perceived difficulty, and reward players for making smart strategic choices." But what does best mean (i.e. on what scale)? Is this just my preferred game style? Am I just deluding myself into thinking I like challenge? I guess I'd rather be fooled into thinking I'm smart than be given a game that I can't figure out.

The point of making games is merely to feed our own values. The two major values are (1) money, and (2) the pleasure that comes from making others happy, or entertaining them. #1 is a measure of #2 - if players are entertained by your game, they'll pay you for it. The more fun and happiness they receive, the more money they'll give you. I don't think these values are separate, and it's one reason why I think discussions of "true" art and good games are pretentious and miss the point. Make a game that makes you money, and that's proof that you're making people happy.

You could make a slot machine. You could fool a bunch of ignorant rubes into thinking they're smart; give the ESP types a reason to believe in their magical powers; and amuse the easily-entertained.

Alternately, you could put some real challenge into your game. Give players choices that actually matter; where choosing wrong will mean failure. Make success cost a bit, so they value it, but not too costly to burn them. Make some choices look difficult when they're actually not. But most importantly, play with their emotions. Players want a roller-coaster ride. Give them both achievement and entertainment, and they'll give you their money.

Real Effects of Cowboy Programmers

2010-05-24T13:27:00.000-07:00

In my previous post, I talked about the perceived strengths and weaknesses of cowboy programmers. I described cowboy coders as isolated, shoot-from-the-hip, hardworking, and antiestablishmentarian.

Cowboy coders often write unreadable code. But it that a bad thing? When someone else needs to maintain the code, yes. When someone else needs to dig through an obtuse and confusing system to figure out which parts are the external interface, yes. When someone needs to look at a clunky, poorly-named set of interface methods, yes. But most often what cowboy coders have is unreadable implementations, which is mostly harmless. The output that matters most in team projects are (1) reliability, ie does it crash, (2) reasonable performance, ie as long as it's not abysmally slow, and (3) readable and understandable interfaces. If you know what a system does and the interface is clean, it doesn't matter what's going on under the hood. That's the whole point of encapsulation; hide the messy bits from outsiders.

Cowboy coders also rarely document. Yet this is a tenet of agile programming: code should be self-documenting. Parameter names, variable names, method names, class names -- all identifiers -- should describe what they are, semantically not syntactically. (This is one reason why I think hungarian notation is foolish; it focuses on something the compiler can do for you.) Variable names like "gc" and "q" and "theFileStruct" are horrible. If that's what any programmer on your team is doing, hit them with a stick. If their identifiers are well chosen, the external interfaces obvious, and the use of those interfaces clear, then again the lack of documentation is not a weakness.

Brilliant code rarely makes sense to other coders. Any brilliant person, scientist engineer artist or craftsman, is likely to be misunderstood. Not understanding them often isn't critical. In a team environment, the interface is what matters, and it's much easier to get a cowboy to make good interfaces than to try to force him to work like everyone else. He'll probably not do a good job, and the process will just piss the both of you off.

Loners can be brilliant cowboys or they could just be slackers. Be careful to not assume that someone that prefers isolation is actually getting something done. The best way to do this is to monitor checkins. Some good cowboys won't check in code for days, but when they do check something in their progress is obvious. Slackers might have the same lax check-in habits, but when they do finally commit what shows up is tiny. Slackers are a threat to your bottom line. Don't just tell them that you want them to check in more often; tell them that you're watching the volume of their check-ins. Slackers will either step it up and get work done, or find a way to quit or get fired. This is one of the important distinctions a manager needs to make about his employees - is he a cowboy, working diligently in the dark, or a slacker, surfing diligently in the dark?

Cowboys can also have an effect on the rest of your team. The best, brilliant cowboys might be reclusive but in my experience they haven't been anti-social. Slackers, on the other hand, are sometimes passive-aggressive or rude. Having a brilliant coder nearby is often an inspiration for the rest of the team; it makes them feel like they're someplace special. Beware of how the team views the cowboy. If the team respects the cowboy's brilliance, treating him like a misbehaving child can send a message to the rest of the team that you value conformity over performance - and that's what you'll get: a bunch of rule-nazis that do the minimum required and leave the building promptly at 5pm. This is the fine line of management: you want to give the cowboy room to do his thing without upsetting the rest of the team. Make sure the rules you impose aren't just to make you feel better; usually the purpose of a software team is to ship, not to measure code metrics. What matters are features and reliability. If you're getting those on a good timetable, be happy.

One of my favorite software-management stories is about a management intern that refused to fire a problem coder that was pissing off other employees, driving them to quit. When the intern finally went to his boss, the intern said the boss did the right thing: he fired the intern, not the problem coder. Your cowboys shouldn't be driving the rest of your team away.

Perceived Traits of Cowboy Coders

2010-05-20T16:12:00.000-07:00

"Cowboy Coders" shoot from the hip. They're lone wolves, programming heroes. They're respected for their work ethic, programming speed, and brilliance - but hated for their unreadable code, lack of standards, and arrogance.

There are many types of 'bad' programmers. The 'cowboy' label is used if the bad programmer has a high opinion of himself (deserved or not), ignores standards, and writes brilliant (if complex and unmaintainable) code. Cowboys aren't stupid, but they might be ignorant. They believe strongly in standards - but only their own. They rarely work well in teams, preferring to work alone. Many cowboys are also workaholics.

One of the perceived strengths of a cowboy coder is their ability to dive into tricky bugs, figure out what's going on (maybe spending all night working on it), and coming up with a complex and brilliant solution. Especially when a deadline is near.

One of the most hated traits of the cowboy is his habit of loudly disrespecting his fellows. This is one reason why cowboys work alone; they can't stand working with others, and others can't stand working with them.

But "Cowboy Coder" is a stereotype. Real people are rarely like that. It's fun to make up or read lists of programmer types, and "cowboy" is one of the stereotypes that I've heard the most. The qualities I've found distasteful in other coders are rarely like the perceived weaknesses of cowboys, and the strengths of good coders I've worked with are more complex that the "work hard" and "brilliant" attributes given to cowboys. Next time, I'll cover the strengths of weaknesses of cowboys that really matter in my next post.

Fun RPG Combat, Part 2

2010-04-24T15:44:00.000-07:00

In my previous post on making rpg combat fun, I talked about some high-level principles behind what's fun and what's not. This time, I delve into specifics.

Rogue-Like RPGs

Rogue-like games make combat fun by not telling you the mechanics. A lot of the 'fun' in a roguelike is learning the rules; what various creatures do, how useful your various abilities are, when you should run, when you should fold, etc etc. For people that like learning mechanics that way, roguelikes are a lot of fun. For people that skew more towards achievers on the Bartle scale, roguelikes can be frustrating. I think the success of WoW shows that there's tons of achievers out there. As an explorer, I like discovering mechanics -- but I also find Rogue-like games frustrating, I think in part because the fun bit of the mechanic is hidden. The game isn't really about discovering mechanics; it's about getting to the bottom of the dungeon and 'winning', which is an achievement. Ultimately, I think achievement is the strongest motivator. So let's leave rogue-likes behind.

Achievement RPGs

In achievement-oriented RPGs, players can have dozens or hundreds of hours of new abilities, creatures, and environments to explore. The fundamental mechanic of these games is always combat. Combat has to be fun, and they make it so by changing it up. Sometimes just cosmetically (with new environments and different-looking creatures), other times with new mechanics. New mechanics include new player abilities, new creature abilities, environmental restrictions (such as a pool of lava or spinning blades that one must avoid and might push an enemy into), and complications like adding a second creature to fight -- forcing the player to not just kill one target, but figure out how to juggle two targets. Mixing two types of targets together creates a huge explosion in the puzzle space. And when the player gains another dozen abilities, they might tackle that exact same mix of targets in an entirely new way.

It's easy to see why RPGs give players new abilities, and then pit them against enemies with ever-changing abilities, too. The game is combat, everything else is window dressing. Make combat interesting, and the player will suffer your bad dialog, predictable plots, and boring tradeskills. And if your abilities are balanced, bam, instant puzzle.

Power Trips

Another aspect of achievement games is the power trip. That's why games have levels. Not because the badge is 'good gameplay', or some sort of esoteric bullshit. But because, when you're level 20, you can go back to that level 1 orc and pound the shit out of him. The tough meany that killed you three times when you were level 19 becomes less of a challenge after you level up to 20. He's not really difficult at all any more, because you now know how the fight goes, plus you've got a little bit of extra hp, ac, and damage output. It feels like a challenge, because you're focused on the fight.

(That, btw, is the point I made in the previous post. If you're busy executing your combat plan, you don't have time to think about bad dialog or predictable plots. Keep the player focused on the combat puzzle, even if his chance of success is 99%, and he thinks it's challenging and fun.)

The Grind

RPGs can become boring if you're forced to 'grind.' But a grind is no different than any other part of the game; you're still in combat 90% of the time. But a grind is combat that isn't new. It's you against the exact same enemies you've fought before, with the exact same abilities. Neither you nor them have different powers. You've solved the puzzle, and now you're asked to solve it over and over again.

I usually got around that boring bit of grinding by focusing on a meta-issue. Not winning the combat itself, but winning faster. By figuring out a circuit through a dozen mobs that lets me kill them as fast as possible. By finding clusters of the mob that I need to kill so that I am not waiting for them to respawn, and I'm not wasting too much time travelling from one group to another. I was able to choose and pursue these goals myself; most players, I think, don't. If you can make that meta goal explicit, it might be one way of alleviating the grind.

The obvious solution, of course, is new abilities or cosmetics. Yet that's kind of the point here; sometimes, for some reason, players will want to go back and kill the same creature over and over again. Normally the game shepherds players into new areas. Some games (Lineage comes to mind here) fail at giving new abilities to either the player or his quarry. But most designers know that's a design that turns off a lot of players; they know that they need to give the player either a new ability, a new opponent, or at least new scenery in which to solve the same puzzle.

What happens when you can't? There is no solution, of course. It's more of a statement about the goals that the game has set up. In order to make money in World of Warcraft, I'd go kill elementals for hours. Usually I could only stand about an hour at a time, but I spent dozens of hours killing those creatures over and over again. Eventually, Blizzard figured out that players were grinding for cash. They solved this problem not by somehow making the grind more fun (my argument is that's impossible), but by adding ways to get cash that were both more efficient and more fun.

There's one other issue I'd like to talk about, an interaction between quests and combat that can make combat unfun.

Press the Button

Say you've got a quest to go collect 10 wolf pelts. Sure, ok, go kill wolves until you've got 10 pelts. You play the combat minigame, usually against a new creature, and have fun. Turn in your pelts, which is where the big XP is, and move on.

But what about the quests where the goal isn't to kill or collect drops, but do something completely different? Say you need to hit a button in the middle of a field, but there's a bunch of wolves there. Now the wolves are in your way. You can solve the puzzle of how to kill them, but it's not really your goal. A good designer can make 'press the button' into an interesting story, but ultimately the player wants the quest reward, not the quest text. The 'button' could be a gravestone they need to read, or an altar where they need to perform a ritual, or a dropped scroll that they need to pick up. Players think of these tasks as different and interesting, but fundamentally they're just pressing a button. Run over here, hover your mouse, and click. The game spits out some flavor text, but really it's just a button.

And many players skip quest text altogether, using add-ons to tell them what combat puzzle they need to go solve next.

Is it better to ask players to go kill 10 wolves? Or ask him to do something such that the player chooses to engage in combat because those wolves are effin annoying and keep interrupting him while he's trying to press the button? In the button case, the player might see combat as an annoyance. I remember many times in WoW where we had to go press some button, and I worked with group-mates to train the mobs out of there, or stealth through the encounter, or whatever, to avoid combat. Combat should have been the game, but I was inventing a new game to avoid it.

And I think that's the answer. Tell the player to kill "the five guards" then press the button, or give them mechanics to avoid combat altogether, so that they get the thrill of 'cleverly' avoiding combat. You want your players to have happy emotions, to think that they've achieved something tricky or clever. Give them the tools so that, however they're solving the quest, what they're engaging in is not clearing out an annoyance but positively engaging in a new puzzle.

see also: Bartle's book on designing virtual worlds

Menu State Management in Games

2010-04-19T15:41:00.000-07:00

I've written about high-level game state management before, but I didn't provide any direct code. I got a couple questions about this recently, so I decided to put a post together.

Menu management is a very clear example of the State pattern. Each different page in the menu is a different concrete subclass derived from a common State base class and managed by a Context. There's a few tricks that make this a bit easier.

For example, menus are often nested. This suggests using a Stack pattern for the context. I generally have a GameContext class that has Push, Pop, and Switch methods. They can either take a State subclass instance as a parameter, or some sort of identifier. I think this choice is 50-50; I don't have a clear preference for either one.

There's two ways of doing identifiers. Again, I don't have a clear preference here either. I tend to switch back & forth between these two solutions. (1) Add an ID in the class itself, e.g.

  public static const MainMenu::kMenuId = 'main';

This tends to be the less error-prone, although it does mean that you've got to add an extra #include (in C++), and whatever language you use it means another dependency. (2) Use a string constant. C++ compilers tend to tolerate four-character codes, ie

  Context.Switch( 'main' ); 

The downside is that if you change the identifiers or add a new menu or have a typo, you run the risk of the system blowing up at runtime. However you might choose to do the identifiers, you also need a way to register them with the Context, and that adds another layer of complexity. So your choice is: that complexity, or require any class that requests a menu state change to refer to the new menu class -- which can get messy itself. Meh? All coding is tradeoffs. Pick one. Whatever your feelings on Good and Proper Coding Practices, neither one has been proven to cause cancer in lab rats.

The Context itself also tends to be an instance of the Singleton pattern, with some public, global access. Pop, Push, and Switch might be static methods, for example; I find that means less code and complexity on the client side. (Never trust anyone using your class to be able to code their way out of a paper bag! Simpler interfaces are better.)

I usually start with a simple, copy-n-pasted examples of the different Menu classes. For example, they'll have their own Scenes for 3D objects and 2D UI bits. This is usually easier, faster, and more reliable than trying to develop the Most Awesomest Generic Menu Class Ever. The UI manager will take button clicks, and then call Context.Switch() or Pop() as needed, or Push() if the user hits the 'previous menu' button.

Game startup, then, will do stuff like initialize the 3D environment, game asset libraries, sound, etc, then start up the game state context and tell it which State to start with, which is often a CompanyLogoState. Usually I have game startup then call Context.Run, which does a simple loop of CurrentState.HandlePendingEvents, CurrentState.Draw, and CurrentState.Tick. There's some complexity there with handling events, being able to handle Push and Pop, updating the state at the right time, etc.

CompanyLogoState.Tick() will usually draw a 2D company logo, gradually brightening from black to white, holding, then back to black. When it gets to black, Tick() will call Context.Switch( GameTitleState.kStateId ), which pops the CompanyLogo off the stack and puts GameTitle in its place. That state does the same thing -- bring up the lights, so the title screen, then switch to the Main Menu state. Both the CompanyLogo and GameTitle states will move on to the next state if a key is pressed; that's done in their HandlePendingEvents() method. Eventually, one of the various Menu states (MainMenu, PlayGameMenu, LoadSavedGameMenu / StartNewGameMenu, etc etc) will need to actually start the game. That's cake: just have it call Context.Push( GameState.kMenuId ). And if the game needs to switch to a full-screen menu at some point, it can pause itself and push a new state onto the stack: Context.Push( SaveGameMenu.kMenuId ). Of course it will be important to plan out all of your various menus and states, and make sure you don't have any recursive loops.

Using this pattern, all of the various high-level states in the game are handled through the Context, which also does event handling and rendering. I've even once modified the process to work in a nested window as well - such as when you bring up the 'game menu' while a game is in progress, which doesn't back out into a full-screen menu but instead shows the game in the background, paused & faded.

As with any code, start simple. Copy n paste as needed. When you need more complexity, well-written code is easy to extend.

Repeat Until Rich

2010-03-27T18:52:00.000-07:00

Not really related to game design, programming, or software engineering, but I've found that this crowd also likes gambling -- specifically, the sort of gambling games that can actually be beaten.

Repeat Until Rich was recently published and is a well-written tale of one card counter's journey through that world. Josh Axelrod (the author) was part of a blackjack team in the team heyday 6-8 years ago. I enjoy these sorts of personal stories; they show the glamorous side of such potentially lucrative pursuits as well as their darker sides; the hard grind of card counting, for one. The movies make it look awesome, but in practice it's god-awful boring.

Adapter Pattern vs Proxy Pattern

2010-03-25T17:50:00.000-07:00

These are two similar patterns that both wrap an object (or set of objects) to expose slightly different behavior to a client object. As with the difference between Bridge and Strategy patterns, the difference between an Adapter and a Proxy is partly one of focus; which pattern you use does not necessarily change the structure of your solution, but the choice depends on how you approach the problem. Both patterns are wrappers, but you use the two patterns for very different reasons.

Some of the confusion that I've seen between these two patterns is one of nomenclature. I was talking to a friend today (hence the reason for this post) where he got into an argument with someone, and the basic cause of confusion was between the idea of a class (any class) as a 'proxy' for a data object and the Proxy pattern itself. As for the Adapter pattern and the verb 'adapt' -- well, every line of code is an adaptation, right? It's a pretty generic verb.

So: Most of the confusion is proxy vs Proxy. I'm using the latter, the capitalization, to indicate the Design Pattern.

Adapter

Common descriptions of the Adapter pattern tend to say that it's an extension of the Facade pattern to deal with polymorphism or to provide a specific interface. Yeah, that's nice. In practice, when I'm getting my hands dirty writing code, I use the Adapter pattern when I am approaching the problem from the client end - as the user of the class that's about to be adapted, not as the author of the library or utility class that winds up getting adapted.

Usually what happens is that I'm writing a bit of code and I start to implement an algorithm when I realize that I can use a certain library class to do the job instead. But the class I'm working in demands a certain interface! Rather than rewriting the algorithm using that interface, I instead glue the library class in. And that, really, is all that an Adapter is: it's an implementation of an interface that doesn't do any of the work itself -- it just passes the calls along to some other, existing class.

It retrospect, you can see that you have Adapted the library class to the new interface.

Proxy

Proxies, on the other hand, tend to do work. Real work. Usually I create a proxy knowing exactly what it is that I want to do. I need a client-side representation of a server object, or a class to represent some big, unwieldy system object that I'm really only going to provide some minor methods on (and hence don't need to instantiate the whole thing). My proxy looks like the real object, but only provides the methods needed locally -- and so only has the complexity to do that limited work.

Often Proxies are one-to-one wrappers; you'll have two classes to represent the object. One class (the non-proxy, usually written first) represents the underlying data, and the Proxy wraps that class to add some specific, narrow behavior.

A proxy might exist across a network connection; it might represent a view into a data object, or a partial instance of a large data file, or maybe it just provides some functions that would be expensive or complex to access directly. I often write proxies to do one simple thing to a more complex class. Instead of making some class more complex, the Proxy steps in.

Which is Which?

In some cases the distinction is obvious. In a client-server application, you might write a client Proxy for a server-side object. You might gate calls to a complex central system through a Proxy, which will provide transaction ordering or synchronous behavior or somesuch. If you need to shove Tab A into Slot B and a simple pass-through class will do, that's an Adapter.

But say you want to write a class to encapsulate OS-level calls to the file system. Is that an Adapter or a Proxy? It's pretty simple, like a pass-through, so it's an Adapter, right? But an object of that class is treated like the underlying object, so is it a Proxy for the actual file on disk?

This is one of the cases where normal pattern use breaks down. Such a class is both a proxy and an adapter. A file object is a proxy for the actual file, but the class itself adapts the OS library calls to your custom project/application/module.

And so it doesn't really matter what you call it. The confusion comes because 'proxy' can be used to refer to the pattern itself (in which a class does work to hide complexity or extract specific behavior) or to an object that represents some real data object. One might say that every data-object instance in your application is a proxy. The concept of proxy still holds independent of the jargon that us OO design-pattern wonks use. Any class can be a proxy - even an Adapter class.

But note that you wouldn't normally have a Proxy that 'adapts' to anything. The Proxy pattern might 'adapt' something, but if the class you write is an Adapter, it might be a proxy but it won't be a Proxy.

As I said above, when I write an Adapter, I know it; the problem in front of me is fairly clear: "I need to shove this old/library class into this custom interface." And when I write a Proxy, it's clear that I'm providing specific new behavior.

Loot and New Content

2009-10-27T13:32:00.001-07:00

Back in the Olden Days, when we had to walk to school in the snow, uphill both ways, the only way to get awesome loot in WoW was to run Molten Core. If you didn't have 36+ friends that were all well-geared, attentive, and competent, your only chance at purples was world drops and auction housing. You could run UBRS or Strat or Scholo if you wanted to, but there wasn't really much reason; there were some nice pieces in there but gear in MC was far better. Yet you couldn't progress in MC but once a week, and you needed to be well-geared, attentive, and competent yourself.

Nowadays, loot is cake. All you need in 9 friends, and there's no trash to fight through so you don't even need a multi-hour commitment.

Better

Is the current system better? Well, what does 'better' mean? It's easier to get loot. You don't need the social structure now that was needed then. 10-mans are easier to organize than 40-mans, it's harder for a player to go AFK, it's easier to get into a guild that has 10 people that can raid on the same night at the same time, and more. The barrier to loot is lower, in that more people will be able to get this group together. Is that better?

You don't need to progress through MC then BWL then AQ20 to get to AQ40; now, run some heroics, build up some purples, then jump into a 10-man ToC group. Or, heck, some heroic 5-mans drop competitive purples. A new 10-man guild can move on to 10-man ToC fairly quickly, and then find a 25-man PUG. The time between hitting end-level and raiding the final dungeon is much lower. Is that better?

One of the reasons that initiation rituals remain in fraternities is that it makes admission to the group that much harder and stressful. We value that which was difficult to obtain. Downing Ragnaros was a serious effin task, especially before BWL was released. It was a badge of honor.

Where is that badge now? Is that relevant? Compared to 2005, nowadays many more people are seeing more content and improving their gear, without getting frustrated by organizational hurdles. Because more people get there, it's less exclusive.

Who Cares?

It doesn't seem to matter. If more people are getting more phat lewt, they're happier and having more fun. I might complain about more people reaching the "elite" end-game ranks -- but there's still a time factor. What distinguishes the top elite from the next group is when they achieved the rank, not if they got to that final boss.

I've talked to players doing 10-man normal ToC and they consider themselves up in the elite. They're very happy with their progression. They know they're not doing hard-mode, much less the 25-man version, but that doesn't seem to be a big deal. At least they're not stuck!

There were tons of players back in the first year of WoW that wanted to do MC, but couldn't, because they weren't in "the right guild." Even in that guild some players got left on the sidelines because their gear wasn't good enough. Now, those guys have somewhere to go. They're not stuck pugging MC and wiping on the first giant; they can do 5-man and 10-man content that continues to give them better loot.

Bias

I want to sit and bitch about how easy kids have it these days, but that just biases me against the current model. What makes a game fun is perceived mastery, and WoW has that.

The WoW end-game is loot acquisition, and as long as players are getting better loot, they are mastering the game.

Lessons

Progression is important. Really, that's it. Players like challenge but not because of the cost of failure. They want to succeed, and look back, and say "I overcame that." As long as players continue to progress, they'll have fun, be happy, and continue to pay.

Creating an Engine from Scratch

2009-10-14T06:40:00.000-07:00

I've been coding since I was ten. That's nearly thirty years now. In that time I've worked on games ranging from simple Apple II fare to big-budget PC and console titles. I've also written a ton of applications and tools, on the PC and Mac and that old Apple II, too.

So I can create an engine from scratch if I want to. Do I want to?

Right now, the 2D RPG I'm working on is an XNA title. I'm not using an engine, tho I am using the XNA and .NET libraries. Coding up my own engine is not too bad, but there's still tons of little cruft that I have to code. I wrote a line-wrapping routine last night; the code that breaks up a string of text across multiple lines. It's perhaps the tenth time I've written such a routine.

It's the sort of thing that makes me wish I had used an engine, something that would give me those sorts of routines. I know how to write them and I've got old code laying about that I can crib from, but I still need to modify the code for the language (C#) and platform (XNA) du jour.

The downside to using an engine is learning it. I remember old Mac documentation, back in the pre-OS X eras. It was awesome. It took a long time to read (compared to today's documentation), but it was fucking stellar. Not just explanations of parameter values, but meaningful sample code (including error-checking) for nearly every use that a particular function had.

Today, most of the documentation and comments I see are like:

int key; // the key

wtf? That comment is noise. It's a waste of space and the time it takes me to look at that and then realize it contributes NOTHING.

Engines are also often buggy; if you don't have source, you're just screwed. Wait six months for the next update and hope it fixes your problem. And being generic engines, they have a strange mix of too-much and too-little functionality. They don't do exactly what you want, but they can do a dozen things that are similar but still inappropriate for your specific needs. So it takes you days to figure out what it does, and then days trying to make it dance the way you need it to -- only to find out it doesn't do that. Then days more to figure out how to change your game spec so that your requirements can be met by the subset of functionality that the engine actually provides.

Using an engine is a great idea if it would take you too long to write it yourself, and if you can amortize the learning time across multiple projects (ie reusing the engine). Finding a great, easy-to-use, powerful, flexible, well-documented, and robust engine is a pain in the ass. Plus, generally impossible. There just aren't enough engines out there (and they're not profitable enough to develop) for them to be stellar products.

The big engines these days are cross-platform; PC, XBox, PS3, and Wii. There's some smaller engines that enjoy some niches, but I don't have high hopes for their lifetimes. Those big cross-platform engines can meet some of those important feature points, but (back when I was seriously looking at them, at game-industry day jobs) they weren't 100%. There's some smaller engines that have a lot of promise, too -- yet they're very niche.

Niche is good. If it does just what you need it to, a niche engine can be great. You don't waste time and money on features you won't use, and it's more likely that the engine does exactly what you need, does it well, and can document its small feature set well. Here, I'm thinking about engines for the iPhone, or 3D-shooter-specific engines, etc.

Which brings me back to that first point: if you lack the experience and talent to quickly develop an engine yourself, chances are, using a cumbersome, weak, inflexible, poorly-documented, and buggy engine will be your best choice. This is mostly cuz of the arcana associated with a new platform and the toolchain that goes with it. An engine isn't just line-wrapping code; it's a sound system, 3D rendering and scene graphs, advanced shaders, exporters for Max and Maya, input abstractions, UI widgets, plus tons more. Maybe even a scripting language and enough of a game shell that most of what you need to do is plug in some art assets, do a bit of scripting, and ship your product. If I was developing an XBLA or a PS3 or even a AAA PC title, I'd be using an engine.

There's a time balance between learning someone else's engine and writing the code you need yourself. The smaller the requirements you have for the engine, the more it makes sense to do it yourself. That's one reason why I'm writing my own engine. Plus, I get to reuse this engine for the next title I do. Plus, I'm not stuck with broken code. Plus, the engine does exactly what I need it to do.

It's still annoying to have to write line-wrapping code. Again.

Fun RPG Combat

2009-09-22T06:30:00.000-07:00

see also: fun rpg combat part 2

I'm working on a retro, 2D RPG, so RPG mechanics are on my mind. I'll go into my plan and the game a bit more at some other time, but today I wanted to explore combat mechanics, and what makes for a fun RPG. But first, I want to talk about fun in general.

Fun

What makes for a fun game? What is fun? This is a big issue that game designers love talking about, but I'm not really sure why -- I think the issues are fairly straightforward. I'll lay out my thoughts and you can be the judge. :)

Let's look at boring first. Boring is when you've got nothing to do, nothing to think about. Mindless repetition is fun; the 'repetition' means you've figured out how to do a task and you're just mindlessly repeating it. Boring is mowing the grass, stuffing envelopes, fighting the same random creature encounter for the hundredth time. There's nothing about the task that's challenging. Maybe the first time, but now that you've figured it out you're just going through the motions. There's no mental or emotional commitment to the process.

Fun is the opposite of boring. But first let's ask: are there activities that aren't boring, but aren't fun? Some activities aren't boring because they require some problem-solving and/or careful attention, but aren't fun. Fun implies a positive emotional response; busy-work activities don't have that. You don't have time to let your mind wander and get bored, but there's something missing. Busy-work activities include writing uninteresting code, building uninteresting 3D models, doing your taxes. Not boring (you're too engaged to get bored), but definitely not fun.

This is pushing us towards fun, obviously. We know what sort of activities aren't fun, and in describing them it's obvious what they're missing. Intellectual interest, or emotional drive. Curiosity, achievement, happiness, social connection, fear, horror, thrill, suspense.... Horror movies and games push the fear and horror buttons; adventures like Indiana Jones go for thrill; mysteries and dramas often push suspense and curiosity. These movies and games like them are fun.

Interactivity

Games are different from other media in that they're interactive. Movies can't give viewers a sense of achievement, and (except for the camaraderie felt around the water cooler when you're talking about how much you love [insert favorite cult movie here]) can't give a sense of social connection either. Movies can pique curiosity, but they don't give you the tools to resolve it yourself. Games can try to hit the big emotional buttons that movies go after (like fear and thrill) or pique intellectual curiosity, but they can do more: they can provide challenges and reward achievement, let players build social bonds to achieve common goals, and let players explore play spaces and puzzles in their own time and way.

Games are also different because they're typically much longer than movies, and usually longer than books. RPGs, especially. There are short RPGs out there and very long books, but in general games provide far more hours of entertainment. This is a bit of a pickle, because games have to figure out how to be fun for longer than 90 minutes. It's hard enough to make a good movie, how do you make 15 hours of fun on a budget a tenth the size?

There are ways of filling time, of course. Grinding is a bad way. But what's the difference between grinding (boring!) and fun? Yeah, well, asking the question makes the answer obvious. We want games that have fun ways of filling time -- or at least, not boring ways.

Games often fluff themselves out with skill challenges. Some games are primarily skill challenges, like shooters and racing games. Others, such as platformers, focus on exploration or figuring out how to get somewhere or kill a boss mob but also contain (possibly extensive) skill challenges. Starcraft is an RTS that's packed with skill challenges on the multiplayer competetive level.

I've mentioned exploration, too, and this is a great way to extend a game. Even in territory you've already covered, you might explore a different aspect of the world -- in Left 4 Dead, you check nooks and crannies for hiding zombies. Once you've played through the campaigns a few times you know the rooms and the architecture, but you don't know where the enemy is. Some games provide rich mechanics that the player is constantly exploring, such as RTS games where players learn how different units behave and interact.

Puzzles and sims both fill gameplay time with puzzles. In obvious ways in puzzle games, but I lump sims in here because, to me, most sims are long series of specific puzzles. Where do I put the next building, what troops should I train, where do I put my resource fields? I view Transport Tycoon, one of my favorite sims, as a series of four puzzles: where do I put the station? How should I build the line around these terrain features? What consist should I run between these two towns? and finally how do I optimize traffic? The player is constantly shuttling between one puzzle and the next.

High Points and Engagement

I think there's two things that makes a game fun: emotional high points, and near-constant engagement. Basically: add big, cool moments, and avoid breaking the player out of play.

If the game gets boring, tedious, or punishing, it can break suspension of disbelief or add enough of a punishment that the player disengages from concern for his on-screen avatar. Failure itself isn't necessarily a bad thing; some games are built around constant failure, such as roguelikes and shooters. Counter Strike doesn't suck even though you 'fail' (get killed) once every few minutes. That 'failure' frames the game and defines the challenge. The player isn't concerned about totally avoiding that failure as much as he's interested in maximizing the experience between those moments. (It helps that Counter Strike provides a social experience for dead players.)

Games without disengaging moments can keep a player at the controls, but an interesting game without emotional high points is equally unfulfilling. It can serve as a distraction but isn't at the same level of "fun" as a game that provides those high points.

High points are the peaks of emotional engagement. Gaining a level in an RPG is a single moment that collects all of the emotional buildup of previous play and hands it to the player at one, big, emotionally-charged moment. In level-based games (ie map levels, like Doom or Starcraft or Mario), finishing a level is that big moment. In adventures, there's often a big puzzle that's solved in each step of the game. Game designers know all about these emotional high points; they make the effort to provide rewards to players at them. Because of that emotional weight, these are also often the moments that players remember most.

Fun games keep players engaged and provide periodic emotional high points. Players enjoy play, and fondly recall the "peak experiences" of games past.

Recommendations

Those, then, are my two recommendations to game designers: provide engagement without boredom, and put more oomph into your game's high points.

In fun rpg combat part 2, I talk about applying this problem specifically to RPGs.

Game Tools with WinForms

2009-09-19T14:00:00.000-07:00

I'm working on my RPG fairly actively this week. I've got maybe another week on the engine, and about that on the content, so it's close to being ready. As I implement more bits in the engine, I'm going back and changing the editor, too, so I'd figure I'd comment a bit on that here.

The RPG is retro, 2D, turn-based tactical combat, single-player, and single-character. Old school. I'm trying to make it not suck, but I'm using simple technology. It's called BlackThrone and it's up on the web so check it out.

The Editor

The editor was my very first WinForms app. I've been coding UIs and tools forever, and C++ since college, and Windows since the OS/2 days -- but C# for only a few years and barely much professionally until last year. So I was new to WinForms, and at the time was coming off of using C++ heavily for a couple years.

My point is, my god this app sucks. I didn't know about User Controls, so a half-dozen tabs, packed with dozens of controls each, are all in the main Form. The main form .cs file is HUGE. Blech. I didn't have any common methods of dealing with resources and graphics, so lots of the stuff was ad-hoc. It's interesting coming back to it now after having left it half-developed for a year.

There's a few things I wish I'd known and done then, and that's the point of this post.

UserControl

UserControl is your friend. It's basically a collection of other controls; checkboxes, lists, text entry fields, buttons, etc. It's great for taking a chunk of your UI (like the controls that would be on one tab of a control panel) and encapsulating them.

In my editor, each resource type is edited on a different tab of a TabControl. The main form contains a TabControl, and in each TabControl is a user control. This means that there's very little code in the main form.

At least, there's less now. I'm slowly refactoring the application, pulling each one of the tabs out of the main form and sticking them into user controls. This makes it much easier to ensure that I've got everything I need, didn't forget something; debugging is easier; etc etc.

Document Model

The editor actually started as just a map editor; the extra resources got shoved in. What I should have done (earlier, like when I added an editor for the second resource type) is added a document-type class.

The editor works on a set of files. The "document" is really a directory; each different type of resource is stored in a different file. One file for the world map, one file for all the towns and cities, one for dungeons, one for conversations, one for items, etc.

The main reason to pull all these in is interaction between the resources. For example, cities can contain treasure chests which can contain items. Hence, the city editor wants to get access to the list of items so that it can present that to the user. I started out hacking into the main form (which is where everything was stored) to get the item list, but even while writing that code I knew that was a fragile, ugly way to do it. I'm slowly refactoring each resource type out of that main form into the Document class.

Small Parts

This is really a generic Agile practice. Classes shouldn't be big.

One of the common functions I do is grab a tile (a 16x16 block of pixels) from my sprite sheet (which is a 256x256 image), create a Bitmap from that, and set it as the Image in a PictureBox. This is "instant feedback" that makes it easier to see which object I'm dealing with. Bad coding practice is to copy and paste these few lines of code from here to there.

My refactor was to create a TileSheet class, and add a method to that to pull a Bitmap out -- and another method to draw a tile into the current Graphics object (eg in an OnPaint event). The TileSheet itself is small -- it's a small part.

Recommendations

If you're building an indie game, I really recommend using WinForms and C# to build data editors. If you're just starting out with WinForms, I recommend reading a book first -- having an idea of the things you can do makes it easier to choose the right thing to do. I started coding first, hacking together sample code from the net. The book I eventually bought, and one I really liked, is _Pro .Net 2.0 Windows Forms and Custom Controls in C#_ by MacDonald, on Apress.

And when you do start coding, think about putting together a document model. In my day job, having a good doc model is critical for good, clean architecture, and it's the same for my home projects.

Loading XML data from a config file using XmlDocument

2009-09-16T08:29:00.000-07:00

Part 1: where to save application config data under Vista
Part 2: how to save data in an XML file using XmlDocument
Part 3: this part, how to load (parse) an XML file using XmlDocument

All code samples in C#, cuz it's my drug of choice.

In the previous two parts, I covered where to save data to, and provided some sample code for creating an XmlDocument that can then be written to disk. The idea here is loading and saving application config data. For games, stuff like the user's preferred screen resolution -- which is the specific purpose I had when I dug up this code.

So let me just get straight to the code. That's why you're here, right?

const string kIntId = "ints";
const string kStrId = "strs";
const string kConfigFile = "config.xml";
private void LoadData()
{
string myAppFile = GetConfigPath() + "/" + kConfigFile;
if (!File.Exists(myAppFile))
return;

try
{
XmlDocument doc = new XmlDocument();
doc.Load(myAppFile);
XmlNode root = doc.DocumentElement;

XmlNode intsNode = root.SelectSingleNode(kIntId);
foreach (XmlNode child in intsNode.ChildNodes)
{
string key = child.LocalName;
int value = Convert.ToInt32(child.Attributes["value"].Value);
_intList[key] = value;
}

XmlNode strsNode = root.SelectSingleNode(kStrId);
foreach (XmlNode child in strsNode.ChildNodes)
{
string key = child.LocalName;
string value = child.Attributes["value"].Value;
_stringList[key] = value;
}
}
catch
{
// feh
}
}

The try/catch is there cuz you should be worried about your users being dumbasses and manually editing your config files. And/or you being a dumbass and screwing it up. Cuz that's what I did. Plus, when I changed formats, some of this stopped working.

Note that I'm using a couple constants to specify the names of the groups that I'm looking for. I do that because of Once and Only Once: mostly to keep myself from mistyping data.

I covered a way to obtain the name for the directory in which to store application data back in part 1, but here's the relevant snippet here:

private static string GetConfigPath()
{
string appData = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
string myAppData = appData + "/MyAppName";
return myAppData;
}

This is for per-user app config data, as opposed to shared (common) config data -- both described back there in part 1.

How to save config data into an XML file

2009-09-16T08:20:00.000-07:00

Part 1: where to save application config data
Part 2: this part, how to save data in an XML file (using XmlDocument)
Part 3: how to load (parse) an XML file

There are many different ways of working with XML files under .NET. You can hand-roll your own code, use XmlReader, use XmlDocument, use someone's third-party library, and who knows what else. I find using XmlDocument the most sensible approach -- why write my own code? I'll let someone else worry about that.

I'll just dump the code here:

public void SaveData()
{
XmlDocument doc = CreateSaveDoc();
string myAppPath = GetConfigPath();
string myAppFile = myAppPath + "/" + kConfigFile;
if (!File.Exists(myAppFile))
{
Directory.CreateDirectory(myAppPath);
}
doc.Save(myAppFile);
}

private XmlDocument CreateSaveDoc()
{
XmlDocument doc = new XmlDocument();
XmlElement root = doc.CreateElement("root");
XmlElement ints = doc.CreateElement(kIntId);
int idNum = 0;
foreach (KeyValuePair kvp in _intList)
{
string id = "int" + idNum.ToString();
++idNum;
XmlElement node = doc.CreateElement(id);
node.SetAttribute("key", kvp.Key);
node.SetAttribute("value", kvp.Value.ToString());
ints.AppendChild(node);
}
root.AppendChild(ints);
XmlElement strs = doc.CreateElement(kStrId);
int strNum = 0;
foreach (KeyValuePair kvp in _stringList)
{
string id = "str" + strNum.ToString();
++strNum;
XmlElement node = doc.CreateElement(id);
node.SetAttribute("key", kvp.Key);
node.SetAttribute("value", kvp.Value);
strs.AppendChild(node);
}
root.AppendChild(strs);
doc.AppendChild(root);
return doc;
}

I used attributes to store info, and ignored the tag names for the contained data. I think the whole 6bytes part of XML is poopy. Yes, I said it, poopy. Attributes work better for me, cuz then you get XML that looks like:

This could be shortened to:

but, well, I got it working and I stopped caring. If you implement this yourself, feel free to take that extra step.

Hmm, I say that now... ok, I went back and changed my code. This complicates loading a bit, because I now care about tags, but you'll see that in the next section. For completeness, those inner loops are now:

{
string id = kvp.Key;
XmlElement node = doc.CreateElement(id);
node.SetAttribute("value", kvp.Value);
strs.AppendChild(node);
}

Much cleaner!

Saving application config data under Vista

2009-09-16T08:14:00.000-07:00

Part 1: this part, where to save application config data
Part 2: how to save config data in an XML file using XmlDocument
Part 3: how to load (parse) XML-based config data using XmlDocument

I was a bit frustrated at finding this info on the net. It required a bunch of searches to pull it all together. I finally got what I needed, but, you know, bitch/moan/whine and all that. So here's everything in one place!

I'm assuming you're coding in C# (or at least can read it), and using .NET. And, like, Windows? Yeah.

So, part 1 of a 3-part series: where do I put my config data?

In the olden days (ie, under XP), you could just create a "config.ini" file in the current directory, ie with no path info, and it would save it in the same location that your application's exe was located. Under Vista and User Access Control (UAC), applications by default do not have write access to the Program Files folder. Plus, that folder might not be on the C: drive, and it might not be called "Program Files". So where do you save stuff now?

The correct location is in the AppData folder for the current user -- or, if you don't want to store user-specific data, in the common AppData folder. You can get these paths using the following code:

string userAppData = Environment.GetFolderPath(
Environment.SpecialFolder.ApplicationData);
string commonAppData = Envrionment.GetFolderPath(
Environment.SpecialFolder.CommonApplicationData);

You can also hunt for the environment variable %AppData% if you want. The above is .NET friendly, so it's what I used.

I encapsulated the above into a function, which I use a couple places in my config save/load code:

private static string GetConfigPath()
{
string appData = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
string myAppData = appData + "/MyAppName";
return myAppData;
}

Loading it requires the following:

string myAppFile = GetConfigPath() + "/" + kConfigFile;
if (!File.Exists(myAppFile))
return;
XmlDocument doc = new XmlDocument();
doc.Load(myAppFile);
// insert parsing here, see part 3

and saving it requires just a bit more work:

public void SaveData()
{
XmlDocument doc = CreateSaveDoc();
string myAppPath = GetConfigPath();
string myAppFile = myAppPath + "/" + kConfigFile;
if (!File.Exists(myAppFile))
{
Directory.CreateDirectory(myAppPath);
}
doc.Save(myAppFile);
}

In part 2, I cover storing data in an XmlDocument, and in part 3 I cover parsing data back out of an XmlDocument and into some local format.

(Apologies for the poor code formatting. Me and Blogger don't get along.)

DRM, Piracy, and Indie Games

2009-09-14T08:18:00.000-07:00

"OMG! teh pirates stoled my gaem!!!1!"

DRM tends to suck. Whether it's the inability to transfer Kindle books (or the fact they costs the same) or the registration hassles with PC software, I think users have a dim view of it. I'm with you there. That's not my point.

On the producer side, complaints about piracy are rampant. "We lost $3 gajillion in sales last quarter due to pirates!" I hate those kinds of complaints. There might be a billion copies of your product out there, and if one does the math that comes out to $3 gajillion, but there's no way those people would have spent that much money on your product if they hadn't found a way to pirate it.

But there is an opportunity cost involved. If pirates couldn't get their warez for free, they'd wind up buying some of those products. They'd spend less on beer, pizza, and auto parts. Minors would spend less on ... what do kids do with spare cash these days? iPods and iTunes? Big Macs and funny t-shirts?

I think piracy has killed off single-player PC games. What remains is the big boys -- The Sims, perhaps. Games that require online registration get hacked, but I think the low price point of Steam titles reduces it. Diablo, although often played single-player, is still played online; that's how you get to compare your epeen to the next guy's.

What's gone are middle-market titles. Everyone and their brother bought Doom 3, but who buys those other shooters? Not the mass-market; just the diehards. The guys more likely to have a bittorrent running in the background 24/7.

That means that successful titles are online (with all the expense that brings), or so popular that they reach out beyond those comfortable with bittorrents, which again means expensive. Niche titles fight for a living and are pirated like crazy. Consoles are grossly expensive to develop for, too.

Are games getting less innovative? Yes. The market sucks. A game designer, a programmer, and an artist can't save up some spare cash and develop a game in their spare time, throw it out on the PC, and profit from it. There's not enough of a market willing to pay for something they could steal instead. Buyers save their money for the console and online titles that they have to pay for. Have a cool idea? You need to convince someone to give you $15M to develop it. Otherwise, you're SOL. Or, just building it in your spare time.

Pros aren't often hobbyists on the side. Once you've done a few years of the crazy game dev rat race, 100-hour weeks and all, you think: screw that noise. I'm working 9-5 and then going home to spend time with my family and friends.

My point is that if it were possible to make money as an indie, more people would do it.

And it is possible, just ... grossly constrained. Next time, I explore revenue possibilities.

The Rule of Seven

2009-08-30T09:20:00.000-07:00

Andrew Doull, on his blog Ascii Dreams, suggests that game designers should follow a moral code -- mostly by not creating punishing or boring game mechanics. One of his rules he calls "The Rule of Seven":

A player should be at most presented with seven options at any one time.

The reason for the number seven here is a reference to the magic number seven, plus or minus two, described in a 1956 paper by psychologist George Miller. The core of the concept is that humans can remember about seven different things at a time; that we can distinguish between seven different qualities or quantities before our capacity to comprehend is compromised.

Miller's Argument

Miller notes that we can get around this: we can count way past the number seven itself, as well as use thousands of words written with 26 different letters, because experience and tricks (such as using arabic numerals in a base-10 system) let us expand the range of qualities that we can express and remember. The point is really that, when faced with a new, unfamiliar group of items, we are at first stuck dividing them into at most seven categories. Never studied trees before? Then you'd probably be able to identify or describe seven types. Never studied breeds of dogs, or types of land animals, or crops, or minerals, or types of architecture, or music? Our natural ability lets us stick them into seven groups. Maybe only five, maybe sometimes nine, depending on the person's intelligence and experience. Until we start studying the subject, of course -- and then we learn all sorts of attributes that let us learn about more types.

And so when you design a game that has new creature types, or treasure types, or places to go -- your players will only be able to distinguish between about seven of them.

Until they learn your game. And there's the rub: how long are they going to play your game? For a short game, one that you finish in ten to fifteen hours, your players are unlikely to learn a lot about your game world, or want to spend time and effort building an efficient mental model to distinguish between all the types of Frobozzes and Gromixes that you've invented, or even to remember if Mithril or Truesilver or Adamantite is the better armor -- even if they've seen those names before.

Roguelike games start with the player in town. They've got ten buildings to choose from, plus stairs to go down and villagers to talk to. The player doesn't group this into "fourteen things" -- that's what Miller answered. The player will see this as three choices: enter a random building, talk to a random person, or head down the stairs. Because there's ten buildings, you've broken the rule of seven: it will take some time for the player to learn what those ten buildings are. If there were only seven, they'd do it quickly. The time difference between learning three buildings, five buildings, or seven buildings is tiny; trying to distinguish between ten takes exponentially longer.

Game Design Ethics

So how does this impact the game designer? It'll stress your players, and possily frustrate them, if you constantly tax their memory. Running out of time and have to choose the right one of those ten shops? Users will fail because they couldn't remember correctly. If you had given them seven choices, players would be a lot less frustrated.

Andrew Doull's basic point about clicklets is that forcing the user to do something boring and repetetive, mindless, without choice or consequence, or in a taxing way is cruel. And the main reason to avoid cruelty is to make a fun game; something that players want to come back to.

Some games frustrate me needlessly. It really turns me off of the game. If I sit down to play a game and am then bombarded with dumbass, frustrating rules and mindless clicking to get what I want, then I feel like a product I purchased for the purpose of entertainment has lied to me, and is subjecting me to pain and frustration. I find that unethical.

An analogy for a moment: Is it unethical to kill someone if you didn't know that what you were doing would cause their death? Out in the real world, we call that manslaughter, and it might be involuntary, but it'll still get you convicted and thrown in jail.

A game designer that builds a frustrating system is still guilty of frustrating his users. It doesn't matter if you knew ahead of time or not. Not knowing is negligence; it indicates a lack of forethought, of consideration. It's inconsiderate.

The idea of the ethics of game design is that: a game designer shouldn't build systems that frustrate, bore, or needlessly confuse their users. (I don't mean all confusion; some jokes and puzzles rely centrally on confusion. Work with me, here.) A designer shouldn't build such systems whether they know they'll have that effect or not; a designer is responsible for building a good product, and for learning more about his art such that he avoids such sinful mechanics.

Efficient Ellipse Drawing - Part 2

2009-07-23T10:59:00.000-07:00

[images coming later]

In Part 1, I discussed drawing lines. Drawing an ellipse, pixel-by-pixel, shares some comments with line drawing, so I covered that there.

In this part, I discuss drawing a circle.

In the next part, I'll discuss complications and provide a more complete circle-drawing algorithm. The final part(s) will cover ellipses.

Symmetry

Circles are handy because they are symmetric. Since we're rendering a circle onto a square grid, the symmetry that's useful to us here is horizontal symmetry and vertical symmetry. We'll also make use of the fact that you can rotate a circle 90º and still have a circle. Combine all the symmetries together, and we really only need to draw one-eighth of the circle.
[insert image here]

Hence, most circle-drawing algorithms will only draw an eight of the circle, and use this symmetry to plot the other 7/8ths. Which eighth you draw is up to you. I'll be drawing the eight from straight up (like 12 o'clock) clockwise to 45º (1:30 on an analog clock).

void PlotEightPoints(int x, int y)
{
PlotPixel(x,y);
PlotPixel(y,x);
PlotPixel(-x,y);
PlotPixel(-y,x);
PlotPixel(x,-y);
PlotPixel(y,-x);
PlotPixel(-x,-y);
PlotPixel(-y,-x);
}

This code can be easily tweaked to draw points centered anywhere in the screen; just add a constant offset to x and y in each case. Something like:

void PlotEightPoints(int x, int y, int xCenter, int yCenter)
{
PlotPixel(x+xCenter,y+yCenter);
etc...

or, if this code is part of a class:

void PlotEightPoints(int x, int y)
{
PlotPixel(x+this.xCenter,y+this.yCenter);
etc...

Borders

A perfect circle on a square grid can either be centered on a pixel, or centered on the border between two pixels.
[insert image here]

It's easy to start the first one. Say our circle is centered at the pixel 0,0, and has a radius of 10. We can conclude that the pixels (10,0), (0,10), (-10,0), and (0,-10) are all points that we want to draw. There's no fractions here, and the logic is fairly simple.

The second example -- when our circle is centered on the border between two pixels -- is a bit more complex, but much of the same logic (below) is the same. I'll cover this case in the next post.

Tricks

The trick to circle drawing is to note that, over this eighth of the circle that we are going to draw, we're only going to draw one pixel per column. Furthermore, as we move from pixel to pixel, we'll either move straight to the right (dy=0), or diagonally down one pixel (dy=-1). Hence: we just need to figure out which of those two choices is closer to our circle!
[insert image here]

The formula for a circle (centered at 0,0) is

x² + y² = r²

where 'r' is our radius.

Let's say we plot our first point at (0,10). Should our next point be (1,9) or (1,10)? We can calculate the radius at those two points easily:

r = sqrt(x² + y²)

Here's another trick: we don't really need to do the square root. We can just pick the point such that (x²+y²) is closest to r², or 100 in our sample case. For (1,9) that value is (1*1 + 9*9), or 82, and for (1,10) the value is (1*1+10*10), or 101. Our goal is 100, so obviously 101 is closer.
[insert image here]

And now for the code:

void DrawCircle( int r )
{
int x = 0;
int y = r;
while (y >= x)
{
PlotEightPoints(x,y);
x++; // always move over one column
int rAcross = x*x + y*y;
int rDown = x*x + (y-1) * (y-1);
int acrossDelta = r*r - rAcross;
int downDelta = r*r - rDown;
int absoluteAcrossDelta = Math.Abs(acrossDelta);
int absoluteDownDelta = Math.Abs(downDelta);
if (absoluteDownDelta < absoluteAcrossDelta)
y--; // sometimes move down one row
}
}

This will draw your circle. In the next post in this series, I'll cover drawing a circle that isn't centered on a pixel, provide a code snippet for drawing a circle anywhere on screen, and handle cases where part of our circle is off-screen.

Cargo Cult Engineering

2009-06-19T13:12:00.000-07:00

Process-oriented development achieves its effectiveness through skillful planning, use of carefully defined processes, efficient use of available time, and skillfull application of software engineering best practices. - Steve McConnell

I'll come back to that quote eventually, but today's post is on cargo cults.

In my experience, engineering teams succeed because there's one or two engineers on the project that are smart, hard-working self-starters, but most importantly follow sound software engineering principles and are capable of taking stepping back and getting the big picture.

Smart, Hard-Working, Self Starters

There's ways of assessing this stuff. Personally, I think gradations of these attributes are mostly worthless. Programmers of average intelligence won't be able to tackle huge problems, or get a lot of features done, but having a smart but "unwise" (using that word as a catchall for what I'll describe in the sections below) engineer is worse than having an average-intellect but wise engineer.

Hard-working is good. But I think easy to assess. And if they don't work hard once they're in place, you need to fire them. If you can't fire them, because, say, you're in France, then that sucks. Your next job will be to get them to quit. Try transferring them to the Siberian Office.

Self Starters are handy, but again I don't think it's at the top of the list. A semi-smart, hard-working, self-starting programmer that insists on overengineering everything, following a fancy & convoluted development methodology, and is unable to assess the importance (ie context) of the parts that he is working on will build lots of great code -- that won't help your product ship or keep customers happy.

What's your goal? Are you capable of assessing context? As a manager, you want programmers that help your bottom line. That means quality code, but it also means code that you need, and code that makes your clients happy. Happy clients are more important than pretty code.

The Big Picture

Whether it's figuring out how one method fits into a class, one class into a module, one module into a project, one control into a web form, a folder or set of files into a hierarchy, one product feature into the next release, themselves into the company, their company into the industry, the product into the market, etc etc -- good engineers are capable of taking a step back and assessing context.

Bad engineers do cargo cult programming. They see the artifacts of good engineers, but they don't understand the principles behind it.

Sound Engineering Principles

Lists are popular. "7 Habit of Highly Effective People", "Top 10 Ways to Ship Better Software," the lists of core rules in methodologies, and the very frequent "Five Ways to Fit into Your Swim Suit for Summer" type stuff.

Lists are easy to make. Just observe for a little while. Pretty much anyone can make lists.

But lists aren't principles. Principles are difficult to apply. They're easy to state, but the whole trick with principles is that they must take context into consideration. Principles must also exist in a hierarchy; for each principle, there must be an antecedent principle that sets boundaries. The antecedent says why a principle is important, gives a guideline for the boundaries of the principle (where it makes sense and where it doesn't), and establishes a benchmark by which to judge the execution of a principle.

Take choosing good names for local variable. This isn't just one floating point out of hundred of practices that make for good software engineering. The list-maker will take this point and stick it into his six-page bulleted list of "Best Practices."

As a principle, one chooses good names because it aids in human parsing of code. Let's chase the antecedent principles here. Human parsing of code is important because it makes maintenance (extension and debugging) easier. Maintenance happens -- so why is it important to make it easier? Because it increases the quality of software and reduces the cost of development. Why are those things important? Why are they important on this product? The answers for quality and cost vary from project to project, and I could answer them in the abstract, but how you answer this question is what settles the boundaries of the principle.

Cargo Cults

Cargo cults mimicked the habits that they saw American military men executing. They thought that the motions themselves were what caused the airplanes to land, and the cargo to show up on the beach. Likewise, the actions that McConnell outlines in that quote above -- skillful planning, use of carefully defined processes, efficient use of available time, and skillfull application of software engineering best practices -- are habits. These are good habits, but I don't think they capture the important traits at all.

Specifically, "use of carefully defined processes" implies that browsing to some Six Sigma website and then handing down the printouts to your engineering team is sufficient for project success. That's just mimicking the habits of successful developers; it's not good engineering.

Builder Pattern vs Factory Pattern

2009-06-18T06:04:00.000-07:00

Versus

The builder pattern is appropriate when object creation is more complex than just calling a constructor. The factory pattern is appropriate when you have a hierarchy of created objects and you want to abstract the mapping of creation parameters to a subclass.

These patterns are often used together. Many abstract factories that I've written use builder functions. Sometimes I'll put the builder function into a base class -- which means that I have a builder function that is actually an abstract factory, which might itself use builder functions.

Now for more detail:

Builder

A Builder encapsulates complex creation into a single method (or class). If creating an object is more complex than just calling the constructor, then all of the work that goes into creating the object can be moved into one method, and that method is the Builder. 'Builder' implies only one type of created object, but that is not necessarily so. Builder really just means encapsulating complex construction!

Say that you want a Widget object, and that creating one means making a DB query or loading something from disk, constructing the object (passing in the query results), then making a few more calls to set up the object before it can be used.

Instead of copying and pasting that creation code -- query, construction, setup -- every time you need to create a Widget, you move all of that crap into a single function. The Widget constructor probably takes a whole bunch of parameters; maybe those come from the database query. Maybe the Widget uses multi-phase construction. The Builder pattern helps hide all that.

If the setup and configuration isn't really part of the created class, ie if it doesn't make sense for that class to know about all the other crap that needs to be done, the builder function might go somewhere else. I think 9 times out of 10 my builder functions are static methods in the created class itself. Instead of calling the constructor I call the builder function, and probably make the constructor private.

I usually use builder functions, not builder classes. The separate functions in a builder class might each return the same object just with different configurations, or each function might return different subclasses.

In languages where multi-phase construction is the norm (instantiate an object then make a bunch of function calls to fill it out), refactoring the construction steps into its own method is an instance of the Builder pattern!

Factory

A factory can create several different types of objects, but it returns its objects via an interface (or base class) reference. Whereas a Builder encapsulates complex construction steps, a Factory encapsulates the decision-making that figures out which specific subclass to instantiate.

Factories are accessed through a single method; that's really the point. You call one function, and it creates either a Subclass1 or a Subclass2, returning it via IBaseClass.

The Gang of Four book (Design Patterns) names both a Factory Method pattern and an Abstract Factory pattern.

In the Factory Method pattern, the factory function is virtual, and different subclasses of the creating class return different subclasses of the created class. That is, you call one class (the factory) to instantiate the second class (the created). The factory class is actually a tree - base class and subclasses. You'll have something like:

virtual ICreated* IBaseFactory::Create(...params...)

So you have two class trees: the factories and the created objects. The two trees might be parallel, ie CFordFactory::CreateSedan returns an instance of CTaurus, and CNissanFactory returns CMaxima, etc etc. Or, the two trees might be disjoint: CFryingPan and CMicrowave return an instance of CFood, while CBlender returns an instance of CDrink (where both presumably derive from IConsumable).

You'll most likely use the Factory Method pattern when you have one hierarchy (the created objects), you're about to instantiate a whole bunch of objects, and you don't want to do a switch or if/else/else trees. So you move the creation into a new class tree, instantiate the factory subclass you want, and then use a method to create your objects.

Alternately, you might have a class that creates a bunch of objects, but that class is part of a hierarchy. Depending on which specific subclass you have, you'd get different created objects. That's the Factory Method pattern.

In the Abstract Factory pattern, you've actually got a set of factory methods. A food factory method, one for drinks, one for dishware, etc. More realistically, you might have a factory method for buttons, one for checkboxes, etc, where different factory subclasses create different appearances. In a game, you might have a barracks that will create an infantry, cavalry, and ranged unit, with different factories for each player race. Instead of disjoint classes for each type of unit, one class (IBarracks) will have three methods to create IInfantry, ICavalry, and IRanged units.

Besides subclassing, your abstract factory could be run off of some other logic. The factory function could do some magic to figure out which subclass to create. It could switch off of a parameter:

ICreated MyAbstractFactory.Create( Enum paramEnum )

or it could use static data or other state to decide:

ICreated MyAbstractFactory.Create()

Abstract Factory is a funky pattern. To use it, you'll want to be creating a matched set of objects. If you find yourself wanting to do that, Abstract Factory is your pattern.

see also
Bridge Pattern vs Strategy Pattern
Ownership, Aggregation, and Composition

Designing an MMO part 1

2009-06-17T06:43:00.000-07:00

Designing a New MMO, Part I: Get Rid of Classes!

Everyone wants to make an MMO. They're fun games, and with WoW pulling in over a billion dollars a year it looks like an insanely lucrative market.

Except, of course, for all those failures. Like Tabula Rasa, which cost a hundred million to make and only brought in a sixth of that in revenue. Unless you've got 84 million dollars you don't mind never seeing again, jumping in should be done with care.

I like thinking about MMO design. I think it's like talking politics. It's not like me and the rest of the crew at the water cooler are going to run for office. Ultimately, the only effect each of us has is one vote -- out of millions. Does it really matter what I think about politics? At most, I'm influencing a dozen people. And I haven't yet converted any of them to the One True and Proper Political Party, so what does it matter?

It doesn't matter. It's fun, though. Likewise, us scrubs talk MMO design. It's an entertaining exercise.

Usually the first topic to come up is something like "classes are lame" or "levels are boring". I think this is a fairly fundamental discussion.

But I'll skip it, because Lum did a much better job than me. Go read that.

(There's no guarantee that I'll ever write a part 2.)

Reusing End-Game Content

2009-06-11T11:02:00.000-07:00

I read a post on end-game content over at Player Vs Developer and was reminded of a suggestion I made to Blizzard long ago.

There are basically three problems that I'll address in this post: players want new content, they want a variety of content, and devolpers don't want to throw away old effort or see great content go unused.

Quake and CTF

One issue I had with Warsong Gulch (a 10-vs-10 Capture the Flag PvP zone) was that the map got boring. This is one issue with FPS games -- many players like having different maps.

Back when I played Quake, there were a handful of maps that everyone played on, and it was interesting to continue playing on the same map, over and over. I was actually learning new things about the maps after a year of play; specifically, I was learning player behavior. Learning where things are on the map is the first step; then one develops patterns; then one learns what patterns the enemy has; and then a metagame starts where players start trying to deceive their foe about what pattern they are running, etc etc. In Quake, I was learning very specific timing patterns, and how to juke out other players and make them think I was somewhere else. I was counting on my opponent knowing the map so well that I could play against that knowledge.

This is like tennis, or basketball, etc. Everyone plays tennis on the same court, don't they get bored of the same layout game after game? The answer is obviously no; the game isn't about the court, the game is about the other player.

Not so with online games like Quake or Warcraft because most players (especially new or casual players) don't want to become PvP pros. And many other players resent having to learn a map well, and instead just want to win without putting in effort. Don't underestimate your players' arrogance. Many players that suck don't believe it; they blame their losses on bad map balance, or the fact that their opponent knows the map 'too well', or some other lame excuse. Players suck. People suck.

When I played Quake on the LAN at work, I would learn the maps quickly (I'm good like that), or I'd remember the map from online play. I'd grab the rocket launcher and red armor and then start tearing people up -- in part because I also played a lot and was a good player. They'd get frustrated or bored, because to them the interesting bit was the new map, not the game mechanics themselves. They wanted a slot machine, where sometimes they won. They wanted to win; they didn't want to earn the win.

My point is that a great majority of people that will pay for your product want variety, not challenge. Don't force them to play competetive tennis; they want wacky new rules and a roll of the dice.

So am I now just bitching about WSG because I want to see new maps? Not exactly. Quake was played on a handful of maps; WSG only takes place on one map. Every time you want to play Capture-the-Flag (CTF) in WoW, you have to go to WSG. The other PvP maps have different gameplay -- Arathi Basin and Eye of the Storm both have a Battlefield/Team Fortress-like base capture mechanic; Alterac Valley is a back-and-forth push to the enemy's base.

My PvP Suggestion

My suggestion to Blizzard was to make more CTF maps, then change the queue mechanism to be somewhat like Arena, so that when someone queued for "WSG", they'd really be queueing for CTF, and sometimes they'd play in Warsong Gulch, sometimes in Netherstorm Gulch, sometimes in Grizzly Gulch, etc.

The major problem with just adding those as separate queues is that it's hard to find players. Now, even with queues spread across an entire battlegroup, sometimes it's hard to find people to play in Alterac Valley. Imagine if there were three times as many PvP queues -- some of those games would never get started! Hence: group several WSG-type maps into one queue. You get more players funnelling into the same queue, and players get to experience a wider variety in online maps. (This is why most Counter-Strike and Team Fortress servers rotate through maps!)

Players Want More Content.

This issue with finding players is also a problem (now that a new expansion has come out) for old end-game content. Who wants to run Scholomance or Kharazan? Those instances are lame! There's level 80 content to do! As much as players want variety, they don't want to do irrelevant content.

Scholomance is old. It takes too long to do all those quests. Once you hit level 61, the content starts becoming trivial, and the rewards for the grind too small. The problem is the same for level 70 instances -- it was hard then to find a group that wanted to do Mechanar, or Arcatraz, or Botanica. There were too many places to go for there to be many people that want to do one specific instance.

One way to fix this is to rebalance Scholomance so that level 80s can do it. They did that with Naxx; it's a fun challenge for 80s and the rewards are appropriate. Yet if they did this to every 60 and 70 instance, it'd be a pain to find a group to do anything. It'd be the problem with Mechanar but far bigger. Especially with the way itemization works -- one person wants to get his hat from here, the next guy needs a pair of pants that drops off a boss there, and once they got their drops they'd never want to do the instance again. It'd be nearly impossible to find someone to do any one specific instance, just because there'd be so few people that want anything that drops from there!

One way to solve that is the token system used at the end of the 60 lifecycle and was fairly widespread in the Burning Crusade world: kill a boss, get a token that can be used by a handful of classes for a number of different armor slots.

Now imagine if you needed Keeper of Time rep for some level 80 gear that you could only get from the Keepers, but that you could get the rep from any of a half-dozen old instances (rebalanced for level 80) and that it also didn't matter at all which one you did. Now you could say "I want to do one of the Caverns of Time", and anyone that wanted Keeper rep could do it. It used to be that people wanted (say) Durnholde specifically because that's where their item dropped. What if their item dropped from all of those instances instead of just one boss in just one instance?

Now everyone could do Caverns of Time again. The developers could re-use end-game content, and players would have a wider variety of options for where to go. The developers could add in one or two new CoT instances, and maybe redo one of the old ones, and everyone (new and old players alike, ancient characters and brand new alts) would have a much wider variety of content to choose from. A group of five players could choose which instance they enjoy rather than which instance that itemization forces them to pick. Players would be far more likely to be able to play a new instance, instead of feeling forced to go do the same instance over again.

The downside to this, of course, is that maybe players are bored of the Caverns -- especially those that were playing before BC came out and have been playing since. I have a hard time believing that Bliz couldn't just redo each of those levels. Seriously. They're making billions of dollars a year on the game. And they could reset KoT rep to Revered, or maybe add something past Exalted, or add a new faction that automatically becomes Revered 0/21000 if the were Exalted before, etc etc, so players would have a reason to go back.

Players want new content. Players want varied content. Developers don't want to develop content, and then effectively throw it away because no-one is doing it any more.

The easiest thing to fix, really, is throwing away content. They removed Old Naxx from the game. They could remove Old Scholomance and who would know or care? Spending the money to develop New Scholomance would be trivial to them, it would be new content even to old players, and (with sufficient itemization eg through tokens) would give players a broader set of dungeons to explore, instead of hitting Kara week after week after week after week after zzzz....

Complexity in Game Design

2009-04-30T19:55:00.000-07:00

My Travian game is coming to a close, ie nearing its one-year mark. I've been poking around at other browser games to assess the competition, thinking about switching, and it reminded me of one of the lessons of game design that I picked up long ago.

I remember playing Warcraft 2 and thinking, "you know, this game would be even better if it had even more upgrades and building types and everything."

A few years later, while playing Kohan, I realized that I was very wrong. WC2 was so awesome because it wasn't any more complex. Kohan (another real-time strategy game) had a different, but relatively straightforward, combat model. It didn't add more building types, or more troop types, or more upgrades -- it just configured armies differently than WC2.

Complexity is great for World of Warcraft because people play that game for thousands of hours. Yet at the lower levels, the game starts out very simple. Starcraft, currently enjoying years of professional play in Korea, isn't any more complicated than Warcraft 2. Chess is much simpler than both.

What makes a game fun is the interplay of choices. With a ton of choices, sometimes randomness sets in and dominates play. "Is unit A better than unit Z732? What about Z731, or Q986? Gah there's so many, forget it! Just build unit A!?" It's difficult to figure out a good strategy (or to be happy with the strategy you chose) when combinations start spiraling up.

Warcraft 2 and Kohan and Starcraft all found a balance with a small number of troops and buildings. Even then, they gradually added all their options in over the course of the game. They don't throw new players into the deep end (the full game); they work up to it over 30 hours or more.

It's like getting decent at chess and thinking, "ok, now that I've learned how all these pieces move, what I need now is more pieces! A larger board!" What makes chess interesting isn't those new pieces; instead, the game changes. The focus shifts to strategy and positional play, thinking ahead and mind games, learning the books and the endgames.

Part of Travian's appeal is its simplicity. If the game got too much more complex -- twice the number of buildings, more complex combat, etc -- then it would be a much harder game to get into. Part of its appeal is its chess-like simplicity. Even in that simplicity there is a lot of interplay, since so much of the game works on an exponential curve.

Good designs are simple designs. Let the fun be in the interplay of a handful of archetypes, not in the mindless proliferation of abilities and powers and resources and buildings and technologies...

Tips on Hiring Agile Programmers

2009-04-27T17:38:00.000-07:00

We're looking to hire another couple programmers here, and while I was talking about it with the coding crew, we had some thoughts, there was a rant or two, so now I'm here.

First, What is Agile Programming?

It's not a buzzword. Agile programming is a methodology, which is just a $10 way of saying it's a set of methods. What brings those methods together is that it makes programmers and the code they write more agile. As in flexible. Bendable. Responsive, dextrous, nimble. Agile programmers should be able to adapt the code they write to changing requirements. That's really the whole point. There's a subthread in discussions about "what is agile?" that basically says you won't understand a problem until you try to solve it, and so changing requirements are a natural outcome of exploring the solution domain until you understand it -- but that's not really my point here. We can argue that later.

Using interfaces and patterns is nice, but that's not agile programming. Interfaces and objects are just a part of object-oriented programming, and patterns appear in any programming language (although most well-known patterns are OO patterns).

One part of being agile is avoiding tight coupling. If there's a one-to-one relationship between two class hierarchies, then any time you add a class to one branch, to have to make a similar change to the other branch. This ties those two trees together; they're now tightly bound. One agile approach would be to use smaller bits, like methods (or delegates, in C#) instead. Or to embed the behavior of the second class in the first. Or to get rid of whatever it is that requires you to have two trees with all of the same class types in them.

Being agile means being responsive to change. Writing all your code through interfaces is nice in theory, but whenever you need a client to pull more information out of a subclass of that interface, you're stuck with a problem -- throw in a using clause, or what? Is the interface providing something specific? If there's a 1:1 mapping between interfaces and implementations, ie one interface class for every implementation class, then you haven't done jack. There's already a way to hide implementation from a client, and it's the fucking private keyword, you moron. If the client is going to break through the interface anyway, then get rid of it, it's not actually hiding anything. You should only write code once; there should only be one class exposed to your client. (A 'using' clause etc winds up exposing two classes.) This is the principle of Once And Only Once. If you've got an interface, there better be a reason for it other than "my teacher told me to." If you're doing something and you don't know why, then you better need to do it to get something to work. If you can skip a step that someone told you was required, and your code works just fine without that step, then you've got smaller, more nimble code. That is what Agile means. (And that your guru is full of it.)

Which gets me to the rant: some programmers do things just because they're supposed to. Like adding interfaces for everything, even if there's no hierarchy there. Or using patterns everywhere. I write patterns all the time, but I don't obsess over it. It just happens. If you have to scan through Gang of Four to figure out what pattern to use, then you're not yet a jedi. That's OK, but it's also not the best way to program. Understanding patterns is better than throwing patterns at a project. That's like throwing bailout money everywhere.

Likewise, you don't need a factory for every object. The constructor works just fine! Just call the constructor! I've seen this problem in programmers that have misunderstood the factory pattern. A builder is a class (or method) that assists with complex construction code; a factory is a class (or method) that can build one of several different objects, and returns them through a common base class (which might be an interface). Again, if a factory only builds one type of object, then why do you have the factory? If a class only has one constructor and construction is simple, then why do you have a builder? Both add to code bloat and complexity, and thereby inhibit the ability of future programmers to add new features or fix bugs. Or even understand what the hell you were doing. And here again is the benefit of agile programming: if your code is small and nimble, you can change it more easily.

Wait, I thought you were talking about hiring programmers?

Many academic programmers heed rules that they don't understand. You want the guys that have figured things out for themselves. There's a lot of clues here to figure out how to tell the first group from the second.

In general, the best way to hire programmers is to get them to do the job they're about to do. Give them a written test before the interview, or stand them in front of a whiteboard and ask them to pop out a design.

Not just a function; a design. The stuff that matters, for agile, is design -- not algorithms. (Algorithms are important, but ultimately agile isn't about algorithms. Test algorithm knowledge, sure, but that's not why you're reading this.) Good programmers have a sense not only of algorithms but also data structures. Good OO programmers can think in module-sized units (as well as class-sized units, method-sized units, or statement-sized units). Ask your candidates to express some designs. If you're interviewing a senior candidate, then he should understand framework-sized units. Ask him to sketch a framework for handling a large, complex data set and a wide variety of operations, probably something related to your personal problem domain. You don't really want a correct answer so much as strong thinking. (Don't judge a candidate by how closely they parrot your personal favorite design, or the one that your office has chosen. That's not what you're looking for here.)

For juniors, start with the simple stuff: persistance and streaming, three-tiered architecture stuff, de novo object creation, parsing. And ask them to get specific; where are the interfaces? What patterns do you use here?

And the money question: why?

The thing to look for is not their answer so much as how they answer. Is the candidate trying to think up a good reason for their answer, or are they just struggling to translate their understanding into words? The faster you can get a candidate to talk, the less rationalization goes on. It's ok if they're stumbling around their words or gesturing a lot with their hands, or just drawing circles on a white board and using too many pronouns -- this suggests that they're thinking of objects, not trying to reconstruct some quiz question a prof gave them once.

Object-oriented designs are inherently visual. They're visual creations. This is why whiteboards are a must in interviews, and why it's very difficult to assess a programmer over the phone.

Getting a candidate to explain what agile means is less important than hiring a candidate that inherently does agile things. And the way to test that is not to get him to talk, but to get him to do.

Noobs and Information

2009-04-10T08:46:00.001-07:00

Many games have large noob populations, and they suck. Dealing with noobs is a pain. They don't know what they're doing, they don't know what to ask, and they're asking all the wrong people in the wrong places.

I think the same thing happens in many domains, not just in online games.

The problem is that the noobs have no information. Games with strong documentation and community features reduce their noob load; games where information is spread out among third-party sources and where game mechanics are not explained by the developer have much higher noob loads.

Warcraft has extensive online documentation, but they still have a high noob load. 'Preventing' noobs requires addressing the needs of the noobs, not the needs of the marketing department. Keeping players interested, getting them to come back, giving them something to look forward to -- these are all great. But it's not what noobs need.

Travian has crappy documentation. There's a lot of different info sites, but many of them are paltry. They focus on a few of the major concepts in the game, and although often broad and deep, are broad and deep in the wrong places.

Single-player games tend to not have noobs. Single-player games tend to require that they explain themselves to new players or else players just stop playing. I've played a number of 'innovative' single-player console and PC games that just didn't make sense. Although these games hint at depth and complexity and something fun, they hide it. And if I can't find it, the game gets returned and I don't recommend it. And I expect they get bad reviews, too.

What noobs need is direction. They need to know how the game scores them. They want to know the roles that they are expected to take. They want to know the consquences of their actions, before they take them. They want a place to go for this information, plus a forum lively enough where they can ask obscure questions.

Direction

Single-player games tend to have scores or mission directives that communicate to players what it is that they're trying to accomplish. Warcraft is fairly open, yet there are a few major goals: get to the level cap (80), accumulate gear, and work through the hardest dungeons. A more subtle point is the things that they should look out for along the way; some guidance on which goals are worthwhile. Many mid-level players worry about gear, spending hours and days getting just the right piece. Then they out-level it a few days later.

Travian takes pride in its opaqueness, supposedly because it gives players 'freedom' to choose their own path. Yet there are a few paths that are extremely useful to the over-arching goal of winning the game. Winning the game is something that's done by an alliance, not by a solo player, or one player that happens to be in an alliance with some friends. It requires the cooperation of dozens, if not hundreds, of players. There are a few strong roles that players can take, as well as some rules for how to be most effective. Yet the publishers don't do any of that; they leave it up to players to discover all of that on their own.

The discovery process can be fun, but there's two important concepts that limit where a game designer should put discovery: consequence (see below) and direction. If a player first has to figure out where he's going, then he's not discovering the game world, or developing strategy; he's figuring out what the user manual would look like, if the user manual had something more constructive than a simple list of all the units in the game and their cost.

Roles

Role is related to Direction. Whereas Direction shows the player what they have to do to win (what obstacles they have to overcome), Role is the set of tools that the player has available to do it.

A Priest in World of Warcraft knows about the spells that he can cast, but a good role is a bit more than "cast these three spells over and over." In a raid, a healer can stay focused on one target, heal several targets, look over a whole bunch of people and top them off -- or stick to some of the utility spells that they have.

Over a career levelling a priest, that player might go Holy (and heal in groups), Shadow (and focus on damage and mana generation), or Discipline (for... PvP?). Ignoring the accuracy of those descriptions, these are ways of telling new players: if you choose this class, you will have these roles that you fit into.

In Travian, roles could be as a Defender, Hammer, or Feeder; one might work solo or in a group. There's an infinite variety of combinations, obviously -- yet there are no general guidelines. Travian noobs wonder what they should be focused on. They try to do all things, without picking a role. They want to be offensive, but don't know how that plays out over a year. It's very frustrating to spend a lot of time on a game building a character (as in WoW) or a bunch of villages (as in Travian) to find out that you made fundamental mistakes early on, and that your current effectiveness is gimped because of it.

Giving new players guidance on the Role that they'll play can help players get started on the road to contributing during a game, rather than observing. Links to discussions will help them understand how other players feel about that role, letting new players find their sweet spot that much faster.

Score

Score defines direction. Score tells players how they win. It gives them feedback, and it's through feedback that players learn to play better. I don't like mashing buttons; winning for random reasons is not an achievement. Score tells me if I mashed the right buttons, so that I can see patterns in the game, start developing a strategy, start discovering the game world, meeting new people, and then killing them.

Open games sometimes have visible 'score' charts that measure inconsequential things. Statistics can be fun to browse; some people like that. I often do. But if you give everybody a useless metric (but one easy to manipulate), many will shoot to maximize that metric, even if it is a detriment to their play experience. If you put up a score-board but that score-board only applies to some players, or is completely irrelevant to the rest, you misdirect your players.

Travian shows village population for all the players. This is the major score rank in the game, since it's something that everyone has and it's relatively easy to see. Yet it, ultimately, isn't a strong measure of performance. But that's a problem with team games; how do you measure 'performance' when so much of the contribution one makes is building social networks, establishing trust, etc?

For vague, open games like travian, maybe the best way to communicate 'score' to players is to give them an overview of previous rounds. Show them the target, and how they measure progress, and then what last round's measuring stick looked like. They might choose a different metric, but at least with this kind of guidance they can make an informed assessment about how well they are proceeding.

Consquences

This was one big problem in many MMORPGs: players were 'free' to destroy their characters, spending hundreds of hours building a character that was sub-par. I remember putting points into Charisma in Dark Age of Camelot. As a Cleric. It did nothing for my character; they were wasted points. The 'freedom' to distribute points as I felt wasn't backed with enough information to make a good choice (unless I had been playing the game through to the end-game already, which didn't even exist when the game first shipped). Further, my choice was hard-locked; it could never be changed. This was a combination of asking players to make choices without sufficient information and then penalizing them, for the rest of their online career, for the wrong choices.

Social Dynamics in Travian

2008-09-07T18:04:00.000-07:00

Travian is a browser-based MMO. I've mentioned it a few times before. The game is a cross between Risk and SimCity. You construct buildings and improve them, train troops, and go wage war. Players have villages that spawn on the big grid, which ranges from -400 to +400 in both X (east-west) and Y (north-south). There are roughly 20,000 people on each server; right now, there's around 12,000 people that have been active on my server in the past week.

Only one person can win, but that win is really for his alliance. And, since alliances are limited to 60 people, his confederation (which is a group of alliances; there is some in-game support for confeds). After a server runs for about 10 months, an NPC race show up. You (and your alliance) beat them up, get plans for a new building type, then you up that building to level 100 (whereas 20 is the max for most building types).

Out of those 12,000 active players, roughly 120 will be said to win. That's 1%. What are the other 99% doing?

Usually alliances in the game divide up into the quadrants -- to the northeast, southeast, southwest, and northwest of the origin. That's four confederations, one per quadrant. Those confederations might be two or three multi-wing alliances, so generously about 1,500 people are in the running to win. That still leaves over 10,000 people that are actively playing and not likely to win.

And let me qualify that 'likely to win' bit. Prices in the game are exponential -- a level 2 building is 29% more expensive than level 1, level 3 is 29% more expensive still, and so on. A player with all level 20 buildings is 29% more powerful than one with all level 19 buildings, and nearly thirteen times (1278%) more powerful than one with all level 10 buildings. If you're not up there at the top, you have no chance to compete.

The players in alliances outside of the top 4 have 0% chance to win. I haven't chased down who has won each game; I'm don't even know that it's recorded anywhere useful. But once you drop off the top dozen alliances, power drops considerably. Number 20 is 1/3rd the size of #1, number 40 is half of #20, and the 60th alliance is an order of magnitude smaller than the top dog.

So what do you do? Or, what do I do? If I'm not in one of the top few alliances, then I'm just ... having fun? Not winning, that's for sure. So why play? Why do other people play?

Judging from the forums, the two main reasons people play this game are (1) they're stay-at-home moms, or (2) they got beat up a lot when they were kids.

#1 is somewhat related to my previous post about who has time to play games that require you to log in frequently -- kids, college students, and the unemployed. Stay-at-home parents are kinda like the unemployed. And those are the people that play. Kids (and college students) are still coming to grips with being beaten up a lot; Travian is a great outlet. Someone pisses you off? Destroy their village and everything they've spent months working on! Hah!

It's a war game, though. Some people lose.

It's funny to see how some people respond to being attacked. A good many don't realize the "war" aspect of the game. And it also seems the developers want to hide that part, too. Not a lot of stay-at-home moms like getting their village destroyed by 12-year-old kids. The solution seems to be "don't tell them that happens," then just hope they don't find out. It's not like every mom gets her village 0-popped. When 12-year-olds gets attacked, whether it's a full-on assault or just a small raid, some of them respond with vitriol characteristic of someone that's just learned some new swear-words and has the freedom to act outside of parental control. More mature

What should someone in this game do when they are attacked? I think a better question is: should you be attacking your neighbors?

There are two reasons to attack another play - (1) to steal some of their resources, called "raiding" in the game, and (2) to destroy some of their buildings and/or kill off their troops. In the late-game, when alliances are competing to finish a world wonder, slowing down your competition is as important as building your own wonder faster. Before that, though, the primary reason to send troops at another player is to steal their resources. A corollary here is to prevent other players from stealing resources, so you attack them to kill off their troops and their ability to train troops.

Stealing resources is a plentiful source of resources. You can easily double your hourly production, and (if you focus heavily on troop-building) gain considerably more from raiding than from you produce through your crops. A maxed-out village will produce over 5000 resources an hour, but can support a couple thousand troops -- which themselves can produce 10,000 resources an hour. Some villages can support 5000 troops, and if that type of village is your capital, it can support up to 180,000 troops. Raiding is big business.

But let's look at this at a meta-level. Either you steal resources from someone else, or they use them themselves. If they use their own resources, they can upgrade their own buildings. The game is fairly balanced, such that each upgrade provides roughly the same return. There's a slight negative bias, such that upgrading a low-level resource gives a bigger ROI than a higher-level resources. Hence, "the universe" produces more resources if you let a low-level farm improve himself. Raiding transfers wealth from an efficient producer to an inefficient producer.

But, because of attacks and raids that prevent a player from building anything, a great many people stop playing. Inactive players are a great source of resources -- they aren't using it. And that's a legitimate reason to farm them; a low-level but inactive user is wasting resources. Anything he produces over his warehouse's ability to store it is just thrown away.

So why 0-pop someone? It removes a source of resources from the game.

Thinking about all this suggests, to me, that the strongest way for an alliance to win is to have a bunch of active players building a bunch of villages, raiding inactive players, and suppressing their foes. Raiding active players, if they're not competing with you for resources, seems to be pointless. And if they are competing with you, then allying with them is a better use of resources than throwing away troops on attacking them.

So why not ally with everyone in your quadrant? That seems like the strongest way for your quadrant to win.

And now we get to "your quadrant." Do you really care who wins? Isn't choosing to root on your quadrant just tribalism? "My quadrant is better than your quadrant!" The other 2,999 active players in your quadrant aren't your friends and relatives. They're a bunch of strangers, half of them 12-year-olds (at least in mind).

So let's come back to why to play this game. If you're competent and active, being big enough to get into one of the confederacies-that-has-a-chance-of-winning isn't difficult. If you're not the sort of person that tortures small animals and snaps at anyone that talks to you, you shouldn't have difficulty getting into those alliances. A little bit of diplomacy and a little bit of activity and presto you're in.

So if you've read this far, you, too, have a shot of winning a Travian game. But why play Travian?

Why play any game? Because it's fun, for a chance to socialize, to build up a cool little city, to compete against other players at a game with well-defined rules, for a chance to take out your aggressions on small forest creatures^H^H^H on other players.

But why attack other active players? Isn't that just griefing? I'll explore griefing in a future post.

Bit Haxorz

2008-08-27T13:50:00.000-07:00

You can change code like:

if (accumulator >= test)
{
accumulator -= test;
x += stepx;
}

into

int subtract = accumulator - test;
int hibit = 1 - (subtract >> 31) & 1;
accumulator -= test * hibit;
x += stepx * hibit;

Magic! No conditionals! You might use something like this if you're working on a REAL inner-loop, such as code that'll run on a GPU or likewise run many times on a mobile or handheld CPU.

Efficient Ellipse Drawing - Part 1

2008-08-27T10:36:00.000-07:00

This is the first in a multi-part series on drawing ellipses, pixel by pixel. Part 1 (this part) covers the basics of shape rendering, using lines as an example. Part 2 covers drawing circles. Following parts will cover ellipses.

My thesis is that any programmer can learn the math and tricks to write shape-drawing code. That's the point of this series -- to show you how to write your own code. If you just want code to copy-n-paste, go to the bottom of this post.

WARNING: Blogger.com likes to eat my code. I've reviewed this a few times, but there's no promise that it hasn't suddenly gotten hungry again. If something looks screwy, drop a comment and I'll take a look.

Background

I needed to implement efficient ellipse-drawing code in the tile editor I'm making, and I searched the net for some sample code but was thwarted. I vaguely remembered the algorithm, but I knew there was some math involved and some tricky stuff to make it fast, so I wanted to get it right. I looked at some sample code, converted it, but it didn't work. I wound up having to re-derive the equations by hand.

Part of the problem is a general problem with all sample code -- you have a specific purpose which may or may not match the sample. In my case, I was working in C# and had to clip the ellipse to the small tile. Plus little stuff, like how you specify the ellipse. A corner-to-corner definition (a bounding rect) can define an ellipse whose center is a pixel, the point between four pixels, or possibly even a point on the midpoint of an edge between two pixels. How do you adapt ellipse-drawing code to those situations?

The answer, really, is that you have to understand the algorithm itself. If you just want a library to do it for you, you can do that. In this case, that's not what I needed. I didn't want to spend an hour or two finding, downloading, installing, and integrating some third-party library -- or even just a single function -- to get something that I could do by myself in the same amount of time. What I wound up coding isn't actually an "efficient ellipse-drawing algorithm" -- I used a subfunction to calculate the error value for each pixel, with no strength-reduction accumulation code to make it faster. For what I was doing, that was fast enough, and the extra work to optimize the function wasn't necessary.

Goal

My thesis is this: line and ellipse (and circle) drawing is simple enough to learn.

Once you understand the basics, implementing your own code is straightforward.

Drawing a Line

Let's say you want to draw a line on a bitmap. If it's a straight vertical or horizontal line, the code is simple enough:

for (int x=0; x<length; ++x)
{
PlotPixel( x, y );
}

When you implement this algorithm in your own code, changes are it's gonna change to something like this:

int data = bitmap->GetDataPointer();
int offset = x + y * bitmap->GetRowStride();
for (int i=0; i<length; ++i)
data[offset+i] = pixelColor;

This is an example of what I meant above when I mentioned rolling your own. Most likely, any time you take an algorithm like this, you're going to change it enough that it won't look like the sample code you're using as a reference. That's why it's important to understand the algorithm. Straight lines are pretty simple, and you might not see much point here, but ellipses are much more complex.

Let's say you want to draw a diagonal line. That's also pretty easy.

for (int x=0; x<length; ++x)
PlotPixel( x, x );

That's kinda cheating, tho. When you adapt that bit of sample code, more likely you'll do something like this:

for (int i=0; i<length; ++i)
{
x = x1 + i;
y = y1 + i;
PlotPixel( x, y );
}

But that just draws a diagonal line. What if you want to draw a horizontal line, or a vertical one, or a diagonal that's at an angle other than 45º? Usually, you have a routine like "draw a line between these two points," and you have no idea where those two points are relative to each other. The complications pile up.

Let me start with changing that function to one that will draw a 45º line in any direction, including vertical and horizontal lines. Say that x2 and x1 are forty pixels apart. I'm going to draw forty pixels; one at each X coordinate. This means I start at X1, draw a pixel, move one pixel to the right, and repeat. This code handles going left or right with a loop:
for (x = x1; x!=x2; x+=inc)
The trick there is that 'inc' variable. If x2 is to the right (greater than) x1, then the increment is positive (+1). If x2 is to the left (less than) x1, then the increment is negative. I actually do the same thing with y.

Another option is to check to see if x2 is to the right of x1; if it's not, then swap the two points.

Anyway, this function will draw a line between two points, either flat (horizontal or vertical) or at a 45º diagonal.

DrawLine45or90( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx < 0) ? -1 : 1;
int stepy = (dy < 0) ? -1 : 1;
int len = dx * stepx;
if (dx==0)
{
stepx = 0;
len = dy * stepy;
}
else if (dy==0)
stepy = 0;
int x = x1;
int y = y1;
for (int i=0; i<len; +=i)
{
PlotPixel( x, y );
x += stepx;
y += stepy;
}
}

On modern machines, conditional code is expensive. Whether you're working on a PC, a modern console, a mobile device, or writing code for a GPU, if statements should be avoided in inner loops. That's why I do this business with stepx and stepy. Those increments also mean you don't need separate implementations for vertical lines, horizontal lines, and diagonals -- this loop does them all. Once you've got len, stepx, and stepy set up, just let it run.

Next: What if you want to draw a line at a different angle, something other than 0° or 45°? That's really the heart of a line-drawing algorithm -- handling lines between two arbitrary points.

From here on (except for the last sample, which is the final working algo), I'll assume that you're drawing a line where dx is greater than dy, ie a mostly-horizontal line.

Here's a simple implementation:

DrawLine( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx<0) ? -1 : 1;
int length = dx * stepx;
int x = x1;
int y = y1;
for (int i=0; i<length; ++i)
{
PlotPixel( x, y );
x += stepx;
y += stepx * (dy / dx);
}
}

This doesn't work, though. If dy is less than dx, then you wind up with a horizontal line (image on the left). If dy is greater than dx, then the line doesn't end at your target point -- it climbs at a constant rate and doesn't match what you want (image on the right).

The y value needs to be calculated in the loop:

DrawLine( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx<0) ? -1 : 1;
int length = dx * stepx;
int x = x1;
for (int i=0; i<length; ++i)
{
int y = y1 + stepx * (i * dy) / dx;
PlotPixel( x, y );
x += stepx;
}
}

The next trick is to get rid of that division in the inner loop. The way we do that is by conditionally incrementing y. This is why we assume a mostly-horizontal line. Since Y will change by either 0 or 1 each time through the loop, we can always change X but only sometimes change Y. For a finished implementation here, you will probably want two functions -- one for steep (mostly-vertical) lines and a separate function for shallow (mostly-horizontal) lines. The code samples will still be able to handle cases where point one is above, below, to the left, or to the right of point two.

OK, so to get rid of the division, we just keep an accumulator, adding dy every time, and check to see if it's greater than dx. We're going to have to watch the signs, tho.

DrawHorizontalishLine( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx<0) ? -1 : 1;
int stepy = (dy<0) ? -1 : 1;
int length = dx * stepx;
int x = x1;
int y = y1;
int yAccumulator = 0;
int yIncrement = dy * stepy;
int yTest = dx * stepx;
for (int i=0; i<length; ++i)
{
PlotPixel( x, y );
x += stepx;
yAccumulator += yIncrement;
if (yAccumulator >= yTest)
{
yAccumulator -= yTest;
y += stepy;
}
}
}

Final Algorithm

DrawLine( int x1, int y1, int x2, int y2 )
{
int dx = x2 - x1;
int dy = y2 - y1;
int stepx = (dx<0) ? -1 : 1;
int stepy = (dy<0) ? -1 : 1;
int lenx = dx * stepx;
int leny = dy * stepy;
int x = x1;
int y = y1;
int accumulator = 0;
if (lenx >= leny)
{
int increment = leny; // note the substitution here
int test = lenx;
for (int i=0; i<lenx; ++i)
{
PlotPixel( x, y );
x += stepx;
accumulator += increment;
if (accumulator >= test)
{
accumulator -= test;
y += stepy;
}
}
}
else
{
int increment = lenx;
int test = leny;
for (int i=0; i<leny; ++i)
{
PlotPixel( x, y );
y += stepy;
accumulator += increment;
if (accumulator >= test)
{
accumulator -= test;
x += stepx;
}
}
}
}

Further Parts

Part 2 - Drawing a circle
Part 3 - pending; circle complications
Part 4 - ellipses

Difficulty Levels in Games

2008-08-26T15:38:00.000-07:00

I enjoy a good challenge, but I don't like losing.

Most console games, e.g. platformers, have relatively low death penalities. Whether it's save points or infinite respawns, dying only sets you back a few minutes -- the time to run back to where you were before. Really challenging games might require that you re-run an especially difficult gauntlet -- the biggest setbacks might be ten or twenty minutes.

The Lego games -- Lego Star Wars and Lego Indiana Jones -- are prime examples. "Dying" means you lose some points, but you can get them right back most of the time. The biggest setback in the game is realizing you skipped a level, that you went through a one-way door and now have to replay the entire level to get back to a previous screen. Which is only relevant if you're trying to get all of the secrets/treasures/etc in a level.

I used to enjoy playing the Hardcore difficulty levels on FPS games, but the single-player portion isn't usually a skill challenge; it's more often annoying and time-consuming than challenging. I just want to see the content. After playing a few levels of Doom 3 on the highest difficulty setting, I decided to go back and play on a lower setting, just to breeze through it.

One of the side effects of that choice was that the game was much less scary. When the spooks and scares didn't suggest that I'd actually die, then I didn't need to fear them. It was actually fun, in a horror-movie sort of way, to conflate the fear of getting your progress thwarted conflated with the fear of the demons. Turn the lights on, play during the day, and crank the difficulty level down, and the game loses any emotional impact it might have had. If you like horror movies, you probably know seeing one late at night is the best time. When the house (or movie theater) is quiet, every little creak and groan can make you jump.

But the Lego games aren't about scares. They're about content. You get to play through the movies, which is fun, and you get to spend time looking for hidden secrets. Both are great fun, and neither one is the sort of challenge that can even have setbacks. I remember playing the old Sonic games, and Mario, and whatnot, and in those, death was a threat. But you only died while you learned a mechanic; after a while, death wasn't so much an ever-present threat as it was something to keep you on your toes. Ratchet and Clank, Banjo Kazooie, and Sly Cooper are similar. Dying (at least, dying several times and losing all of your Lifes) could set you back a good bit, maybe fifteen minutes, but you didn't die that true death very often.

As I mentioned in my previous post (about train tycoon games), I've been playing Railroad Tycoon 2 again lately. I bought RRT3 and Railroads! (aka RRT4) at the same time, and I'll go through them again later, but for now I'm playing through this high-rated classic game.

When you screw up in RRT2, you lose the mission. You don't have to win the mission. In fact, you could just Resign your way through the game and see what each of the levels is about. There's no content block -- the entire game is open to you as soon as you buy it. So what's the challenge? Somewhat like a toy, the challenge is up to you. You don't have to get gold medals, but it's the highest reward the game offers. So you've got a few choices -- play all the missions through, win or lose; win all of the missions; or win all of the missions with gold medals.

For me, getting the gold medals was my goal. It was a bit of a pain, because I had to learn how to make money. I played through all of the Canada mission (#6) and lost -- I had nowhere near enough money to win. I wasn't really sure why. I looked around a bit, and from the comments I saw, I realized that I needed to focus more on long-distance hauls, be less focused on getting strictly to each coast (going to Halifax early is a waste of time), and to spend more time supplying and exploiting the industries available. Another change I made in my second run-through was to be more careful where I laid tracks, exploiting terraforming and avoiding congested routes.

A lot of learning is required to do well. Unlike, say, Lego Indiana Jones, I can't just plow my way through an RRT2 mission and win. The game makes it hard to pay attention to elevations, but I can't just ignore them. The game makes it hard to mind consists and stations, but I can't ignore them either.

When I lost the Canada mission the first time, I felt like it was out of my control. I didn't know what I was doing wrong. When you lose a life in a platformer, it's usually pretty obvious what you did wrong -- there's lava there (oops, didn't see it the first time); you have to fight this boss a different way (and a few minutes of trial and error usually shows you how); or you need to time your jumps and swings and whatnot better. There are skills in some of those games, timing related skills, and usually practice is a trivial way to increase your skills.

In RRT2, I found out that it takes six years (about ninety minutes of real time) to send a train from Halifax to Vancouver. Geez! I started a year too late. Figuring out how long it'd take to send a train that far... is not really possible. The best you can do is to spend a half-hour testing and measuring, and that's a horrid waste of time. F that.

Platformers are often safe exploration games. Or, if you have good combat skills in the game, the challenge isn't too onerous. Once you defeat the foes, they stay dead, then you can go explore without hindrance. Other games force you to explore the mechanics -- how do you make money in RRT2? You have to tease the profit equation out of the game.

And here we get to what I ranted about in yesterday's post: the feedback loop for figuring out that equation is slow. Deadly slow. "F this, I quit" sort of slow. Lose the mission enough times and you go hunt down a FAQ. Why bother solving it by yourself? I kept losing the Whistestop Tour mission as my train ran out of sand, and I thought, wtf?! There's only one way to get the gold medal, and it requires (as the game often does) to ignore the help that the game offers. (That Whistlestop mission offers you an upgrade if you get to a town in time, but there's no way to get there -- none of the engines are fast enough to get close enough before you run out of sand.) These are trial-and-error lessons, but the downside is that you have to error a lot, and spend a lot of time doing so, before you move on.

Games should calibrate themselves to players. If a player doesn't have the skill or the knowledge to get a gold medal, platformers give them silver and bronze medals. They say, "thanks for playing, here's your twinkie" and tell you you did a good job and let you move on to the next game, brag to your friends that you finished, and score a few achievement points.

Telling the player "ha-ha! You lose! Now you have to do that all over again!" sucks. And it sucks in builder games where you build this big cool rail empire... then never see it again. You throw it away. As awesome and profitable and elegant as it was, it's gone. Oh, and cuz you lost? Yeah, you're throwing it away with nothing to show for it but some bruises and an admonition to try harder next time.

The skills you gain when playing sports and lose, at least, are something. Throwing away my cool rail empire and the hours I spent building it just to gain skill at beating the remaining levels -- that's not really a skill I want to be proud of. I can't say "I accomplished nothing last night but learning how to beat this game that I'm gonna play for a couple more weeks then never touch again." Who cares? Getting better at shooting baskets, or pitching, or hitting, and saying "well we lost and I sprained my ankle, but I think I learned a lot about the sport" is worthwhile.

Tycoon War : Transport vs Railroad

2008-08-25T07:47:00.000-07:00

I've been playing Transport Tycoon and Railroad Tycoon II recently, so here's a post on the differences between them.

Obvious Stuff

Transport Tycoon covers all sorts of transport -- trains, planes, buses, trucks, ships, helicopters. Railroad Tycoon has only trains, but adds in economic 'tycoon' gameplay elements -- your "avatar" has a personal net worth, he can buy stocks and receive dividends. Some of the RRT2 missions focus on that aspect.

And that again is another major difference: TT is a toy, but RRT2 is a game. The first hour of TT gameplay is challenging, especially if you start with buses. Making money with buses and trucks is very difficult. They can pay for themselves, but expanding your empire with just road vehicles is definitely a challenge. But if you start building trains and hauling goods, it's very easy to make cash. Once you get a few coal trains running, money is no longer and object and it turns into a toy.

I like the toy aspect of TT. Once I have all the cash I care to spend, I start building giant, all-encompasing rail networks and elaborate switching and signaling systems. Elegant train networks are Art. But, since it's a toy, and because one needs to switch from diesel and steam trains to electric (rebuilding your entire network), and then later upgrade to maglev, you can't just continue making a more awesomest network. So I build up the network to a certain point then start over. Typically my 'games' last for one session, or a day. The next day I play, I start a new game.

Whereas with RRT2, after a few hours, you finish the mission and move on. You don't have to, but with the enticement of future missions and gold medals to be won, why stay with a finished mission?

Building Routes

First, to be clear, both games work with underlying square-tile engines. Track is built from tile to tile, and can go in eight directions (ie the four cardinal directions plus the 45-degree angles).

To build a route in TT, you have to lay track in straight stretches. Vertical climbs are very obvious; a given tile-to-tile segment will either be level, up one level, or down one level. The entire map might have eight or so distinct levels. Elevation changes are an important aspect of gameplay and I'll cover it in more detail later.

In RRT2, you can lay track tile by tile if you want, but the game provides an automatic track-stretching algorithm: select a start, drag to the end, and the game will figure out how to curve the track between the two points. Nearly every pair of adjacent tiles has an elevation change; elevation changes comes in .1 value increments, with slopes of up to 12.0 (or more).

A side-effect of these decisions is that track-laying is a critical gameplay element in TT, and not a concern in RRT2. You can be picky about how you lay tracks in RRT2, but why? The game generally discourages the player from being critical about the path that his trains take.

In TT, when two trains occupy the same track tile at the same time, they crash and burn. In RRT2, one train stops and the other passes. You can build two-way rails in RRT2, but that just means trains can go in both directions -- one can't overcome another. If you have a steep mountain grade or just a long stretch of track, and trains with varying engines and loads, in TT you can build extra rails. That, again, is part of the play to TT -- build efficient routes. In RRT2, since trains won't crash and building (and controlling) additional lines is difficult to do, you basically ignore the problem.

Efficiency is a big part of TT, and difficult to pay attention to in RRT2. Yet it has a very similar effect in both games, and is a critical component to successful route-building.

Elevation

One of the basic mechanics of both games is the option to choose which engine pulls a given train. Different engines have different speed characteristics -- fuel costs, maintenance costs, acceleration, reliability, and how well they deal with climbing. Even with the best, strongest engines, climbing up a steep slope (in TT, several levels; in RRT2, a slope over 2.0 or 4.0) causes a significant slowdown.

The smart track-builder avoids elevations as much as possible. When the money starts rolling in in TT, I start terraforming like crazy -- digging holes through hills, leveling mountains, in-filling valleys -- just to avoid level-changes. Fast trains means more profit. Both games reward quick delivery, and a train that's not climbing a hill can be delivering more goods, too. When you avoid hills, you win twice -- more profit from what carloads you do deliver, and the opportunity to deliver more carloads.

With TT's focus on track-building and the obvious level changes, it's easy to make efficient routes. It's a big part of the game.

RRT2, though.... It basically hides elevations from the user. Because of the fractional level changes and the isometric display, it's often hard to figure out whether a given stretch of land is level or slightly sloped. When you lay track, the UI will show you the level change from tile to tile, but it's not always obvious whether it's a climb or a descent. The game makes it hard to make efficient routes.

Implicitly, then, you're not supposed to be efficient when playing RRT2. Just build your stations and your trains and move on! This is one of the things that defines getting gold medals from missions vs silver or bronze -- if you pay extra attention to what's going on, turn on the grid, carefully lay your tracks, and even do some landscaping, you can dramatically increase the speed your trains take through some routes.

Stations

Station-placement is a minipuzzle in both games. It's surprisingly similar, because of the shared mechanic -- catchment area. TT stations are relatively cheap (tho maybe that's because I'm used to having more money than I need), and their catchment area is always four tiles from the edges of the station (you can create stations that are longer or have more tracks). RRT2 has three different station sizes, with each bigger and more expensive station having a larger catchment area.

RRT2 has missions and it's difficult to establish a cash cow, so you're always concerned about optimizing station placement. Stations are expensive. You're only going to build one in a town, and there's no options to build longer stations or multiple platforms, so you have to choose a good location. Elevation is a consideration, too, for the tracks coming in to a town's station.

Economy

Ok, so you bought your stations, laid the track, and now you need to figure out where to send trains. Both games have Industries that produce goods; some are strict producers (grain farms, cattle ranches, coal and iron mines), others are intermediates (especially steel), and others produce final goods (such as "food" and "goods"). Plus cities generate mail and passengers.

Trains make money by delivering goods that are in demand. TT cares less about 'demand' -- either a station accepts a type of good (and pays a rate depending on how far the good has travelled) or it doesn't. In RRT2, a station will have a demand rate for goods. In both games, stations pay more for goods that are delivered quickly -- especially passengers and perishable foods. Other goods, such as coal, don't "expire" and therefore the pay rate doesn't depend on how long a train takes to get to its destination. TT has a weird model, where it's very lucrative to haul coal across the entire map, which isn't realistic. It's a game, there's tons of unrealistic things going on, but this aspect of the economy model seems out of place.

Trains & Consists

Consists switch things around: in TT, a given train has the same consist throughout its entire life. You buy the engine, attack coal cars and passenger cars and mail cars, send it off, and (usually) never change what's attached. In RRT2, you can change consist at every station. It's easy to set up a route, with one train, that brings grain from station A to station B, and then carries baked bread (ie, "food" manufactured at a bakery from the grain you delivered) back. Unlike the other mechanics I've mentioned above, it's easier to tweak consists in RRT2.

Yet this fits many of the other gameplay elements in RRT2: you can be picky, but who's picky? Specifically, you can change the consist of a train right before it gets to a station (or even when it's unloading), so that it loads exactly what that station has available at the moment. If you spend a lot of extra time micro-managing the game, exploiting the finer points of the UI, you can dramatically improve your return.

I generally stop doing that micromanagement after a while, because it's a repetetive, mechanical task. It's not even a puzzle. It's almost the sort of thing I'd like to assign an algorithm to. More on that later!

Speed

TT's trains move much faster. Both games have map sizes that are roughly equivalent, and both have game-speed controls (letting game-time move faster or slower), so you'd think it wouldn't matter. But one of the side effects of this is that inefficient routes matter much more in RRT2. Since the missions are time-based ("achieve goal X by 1896"), you can't afford to waste time, and one inefficient route can kill you. It takes as much as six game years to cross a map in RRT2, whereas my slowest routes in TT take about four months, and that's for slow trains going up and down hills from corner to corner. Most of my "long-distance" trains take about three months to get to their destination; the vast majority hit a new station once a month. Since journeys take so freaking long in RRT2, several of the missions are to just make one trip -- say, send two trains from one side of the map to the other.

This effectively adds randomness to RRT2. Did this train make money this year? Did your company stock go up or down? Was the route so long the train ran out of sand and water right before it got to the destination? Did you not build the expensive sand, water, and maintenance sheds at the last station it was at? Doing well means either getting lucky, or building your lines to minimize dependence on all this randomness. You're not managing trains and delivering goods; you're figuring out how to build lines that are short, and get a bunch of trains to hit the stations where you built roundhouses.

The slowness of RRT2 also means that it takes years to see if a given plan works out. Was trying to branch out to enough remote locations to get that steel plant running a good move? Years later, you find out: no. Too late, the deadline for the mission is too close, start over. Or, just skip the mission. Play around a little bit, wait til it tells you you failed, and move on to the next mission. If you do that, RRT2 becomes a toy, too -- if you don't care about the goal, then the goal might as well not exist.

I want to succeed, though. I want to figure out how to build profitable train runs, to turn a small bit of starting capital into a big empire. Which means failing missions, and then playing them over and over until I get the gold medal. Bleh.

The Designer Told Me Not to Worry

I'm moving into meta-issues here; consideration of gameplay elements from a game-design standpoint.

It's easy to focus on the factors that a game makes obvious. When games make stuff obvious, the designer is saying "pay attention to this factor." When factors aren't obvious, when they're hidden, it's difficult to assume that you are supposed to pay attention to it. It's like the game designer is telling you not to worry about it.

TT makes elevation obvious. You see specific elevation changes, and work around them. You deal with whole units. RRT2 works with fractional units, and hides them, too, and on top of that gives you a tool for building rail lines that effectively avoids tweaking elevation changes. You can't see what the elevations are, so how are you supposed to take it into consideration? It tells you how steep the route will be, but so what? Can you really work around that? It's the sort of thing that I wind up just ignoring -- until I realized that I needed to pay attention to it, turned on the grid, and started getting obsessive.

Train Management

I'm just going to consider these two models as train-building games. They both provide more, but I want to look at them as lessons for building a similar train-buliding game. What lessons do they teach?

In both games, you spend money buying stations, laying track, and acquiring engines. Then you
make revenue by sending the trains around. Your score depends on how well you manage your engines, and how efficiently you played the station-placement and track-laying minipuzzles.

So, really, let's start there: your SCORE depends on how well you play those minipuzzles, and then how well you manage the resources you have available -- goods waiting at stations, and the trains you have to transport the goods around. Theoretically, the games should make that easy to do. Yet neither really does.

In TT, it's possible to open up a miniwindow for each train; a small version of the game window proper, showing where the train is in the world. If you open a bunch of these, you can see how your trains are doing. This is really only effective for seeing if the train is lost, or stuck in traffic. Checking out what it is carrying -- a full load or not -- requires opening up a sub-window. There is an All Trains window, and you can even put trains into groups to limit what you're looking at. The window shows profit and loss, and (for some car types) whether the car is full. But so what? This only tells you that a route is unprofitable. To change consist, you need to send the train into a depot -- which means taking the train out of service for a while. And also distracting yourself from doing anything else until the train gets to a station. You could leave the window open, and go build more tracks or something, but when I do that usually the train gets to the depot and I don't notice for a while -- and then I have to remember what I was going to do anyway. RRT2 lets you change consist immediately, tho it will only take effect the next time the train arrives at the station -- ie, cars won't magically appear or disappear while the train is en route.

(Speaking of which, RRT2 does let you replace an engine at any time, magically, wherever and whenever, while TT again requires that you send that train into a station. OpenTTD does have an option to auto-replace engines and road vehicles, though, which is nice. It's annoying to require sending the train to a depot, especially if the depot isn't on the line, so this is a bandaid over a bad feature. A better solution would be allowing the player to replace engines anywhere, anytime.)

In TT, you can also pop up miniwindows for each station, which lists the goods waiting for pickup. But since you can't actively manage consists, your primary option for changing what gets carried is to add more trains. Lots of passengers waiting at that inner-city station? Buy more trains!

RRT2 likewise has a trains-list view, which takes the entire screen and shows six whole trains! Omg! Six! The normal UI (ie not this trains-list window) has a listbox down at the bottom that shows all your trains, and it's a great tool. It shows the consist, whether each one of those cars is full (recall, in RRT2 a car is either empty or fully loaded; no in-between), how far it is to its next stop, the name of that next stop, current speed, status (needs water/sand/repairs), and the value of the cargo that it's carrying. This is great stuff -- this is everything you need to assess whether you've got a good route or not.

Except that it only shows four trains. When you've got a dozen trains running and a bunch of stations to manage, seeing only four trains is a kick in the teeth. And you can only look at trains OR stations, not both. The station info panel is also nice; it shows what goods a given station is supplying (and it what quantity), tho not what the demand level is. Again, the view is limited -- only two stations at a time.

Conclusions

Let's go back to my summary of what these games are about:

Your SCORE depends on how well you play those minipuzzles, and then how well you manage the resources you have available -- goods waiting at stations, and the trains you have to transport the goods around.

There are three minipuzzles in both games: station placement, track layout, and engine/consist choice. For the most part, in both games, once you've done any of these (say, placed one station), you don't go back and change the choice. You might tweak a train route, or change a consist, but you can't spend the entire game doing that. Maybe that's how you consistently win the gold medals, but it seems awfully obsessive to me. Tweaking consists at every train arrival is just dull. Plus, I don't want to drag each mission out into a 12-hour marathon session, because (like I said above) if something doesn't work out, you have to replay the whole mission all over again. Bleh bleh bleh.

The strategic element to both games is similar -- what industries to you chase down? Do you branch out to Northern cities, or stay focussed on reaching the west coast? This is great; it's a big part of transportation-empire building. Good stuff.

I just want better tools.

I want TT to tell me, on, say, hover-over, what's waiting at a station. Missions would be fun, too. Some players put out quiz-like puzzles, saying stuff like: "fix this juncture" or "extend this network to include Town X without interrupting the existing traffic." More of that, plzkthx. Get rid of depots. Make train building easier. Since, for the most part, you build a train once, set its route, then leave it alone forever -- flexible tools for managing that route make no sense. The tools should be optimized for the tasks that you perform often. Don't give me the chance of sending a train into the middle of the lake -- if you want me to choose a station, give me a list of the fucking stations. Srsly. Fix the long-distance gravy train and it could be a fun challenge to build a network encompassing the entire map.

RRT2 should start by getting rid of the tycoon aspect. Other than the missions where it's the specific goal, it's completely ignorable. In fact, you should ignore it, because milking money from the company via dividends makes it much harder to grow the company. I haven't even gotten into how labyrinthine the stock-market aspect is. There's a lot of statistics there, but wtf? Who cares? And graphs beat pages of text any day -- TT and other Chris Sawyer games have all had great charts. Give me those. Give me good train and station overview tools. Give me explicit terraforming tools. Let me see more than four trains or two stations at a time, without hiding everything else.

Sometimes when I'm playing TT I think, "I wish there was more variety in the buildings." That's a great thing for a designer to have players complain about, because it means they're not bitching about everything else. And I have been bitching this whole post, but I still do enjoy the game.

Good Minipuzzle Examples

2008-08-20T07:10:00.001-07:00

A couple weeks ago I made a post about minipuzzles, and one thing I left open was how to make good minipuzzles. I'm going to talk about that today, but first I want to summarize what I've said earlier about terminology.

Terminology

Many console and computer games have minigames, like a section within a platformer game where you play a shooter for a few minutes and then go back to normal platformer gameplay. I'm not talking about those.

When I say puzzle I mean what I said about the difference between puzzles and games: they both have goals but puzzles are static whereas games are dynamic, either through randomness or by having an opponent.

Minipuzzles are often not separate activities within their game, and minigames often are. I've mentioned the station-placement and track-layout minigames in train-building sim/tycoon games. Placing a station is a normal part of gameplay. Calling it a minipuzzle calls attention to the fact that there's a subgoal in play -- that you can ignore the rest of the game for a moment and focus on one small puzzle: how does the player place this new game element in order to maximize future score and minimize up-front cost?

Subgoals

That hints at one of the critical factors in good minipuzzles. The station-placement minipuzzle challenges the player to compare up-front cost and future score. The player is making a strategic decision -- should he spend more now to make more later, or are his current funds tight enough that he will just take a cheap solution instead? Is this one particular station important enough to his future plans that he needs to be careful in placement? The conflict between cost-now and revenue-later is a common strategic element.

Making it a good puzzle demands making the decision difficult. If the player can trivially choose the solution to a cost/revenue puzzle, then the decision doesn't add much to gameplay. The question shouldn't be just one of "A or B," as I'm describing it here. The station-placement minipuzzle actually asks the player where to place the station among dozens of possible choices. One placement will capture more big buildings in the town but cost more; another blocks an important road; a third captures a couple big buildings but requires the destruction of another.

Design Your Own

But what about your game? I figure the best way to describe how to add minipuzzles is by example.

I was working on a city-building game recently, and decided I wanted to put some minipuzzle-type ideas into it. City-building was already on a grid, so I had a great start. With a wide range of choices, a player might choose a solution randomly, or based on aesthetics. Limiting the choices gives the player an easier chance to apply a metric to his decisions. I'm reminded of Mark Lepper's research into choice: give people too many choices and they're always unhappy, thinking they didn't choose the best outcome. Like a 401k that offers you hundreds of possible investments, or a an insurance plan with dozens and dozens of options. How can you evaluate them all? You can't, and the result is a nagging feeling that you chose poorly. I've used my buddy Antoine's quote before and it's fitting here, too: "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove." Make the puzzle simple and limit the player's choices.

OK, so you've got a grid, or some other mechanism for restricting choice, now what? A friend pointed me to Medieval Conquest recently, and the game CD had a demo for School Tycoon on it, so I played that briefly. At the beginning of the game, it's hard to tell what a good metric is for placement. Buildings go down on a grid, but it's very difficult to tell what makes for good placement. This is the second key: give the player a visible score. In Transport Tycoon, you can see the size of the catchment area that a station will give you, so you immediately have an idea of how much traffic the station will generate. You also see how much it'll cost you. By giving the player explicit metrics, they are left with the strategy choice of A or B as well as trying to find new arrangements within that limited grid that maximize their chosen balance, too. If School Tycoon had made some placements more expensive (say, by requiring the removal of trees or levelling ground), or included a mechanic that makes some placements more effective and easy to score, then I could have seen a puzzle there. As it is, building placement in that game seems random to me. What makes one placement better than another?

Hiding such factors from new players does add depth to the game -- experienced players will develop a sense for good placement, not just for one building but maybe for a cluster of them. However it removes placement as a minipuzzle. The game seems random to new players, and that means sometimes they'll have an easier time playing the game and other times it'll be harder, and they'll have no idea why. With challenge mismatched, they could be bored or frustrated, or switch from one extreme to the other from play-through to play-through. And then they hate your game, return it, and tell all their friends not to buy it, your publisher will start to hate you, and then your dog will die. :( This whole chain of events could be avoided by giving players an obvious building-placement score up front.

Let me switch genres here. There are elements of World of Warcraft that I consider minipuzzles. Farming mobs can be a puzzle: the goal is to maximize drops while minimizing downtime. The player considers drop rate, their own talents and gear versus that mob (which decides which particular mob they'll have the easiest time farming), and where the mob spawns are. The puzzle is to minimize downtime, either waiting for mob spawns or regenerating health or mana. There's a bit of randomness to this puzzle, so it is a bit game-like, but that's why I mention farming: over thirty minutes or an hour of farming that randomness disappears into noise. The player is left considering, "which of my abilities and in what order do I use them in order to maximize the number of drops that I get per hour?"

Here we have the first two elements: limited choice (the player only has so many spells and targets to choose from) and obvious score (kills per hour, which leads to drops per hour). But there's several subtle points here that makes this such an intriguing puzzle. Some abilities are obviously much better than others; very low-level spells don't pack enough punch to count and some creatures are resistant to certain spells.

But consider DOTs -- damage-over-time spells. They are often expensive to cast and they do a lot of damage, but getting maximum benefit from them means the target should be left alive for the spell to run its course. Throwing it on a creature early in a fight is better than later in a fight, but it's possible that the mob might die too quickly for it to matter anyway. The player might run out of mana after killing a few mobs because he's not making efficient use of mana. Each individual mob dies quickly, but the extra downtime means the player's kills-per-hour number goes down. The player has wound up chasing the wrong goal. At first glance, it's easy to assume that the faster you kill one mob, the faster you kill a hundred, but the addition of downtime complicates the equation. Maybe the best solution is to dot up a bunch of creatures and then run away and let the dots run their course!

This puzzle is interesting because of the interplay of several different game elements. One combat session -- killing one creature -- is the putative goal, but it can't be considered in isolation.

Conclusion

I don't think Chris Sawyer thought of station placement as a minipuzzle when he designed Transport Tycoon. I think the minipuzzle is a natural outgrowth of other design decisions made along the way. The same with World of Warcraft. Farming is a minor part of the game; it's not necessary to play it, and many people skip it completely.

Yet we can still analyze these games, see what was done well, and steal those ideas for our own.

In the next post in this series, I'll cover some minipuzzles that I tweaked in some of my own projects, and consider how I might change other games in order to emphasize the minipuzzles in them.

On Writing

2008-08-14T20:48:00.000-07:00

It used to be, when I wrote emails or posts, that I'd spend an hour or more on any decent-sized bit of writing. With this blog, I'm more taking the approach of just spitting out words. The main pages that I go back and give any sort of edit to are those that have somehow garnered hits. My page comparing the strategy and bridge patterns, for example, has been popular, so I went back and cleaned it up.

Usually I start with an idea, something I want to rant about, or a point I want to make. And generally that means starting with an anecdote, the one that prompted the rant in the first place. Or maybe something that gives back-story.

Usually it took me til half-way through the post before I figured out what my point was, and then I'd go back and revise the structure in order to make that point clearly. I reckon that'll happen with this post, too. I just ... rant ... until I figure out a good point to make.

I think the best (short) articles make only one point. My dad likes to write in to newspapers, and he often tries to shove in three or four or more points into every letter. The result is thin -- letters to the editor have to be short, and if you spread that space out then each point is that much weaker. Writing such letters should be an exercise in finding the best, most effective points. Throwing in snide asides also destroys any hope that anyone other than "the choir" would be willing to listen to the rest of your message.

My blog posts have been larger than such short letters, however. They're like medium-length magazine articles -- maybe long magazine articles, given the growing tendency towards shorter articles and more pictures. I'm free to make a few points.

But making one central point is still key. So maybe that's my point here: make one central point.

In what I think have been my best posts, I've gone back and put in a proper introduction and conclusion. I also think it's critical to give an outline at the start of an article. This ties in to what I think is the best way of explaining new concepts: give a broad outline, give some examples, give at least one counter-example (to help set the boundaries of the concept), and summarize at the end. The introduction and the conclusion can almost be the same material.

Public speaking is somewhat related, although there other factors come in to play. For example, I think starting with a suspenseful question or introducing a stirring story at the top of the speech is a great way of generating and keeping interest. Speeches often have captive audiences. With the written word, your audience can glean information much faster but can also leave as soon as they get bored. So should written articles be even punchier? Meh. I don't mind if people don't read my blog. I figure, if you want the information, you'll read it anyway.

Which is a crutch. I guess I shouldn't do that. That makes me want to sit and restructure this post -- but I've decided to take the approach here of not editing and using this post as a comparison point for my personal edification. I have a feeling I'll come back to this post in a month and revise it.

Until then, revel in the spaghetti.

Oh, yeah, another point I wanted to make: people that make forum posts that are filled with bad grammar, spelling mistakes, txtmsg abbv, and a lack of capitalization or punctuation are posts that I ignore. If they can't be bothered to spend a few minutes not speaking like an 8-year old, then I'm not going to spent more time than that trying to decipher their meaning.

I remember reading someone with ADD that said that they tended to make titles and subject lines that had nothing to do with the post within, knew that this confused people, and even acknowledged that he had this problem -- but decided to blame it on ADD, instead of deciding to fix it. What an ass. Knowing that you're doing something wrong, stupid, wasteful, inefficient, whatever -- that's 90% of solving the problem. If you know you have a problem but then intentionally, consciously refuse to fix it -- that makes you a bad person. Even Hitler wasn't that evil.

And with Godwin's law invoked, I'm off. See you next week.

College Degrees and the Game Industry

2008-08-13T18:58:00.000-07:00

http://game-engineering.blogspot.com/2008/08/difference-between-pros-and-amateurs.html

Do you need a college degree to get into the games industry?

No. But...

Is it helpful? Hmm. It might be helpful but definitely not required. I know a number of good programmers that don't have college degrees -- one is a programmer in the financial industry. Most dropped out, one left after a clerical error meant he had to take a year off. He spent that year working at a studio headed by one of the most-recognized names in game design.

Do you really want to work in the games industry anyway? It means long hours, with no creative input, and no job stability -- in exchange for working on games. Work is still work; you still have to show up every day and put in hours debugging someone else's code and working with poorly documented 3rd-party libraries.

I've left the games industry to be an indie developer, in my spare time. I have a day job in the normal tech industry, which pays much better, has more job stability, and requires fewer hours. No all-nighters, no all-weekenders, no six months of crunch time.

Greg Costikyan's article Death to the Games Industry brings up some important points about the iniquities in the industry -- as he does also on his blog. Hmm, in fact, his GDC rant is described as "on the iniquities of the game industry".

In short, the business of the games industry is set up so that the vast majority of the profit goes to publishers and company owners, and a vanishingly small amount goes to the line programmers, artists, designers, musicians, and writers. You'll never get rich by joining the game industry proper, nor are you likely to achieve much in the way of critical acclaim. The one-man shops from a decade or two ago have gone on to become famous studio heads, but except for the indie and mobile markets one person can't build a game by themselves. Even then you really want to contract out bits like art.

Getting into the industry requires either real job experience (doing something other than java crap for some defunct web startup) or an awesome portfolio. I recommend getting both. Get a non-games job in your field of interest and work on indie projects on the side. Indie distribution is growing, so it's becoming easier for someone to carve out a profitable and self-sustaining niche.

And that brings me to my point: get a college degree not because it will help you get your first job in the games industry, but because you probably don't want to spend your life as a nameless cog at a faceless international entertainment conglomerate. Maybe you'll do games for a few years and then want out. Or maybe you want to pursue this indie, spare-time route. If you're young and have free time that you'd otherwise give (for free) to a game company, spend it on your own pet project. You'll own it, it'll be a great resume addition when you do decide to move into the games industry, and hopefully the industry will grow to support indie games.

If you really do want to get a job in the games industry, then definitely prepare a serious demo. I talked about the big difference between pros and amateurs in a previous post; if you act like a pro when you're not yet in the industry, your application will be much more impressive.

College is not for preparing yourself to work in industry. Computer science is something academics and researchers do; programmers are more like engineers or craftsmen, not scientists. Go to college for the beer, being well-rounded, joining a fraternity, and meeting babes. For all that, it's definitely worth it.

Mental Economy - Communicating with Programmers Part I

2008-08-12T21:02:00.000-07:00

Good programming style is more a matter of communicating well with other programmers than capturing an algorithm elegantly. Sometimes that other programmer is you, in six hours or six years. Being a good programmer starts with good problem-solving skills and a broad knowledge of both algorithms and APIs. Good employees are disciplined and self-starting. Beyond that, on almost any scale of project, is writing code that can be easily understood.

There are a few aspects of inter-programmer communication that I want to cover. The first is mental economy -- how much data your brain can work with at one point. Part two is about jargon, and in the third part of this series I'll cover grammar.

I was working on ellipse-drawing code the other day and, while mired deep in the math, realized that I didn't have a lot of bandwidth to deal with other bits of the code. I've talked to (and, unfortunately, worked with) a number of programmers that think they're great if they can solve really complex problems and fix deep bugs in spaghetti code. I think it's worse having a manager that thinks the mark of a good programmer is fixing deep bugs in spaghetti code.

The problem with spaghetti code is that you spend all your mental powers unraveling the spaghetti, rather than solving the problem. Part of the problem with the ellipse code I was working with was that the paper I was reading from had bugs. So, not only did I have to read and understand what the code was doing, I had to reverse-engineer the algorithm they were using. They had comments like "it's faster to do it this way", without explaining why, or even what the 'stupid' way was.

I liken the brain to a CPU. An x86 CPU, to be specific, according to its architectural definition rather than its actual implementation, which is even worse. Details aside, it only has about 7 (plus or minus two) registers to play with. Having to deal with chasing down the meaning of a new or unknown or poorly-explained piece of data means saving some state off to long-term storage (e.g. a piece of paper), exploring a bit, and then reconstructing where you were before.

That's the point of variable names, subroutines, and classes. It's not to elegantly capture behavior; the purpose of "elegantly capturing behavior" is a means to the ends -- the end of minimizing the subroutines that you'll subject your brain to when you try to parse code.

You can either be born brilliant, or trained. About half of the great programmers I know have learned to be brilliant. They're rational, methodical, skeptical, and mentally disciplined. Writing code that is well-organized makes it easier to read code, and that makes that code easier to extend, modify, and debug. They "work smarter, not harder." They don't have to waste brain power untangling spaghetti, or mentally keeping track of dozens of variables and routines and equations.

If you haven't read that George Miller paper (the "plus or minus two" link above), I highly recommend it.

The Difference Between Pros and Amateurs

2008-08-11T19:35:00.000-07:00

I always thought I was a good programmer because, you know, Dunning-Kruger. When I got my first programming job we were using a language of which I only had academic knowledge, and I knew I was out of my depth. I spent many weekends reading and studying and trying stuff out on my own in order to get up to speed and learn everything I could about this "Object Oriented" stuff.

A few years later, I got into the games industry. At the time, I had been following John Carmack's .plan updates, reading books and forums, and trying out computer graphics stuff at home. I had demos and knowledge, but even then, I knew that I was "the new kid" in a company filled with industry amateurs. Whatever I already knew about C++ and assembly and computer graphics, I was working with people that had already been in the games industry for years.

Same thing when I got into C# and Web Services, and then with ASP.NET, etc etc.

The difference between pros and amateurs is that pros do it 40 hours a week.

When I was in the games industry proper, I was typically involved in the interviewing process. Many of the candidates that I spoke to had no prior industry experience, but had taken some classes at school, or done some stuff on the side.

The difference between a year working for a game company and a year taking a class is astronomical. A class is three hours a week of instruction, and maybe that again on a project or homework -- and that's just to learn the basics. And you get the summer off, and a few weeks for Winter break, and so on. A year working for a game company is 60 hours a week working on games -- whether that's art or code or design. Plus whatever books you read on the side (for me, easily more than I ever spent reading textbooks in school). Plus the side projects you work on when you're home. Plus meals and recreation time with other industry insiders.

If you want to get into the games industry, don't read blogs for hours every night and think you're learning. The agile manifesto applies here as well: you learn more by doing than by thinking. Thinking through stuff is great, researching is fine, but there's no substitute for getting your hands dirty.

I remember Dave Sim (of Cerebus fame) saying something along the lines of "every artist has 3000 bad pages in him before he'll draw any good pages." Pretty much everything is like that. Sure, you play Guitar Hero on the weekends, but are you a guitarist? Hah, no-one really thinks that. It takes a couple years of practice before anyone would be willing to pay to hear you play. Art is the same way -- remember those art geeks back in high school? Some of them were pretty good. Not, like, professional good, but pretty damn good for high school students. It takes a lot of effort to get good at something. Games are, of course, the same as everything else!

I'm working on a few WinForms apps on the side, and building them has taught me far better than books. Books are great; they're a leg up. They point you in the right direction. But when you need to do something, having experience under your belt is a much better resource than a book. Some books are better than others in this regard. The Wrox ASP.NET 2.0 Problem - Design - Solution book is great, because you do something useful by following the examples. Reading it is ok, but actually building the samples yourself is much better.

And again, compare that you building your own app. Consider what the professional developer is doing -- he has to get something working. He's on a deadline. He's got a boss looking over his shoulder. He's got a client to impress. He's spending forty hours a week getting his hands dirty.

Are you?

If you want to get into the games industry, then take it seriously. Make it your hobby. Build games, code tools, craft models, paint textures, construct levels. And not just on the weekends, and not after spending the day surfing the web, doing "research."

Quitting - Online Game Addiction

2008-08-10T16:53:00.000-07:00

I'm addicted to Travian. I know it's a bad addiction. Yet knowing that, I still don't quit. I write that line and think, "is it really a bad addiction?" Why is it bad? If I could convince myself it's a bad thing, I'd have a much easier time quitting.

I want to do something else with my time, but I also want to preserve my investment in the game. I want to keep growing. I'm close to several big, short-term goals in the game, and I want to keep going until I get there. I don't throw away perfectly good clothes, or a working LCD monitor, or books, or even old computer games that I've already played. It's weird with a game, because what's there has value -- but only to me (but see below), and only in that game world. It's not like I could put this account up for sale on craigslist. It's like sentimental value in that regard, like a useless trinket purchased as a souvenir of a fun time that I once had.

I quit World of Warcraft three times. The first time was because guild drama made playing frustrating. The second time was because I wanted my life back. The third time I quit, it was because I lost interest in spending the time in the world and I found something else that I wanted to do more. I'm ok with playing games. It's like watching movies, or TV shows, or whatnot.

The thing about online-game addiction is that you can't really "sleep on it." I think it's best to quit cold turkey -- to announce to everyone that you quit and get on with your life. Often there's sufficient value in the game that you might want to preserve your progress, to sell your characters off or give them to friends. (No sense in all that value going to waste.)

That value is why I don't want to leave. I have a level of progress that others might envy. (Obviously a great many players wouldn't envy what I have, because they already have more. The same is true with level 70 WoW characters, for example. My point is that there are people, and a good number, that would want a shortcut to a high-level character and/or account.)

--

I decided to just take a break and leave the game for a few hours. It worked. I haven't deleted the account, but I don't feel the pull to sit and watch constantly. I don't know if a cold break is better than slowly toning down doses, but if the rest of me (ie my conscious mind) has decided that I don't want to play any more, then I just need to give it time. Eventually my desire to play will go away.

Powerful Players as Incentive

2008-08-07T19:31:00.000-07:00

One of the things I mentioned in my previous post is the way that powerful players -- those with high scores, cool gear, and achievements -- serve as role-models to new players.

It is often not, strictly, the players themselves. It's not like they spent their lives getting good at a sport, or a musical instrument. We're talking gamers that spent too much time in a raid dungeon or playing their XBox and so did something that nearly anyone else could do, given enough time. "Role models" isn't the right word; I guess I'm hunting for a better one.

When I was playing WoW, I took a break after about a year of playing, then came back a couple months later. I remember talking to a new level-60 priest and he said I was regarded as one of the best priests on the server. I was definitely one of the best-geared, having played on that server since opening day, but best? How does he know?

I've felt the same way myself, about other accomplished players. And friends. I see someone with high scores, cool gear, etc, and I want to match them. Their accomplishment is a challenge to me, to do better myself, to match (or surpass) their score.

Knowing something is possible is a big part of the incentive to me; it's knowing that I could be even better. It's like, I think I do well and then see a bigger score, and say, "hey, I'm a good player, too, I should have a score that high." I want to have the high score but I'm not as concerned with letting people in my real life that I'm the one with that score; for me the draw is testing myself against a known measurement.

There's a lot of different incentives, really. One of the other incentives for me is closure, which drives collecting. It is an encouragement to get a full set of Tier X equipment in WoW, or to collect all the Pokemon, or have a full set of Magic: The Gathering rare cards from a certain set, etc. Other goals include wanting to be on top; to measure themselves; to crush other players; accolades; or keeping up with siblings or friends. I mentioned jealousy and greed yesterday.

These are all drives that come from seeing other players that have already achieved these goals; I'm not talking about the Achiever/Explorer/Socializer/Killer spectrum here. This isn't really just an achiever thing either -- at least, I don't consider it to be. My point isn't that players want to achieve these things, it's that they see other people that have achieved them and are motivated by that to go do it themselves.

The Lesson here is: make your achievements visible. Give players a chance to show off their
accomplishments. Make sure new players are exposed to the wide variety of power-ups in your game.

And the ways of going about that are plenty: leader boards, flashy gear, XBox Live-style achievements, and providing some way for high-powered and low-powered players to mix.

Mini-Puzzles

2008-08-06T18:17:00.000-07:00

I've talked of minigames before, in my previous post about game theory, but when gamers say "minigame" they mean a complete game-within-a-game. Run around in a platformer, take control of a gun emplacement, play Tetris or Breakout or Artillery, break down a wall -- then go back to running around.

The station-placement "minigame" in Transport Tycoon is somewhat gamelike, but the score is ephemeral. There's no win or lose; there's just "better" and "worse", and those measures are fuzzy. I think of it as a puzzle, since there is no opponent, no time limit. There's a goal, and a rough measure of score, and that's it.

What's great about Transport Tycoon is there's a ton of these puzzles in the game. Station placement, track placement, route optimization, and building fast & efficient intersections ("junctions" in the parlance) are all puzzles. And I like puzzles. :) I've got a handful of Hanayama cast puzzles on my desk at work, burrs and other wooden puzzles at home, and I can solve a Rubik's cube. So the game fits me.

One of the main differences between mini-games and mini-puzzles is that the puzzles are integral to gameplay; they are almost meta-games, in that doing such puzzles well achieves a goal beyond what the game sets for you. There's a group of players obsessed with crafting elegant junctions -- both fast and eye-pleasing.

This is definitely the sort of mechanic that makes every game better. Not every player needs to enjoy it; seeing the creations of others is an incentive to try your own hand. These complex junctions are inspiring. As with seeing high-level players in WoW, or the high scores on your favorite XBLA game, knowing it is possible is encouragement to try it yourself. Whether it's jealousy or greed or curiosity or admiration that drives players to achieve the same power doesn't matter. Because your players want to play more.

Would you rather make a game that other designers rate highly, or a game that players love?

My answer is, clearly, the latter. I'm offended--morally offended--by designers that look at games like Myst or The Sims and say "I don't know why people like those games, they're so stupid." That's a topic in itself that I might discuss later but let's gloss over it for now.

Or maybe not. My point of view is not to make games because I want to express myself as a designer -- I want to make something that people will enjoy. Some money would be nice, too.
My goal in this post and in this blog (as it relates to game design) is to figure out how to entertain players.

So back to the topic: I think minigames are 'cheating'. It's easy enough to 'design' a minigame because they are, generally, just executions of known designs. There's some GBA title that I remember being mentioned on Penny-Arcade that's like a billion different 15-second minigames so obviously there's room to stretch. (I feel like I should go look that game up.) Part of the power of the minigame comes from a player's experience with the genre of minigame, however. The power of a minipuzzle by contrast is that it forces the player to make a decision about how he is going to play the game proper.

Take track layout in Transport Tycoon. Building a cheap but speedy rail line around a mountain is no easy task. Yet how that player builds the line affects how his game develops -- if there's enough of a detour to go grab another town easily, if his line will be easy to upgrade, if he needs to buy different engines just to handle this one tricky stretch, etc. And basic stuff like how much he spent on it, and how efficiently the mountain line gets goods to and from each side of the hill.

--

Now, do I have a conclusion? Hmm. The lesson, if any, is "add minipuzzles." The tricky part is how. Sounds like a good future topic, eh? Part II in this series explores several good minipuzzles and examines what makes for a good minipuzzle. Part III, not yet written, will look at ways to add and improve minipuzzles.

Time Sinks and Addiction

2008-08-05T18:56:00.000-07:00

Can you be addicted to something that doesn't take much time, money, or energy?

I was thinking about games that pull me in and don't let go. They're addicting because they're demanding. Most games are very demanding; you're either playing or you aren't.

But there's a bunch of games that aren't as demanding -- browser games, play-by-mail games, play-by-email games, the turn-based games that were popular on BBSes back when that was cool, etc. You play once a day, or maybe more, but you're not stuck to the keyboard. I don't think these games are very addictive. You might wait expectantly for the next turn to show up in the mail, and maybe that's a bit addictive, but it's also easy to go a week without playing, or planning, or thinking about the game other than "I hope my turn shows up soon."

Except Travian has been like that for me. You don't need to be at the keyboard all day, but it helps. There are those that play "speed" servers like speed freaks, and have "sitters" (people on the other side of the globe) that play the game with them -- where each one of them plays the game for 12 hours a day.

You can play the game by stopping in once an hour, or every three hours. The game is like compounding interest, though. You collect more resources, which you use to make bigger fields or more combat troops, which then respectively either produce or steal more resources. Which you then re-invest in bigger fields or more combat troops.... The faster you re-invest, the greater the growth. If you delay in turning around those resources, you'll collect a certain percent less -- say, 10%. And just like compounding interest, over the course of a week that 10% turns into 100%. Week on week, it adds up to orders of magnitude.

For me there's this very real, mathematical incentive to re-deploy troops as soon as they come back. Why leave them sitting around when they could be out making money for you?

In some sense the game's a time sink. A more elegant troop-command interface would make sending out raids faster, especially when one is raiding the same targets over and over. A way to queue orders for, say, an entire day would mean you don't need to log in and check so often.

And yet the game isn't like that. I feel compelled to log in, in order to play "efficiently." I'm addicted; I need my quick little fixes, over and over. I keep coming back for more, obsessively pounding the lever and getting my food pellets in tiny doses.

A similar mechanism happens in "full-time" games, ie games where you generally stay logged in / connected / playing for longer sessions. Tetris has levels; Diablo has levels; World of Warcraft has character levels; Half-Life has levels; Guitar Hero has songs and venues and stars; Mario has stars and levels; etc etc. There's always "just one more" task, and it's small.

Sometimes the task is, well, kinda stupid. I'm sitting here thinking about how to spend less time mucking with Travian, because I'm obsessing over it at the moment. I was tempted to just delete the account, about an hour ago, and move on to the next game -- or get back to writing code. That's because there's not a lot of 'game' to Travian. It's a bit like Chess in that regard; the pieces move rather simply, but it's the complexity of human opponents that makes the game so rich. It's not a puzzle, nor a simple strength or skill test; there's a lot of strategy involved in doing well. (Strategy of the planning variety.)

Addictive games give out rewards frequently. When the player expects some new trinket in a short while, they'll keep playing, and then stay, expecting the next trinket. There's easily more complexity to add here -- such as adding high-level or bigger rewards every so often. And tons of other stuff. But the basic notion -- small rewards at frequent intervals -- is the heart of addiction. All the better if the game demands constant attention and rewards that attention.

Ownership, Aggregation, and Composition

2008-08-02T19:21:00.000-07:00

Object Oriented Programming has a lot of associated jargon. You don't need to know the jargon to be a good architect, but understanding the concepts is important.

Short Form: composition is when class A owns an instance of class B; aggregation is when class A contains a pointer to class B (ie as a member variable), but doesn't own it. (Ownership implies that when the owner is destroyed, it will delete its ownees.)

Problem

There's lots of other sites that explain these things. Do they do a good job? I don't think so. I think most of them are targeted at either someone that knows nothing about OO, or someone that knows it fairly well but just wants a refresher. Like me. What's the difference between aggregation and composition again? Oh, composition is when you own the object, yeah, ok... If you aren't familiar with these concepts, then go read up on OO. I'm assuming that you've run across them before, and most likely distinguish between these two when you're writing code.

It's the sort of thing that's almost automatic, if you've learned to avoid pitfalls. Ownership is an important concept because of memory leaks. In C++, you've also got to be wary of dangling pointers and double-deletion. Back (in the olden days) when I was writing C++, I was always very careful to mark which class owned a given object.

In complex projects (especially games) you often have a ton of different objects which each have to reference the same thing. Bullets are fired by players, need to be drawn, create visual effects, collide with world geometry, etc. And in order to optimize several subsystems -- graphics and physics being two time-intensive subsystems -- you might have arcane container types. So how do you keep everything in order?

Solution

The answer is explicit ownership. Make it clear, to yourself and to whomever else is using the code. Put it in comments in the code, probably at the variable declaration and also in the header file for the contained class. If you scribble a diagram up on your whiteboard, make sure you're marking ownership clearly. Have only one owner.

Stay away from two owners. Good architectures would be having one clear owner, or having many owners -- like five, or twenty. In the latter case, you'd use reference counting or some other scheme to control deletion, such as using a globally-accessible (ie Singleton) container or manager or cache for those objects.

Sometimes the problem is something like this: bullets belong to players, but are aggregated within some class in the graphics system. But then a player logs out, the player object gets deleted, and now the graphics system has an empty pointer. Do you reference count this object? Do you keep the player object around (even after the player has logged) until all associated objects are deleted? This latter solution is why you often see players still in the game after their connection has died -- it's not so much an issue of the game not noticing the player has disconnected as the code doesn't want to delete the object yet.

Usually the cleanest solutions I've found to these my-two-dads sort of problems comes from thinking laterally. Do something completely different with bullets. Maybe a custom "reference count" used only by those two systems (although I think this is a hacky solution). Maybe bullets aren't owned by players at all, but contain a reference to a player ID allowing whatever system deals with the bullets to back-track to the player without having to worry about the player object still being around.

Jargon

The are two reasons to learn standard OO concepts. One is to help you become a better programmer. The other is so that you can communicate these concepts to other programmers. For any given concept that you learn, it's important to have a tag, a name, a label by which to refer to that concept. Having to say "that thing where you own this object that then has a pointer to a base class" is messy, when you could just say "bridge" -- which also captures a bit of intention, as well as architecture.

Say someone comes up to you and asks you what the difference between Aggregation and Containment is. Do you know? Can you explain it clearly? Probably only if you use those names a lot. I think ownership is an important concept and I use that word a lot in my code -- but I don't say // this object is aggregated or // contained. That would be lame.

I know the difference between the two. I don't think I'd be able to explain which one is which next week. Maybe, because I spent the time to write a post about it -- but that would be why, not because I use those words all the time. I think they're an awkward way to look at a more fundamental issue -- ownership.

Status as a Game Mechanic

2008-08-01T20:07:00.000-07:00

Note: I've been using "mechanic" to refer to what the game does "behind the scenes", and using "gameplay" to refer to what the player does with his time. However I'm used to using "game mechanic" and "core mechanic" to refer to what I'm now referring to as gameplay... I think I need to revise my nomenclature. (See my previous post on game design theory for some discussion on these terms.)

Definitions

Players give many reasons for playing games, but do you trust your players? Are they all sufficiently introspective and educated to understand their own motivations? They know if they enjoy something, but I'm talking about why they enjoy it. I'll go into my own theory of fun at some later point, but for now, let me say that one of the reasons that players enjoy games is the status that they can show off for their achievements.

I'm not talking about achievement directly. If happiness is the achievement of value, then a well-adjusted person is happy (and enjoys a game) when he achieves game goals that he values. But that's not status -- status is telling your buddy how you did in the game last night, or riding your new mount through a capital city in Warcraft.

The issue is a bit complicated becomes there's both showing others as well as knowing that you achieved that status item. The braggart doesn't care about getting a status item except to the extent that he can brag about it. The latter is like the guy I mentioned above, someone that has internalized the game goals as his own values and enjoys the status symbol as a record of achievement.

My point is that it doesn't matter why a given player wants a status item -- just that he does want it.

The lesson is obvious: put status items in your game.

Examples

Many games have implicit status items. In RPGs, it's your character's gear. This is one of the great driving forces in WoW: do you have your dungeon 3 set? A flying mount? An epic flyer? Tier 4? Tier 6? Legendaries? Status in MMOs also comes from the group you play with: has your guild cleared Kara, Gruul's, or Black Temple? How far are you through the Plateau? I'm calling these status items implicit because the only obvious score in the game is your level - and is the same for all players at max levels.

In platformers, progress through the game and the accumulation of collectibles and tokens are status indicators. The game tells you what the status items are, and how many you've gathered so far. Yet these items are intrinsic to gameplay; the game is essentially nothing but pushing your status up.

In multiplayer first-person shooters, your status is your standing on the leaderboard. There's not much else to the game other than that score. Single-player shooters might also have a leaderboard that's shared; XBox 360 games typically have a Live component that shows how you measure up against the playerbase. (Level-based shooters have implicit status measured as progress through the game.)

The 360 brings up another way of gaining status: achievement points. I was playing Guitar Hero with a friend last weekend and he was going for a bunch of easy achievement points to push his Gamer Score over the 20,000 mark. We were joking about the arbitrariness of the achievement, even while going for it.

That's the way the brain works

It's the way the brain works -- which is my message here. Even if you know you're shooting for an arbitrary or meaningless goal, you do it anyway. Some people gloat in their shiny new beemer or tier 4 set piece or gamer score, and for them status symbols are clear motivators. The rest of us kinda catch the same disease by association. We might not feel the need to tell everyone about our status, yet we seek it just the same.

It's the score, it's what you're supposed to do.

This ties in a bit with my previous discussions on open worlds. Be careful of removing any sort of status indicator, or your player might think he's stumbled on a toy and wonder what he's supposed to do with it. Obviously we don't want to play or design boring games that people feel stuck playing just because they're chasing some status symbol. However, if your game is good, that status symbol can show them the way.

Don't be afraid of character levels; players like them. Use them to point your players towards the fun stuff you put in the game.

Slowing Players Down

2008-07-31T18:45:00.000-07:00

Players vary wildly in the amount of time they have to spend on a game. Some -- teenagers, the retired, the unemployed, addicts -- can spend nearly every waking moment playing a game. As far as the average player is concerned, this level of dedication is effectively identical to the player that spends every evening (say, five nights a week) playing.

And then there's casual gamers, a hard bunch to pin down. Some play casual games as much as the hardcore addicts mentioned above, but somehow they don't "count" because they're not playing "mainstream" games. Obviously I have issues with this distinction, so I'm just going to bypass the issue. What concerns me here is players that play one of these addictive games (like, say, WoW) but only casually, one night a week or maybe a few hours a week scattered here and there.

One common thread of discussion in MMO design is the disparity between these two groups. Some players will pour thirty or forty hours a week into a game and others just a handful. How do you keep the second group relevant? One obvious answer is by Slowing Players Down, a solution that can be implemented in numerous ways.

Of course, any attempt to categorize such a range of concepts doesn't really capture the full range of possibilities. Categories are there to help us cope. So don't take my categorization as an attempt to define all possibilities. I'm just categorizing to help explore the range of solutions.

One solution is to cap the amount of progress players can make over a period of time. Another option is to give players distracting time-sinks that might be accomplished offline instead, allowing casual players to catch up to more dedicated players. A third solution I'll explore is to give players resources that replenish in real-time. The non-solution, letting hardcore players outpace their slower fellows, is the foil by which I'll compare the other solutions.

Cap Progress

In China, players are only allowed to play for five hours before their abilities are suddenly decreased in power. Limiting the amount of experience players could gain in a session only limits players levelling up; players in the end-game are also limited if their abilities suddenly don't work any more.

This is a severe encouragement for players to just log off. They might stay online and socialize, but often a major enticement of socialization is the possibility of getting a group together to do something. When that possibility is gone, the only thing left to do is chat. Certainly, some players might continue chatting, but I think this is a mechanism that will catch most players.

Putting a hard time-dependent limit on players abilities is fairly harsh. Generally you want your players to play your game. For an MMO, time investment is the major factor influencing "score" or status within the game. Heavily-invested players continue to play more because they want to maintain and protect that investment. This is a mix of the endowment effect and emotions such as commitment and attachment. When you tell players they have to stop playing, they might realize that they can stop playing -- that maybe they can be doing something else with their time. I found it much easier to stop playing WoW after periods when I was away from home or lost internet connectivity at home. Being frustrated when one wants to play (eg when the servers are down) associates those negative emotions with the game. When the stop rules are arbitrary, the player also grows to resent the developers and the game by association.

That's not to say that you can't get away with it. Tuning the stop rule is tricky, though, and you'll also be pissing off some of your player base.

Ultimately, I consider this solution the default; the cop-out easy solution to take when you can't build anything else into the game to help balance out the disparity between hardcore and casual players.

Time-Sinks

Another simple solution is to make players do something boring and time-consuming to progress. This is like the hard-cap, above, but ... well, soft. ATITD happens to have a number of these time-sinks. The problem here is that dedicated players get stuck doing something boring if they want to progress. Some hours, progress is fun; other hours, progress is boring. Hardcore players decide your game is boring, and then bam! they stop playing altogether and unsubscribe.

The trick is coming up with a time-sink that can be accomplished offline, but yet is still fun. Giving the players the option of pursuing a different advancement track dodges the progress issue. But you effectively bundle two games into one product, which means you need to two games. If hard-core players will be spending as much time on (say) tradeskills as they will doing combat, then tradeskills need to be as deep and interesting as combat is. Making combat sufficiently interesting and balanced to keep players subscribed is hard enough and now you want to make two systems that complicated?

A solution like forcing players to run around, on foot, to continue progressing is punishment. You're better off putting in a hard cap.

Real-Time Resource Replenishment

Eve uses this sort of model: players gain skill points whether they're online or not. Eve's developers CCP have effectively dodged the problem of developing two different games. Most MMORPGs have two major forms of score: assets and experience. ('Assets' includes both gear and gold.) Eve just sunders the XP into its own pool. Players can continue accumulating Isk in Eve while they play online, but if they want to take a break they can log out and know that tomorrow they'll have higher skills available.

WoW itself uses this model somewhat in their rest system, and in fact this problem -- helping casual players to keep up with the hard-core -- was the major reason they introduced it. In WoW, you gain "rest experience" whenever you are logged off. It accumulates fairly slowly; you won't be able to keep pace with your catassing buddies, but gaining XP more quickly when you do have it is refreshing.

ATITD uses this model, somewhat, but it's tied in with the rest of the game being a slow, tortuous death. Am I biased? Do I sound jaded? I think I'll move on.

Travian also uses this model: your resource farms continuously produce more goods according to wall time. Every (e.g.) twenty seconds or so you see one of your resource counts tick up. I've never played Eve, but I've played Travian, and this mechanic seems the best to me for solving this process. Players that excel in Travian pay attention to the costs of infrastructure, resource, and military units, and develop strategies that help them maximize growth. The game isn't about clicking on your town and building new grain farms and iron mines; it's about deciding which one to build first -- or if you should recruit more troops instead.

And there lies the crux of the issue. Whereas the two previous methods were ways of hamstringing and punishing players, here is a mechanic that assumes an equal footing. The even distribution of resources to hardcore and casual players alike levels the field out considerably. There are still ways for the hardcore player to extract more resources from the game but it is nothing like the disparity between WoW catassers and casuals.

Conclusion

If a game allows a player to gain a significant advantage by spending more time online, one can't "fix" that by throwing in a couple hurdles. Nor is it the sort of thing one can throw in at the last minute. A holistic solution is more effective as well as more elegant. In Eve and Travian, the slowdown mechanism is intrinsic to basic gameplay.

One might take issue with slowing down players at all, and that's something I'll tackle at a later time.

Exploring Game Mechanics

2008-07-29T21:54:00.000-07:00

Among the Bartles types, I'm primarily an Explorer. Specifically, I enjoy exploring game mechanics. All my charts and spreadsheets for Travian were, in part, to figure out how the game mechanics manifested -- what was the most efficient way to goal X?

With a toy, people develop their own goals. Either they (incorrectly) perceive the game to have a goal that you are "supposed" to achieve, or they explicitly choose something to explore, or they do what they did in the previous similar game that they played. I'm going to explore each of these in turn.

Misperceived Goals

When players project a goal onto the toy, they become frustrated when they get to that goal and they aren't rewarded. The same thing can happen when they are playing a game and misperceive the goal. This is especially frustrating when the game did a poor job of communicating the goal. If it's only once the player has played towards the goal that they understand it then you've lost an opportunity to keep that player happy. (Unless your mechanic is confusing players, in which case you're developing a niche title, and rah for you. I'm not talking about small-market hardcore games.) And some players might get distracted along the way, but that's besides the point.

Challenge is important in games, but only in that it manifests as perceived challenge. Since it's unlikely for a game to be challenging but not seem so, the important point here is the contrapositive: a game that players perceive to be challenging but really isn't. Players succeed and think they're smart in doing so. In the case of our toy with misperceived goals, players find the game to be extremely challenging and themselves to be under par because they can't win. I don't like losing, even if it was a good fight. I prefer losing a good fight to winning on a coin flip (unless we're talking real money, in which case it's better to be lucky), but losing when it's an unfair fight weighted against me just makes me frustrated.

The root of such frustration is misplaced expectations. Manage your player's expectations. If you've built a toy, let the players know.

Choosing Exploration

Experienced explorers tend to know they're explorers. Maybe they haven't heard of the Bartles types, maybe they don't think of it that way, but when you sit them down in front of a toy (or game), they'll go to work taking it apart and figuring out its mechanics.

To them -- or, I should say, to us -- figuring it out is the game. We're curious. I've got a competitive side, and that manifests as wanting to know the rules. Since most games don't document themselves well that often means it's up to the players to figure out how to win, whether one strategy is better than another. In strategy games, this is, really, the point, but there's also a mechanical aspect to winning: just how effective are the various units? If you face two off in a fight, which one will win? Which is more cost-effective? These sorts of explorers are comfortable with math -- at least the basic algebra used to derive these effectiveness measures.

Other explorers want to figure out your AI -- do feints work? Can they draw the NPC troops into an ambush? A great many players fit into this type of explorer mold, and it's generally an explicit part of many games. For toys, of course, there's no goal to win, so exploring the AI in a toy is a chosen goal.

Trying to keep mechanics-explorers happy is a difficult process. The more successful your game, the more people will be trying to figure it out. There's so many people playing WoW, for example, that the only undiscovered rules are those for the rarest and most inaccessible of content. Even in complex-rule games like ATITD, there's enough people pounding at the formulas that a great many of them have been found. There's two things going for that game here, though: (1) many of the rules are still very complex, such that the basic formula is sufficiently obscure that it wouldn't have been discovered except for developer intervention, and (2) the player base is small enough that there's only a small group dedicated to exploring any given mechanic. Yet it's a great example for developers looking for ways to keep their mechanic-explorer playerbase happy.

Default Play

This is the catch-all category. "Default Play" is what happens when gamers are given a toy, and when games don't tell players what to do. Many players (probably most) aren't sufficiently sophisticated to figure out that your 'game' is actually a toy. The distinction itself is somewhat arcane. It's also aggravating when the developers themselves don't know (as is the case with Travian).

This mode of play is the less-offensive younger sister to the first option. I'm saying that players pursue a goal but only indirectly, through the actions that they expect that the game wants from them. Stick a score somewhere on the screen (such as accumulated dollars or gold, or city population, or whatnot) and that becomes the perceived goal: how high can you get that number?

Games like The Sims keep the player so busy in many day-to-day life choices that they might not even know what goals they are pursuing.

The problem with this path is that players might eventually grow bored. Not knowing what goal they are "supposed" to achieve, they wonder why they spend time in the game. This was a problem for me in ATITD, to some extent: I knew what I wanted to do (play with crossbreeding), but I didn't know how to get there. What was I supposed to do in the meantime? I knew I had to somehow level up, but it wasn't clear which way I should go to do that.

And hence the problem with open worlds: when players are allowed to go anywhere and do anything, they often find themselves puttering around a bit hoping they had some direction.

Conclusion

Explorers are a subset of the overall gaming market. A niche, if you will. Catering to them can be very rewarding for those explorers but leaves everyone else scratching their heads. A game like ATITD would, theoretically, be heaven to me, if it wasn't for the atrocious UI and the excruciating primary mechanic (i.e. waiting).

You can add some fun for explorers by hiding some game mechanics. Although this will frustrate some of your early-adopter Achievers, eventually the explorers show up and start mapping the territory. Most games have simple numeric systems somewhere; combat is an obvious place. In addition to basic math and stats, consider adding in ATITD-like mechanics: complex tradeskills or gathering results or world spawns that follow a formula that diligent players can unearth and profit from.

Above all, make sure to match player expectations. Let them know what they're getting into.

Power is Power

2008-07-28T19:25:00.001-07:00

or, On Information Management as a Game Mechanism

Power is Power.
or
Power¹ is³ Power².

Power¹ is the ability to express complex ideas. Power² is power -- buying power, the power of command, the ability to get more done. What does "is" mean? Well, see, it means "is." Try to keep up here.

I'm still playing Travian. As part of playing the game, I've developed a complex information-management system that lets me assess what's going on in the game world and perform actions in a fast, efficient manner.

Specifically, I've created a map of all the other players in a 21x21 grid centered on my village. Once a day, I copy that map (it's text in a monospace font) and update all the population numbers. This lets me assess who is growing and who isn't. Also, I add in markers indicating the race of the player at that village, what guild they're in, if they're still in Beginner's Protection (and therefore can't be attacked), and, if I have already attacked them, whether it was a profitable raid.

Good players in Travian have a city that is constantly growing in population. It's how you get more power (military power, in this game). Hence, it's important to assess how strong my neighbors are. If they're not growing quickly, then they're weak players. If they're not growing at all, then they're inactive and I can then raid them with impunity. If they're growing quickly and allied, then I definitely stay away.

It took me the two weeks that I've been playing the game to move to my current system. It'll probably be tweaked further. I started with a post-it note, with the populations of the villages around me; I was basically only indicating which villages were active (by hilighting the population with, um, a hilighter). Then I switched to a text file. Then I made the map larger -- it grew from 7x7 to 11x11 to 36x48 and then shrunk to 15x15 (with two lines of 8 characters per village) and now to its current 21x21, five characters-per-village format. The width fits just fine on my monitor, allowing me to have the game open in one window and the text editor open next to it, with no overlap.

Basically the process I went through was to record different statistics and find out which were important to me. I was also subtly tweaking how I was storing and representing the information to make it easy and effective to use.

And all along, I thought, "why doesn't the game give me this information already?" This is precisely the sort of thing that a computer program would excel at.

I don't really need all this extensive record-keeping. (What does "need" mean, anyway?) (And I haven't mentioned the spreadsheet that tells me who to attack next, either.) Luckily, it doesn't take long to manage. It's unlikely that past winners and other successful players keep these kinds of records. At one point I was playing four games, though, and in that case these sorts of records are essential. But if you're only playing one game, chances are you can memorize what's going on around you without much effort.

The nice thing about records is that you don't have to memorize anything, and places where your memory might be fuzzy -- well, you don't have to worry about that. You've got the hard copy to tell you what's what.

But what if the game tracked all this stuff for me? Then I wouldn't even have to bother. And other players would know, also, if the players around them were inactive, or growing slowly, and what race they were (at a glance, without requiring bouncing through a few pages), and if they were under BP (without requiring bouncing through many pages), and how many other local players were in the same guild, and at a glance where all the big-pop cities were.

What if the game gave that information to everybody? I'd have a much harder time extracting profits from my inactive neighbors; everyone else would know about them. My opponents would make fewer mistakes, increasing the challenge. The game would shift from being one of good information management plus some basic strategy to being almost all strategy. I'm reminded of Costikyan's comments on Campaigns for North Africa: the game accurately simulates matters such as where individual pilots are and how much water each battalion has, but who cares about that stuff? Generals have staff that worry about that stuff. Strategy is hard enough without also having to micromanage pilots and water.

Some games, generally PC sims, wargames, and the like, depend to some extent on making the player manage these resources. It's busy-work. It keeps the player busy, thinking he's doing something meaningful (and, indeed, if he botches it, his troops die). But it's not a great challenge; it's a puzzle within the larger game. It doesn't lend color to the atmosphere of the game and often also has no effect on the outcome of the game -- unless you fail at the sub-task.

I think a hodge-podge of activities can work. I really enjoy Transport Tycoon, even after all these years and despite it's toy-ness, because the collection of activities in the game fit the theme of building transportation infrastructure. The game isn't really about building an empire; that's something that happens while you play the infrastructure-building game.

This is a perspective that should help you hone your game. If all of your gameplay is related to things that the Chairman of the Board would never bother with, then don't make your player take on the role of Chairman. He's the Chief Engineer, or Architect, or what have you. The chairman plays with toys -- he sets his own goals. If you decided to make a game, make the player's role match. If the gameplay fits the player as an Architect rather than Chairman, then maybe your product would work better as a game rather than as a toy.

Sim City is definitely a toy. In later versions, you micromanage stuff like water distribution, and to some extent playing around with the transportation network was Architect-y, but the gist of the game -- zone and wait -- is a toy. It's like a giant ant farm. Set some parameters and watch it go. If you wanted to take that product and make it a game, I think the mechanics would have to change a lot. When you want to give the player goals, you also need to give him ways of achieving those goals, and the more direct the better.

If Travian made all my record-keeping obsolete, I think it would change the flavor of the game. Diplomacy would be a much more obvious aspect. With stiffer competition for farms, keeping farms alive and eventually bringing them in-house would be more important. Wars would be fought over inactives, since everyone would know what pieces were in play. Mechanics would have to shift to emphasize strategy, or else it becomes pure diplomacy. Or maybe diplomacy would be the major goal!

Is your product a toy or a game? Is your player an architect or a chairman?

Selling Add-Ons

2008-07-25T21:13:00.001-07:00

Games, both single-player and multi-player, have recently been selling small Add-Ons much more often. The model is small, incremental payments -- like pinball or arcade games, really. Micro-payments were theorized to help the webcomics industry get started but that didn't happen. MMOs do periodic macro-payments. The costs of Add-Ons on both PC and console games is somewhere between these two, and I'd hazard that it's helped many otherwise marginal projects reap big rewards.

I remember one of the devs from Iron Realms talking about how a few (hundred?) of their big fans could spend a thousand bucks a year on their game, and those core players could pay a hefty percent of a project's development and maintenance cost. It's somewhat like the core fans that indie musicians, authors, and game developers look for: a few fans that are so dedicated, they not only spend much more than the average fan but they also help proselytize your products.

At the core of the idea is the notion of charging different amounts to different customers. At the other end of the spectrum from those core fans is the broke and or miserly fans that don't want to pay $15/mo. But they might pay $15/yr, especially if you can break it down into tiny payments that they can somehow squeeze out of whatever meager resources they have. Paying for some gold in Travian, for example, can be done with an SMS. If mommy is paying for your cell phone, you can just squeeze in one SMS a month and get your gaming fix. Save up a few bucks by stealing lunch money and maybe a friend will help get those dollars transferred to PayPal.

There's a bunch of great benefits to this approach. The guys that can afford to burn $50 a week on your game can do so -- you've got a business model that takes as much money from your rich customers as it can. Broke fans can build a community and a customer base, especially if the core game is free. Get them hooked, and then when they do come across some money they'll spend it on your game. In the middle are the players that are willing to spend $5 to $20 a month -- usually the majority of the audience for traditional business models. Except now you've given those guys an extra little incentive to spend even more. If they were happy spending $14/mo on WoW, they might have the resources to spend a lot more, and if you tell them they get 25% more production for just $1.20, they'll jump.

Small amounts of money are easy to spend. Gabe & Tycho mentioned this recently -- price something at a buck and it becomes much easier to try something.

The elephant in this room is, of course, iTunes. Consumers don't want to drop $15 on a dozen tracks, knowing they like one of them but hoping that the rest don't suck.

Or maybe it's just that the kids that used to scrimp and save to buy their media now, instead, just download it from some bit torrent. You can't convince a kid to mow a lawn to buy your CD if he is willing to click-click and download it for free. The only way to get him to spend money is to prevent him from getting it any other way.

This is probably the saving grace of games nowadays. PC games seem to be going downhill. Those that are still around are the few big, mainstream titles -- casual games like The Sims and games that require online play like WoW or Team Fortress 2. I remember players in the game rental market worrying about the state of the industry, and honestly I have no idea how they're doing now. I think the used games market has replaced it, but I guess I should just shut up about that and look for an educated opinion.

I haven't really mentioned console examples but that's not because I don't mean to include them here. I was just using PC examples. "DLC" for XBox 360 titles and (I guess) the other consoles is another strong market. $5 for a horse? No, but I'll pay $5 for an expansion pack, or $1 for some gamer tags.

I think selling Add-Ons like this is the way of the future. It's customization in a way-- instead of charging users $15 for a CD, you charge them $15 for a dozen tracks of their choice. Sophisticated consumers don't want you telling them how to have fun; they want options. Business realities mean the box itself is gonna cost $50, but the extras let you extend the game without having to sell that, too, in the initial box.

Silver Bullets

2008-07-24T18:56:00.000-07:00

As Fred Brooks says, there are no Silver Bullets.

The basic message is that there is no language, tool, organization structure, or practice that will magically solve your problems and let you ship software on time. People who have read his 1987 essay come away from it avowing to never use a silver bullet -- but I think the result is often that they instead use a different phrase to refer to their silver bullet.

If you've got a practice in your organization that is essential, the sort of practice that anyone using your given language and tools would be a fool not to use, then that's your silver bullet. Do you have seven different pointer wrappers that everyone must use? That's your silver bullet. Do you require programmers to write an interface for every class that they implement? Are naming conventions the sine qua non in your office? Are you lax on a number of XP practices but absolutely adamant about unit tests?

Just because you don't call it a silver bullet doesn't mean it isn't.

Complexity is a hard problem, and ignoring some problems can produce an order-of-magnitude decrease in productivity. There's a difference between being avoiding willful ignorance and requiring some critical practice. I've often run into people that had a bad time "at their last job" or "on the last project," and are committed to avoiding that problem at all costs.

This is dropping context, though. The solution will remove the problem (but see below), but was the problem destiny or was it the result of an organizational shortfall? Maybe their last project had a lot of dangling pointers and memory leaks; using pointer wrappers won't make that problem go away. It doesn't even make it harder. Adding complexity to a project makes working on it more difficult, painstaking, and error-prone. Although they're trying to remove what they see as a flaw in the language (in this case, unmanaged memory), the solution doesn't change the language. Programmers can ignore, misuse, or work around pointer wrappers. Plus they've got to throw out their old understanding of the language and use a "new and improved" flavor of the language. All of their experience, previously very valuable, now works against them. It's simple to follow someone else's explanation of their solution, but understanding it and grokking it sufficiently to use it yourself is not trivial or fast. Forget using it adeptly!

Training programmers to understand memory allocation and giving them a model (such as 'ownership') to follow goes a long way to reducing memory misuse, makes them better programmers, is something they can use for the rest of their career, is a topic well-documented in books, magazines, blogs, and seminars, and requires no new tools or code.

Game Tutorials & Instructions

2008-07-21T18:18:00.000-07:00

In my ATITD rant follow-up, I mention the importance of explaining how to do stuff to players. Here I wanted to talk about what happens when you don't explain things -- beyond players just not playing.

I'm playing Travian (sign up and get me gold!) with some guild-mates. The rules and etiquette of Travian are hidden. They're not obvious. What is the game about? How do attacks work? There's competition, so according to the nomenclature I set forth in the previous post on Game Design Theory, it's a game. It has goals, but they're not clear. Evidently the goal is to build a Wonder of the World. I think maybe you need to be in an alliance that builds 4 of them; I'm not sure. There's no "How to Win" post somewhere that I could find that out; I'd have to chase down someone's stickied forum post -- on maybe the .com forums or the .us forums, who knows?

How does one get started playing the game? Just jump in and click and you'll find out. What do you do? Either find out the hard way, or spend a lot of time reading the forums and gleaning some idea that way. Let me be clear here: you don't go to the forums and, oh!, there's a post explaining everything! No, you go read a ton of posts and get a slightly less foggy idea of what the game is about. There's some early build orders posted, for example, but they kinda assume that you know what you're doing after that. Players have no goal given to them early on.

Learning the Game is Our Game Mechanic

There seems to be the idea that "figuring it out is part of the game." This is a common thread in several of the indie-ish games I've seen, whether it's something semi-well-known like ATITD or Travian or smaller single-player games or whatnot.

If learning how to play is one of your game mechanics, then your game is an Alternate Reality Game where you have to surf web pages and ask questions in forums -- but you get called a noob for a while. Do you enjoy being called a noob? I don't.

The 14-year-olds get called noobs because they haven't learned to use search features. I guess there's older kids that are just as annoying. In fact, there's probably decent folk that post questions in the forums just out of frustration. There's a pattern here that I've mentioned in previous posts: Hide stuff from your players and they wind up engaging in behaviors that piss off your elder players.

What Really Happens

When your game first comes out, no-one knows how to play (except the kids in beta). Since those kids in beta know their way around, they'll make posts on the forums to show off their knowledge. Don't think that "the players get to learn the game mechanics" is a feature. It's not. Trial-and-error isn't a fun, strategic, or rewarding way to learn something, so even that's not a great thing. Maybe a few dozen people 'learn' your game the hard way, the rest learn through some mix of hard knocks and forum browsing, and your "game mechanic" is now over.

New players aren't strictly forbidden from finding out how to play the game; they just have to get that knowledge from the elders. Some newbs will find out, others will just get frustrated and quit. The elder players are those that already know what's going on. Some of them (often highly regarded by the community) then pass that knowledge on. The lack of documentation means that some elders have to take on the role of mommy and teacher, and assuredly some of them really enjoy that role. But you're losing players just to make a few people warm and happy by providing the documentation that you should be providing anyway. Those knowledge-mavens will find something to write about; they always do. You wind up with a game structure where you have: a set of in-crowd elders that have learned everything the hard way; a set of up-and-coming players that are poring a lot of time into learning your game (when they could be playing it more, or otherwise enjoying their life); and a bunch of nubs that are getting frustrated, making stupid posts, bothering elder players, and either leaving or maybe becoming non-nubs.

If you gave the players good documentation, your nurturing elders would find something else to write about -- like good strategies. They'd participate in design and meta-game discussions. They'd build the community, rather than just stem the leaks produced by shoddy docs.

Good documentation helps to build your player base. Players like knowing what they're supposed to do. They enjoy games that have score-cards. Tell your players how to play and tell them the goal and then let them figure out how to win.

Games, Game Theory, and Puzzles

2008-07-18T20:49:00.000-07:00

The difference between games and puzzles is that puzzles are static; games have an opponent or an element of randomness. Both have a goal; you can solve a puzzle or win a game.

The difference between toys and puzzles are that puzzles have a goal.

The difference between games and toys is that games have goals. With a toy, you have to think up your own goal. Building toys like Lego blocks and Tinkertoys are a bit puzzle-like in the way they respond to your actions; they don't really 'behave' different. If you built a tower out of them, though, it creates a new context. You can build a fort, or a car. But a toy like that isn't a game unless there's a goal.

--

Game Theory is, well, the study of games. It's the attempt to capture, in mathematics, game-like behavior. It's typically mentioned in discussion of economics, ethics, and politics. You might built a tree of "if I do this, then my opponent might do one of these three things, and for each of his responses, here are my possible reactions...", and then weight each action by some probability and/or 'strength', eg how close you are to 'winning'.

If you play a game against a rule-bound opponent, one whose response to your actions is dictated by a formula that doesn't involve randomness, then what you have is really a puzzle. Puzzles are generally amenable to solving through logic, although some puzzles are grossly difficult to solve without tools. Simple tools would be pen & paper; maybe add a calculator. A more complex tool would be a computer program.

--

To some extent, the goal of the meta-game of poker is to figure out how to turn it into a puzzle. It's not really a puzzle due to randomness, but then, I'm not talking about poker proper. You can sit down and play one hand of poker; that's a game. But if you play against the same opponent over and over again, you can start to analyze your opponent's behavior. Assign each of their actions a percentage, due to randomness. Once you've done that, game theory will tell you how to act.

Likewise, from session to session over the course of a year, you'll face many similar opponents. If you can put your opponents into buckets -- rock, fish, shark -- then you can again apply game theory to the problem.

This is what happens in many video game communities, most especially in RPGs and Sims. Players want to figure out the rules, and then from there figure out how best to beat the game. WoW players figure out where their best items drop and go farm; Sim and RTS players calculate their optimum build orders.

Game designers can do the same thing, of course. It's a great way to find the holes in your design; possible exploits; build strategies that can make the game too easy or too hard.

I guess I don't have a lot to say here. :) I thought it interesting to think that game theory reduces games to puzzles.

Towards a Hermeneutic Theory of Comprehensive Artifactual Construction

2008-07-16T11:11:00.000-07:00

[a parody of/editorial on the MDA paper]

Introduction

Computer and video games are more complex than other types of artifacts. People building new cars, warships, commercial airliners, investment and accounting systems, and legal doctrine don't have to deal with the complex, dynamic, and often unpredictable behavior, like we have in games. Games are hard. Harder than these other things, obviously.

Towards a Comprehensive Framework

Lots of different people are involved in making games. We're not all interchangeable cogs. As a result, we can't treat everyone else on the project as if they're exactly like us. I bet you never thought of that, huh?

As games continue to evolve, the behavior of AI-controlled game agents will increasingly come under the purview of non-technical people that don't understand logic, algorithms, and efficiency. Those agents will be part of game design, because obviously they aren't now and haven't been before. As we all know, it wasn't until very recently that AI units had any effect on gameplay.

WTF is "systematic coherence"? I don't think it means anything. I think it's a cover for not knowing what you're talking about. If you hold your goal as a floating abstraction, represented by the pairing of two multisyllabic vagaries, then you can pretend you're doing real work.

Your first paper should be "this is systematic coherence, here's some more examples, and this over here is not." Prove to me that it is a goal. "I'm an academic, I've got a badge, act as if my pronouncements were deep" is just a snowjob.

I can sit here and pretend to know what systematic coherence is, but because you never define it, then we'll never know if what I think it is and what you think it is are the same thing. To the extent that that coherence is the goal of your paper, I think it critical for you to define it.

In Detail

Designers and Players have the exact same fucking view of the game. The designer (or, when the designer doesn't understand the AI, the programmer) starts the process knowing the deepest hidden layers of the game -- the mechanics. But they both perceive the aesthetics of the game, and from there can pick apart the possible interactions that they are offered. These interactions are what I call gameplay: the tasks that players perform while playing a game.

Aesthetics isn't hidden from a designer the same way mechanics are hidden from players. Rather, because the designer starts with a deep understanding of the gameplay and mechanics, he finds it easier to ignore the aesthetics. They carry a low mental load. That's what happens when you get used to something. When you drive down the same road every day, you get used to the signs and the trees and the buildings. You form internal mental blocks that subsumes all of that detail. You ignore it on a conscious level. That's the product of familiarity; it happens to everyone over time.

You shouldn't be focused on the mechanics. If you are, you're a shitty designer. The mechanics are the puzzle of the game, but they exist hand in hand with the gameplay. You can't have one without the other. A great puzzle can frustrate players with gameplay that obscures the mechanics; likewise, gameplay that is too powerful can trivialize your puzzle. Sirlin makes good points here: simple mechanics only made time-consuming via an inefficient interface make for a bad game. Expose your mechanics; let the mechanics be the puzzle, not the interface. I swear at ATITD for this sin.

And I think your "aesthetics" are models of fun. They are all either models or attributes of gameplay, except for Sensation.

"Sensation" is a product of the graphics in a game -- both the technology of the graphics as well as the art. I think this item can be interpreted in multiple ways, so again I'm picking bones with the depth of this paper: define your terms. Rhythm games provide physiological sensations tied to the beat of the music that can be relaxing. Games like Rez provide a meditative visual stimulus that can be sense-pleasure, and to some extent the simple-mechanics of shooters like Geometry Wars provide the same numb-minded sense-pleasure. I find bright, saturated color schemes in many medieval-fantasy games to be visually pleasing. Back when I was playing Quake hours a day, I'd get into The Zone, which was a partly physiological state frequently described of sports players. Meditative/Zone-like games are defined by their gameplay and the simplicity of their mechanics; the color schemes I mentioned above are entirely in the domain of art and aren't a part of the mechanics or gameplay at all.

Fantasy is often purely a result of the art and aesthetics of a game. If you're baking bread in a medieval fantasy world, the fact that it's baking and bread is just a surface gloss; the game only sees counters moving from one state to another. "Ingredient X + Ingredient Y = Product Z." Fantasy doesn't come from having production rules; it depends on the player's imagined interpretation of those mechanics.

I could go on but my point is one that high school English teachers drilled into me: each item at the same depth in your outline should be of like kind. Don't put three apples and an essay on transformative hermeneutics into a list together. (You can tell I'm not an academic because I didn't use the word 'towards' in that sentence.)

The varied list isn't a strong analytical tool; it's great for brainstorming, though. Or rough categorization. If one stops by a campus bookstore, one could likely come back with three apples and an opaque essay. Disjoint buckets provide a quick, easy way to segregate the items pulled from the campus-store grab-bag. (And still, the list would benefit further from more rigorous definitions.)

The strongest value in this paper is the list of fun buckets, but I expect that there's better treatments of fun out there.

Game Design Curriculum

2008-07-16T08:48:00.000-07:00

There's a few concepts I want to discuss but I'm not aware of how these concepts are named within the game design community. I don't want to fall into Dunning-Kruger but I'm not sure that the design community does identify these concepts.

I think D-K is worth exploring a bit. It's easy for any game player to say "I could make this game better!" I remember thinking that when I played Warcraft 2. I thought, if only they had more units and more buildings, this game would be more awesome! Eventually I learned the lesson that my good buddy Antoine so cleverly encapsulated:

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove. – Antoine de Saint-Exupery

Anyway, point being, it's easy to think you, too could be a game designer. After all, you play games. I play games. I can criticize them. Therefore, I can do better. Right?

The example I've seen is often making music; playing in a band. Lots of people have tried playing a musical instrument, so I think a good number of people have experience enough with playing that they can see that you don't just pick up a guitar and be ready to hit it big after a couple weeks of practice. It takes a couple years to get good at playing an instrument, especially if you're expecting someone to pay you for it. Or drawing; I think it's common knowledge that it takes years of drawing and sketching and painting before others will give you money for your scribbles.

So, the context here is: do I know what I'm talking about, or is this the sort of stuff they teach in the first semester of Game Design School? Obviously, there's a problem in that there's not that many game design schools out there. Like, four, maybe. There's no general game design curriculum. It's very difficult for me to say whether or not other people have covered game design concepts that I see.

A few hours of surfing later: there's a lot of thought out there on game design curricula.

I see mention of things like Bartle's Types, but that's fairly rudimentary -- a lot has been added to the Types discussion since then. Nick Yee, for example, has researched player motivations in MMOs extensively. Understanding all of that data isn't the sort of thing you can put into a single blog post. He constantly writes about it. It's a deep topic. A good game designer should be familiar with it; I could see a Game Design Theory course spending a week or two covering MMO motivations.

I'm not a Raph fan. He got several "battlefield promotions" at Origin when the more senior designers on UO left; he was the last one still alive when the game shipped, and now people think that he created the game. He doesn't claim that, but he definitely profits from the design. I remember an interview I had with Sucker Punch (of Sly Cooper fame) and they basically instilled in me the idea of teach-practice-test: give the player a chance to learn a new skill in a safe environment, give them a few easy practice tests to make sure they can execute the skill, then test that skill in a challenging environment.

Raph's Theory of Fun seems to be that sentence, but stretched to book level. Looking a bit deeper, it seems the book is an apology for working in the entertainment industry, from someone that felt pressure from his family to do something "real." Maybe not. I haven't read the book, because, again, I'm not a Raph fan. The book has won tons of awards, though, so what do I know? If some other guy gives it a badge, then it must be a fact that it's brilliant, right? There's not a whole lot out there on video game design. Stop by a bookstore; count how many game design titles you find. I'm at a bookstore about once a week, and 95% of the time the number of design titles is ZERO. So if Raph has one of the top 10 books on video game design, then... um, there's only numbers one through four. I could publish this rambling rant as a book on game design and it'd be the 5th best book ever written on the subject.

Grr. Ok, so enough of that.

"Game design" also applies to board games, pen-n-paper RPGs, etc. I've seen several books on board game or war game design. The design of other games is significantly better documented than video game design.

Game design course curricula that I've seen generally cover the biggies: Raph's book, Bartle's paper, maybe related stuff like McCloud's Understanding books, Costikyan, and Sirlin. Textbooks themselves are scarce: Rules of Play, maybe not any others. That's the only one I know about. There's no series of textbooks for a bunch of different game design courses. The 'meat' of the design portion of the curricula are studios and seminars, anecdote books, post-mortems, and the like.

(Take Computer Science in contrast: you can stop by your local college bookstore and find textbooks for dozens of different comp sci classes. Plus software engineering texts, plus all the lay books on theory and practice for tons of subsets of theory within software development. My point is that there's one game design course textbook. Design courses read other books, the equivalent of lay books. Those books are not courses in game design; they cover aspects of game design, but aren't written as textbooks.)

So... where do I go for nomenclature? I can't justify spending too much time researching a given topic because there's not enough out there to find.

So I'm just going to make it up as I go along.

The Settlers

2008-07-13T19:53:00.000-07:00

From Wikipedia: "Many fans of the franchise consider [Settlers II] the best game of the Settlers series, primarily because future installments changed the transport management aspect considerably." In fact, Blue Byte (the devs) recently remade the game (Settlers II 10th Anniversary Edition) because it had been so successful. Blue Byte have been making Settlers versions for 15 years now. It's fairly popular in Europe, and each game sells (I'd guess) in the 200-500k copies range in the US.

Settlers II gameplay: the game plays on a hex grid. (1) Build buildings, in the interior of the grid. Minions automatically head to the building, construct it, start working there, and place their produced goods on the road in front of the building. (2) Place roads along the borders of the hex grid, connecting buildings together. Minions automatically show up on the road. Whenever a good is placed at one end of their road, they head over, pick it up, and carry it to the other side. I think buildings automatically have a flag out front, so if a needed resource (say, wheat at a baker) gets placed in front, that good automatically goes into the building. (3) Place flags on the road, to subdivide the road into smaller stretches. Your village's population rarely supports enough minions to place roads & flags all over the place, so one has to exercise care when placing buildings, or else you risk shutting down your economy.

Buildings produced stuff. Some required materials to be carted over; others gathered resources from the environment. The woodcutter's hut, for example, produced a minion that would wander the area around the hut, cutting down random trees. The stonecutter's hut needed to be placed near a stone quarry (which showed up on the game map). Mines needed all three types of food (bread, fish, meat) to go, and you needed ore to smelt bars to craft weapons to equip soldiers to take over territories, so the game missions -- "take over territory X" -- meant building a full village.

gameplay in Settlers VI, aka Rise of an Empire, released in 2007, the game I bought yesterday: build resource-gathering huts in random places, build resource-processing buildings in random places, sit back and wait. Missions have around a dozen miniquests within them, which are things like "defeat this troop of bandits" or "deliver 9 pairs of woolen pants to your neighbor" or "promote your Knight to Sheriff". Of course, each of these has prerequisites, which is what the gameplay is. Build the right buildings. But placement doesn't seem to matter much. You can't tweak production or distribution. You can upgrade buildings, but wood (the resource required for most upgrades) is something you just gather more of. It's not like it's scare or that you have to decide carefully what to upgrade. Mostly you just sit back and wait until things are running smooth enough for you to skim some off the top and declare the objective finished.

Puzzle Pirates has minigames that have nothing to do with gameplay proper. "Sailing" and "Bilge Pumps" are Tetris-like/Match 3 kinda games. You play the puzzle minigame for a few minutes, the ship defeats a foe, you move on to the next fight.

I've described Transport Tycoon as having four minigames: placing stations in cities, building efficient tracks over mountains and around rivers, setting up train consists (the set of cargo that they haul from city to city, plus which cities they stop at), and optimizing rail lines to maximize train throughput.

The station-placement "minigame" in Transport Tycoon is very different than what's in Puzzle Pirates: you only place a station once per city, so it's an important but not frequent minigame. But it is a puzzle; it's not just "select a city and hit Build Station Here". You want to place a station that captures as much of the city as possible without razing any of the important buildings. You can be lackluster about it, but I think people that like the game like the challenge of optimizing their station placement. Likewise for building rails around mountains and rivers; you could just slap it down. What makes the game fun isn't "I finshed the mission!" but rather "Isn't my rail line awesome? Do you see how cleverly this station is placed? Look at this rail line! All those trains, isn't it grand?" It's like raising kids: see what my kid did?

Settlers 6 just seems to happen by itself. I wasn't particularly clever about placement. I built a wall around the town, but there was so goddamn much stone that the wall just... man, I could have built a wall twice as big. And there were random obstructions in the way, like this big boulder and a cliff face and a river, but I just kept building walls. Not particularly clever or interesting or expensive or tricky. It's just there. It's like clicking "Build a Wall Around This City" then standing back. You have to micromanage the wall, but you can't do it well. It's busy-work.

I think the main thing is that Transport Tycoon shows you how good of a job you did. Same for Settlers II, and Sim City. The good games invest the player in his decisions. I remember the decisions I made in Settlers II, and Transport Tycoon, and SimCity. In Settlers 6: meh. The buildings are just there.