One more thing (ATITD)

A followup to my previous post, a rant about A Tale in the Desert.

The ATITD New Player guide (which is on the Wiki, meaning that it was written by players, because the devs would be damned if they could be bothered to write any documentation) has this quip:

One thing I am sure you have noticed already is the dearth of documentation or in-game hints and tutorials. Some say this is the developers being lazy, but there is another reason. A Tale in the Desert is a highly social game. You are meant to interact with other people.

A dearth of tutorials and documentation means you can't ask the game how to play. Some say "it makes the game more social."

I vehemently disagree. Noobs asking dumb questions like "how the fuck do I get a camera that isn't utter shit" isn't social. That damn noob should look that stuff up on the web. I hate Barrens chat, in part because it's dumb questions like that. "How I mine for fish?" Damn, noob, google that crap.

It's a different problem in WoW, because most of these easy questions are things like "Where is Orgrimmar?" What makes those people noobs is they haven't yet found the Map interface, or they're too lazy to use it. It's really easy to find -- there's a button right there on your screen that takes you to the world map, and Orgrimmar is right frickin there on the world map. The world map is not hidden very well. If you can't find the map in WoW, you're a moron. And if you ask in chat, then I hate you and want you to die in a car fire.

In ATITD, the option is hidden. Or broken. Or doesn't even exist. The only way to find out is by asking someone, or reading a web page.

The web page is written by people that know the game well and hence are likely to not remember what exactly was so frustrating to new players. This is a problem in lots of places in the world: either you're in and you know everything and don't recall what it was like being new, or you're out and no-one has bothered to put anything together to help you get started. This might be OK for maintaining a sense of elitism; a special barrier to keep riff-raff from joining your private social club. But for an MMO? The devs should want a ton of players. Maybe the ATITD devs thought 2000 subscribers was "too many."

Apple had awesome documentation for the Macintosh. I guess they still do. That's my standard for documentation, and by that standard, 99.9% of the documentation in the world is utter shite. If Apple gets an A+, then everyone else is failing the class. It's not even close.

The problem is that most people don't know jack shit about epistemology. And I don't mean the nonsense spouted by Wittgenstein and the like; I mean simple concepts, like "concept." Concepts are mental entities. You form them most efficiently when you see a few positive examples and at least one negative example. The negative examples are crucial.

Spouting words that you feel are similar to a concept you are trying to communicate doesn't make your listener understand you. Good communication understands the position that the listener is in. A good communicator draws a mental map; he points the way and points out hazards. The work is done by the listener; the listener has to be able to see the similarity underlying the concept you're trying to communicate, and to be able to delineate that similarity from background noise (which is the purpose of negative examples).

Good communicators have an idea of what the listener is thinking. It doesn't matter how well you know the concept; you have to know how that concept is different.

You can show a kid a picture of a golden retriever, and a dachshund, and a labrador, and a pit bull, and a german shepherd, and a chihuahua, and say, "these are all dogs." Showing him the breadth of the concept isn't enough; you also have to point out where the breadth ends, and where a different concept begins. That child might see a cat and exclaim "dog!" proudly. Or see a particularly fluffy couch or shrub and say "dog!"

The person who knows most what a newbie needs to know is the newbie himself. He'll tell you what he's wondering. Beware of newbies writing guides without adult supervision, though, because they might label that cat as a dog.

so... wow. Totally off topic.

My point was that bad documentation doesn't make a game more social. Good documentation answers the questions that you don't want the game elders to have to answer over and over. That's what FAQs are for; they're primarily a benefit to the elders, not the newbies. And they also benefit the game developers, because if a newbie can get accurate answers easily and quickly they're more likely to hang around and pay for your game. If your documentation doesn't answer the question, the newbie will ask in general chat and get his answer, pissing off everyone else who has to read the same damn question for the 20th time this hour.

The questions that you want your elders to answer in-game are questions of judgement: where should I start my settlement? What spec should I use when levelling up? Should I do X or Y?

You don't want them answering "how do I do X?" Your documentation, in-game tutorials, and UI design should make that easy for the new player to figure out.

Rant: A Tale in the Desert

my god I just had to rant.

I played ATITD before, so I'm loosely familiar with it, but I wanted to play it a bit more and try out some of the mechanics. But mein gott it's pissing me the hell off.

WoW did a lot of things right. Previous MMOs were hard-core, and one of the ways that they were so is that you either knew how to play already or you weren't welcome. You have to figure out everything on your own. WoW just tells you the answer most of the time. I had to find some tar in Egypt (much easier name than ATITD). OK, fine, I have to find it on my own. But the game didn't even give me any hints. What's it look like? Can you give me a rough idea of where to look? In old-school MMOs, you're just supposed to wander around until you figure it out on your own.

Some people love that, but those people are in the minority. I used to think I liked that mechanic, but I GREW UP, DAMMIT. The game isn't about figuring out where the fuck they hid the tar, it's about choices and exploration. "What the fuck is tar and where do I find it?" isn't exploration; it's confusion.

Finding cool stuff is exploration, like waterfalls or hidden buildings or new zones or statues or ruins or whatever. Fog of War in the minimap helps that -- tell me where I haven't been. A "here's everything" minimap means that you don't "discover" the Universities in Egypt. (There's no mechanic in the game to tell you, anyway.)

• Movement is just lame. Click-to-move means when I'm trying to move I instead sometimes click on objects. And then I want to punch something.
• You can't move with keys AND have a chat window open.
• You can't click in scrollbar elevators to move chat by a page.
• The camera SUCKS. You can't control pitch independent of zoom.
• The camera SUCKS. You have to move the mouse to the edge of the window to yaw the camera.
• You start the game far away from anything interesting.
  
• To do ANYTHING requires driving through a bunch of menus.
  
• The intro quest has like 30 steps. WTF? That's not a gentle introduction. It's a "gentler" introduction.
  
• When you try running down a slope that's too steep, you get a pop-up dialog that you need to dismiss before continuing. And since you click to move, chances are you're going to get that dialog a lot. This is exactly the sort of thing the player should be left to figure out on their own -- STEEP SLOPE = BAD. They hide the tar but you give us an idiot dialog for steep slopes? Please.
• You can't split windows that start off stacked.
• Recipes are hidden. What's it take to build a chest? Try building a chest! If you don't have the ingredients, it will tell you. If you do have the ingredients, it won't tell you, it'll just dump you in the construction interface.
• Making boards? Oh. My. God. You have to stand there and hit 'p' 200 times to make 200 boards, a common ingredient in low-level stuff. At 2 seconds per board, that's 400 seconds, about 6 minutes of staring and hitting a key... That isn't a game, it's work.
  
• I could go on, but really, kill me now.
  

One of the main mechanics in the game is running around. Travel time isn't fun. It's shouldn't be a barrier to play. If a game had no travel time, then you'd just sit in one spot (maybe away from everyone else) and do your own thing. Keeping locations separate means getting there is an accomplishment. But my god keep it in check. Here, it's a lame attempt to extend the time it takes to get anything done. WoW requires some travel sometimes, but a play session isn't 90% running or waiting. A lot of the 'trick' to ATITD is figuring out how to use your time while you wait for some lame timer to expire. You can't just do what you want.

WoW lets you open a bunch of chat windows for example; here, you can only look at one of the System, Main, local, and Whisper windows at a time. Oh, and since you can't use the keyboard to move if you have the chat window open, either you use the lame camera and mouse-click-to-move (which makes me want to punch things) or you keep chat closed just so you can move around easily. THIS GAME IS HARD TO PLAY. Not hard as in gameplay; just telling the game what I want to do (like, "move over there") is a challenge. The UI is the challenge.

WoW does recipes very well. One window per tradeskill. The top half is all the recipes you know, the bottom half is (1) a listing of the ingredients you need, (2) a display that tells you how much of each of those ingredients you already have, so you can tell at a glance what you need, and (3) a display of what the hell the thing you're creating is. What's the difference between a Chest and a Large Chest? Build them and find out! ATITD will be damned if it's gonna help you out! If you don't have two monitors (with the second one opened to someone else's website), then you just get the "challenge" of figuring out what the fuck is going on.

Small steps and frequent rewards = happy player base. The designers don't seem particularly interested in that kinda stuff; the game had an archaic interface when it first came out, and it's only barely improved.

If you're doing one action a bunch, you can make a floating window with that button in it, but ... bleh. Figuring out where commands are hidden is bad gameplay. Mechanics like "what do you get when you cross these two grape strains, and what does that do to wine?" are great. Brilliant. Exactly what I want. Hide that stuff, let me figure it out, I'll love you for it. BUT DONT HIDE THE DAMN "plant vine" BUTTON. Dumbass.

One of the main mechanics in the game is running around. Travel time isn't fun. It's shouldn't be a barrier to play. Travel time keeps you from doing everything without meeting other people. Here, it's a lame attempt to extend the time it takes to get anything done. WoW requires some travel sometimes, but a play session isn't 90% running or waiting. A lot of the 'trick' to ATITD is figuring out how to use your time while you wait for some lame timer to expire. You can't just do what you want.

Take gathering wood. It's a grind. Click on a tree, run to the next tree, cycle, repeat, repeat, repeat, swear, log out, uninstall... It doesn't take any longer to gather stuff than it does in WoW; in fact, I think it takes less time. Hmm. I tolerate Herbing in WoW; but that's profitable. Skilling up and leveling up shouldn't be a grind. If I want to grind for extra cash, that's one thing. But grinding for basic mats is excessive.

My beef here is how boring the activity is. Herbing is ... mostly boring. I tolerate it because ... I want something special? I know I'm doing it for the cash? I guess the point really is that it should be better in WoW; that herbing is lame. Another major point is that I've already bought into the rest of WoW; ATITD feels like nothing but grinding. Gather wood (boring), make boards (boring), run to the university (boring, and frustrating because of the camera), run back, go gather more slate because the wood plane broke, grind away for another 20 minutes... There's no fun anywhere there.

Fun would be trying out crossbreading wines, or flax, or beetles.

ATITD is not quite "death is fun!" but it's damn close. It really really doesn't want me to play it.

I'm gonna play my 24 free hours and see what I can learn from that, and then it gets erased. FUCK THIS GAME. It's so sad, the economy and tradeskills are really deep and complex and interesting and really appealing to mechanics-explorers like me...

Then again, I could just read the webpages. I'd learn more, and I wouldn't be so bored. What I've been doing is reading the web (and working on this blog) on one computer, while I mindlessly run around or do whatever on the other machine. Downtime is time to socialize, but ... meh? The whole game is downtime. I reckon the stuff that I'm hoping is fun (crossbreeding, etc) is going to be just as boring.

And I need to be like level 12 anyway. Each "level" is roughly one of these grind-quests. So, just to get to what I want to look at is going to take that much grinding.

I'm torn. I think I'm going to play out the 24 hours because (1) it's free, and (2) I'll be able to do it while reading and typing on my second computer.

So, should you check it out? That depends on your grind-tolerance, and whether you've got a monitor big enough to both play the game and do something useful at the same time. Two machines helps a lot, because I can leave the game window focused and just mash the 'p' key every two or three seconds without having to worry about window focus. So, if you've got a similar setup, give it a try.

I really recommend learning about the game because the tradeskill stuff is great.

The rest... /sigh.

Creeping Featuritis

This post was going to be on state management, but it turned into a discussion on featuritis.

My previous post on state management covered high-level game state. While rummaging around the web this week I ran across a few sites that offered finite state machines and whatnot. That's generally what people mean when they talk about state management, so I thought it'd make a good topic.

When designing a new class or building a tool to help build a game or when refactoring, one of your first questions should be, "where do I want flexibility?" Making code flexible in ways that you aren't (and won't) use means it'll take longer to get the code written and working, it'll be harder to use, and it's that much longer until you actually get something working.

So before I get into the FSM discussion, I thought I'd discuss flexibility for a bit.

One of the programmers pitfalls is gold-plating. Creeping featuritis. Whatever you call it, the tendency to make the bestest evar lies somewhere between pride and sloth on the road to hell. I believe strongly in YAGNI (see Wikipedia too): You Aren't Gonna Need It. YAGNI is a way of life, as all good principles are. It's not something you think about once in a while; it should guide a lot of your coding decisions.

For example, I'm working on editors for a game right now. My #1 goal is to get the game shipped. To have a decent, working game with a working combat and advancement system that I can use as experience when developing my next game. Whenever I think of adding some new feature to the engine, or making some system more complex and ever more awesome, I stop myself, and then figure out if that feature belongs in version 2, or 3, or 7. I write down my choice, and then go back to getting the current game working.

In fact, working on the editors is kinda backwards. The main reason I didn't start with a simple game engine is because I'm planning on using XNA, and I know way less about XNA than I do about WinForms. I figured I'd read up on XNA while building the editors, and by the time the editors were done, I'd be ready to jump into XNA coding. I like top-down coding: get something simple working, and progressively add more features. Some programmers think you should start at the bottom, making awesome libraries, but the problem there is that you never really know what you actually need.

I've learned a lot about WinForms while building the RPG4 editor (where 'RPG4' is the working title on the game). If I read a few more books first, chances are I'd still be farting around, trying to learn the framework better. I bunch of stuff I did early on was just stupid. At least, looking back, the design is bad. But I know that in part because I learned what I needed to learn as I went. Whenever I found myself adding yet another function into the main Form.cs file, I knew there had to be a better approach. Of course I knew why it was a bad idea; I knew that years ago. A decade ago. But here I had very explicit evidence about how much extra baggage you can add to a form until it becomes unwieldy.

There's a difference between too many methods in a class and too many features in a project.

I think it's a mistake to make one game (or tool or even a day-job work project) and keep adding more and more features. There's a difference between adding icing and adding cruft, and it's really a question of scale. I think it's better to err on the side of caution, of too little rather than too much. With too much, you've wasted time and energy. If you have too few features, you can always add more later.

But too many features in one class (instead of refactoring) is a different beast. I'm planning on a sequel. This is kinda like Fred Brooks' advice to "build one to throw away." I'm not worried if there's some cruft in my current project, for two reasons: (1) the design purity isn't a sign of my worth as a human being, and (2) I'm learning here! I don't need to refactor mercilessly, because in games you code it, ship it, then burn the source code. Being able to reuse systems next time is great, but being able to build a bigger, better, and faster widget next time is worth alot, too. Especially if you're going to be at a different company...

Technology changes quickly. Every year, there's new video cards out. New pixel shader standards. New consoles to consider. Phones and mobile platforms get more complex every year. It's very difficult to change a complex system to handle data in a fundamentally different way. Trying to add 3D into a 2D game engine is... blech. Besides being difficult, the solution is gonna be clunky at best.

If you build clean, tight systems, you can build them quickly. They do what you want to do, they're easy to work with, easy to change, and when you need to throw them away, you're not throwing away a lot of time and effort. I remember deciding to rebuild a 3D engine at one company, and the artists were shitting their pants. They'd seen engineers before, and what usually happened was the engineers would build, and build, and build, and then two years were passed and the thing still wasn't working.

That's what you get when you build from the bottom up. You spend time adding features you don't need, you add classes that wind up never getting used, and the whole thing is difficult to work with, too, because it's so huge. And then that hugeness starts producing bugs that are difficult to find. And then you work all weekend digging through code to find the bug, and you get it fixed, and everybody thinks you're a genius -- but two years are passed and funding ran out and the project gets cancelled.

A genius doesn't build a house of cards and then impress people by replacing one of the cards in the middle of the house. That takes a lot of talent, but the house of cards isn't what the company wanted. They just want to ship a game! Any fool can make a complex system. The smart programmers are the ones that know that a simple system with all the features that you actually need does more for the project.

You have a great game idea?

Looking for some programmers and artists to help you bring that idea to reality?

You're going to have a lot of difficulty. Ideas are easy to come by. There are thousands--maybe millions--of posts across the internet by people that have great game ideas that are looking for someone to help them out. There are people employed in the games industry that have a great idea and want someone to help them out. There are people with day jobs that want to get something going on the side. There are college students, high school students, middle-school students...

Ideas don't sell games. The difference between getting an A+ and an A from a games-review site might be on the quality of that idea, but the difference between an idea and an A is far, far greater than from an A to an A+. The work put in by the programmers and artists and level builders and world scripters will far exceed the worth of that idea.

And then there are the great ideas marred by buggy implementations. Take Shadowbane, widely acclaimed as a tremendous idea and a disappointing failure. Dozens of people spent years of their life on that game. Do you think the idea you came up with this afternoon is worth more than all those man-years of effort?

A game isn't just one idea; it's thousands. A great game isn't made by that one idea alone. It's instructive to read the reviews of the top-rated games; they're never perfect. There's usually more than just nits; usually the review is "it had this flaw, but that's easy to overlook because the rest of the game was so awesome." What is it that makes Half-Life awesome? Is it one idea? Or is it the execution, the cutscenes, the voice acting, the level design and textures, the AI?

What about Team Fortress 2? Is it the idea of having charismatic cartoony characters? Reading behind-the-scenes interviews, it's amazing how much was removed from the game to make it better. There's no one idea that makes that game great; it's the process that produced the game that allowed it to excel.

Take any other popular title, from Mario to Warcraft to the Sims.

Having an idea like "it's got the same art quality as TF2, but in space!" isn't worth the time it takes to think it. That "same art quality" represents a huge amount of work, as well as some skilled judgment in art direction. Plus the technical side!

I'm amazed at the number of teenage guild leaders in World of Warcraft. 99% of you suck. Great, so you're 15 now. Do you think 12 year olds are particularly mature? Would you be willing to follow an 8-year old into battle? No? Then why the fuck do you think someone twice your age would think you are a good leader?

Likewise: you have a great game idea. Swell. I'm happy for you. I have "great game ideas" every fifteen minutes. More than that if I'm stuck in traffic. A great game idea and $1.07 will buy me a cheeseburger.

If you want to get into the games industry, don't start with an idea. Learn to draw or to program. Make some levels. Learn to script.

But whatever you do, please don't make a post on every game dev board you find, asking for other people to make your game for you.

Schedules

Gantt charts suck.

They're great for work that's like manufacturing, where you have a clear assembly-line perspective on how the work is supposed to be done. Gantt charts are useful for resolving dependencies between different parts and finding out what the gates on development are.

But programming isn't manufacturing. It's not engineering, either. I'm a big proponent of software engineering, but that body of knowledge is more like disciplined craft than engineering. An engineer can plan out what needs to be developed, what each piece needs, and how long each piece will take to build. He can make you detailed drawings on how the piece looks. He'll give you the formulas for all the chemical reactions that go on in your plant. He'll tell you how strong that girder needs to be to hold the weight and stress that will be put on it.

But programmers can't do that. How long will it take to write the AI? Hah! The designers don't even know what the AI will do yet, or how complex the collision maps are, why would a programmer have any idea how long an AI will take?

I've written many different particle systems. I could clone one of my old systems fairly quickly, and also give you an accurate estimate of how long it would take to do. But no system exists in a vacuum. A particle system has to integrate with the underlying graphics engine. You might want to add some constraints to the system to prevent it from bogging down the CPU. And then there's always new features to add halfway through development.

If you ask me to build the same system that I built last year, then we're getting close to engineering. If I built that same system a half-dozen more times, it'd be the sort of streamlined, organized project worthy of being called engineering. But hah! And hah again! The technology moves to fast for that to happen.

New systems are research projects. If we could properly schedule research projects, then we'd have a cure for cancer already. We woulda had one decades ago. But research isn't like that, and most systems in games are new systems, similar to last year's model but with a new twist. There's no good way to figure out how that twist will effect the project until it's built, though.

And that brings us back to agile development. Scheduling is just a loopy fallacy. If it wasn't for programmers being exempt employees (or employers dodging the law and refusing to pay overtime)... well, actually, I think that's the sort of mess that would force a lot of people to reassess how they schedule programming.

An iterative model means frequent releases. Agile development means prioritizing features. You might not know when everything you want will be done, but at least you'll be sure the important bits were done by the time you need to ship.

I'm working on a little sprite editor this weekend. I need both a subset and superset of the tools that most paint programs have, so I'm just building my own. (I wrote my first paint program for the Atari 800 around twenty years ago.) At one point, I was tempted to write down all the tasks that I needed to complete before I considered the editor done, then decided to throw the list away. I don't really need to know when the tool will be done. I know what's important, and I'm doing the big, obviously important stuff first. Things like frickin drawing. Saving, loading, color picking.

I'm not trying to build the uberest components ever, before the app runs. I'm not amassing giant graphics libraries, full of all the latest algorithms and hippest widgets. Screw that. If I need that stuff, I can add it when I need it. Right now, I need a way to use an Eyedropper without having to take my hand off the mouse, or reach across the keyboard (usually meaning looking at the keyboard), with the chance for error and time wasted. That feature? That's in already! Although minimally functional, it's already useful.

And hence another problem with schedules: you might have the most accurate schedule known to man, but if your programmers are busy adding features that no-one will ever use, then you've wasted their time. Your project is less likely to succeed because you were more worried about being 'done' on time than you were about what you had working.

The stuff that slows down programming, for me, is almost always completely outside the scope of programming. Things like 3rd-party libraries being incompatible (from things like XNA not building under Visual Studio 2008, to creating MS Exchange mailboxes on Vista requiring not a simple code library like in XP but a completely separate scripting system). That shit set me back days, on tasks that were, otherwise, only a few hours long. On my current game, the conversation editor took me over a week to complete, when nearly every single other editor took on the order of 3 hours. Why? The design kept changing. (My designer is a fucktard. But all the chicks say he's sexy so I'm stuck with him.)

So, you might ask, how in the world can you schedule if you can't schedule? Again with the iterative development: you'll be releasing on a regular basis anyway. If you have a drop-dead ship date, quick iterations mean you'll have something steady. Prioritize the tasks that you give your programmers, and they'll get the important stuff (and the low-hanging fruit) done. The better your programming team, the more features you'll have at ship. And because they released new builds all the time, it'll also be a robust game.

High-Level Game State Management

By 'state management' I mean high-level game state. For example, when a game starts up, it might display a sequence of loading screens, including company logos, a game title screen, and intro cinematics. Then the main menu; then the game proper. Within the game itself, the game might have different screens that it displays and moves among, from character info to world view to options, etc.

I've seen some weird state management systems in my time. Almost all of the "systems" I've seen other people use aren't really systems; they were just hand-coded transitions, often involving a lot of global variables, a bunch of free functions, large switch statements, etc. Or maybe just a bunch of nested function calls, meaning that, when you quit the game, it backs out all the way through the main menu, past the title screen, the company logo, and the intro loading screen...

A programmer that's used to doing something one way, and satisfied that the approach is efficient, is unlikely to do something different. So here's something new.

I use a class-based state management system, cuz I'm a C++/C# programmer. State is managed through a 2-level inheritance hierarchy -- no complex class relationships, just one base class and one subclass for each different state. The main loop calls a static singleton to do whatever needs to be done in the current state; that singleton calls the current state subclass (of course, through a virtual function) to do its thing.

Each call through the system renders one frame. Usually; the current state can spend a bunch of time if it wants, which really only happens when loading new content. Even then, I sometimes leave the loading work to a different thread and continue rendering frames. This is one instance where the specifics aren't important; how you handle loading is independent of the idea of using a State parent class and its children to switch between different high-level states.

When a State has figured out that the game needs to move to a different state, it tells the state manager. I stick an enum for the different states in a header file. (Note that this means a bunch of recompilation "every time" I add a new State subclass. The thing is, that doesn't happen that often. There'll be maybe eight or ten states in the entire game, and over the lifetime of the project, ten extra recompiles is no big deal.) Since each run through the state manager generates one frame, the state manager can do cleanup and transition to the new state cleanly on a frame boundary.

I typically use an event model for controller/keyboard/mouse input. The events are grabbed at a high level and fed through the state manager. Abstracting input is a handy thing, and this structure solves that problem.

I've sometimes built complex stuff like preloading and caching into the state system. Separating out each game screen makes a bunch of stuff easier. Since the state objects aren't unloaded when state changes, a "level" can keep itself in memory, cached provided there's enough memory for it, meaning no lengthy load when the user (say) backs out to the main menu then reloads from a save point.

The State parent class has, over time, morphed into a Screen class. The different 'states' that this system models are often the major screens in a game: the loading screen, the company logo, the game title, the main menu, submenus, and the game proper. If save/load is handled through a fullscreen interface, that's a chance to move that code into its own class.

It doesn't matter to me if you use this structure, of course. I hope it's given you some ideas for structuring the high-level bits of your game differently.

Note: I've made a followup post on state management in game menus.

Open Worlds III

Open Worlds III: When NPCs attack!

I think open worlds are compelling because they're immersive. They feel real. It really appeals to explorer-types, which is my main drive. (What's yours?)

I think creating an open world is a balance between two goals: (1) giving the player places to explore, neat things to see, and a chance to play with game mechanics on his own time, and (2) telling the player what to do next.

Any good game gives the player places to explore. Unless the game is timed in such a way that there's no save, and the player has no choice but to win or die, the player has a chance to run off and chase butterflies. I don't know of any game that doesn't give the player a chance to explore. Even in fighting games, the player can choose to not engage the opponent and spend some time jumping around or seeing what else is in the world. (Chances are there's not a whole lot; background animations maybe?)

Exploration isn't just running around and mapping. Explorers also like discovering and understanding game mechanics. They want to root out the math behind combat. They figure out how to min-max their characters. Yet this isn't part of being an open world, though. Complex game mechanics gives explorers extra goals, but it doesn't really make the world open.

An open world is non-linear. The key here is giving players options. Not only does the player not have to stay in Fooville to work on the main quest, but they also have something to do elsewhere in the world. The golden Ultimas (ie 4-7) had quests all over the world. In Mario World 64, there were places to go grab stars in each of the 'worlds'. In the Grand Theft Auto series, the player might have several independent quest chains they could pursue, or they could just run around and explore and map and try out mechanics. In all three, the player had not just the opportunity to go anywhere, but they also had something to do when they got there.

Just making random encounters and procedurally-generated dungeons to explore isn't enough. The 'something to do' should be game-relevant. Side quests and parallel quests are important here. If the player 'plays out' a region of the world in one session and then has no reason to return, the openness of the world loses its meaning. If you can go back to Trinsic but there's nothing to do there, then the choice of returning is meaningless. This ties into the next point:

With an open world, you get the economy of being able to re-use content; instead of the player only seeing your intricately built environment once, they get to run around inside it over and over. I think the biggest benefit here is that this makes balancing world richness easier. When parts of the world are made by different designers and/or at different times, some might wind up being more complex than others. Now that content is placed over the world in layers, I think it's easier to make that depth consistent.

The second pillar, the other end of the spectrum, is giving the player a goal. When you allow the player to go back to revisit content, you need to tell him he can do so. Tell him what he needs to do to advance the plot. If the player is lost in a big, open world with no idea of which of the billion NPCs in the world he needs to talk to, he'll probably become frustrated and stop playing. And return your game and tell his friends it sucks. Then not buy the sequel, that's for sure. (One way around this is to have several different threads that all point in the same direction; e.g. NPCs in each of your major cities might have their own independent quest to go talk to the next relevant guy. If the player completes one but then gets distracted, one of those other quests should send him back.)

Some players really like being given a direction. It's essential for Achievers. I think all players benefit from having a clear goal to pursue. I think this is a key part of the appeal of class-based systems: tell the player what the measuring stick is. Give the player a clear understanding of the rules in your world. Help them fit in by telling them how your world works.

Linear games might get this wrong, if they don't tell the player what the current goal is. The player might be stuck in one location (it's a linear game, on rails), but not know what it is he needs to do to move on. The player needs to know what to do, not just where to go.

These two pillars don't form a continuum. It's similar to the Libertarian argument: there's really two axes here. You want to make sure the player knows how to move the game along, but at the same time provide him flexibility in what he does next. A great game doesn't need linearity; it needs to avoid leaving the player in a vacuum.

Agile Development

I'm an agile developer, but I don't use XP or Scrum. "Agile" is the umbrella term that includes XP, Scrum, and a host of other practices. "Agile Development" isn't a methodology unto itself.

To me, the heart of Agile is adapting to change; being flexible; being able to change quickly. Citing "continuous attention to technical excellence and good design" as a principle sounds disingenuous to me. That's not what separates Agile methods from other approaches. Likewise, citing Simplicity isn't very useful unless you make it clear what you think Complexity is. Yeah, messy code is bad. I'm not sure who you're going to find that's going to disagree with that.

The key observation that leads developers to agile methods is that, as programmers, we learn much more about a problem and its solution by solving it than by staring at it. Agile is the opposite of Big Design Up Front. Planning is a good exercise, and I think any competent dev team has a plan -- but when they learn more about what they're building, they'll be more willing to change that plan (and come up with better changes to boot). The core argument here is that solving a problem produces information about a problem faster and more effectively than planning alone.

There are three major practices central to agile methods. They are iterative development, top-down development, and flexible code.

Iterative development means making frequent releases. If you want to adapt to change, then you need to adapt; to change. Grossly, there are two approaches here: (1) build the whole thing, then stand back and see what you need to do different, or (2) build some of it, then stand back and assess what your next step is. Iterative development breaks up a big project into small chunks so that you can get something finished -- to make progress -- before you go gallivanting off in another direction.

An agile developer can shuffle priorities around at each iteration. Quick iterations also means more visibility up the management chain; they know where you are because you released something recently that shows where you are. Iterations also give your customers a chance to give feedback before you've gone "too far," and it provides a chance to reign in a wayward developer who has gone too long without contributing to an iteration.

I think most of the benefit of frequent iterations is incorporating feedback. To me, a big up-front design that calls for frequent releases seems squirrelly. Why are you releasing if you're not going to listen to feedback? If you're using a waterfall model, then your interim releases are going to be full of bugs, untested, and probably won't have a cohesive set of useful features.

I like planning using something small and physical; I haven't been too happy with any of the automated tools I've seen. I write down features on index cards, and sort them by priority. Every time someone completes a task, they go to the table-o-index-cards to grab their next task. (Usually they know ahead of time which set of cards are going to be theirs.) When too many features show up and/or developing an important feature takes too long, it is real fucking easy to see what tasks fall off at the back end.

Top-down development is making something simple that runs and slowly adding new features to it. I think one of the great bugaboos in software development is YAGNI, and top-down development is its cure.

In games, it's fun to get something working quickly. Plus, something working quickly gives your team more time to figure out what works and what doesn't, to see models and animations in action, and to start playtesting and thinking about balance.

Adding new features can be difficult if your code is a mess. Working around that is my third pillar today:

Flexible Code. It's hard for me to explain what this is, because unflexible code just looks so alien to me that it makes my brain hurt. The bad practices that hurt the worst here are hidden side-effects, large functions, blob classes, opaque data structures, and automation.

Automation makes a lot of things easier, but it's horribly inflexible. By "automation" I mean code structures that encapsulate some set of features into a magic little opaque blob. (You're not detecting any bias here, are you?) "Automated" code magically sticks items into queues, deletes items, changes variables, etc etc, usually in ways that someone debugging code would never know about. "Automation" often makes systems significantly easier to build, once you've learned your way around the code. But bugs can be a nightmare to remove, and god forbid someone new has to learn the system. Or its original developer leaves.

Ultimately, the goal of agile methods is to increase productivity. The two main ways this happen is by only writing code that you actually need -- by prioritizing up front and coding top-down -- and by making it easy to add new features. Some of the most frustrating experiences I've had while coding have been when I've been faced with a system that violates some of these rules. 3rd-party systems are often the worst, because (for contractual reasons) you can't see their source code, so the whole thing becomes magic. How does it work? Who knows! Plus they never bothered to document anything! Grrr.

There's tons of resources out there on agile development, but my favorite is the c2 wiki, aka WardsWiki, the firstest Wiki evar. I learn a lot more from reading both sides of an issue and making up my own mind. The C2 wiki is a great place for that. :)

Naming Conventions

Hungarian is lame. Foolish. Using Hungarian is saying "knowing the type of this variable is sofa king important that I must encode it in the variable name."

Typing isn't a major part of programming. Being able to type quickly helps, but short names don't save you that much. If you have to spend just one second trying to figure out what a variable is, that short name just cost you more time than you gained. So I'm not complaining about typing the extra characters in the name.

Source code is for the programmer, not the compiler. Compilers are easy to satisfy. They tell you if you did anything wrong. If you need to make sure you have the types right... don't. The compiler will tell you. In C#, you can't mistakenly treat an int like a char, or a bool like an int, or even mix your pointer types transparently. With warnings cranked up, C++ is just as type-strict. Back in the olden days of C, when pointers could go to void* or int or any other type without letting you know, the programmer had to be careful with variable types. We don't need to do that any more. It's a bad justification for variable-name cruft.

But correctness, that's a different kettle of fish. Your code should be easy to understand, by you, by your coworkers, by yourself in six months. That's my standard here: variable names should help you understand the code.

One analogy I frequently make is to say the brain is like a CPU. You've got 7 (plus or minus two) registers to play with. Time that you spend parsing a Hungarian prefix (and then discarding it) is still time spent, plus processing all that will consume one or two of your registers -- meaning that you'll either have to dump some registers into long-term storage or, more likely, discard them. When you're looking at a function, you've got to keep a lot of stuff in mind. What should the function do? If you're debugging, what is it actually doing? You might be thinking about a calling function's needs. The algorithm itself might be complex. The more complex the algorithm, or even dealing with special cases, the more registers you need to understand it. If you're wasting registers dealing with cruft, then it'll take you longer to make the function correct.

Forget typing it in the first place. You want to minimize the time you spend on a function while still making sure it is correct, which means satisfying yourself about correctness as efficiently as possible.

Words are tags; labels. Their written (and spoken) forms serve as anchors for the underlying concepts. Those concepts are mental entities. When you're thinking about an algorithm, you want to be working with simple tags. If a tag is something long like "previousWorldStateIndex", or, worse, "wsidxPrevious", then you've got to blow registers parsing all those keywords. When thinking about the algorithm at hand, "previous" works just fine. When you're in deep thought, all you need is a simple handle, not an accurate one.

Your functions shouldn't be long, either. Most of mine are around 7 (plus or minus two) lines long. There's a good number that are shorter, plus some that are over 9 lines. If you can abstract a line into one thought, then you can grasp a whole function at once, rolling your mind back and forth over it, like you'd probe a strange object with your fingers.

A variable declaration defines an object type just fine. If the function is only 7 lines long, you don't need to repeat the variable declaration over and over. When I'm debugging, I need to read that declaration just once, and then I've loaded that concept into one of my mental registers and I can ignore the declaration from then on. Because the compiler will catch gross type incompatibilities, and your thinking about the algorithm should catch others, all you need is a one-word tag for the variable.