Another post intended to help newbies learn some of the basics that normally require you to screw up first. This is my opinion, not some industry standard, but I hope it helps.
If your game is the sort that lets people save, it's important to think about some aspects of that.
Most fundamentally, there are several games I've stopped playing not because they were bad, but because their save systems were impossible to get along with. For example, in Dynasty Warriors 6: Empires, in order to save your game you've got to select a hard drive, select a slot, click A, click left then A, and then click A again, each with a second-long fade animation you can't skip. It takes a good ten seconds to tell it to save to the same exact place you saved it last turn.
An equally serious problem are games that have one save-load screen. The worst mistake a save system can cause is when the player clicks on "load" when they meant "save". Enough time has passed and progress has been made they they feel nervous about losing it, so they go to save, and BAM, they lose it because they went to save. That'll make you lose a player real quick.
So, if you allow manual saving and loading, the basic rules are simple. Have two distinct screens, one for saving, one for loading. These screens no longer need to have "save" or "load" buttons, those are relics. The only reason to do it in an old-fashioned way is if your publisher or platform demands it.
If you allow the user to name their saves, then when they click on a save slot, it should start with an arbitrary name but highlight all the letters so that, if the player starts typing, his text overwrites. While the slot is active, a "cancel" and a "save" button should pop up next to the slot, preferably not in a layout where you will accidentally click one when you mean the other (circular buttons with different colors are good). Pressing "enter" after you edit the text (or without editing the text) should save, while pressing "escape" (or "b" or whatever) should cancel. There is no need to pop up another window demanding confirmation, because the confirmation is built into the way it saves.
If you do not allow your user to enter a name, the old way is still the best: the user clicks on a slot and, if the slot already has a save game in it, a window pops up to ask if you're sure you want to overwrite. Generally, I like to default to yes (and have the "yes" button under the cursor's current position), but you can argue either way.
In terms of slots, games disagree on whether to use big slots where you can only fit 4-5 on the screen at once, or small slots that can fit dozens. I think big slots are best (as long as you can scroll to see more), but that's up to you.
Also divided on is whether to include autosave slots on the save screen or not. I think you should: players are better off knowing how often autosave saves, and how many rotating autosave slots the game uses. I also recommend making autosaves distinct from user saves, in that a user cannot save over an autosave slot, or delete one.
Load screens are a similar matter. Your slots should have the same layout, and you should definitely include autosave slots. However, the screen itself should be visually super-distinct from the save screen. If save is green and leafy, load should be a giant red mech. It should be impossible to mistake one for the other, and you should assume nobody will ever see the word "save" or "load" where it is emblazoned across the top of the screen. You did label the screens, right?
There are two ways to respond to a click to load. Well, three, but the click-and-instantly-load option isn't accepted very well, for some reason.
If you are using small slots to fit lots on the screen, when the user clicks on a slot an info card should "pop up" in a standard position on the screen, saying more about the save game (time elapsed, position, party members, ammo, etc). Clicking on the slot OR the info card should load. The info card might have a visual tag - an arrow and a "LOAD" icon - but this should not be the only place to click. Any reasonable click should work.
If you are using large slots or your publisher/platform demands it, pop up a dialog. "Load this game?" Again, I like defaulting to "yes", with the yes under the cursor, but whatever your publisher demands takes precedence.
The automatic naming of save games is an art that most games don't bother with. The location and total time of play are important, but it's also important to give the player some context as to what was going on when they saved. If the game is smart enough, I like to put a "headed to..." or "just finished..." tag on my save games automatically. This is more important in games where there is a lot of backtracking and freedom, and can functionally just tell the player what his active quest is, or what plot point he most recently completed.
---
Every game should autosave what it can. Not all games need to autosave the exact position of all the pieces, or the velocity of the player, or any of that. A lot of games only need to autosave points and victories and what level you're on. In some cases, this kind of autosaving is so basic that all this talk of slots and loading makes no sense: something like Bookworm Adventures, for example, just saves your progress and that's it. No need for slots, no need for manual saves or load screens.
However, many games with less linear progression and more player freedom will need to think about how autosaves fit into their overall loading and and saving schema. The answer is: autosaves are your overall loading and saving schema.
The truth is that manual saves are relics. There's no reason not to include them, so include them. But you should build your game with the assumption that the player is going to rely wholly on autosaves. I think you will find that, in a few years, that is exactly what players will do.
Autosaving is still a young science. One important detail is that an autosave can't take any time to do: you can't pause the game for an autosave. This can be troublesome if you need to save a lot of information, but there are always ways. Having the save happen on another thread is always possible.
Despite the fact that autosaves should happen fluidly, you should put up a marker when you do autosave - just a little thing in the corner of the screen. In the future I expect this will be unneeded, but for now people still don't trust autosaves to save well, and you should put up an icon.
Never use just one autosave slot if you have multiple manual save slots. Three is a good number if you're worried about space. If you're not worried about space, use ten. You can revolve through them, but I actually recommend only revolving through them after a certain amount of time (five minutes) has passed. If you autosave ten times in two minutes, there's no reason that should overwrite the entire set of autosaves.
Autosave as intelligently as you can. If the player is about to enter a room with a big battle, autosave. When the player quits the game, autosave. After the big battle, autosave. Something new picked up? Autosave. If you find your game autosaving "too much", it's only a problem if it is affecting your gameplay or slowing the machine down.
In the unlikely event that you are autosaving something with diverging paths (such as the "moral choices" of Bioware games) you should consider autosaving into a permanent slot just before each option, such that no matter how many more autosaves are made, the player can always return there and try the other path.
Autosaves should have reasonably useful names so that, when a player wants to load, he knows exactly where he was and what was going on. Screenshots included in your autosaves are also valuable for this.
...
The last kind of save type is the quick save and quick load. To be honest, I don't like the quick save and the quick load, not unless they are somehow fundamentally linked to the gameplay. I think quick saves will cripple your design if you're a good designer, and let poor design slide if you're a crappy designer. See: every FPS with a quick save.
Some people still love quicksaves. It makes them feel in control. I think it's bad design to cater to that. But, hey, whatever floats your boat.
I have no real advice on their implementation, other than to remind you not to make the quicksave button right next to the quickload button. Put an empty button between them, at the very least.
...
The technical side of loading and saving can be quite difficult for a beginner. Reading from a file to initialize (or re-initialize) tons of values for tons of objects is pretty intimidating.
If your needs are minimal, a simple custom save format will work fine. However, if you're talking about saving in the middle of a level and bringing everything back exactly as it was, you're talking about a whole lot of parsing code.
Many languages can automatically save and load objects if they are correctly tagged. For example, in XNA/C# you can use the [Serializable] tag to make it so you can write and read XML representing the object. This is typically good enough for a small project, although if you're talking about a whole world of objects, it can be pretty slow and fatty.
If you are developing a game with a huge number of must-be-saveable elements, you probably want to not develop that game, because it's too complicated for an indie. However, assuming you absolutely must, you have two options.
One is to do most everything through a database. If the state of the object is stored in an in-memory table, you can create versioning information in that table to save the state when you need to. You can write the table to the hard drive intermittently, or when the player quits.
Also, when I develop my tools to do level design, they output a particular script (I normally just use XML these days). For ease of integration, I usually make my save games use the exact same script. This can be optimized, if needed, to only write the changes between the level script and the current moment.
However, I need to stress: an indie game will almost certainly NOT have such punishingly huge levels that it needs to save using these kinds of methods. Normally, just a simple custom script or a serializable tag will do the trick.
Thursday, April 29, 2010
Tuesday, April 27, 2010
Game 101: Menus
I talked with a buddy and we lamented that most newbies to game dev seem to make the same mistake as other newbies did. If you are a newbie, and want to avoid the mistakes your ancestral newbie brethren made, I hope this series will help.
This is just my opinion, based on my experience, and I am not a god-king of game dev. Take it with a grain of salt, and read the comments (if there are any) for other opinions.
SO!
This is an article on a basic part of game design/programming that's often overlooked: the menu.
...
Every time I go to XBLA, I see the indie games. I look at their screenshots. Invariably, the screenshots include at least one image (frequently two or three - out of five!) of their menus.
I think this is because a young developer completes the menus and says, "hey, that was hard! But now it's a real game, not just a toy! I'm so proud of my menus!"
So, here's some advice: your menus are not important. Or, rather, they are important in the same way that a house's structural beams are important. They need to be there, but nobody really cares. A few games (like Riddick) have very flashy menus, but they don't make the game any better and are essentially programmer wank to give the coders something fun to do when chasing down the damn rendering bug has finally gotten to them.
Because menus are both fundamental and somewhat difficult for beginners, I thought I would share some basic advice for how to get it done.
Zeroeth, before anything, I need to make it clear: your menus and your gameplay screens need to play nice. I generally make them the same top-level class and control them in a predictable manner from the main game object. Trying to hammer menus in when you've created your entire code base to blitz right to the gameplay makes your life harder than it needs to be. If you start right up front understanding that menus and gameplay will be trading off control, you can save yourself a load of pain.
Okay, next and first I'm going to cover the basics of menu design. Later I'll cover the basics of menu programming.
Menu design is something that most games do fine, but sometimes you'll stumble across a game - even an AAA game - that does menu design poorly.
The first thing to consider when making your menus are the outside requirements you must adhere to. Most indie devs probably don't have any outside requirements, but sometimes you'll run into something like "in order to be published on the XBox, you have to do X and Y in the menu, and always default to 'no', etc, etc". If you do have these sorts of restrictions, make sure that you take them to heart, even if they are sub-par. In this case, being uniformly sub-par is much preferable to being erratic.
With that said, the actual contents of your menu will depend mostly on your game. Don't feel the need to stick everything on one screen: generally, you want between 5 and 10 options on an "options" screen, 3-6 on a non-"options" screen such as the main screen. Save menus, stat-level-up screens, and score screens are their own special cases, since they have loads of nearly identical elements and only a few real "menu" choices. Anyway, if you need more options than you can really fit without crowding, think about splitting the screen into two or more tabbed/scrolled screens.
Modern games are split between the older "change, then save/cancel" style and the newer "save instantly when you change" style. Personally, I think the save/cancel style is obsolete, and I think you should change the options the instant that they actually change, or as soon as that option loses focus, if the change takes a moment to propagate.
Including a "reset" button is generally a good idea, as is a dedicated "back/exit" button. I don't think I've ever used a reset button, but like the high-priced menu item at a restaurant, it makes all the other things the player could experiment with seem reasonable. So have one.
Even if your game is completely simple, you should save your options settings to a file so they remain true between plays. It's surprising how irritating it is to have to change the settings every time you start the game up. Similarly, even if your game is dead simple, you should have some options to set. Volume, at the very least. Only the most primitive games don't have options menus, and that's only fine if that's what you're aiming for.
When it comes to flashy layouts, the basic answer is "don't". You can theoretically get away with very flashy menus, but in practice it's much too much work for much too little return. Keep your menus simple: menu name on the upper left, game logo on the upper right, menu options striped down in a column, back/exit on the lower left, reset on the lower right. This works for 99.9999% of all indie games.
You may, of course, have a background image that makes it look slick. If you're really feeling your oats, you might have that vertical column of options drift slightly, but keep it a column. The days of fifty options spattered at random across the screen are over.
I hope.
Your main game menu is an exception in two ways. First, it generally doesn't have the menu name, back, or reset: it's normally a single column with the last option being "exit". Second, it can be quite artsy-fartsy if you like. I don't recommend it, but you can use a radial layout, or dodgy positioning, or even scrolling-fading choices. This is all fluff, but it can be worthwhile if you want to make an impression. Just don't do that in the various sub-menus! Keep anything that actually involves complex options or choices as clear as possible. Either way, never include screenshots of your menu as ad copy.
As you develop your menu, you may find you need really complicated menus. For example, if you're building an RPG, you may have to have fifteen stats, ten skills, a portrait, an equip-dummy, an inventory, etc, etc, etc.
Your maximum complexity is going to depend on you. With an in-game menu that the player will access a lot, you can be more complex because it's more important that the data be right there rather than hidden behind a click. On the other hand, even then too much complexity is a bad thing.
Depending on the nature of the game, I frequently use multiple, dockable menu windows instead of a single, really complex one. For example, my equip dummy and my inventory wouldn't usually be a single window: they would be two distinct windows that happen to be up at the same time.
It's really surprising how much easier this makes things. If each dockable menu is "simple", you can create very complex but easy-to-program and easy-to-use interfaces by combining these simpler modules.
...
Second is the actual programming. There are loads of ways to do menu programming, and if you're using middleware that has built-in menu support, this next part won't matter to you. Just do it like your middleware says to: there's absolutely no reason to reprogram the wheel.
If you aren't provided with a decent set of menu tools, it's relatively easy to make your own. I generally make a set of menu libraries for every language I program in. Because menus just have to be functional, not awesome, you can re-use even poorly programmed menu libraries.
If you search on line you may be able to find a menu library for your language. You can also make one yourself. Generally, I do the latter, and here's the technical structure I use:
I make a main game object that wrangles all the rendering and IO. Usually this already exists, and you can just inherit from whatever the object is, or make your own and simply reference it from the existing main object.
The main game object contains a stack of "screen" objects. Depending on the situation and the language, this might be a simple array, or it might be a few explicit members and you have special code for each. Either way, some of those screen objects can be menus, some might be your game screens where the play really happens. The main game object then updates, paints, and sends control objects to those screens: the active screen gets the normal update, paint, and control, while the secondary (but still existing) screens get a special brand that keeps them visible but usually grayed out and frozen.
Remember to paint in the right order: most languages will paint in front, so you have to paint from the rearmost passive screen up to the foremost menu/game screen. If you are using a mixed 2D/3D system, this can get pretty messy, so be careful to understand how, say, a SpriteBatch will screw up a 3D GraphicsDevice.
Each screen has events it can fire, and the game object can catch these events and interpret them. This allows the game object to get rid of a menu screen and create a new active screen, take actions based on your selections, etc. Generally, I have an "empty" event that simply passes the screen object when it fires, and I also have a generic string event that passes the screen object and a string. The former I use for clearing away a screen, the latter for making a selection on it. You may also need one that contains a number as well, for things like changing the volume or the difficulty.
Nearly every language supports an event-driven system like this, and it makes extensibility very very easy. For example, we can easily create a member for the screen class that contains a screen object. Instead of making the main game object control every screen, we can have custom overlays for each screen. This is very handy if you have special menus, huds, or maps that pop up on top of a game screen and depend heavily on the game screen's information.
The fact that the screens are "agnostic", just firing events into space, means that it's also easy to rearrange them. I frequently have very different menu layouts between development, demo, debug, and the rare "release" menu layout.
If your game has complex menuing, such as an RPG, you'll probably need draggable, dockable menus. Some engines have a dockable window system built in, but if you need to make one on your own, it's not actually very hard: there are dozens of tutorials for any language. Just be aware you may need to do it.
If you're using an XBox controller, the player may not really be able to drag your dockable windows. Use them anyway. You can manually place them using your code, and it'll be a lot easier than hard-coding complex, monolithic menus.
Actually rendering the menu text shouldn't be terribly difficult for you, but it is generally better if your menu screen class has an array of options that you can arbitrarily add to, instead of painstakingly scripted line-by-line menu placement. The menu screen should understand how to navigate through them, highlight the one you're on, and throw an event if you select one. You may want to make your line-by-line menu items small classes that render themselves, so that it's easy to do radio buttons, sliders, etc. Often, your development environment will include such items already: no reason to make your own!
This is all very basic, but it's hard to know how basic is basic enough, so there it is. Post additional advice or feedback to the comments.
This is just my opinion, based on my experience, and I am not a god-king of game dev. Take it with a grain of salt, and read the comments (if there are any) for other opinions.
SO!
This is an article on a basic part of game design/programming that's often overlooked: the menu.
...
Every time I go to XBLA, I see the indie games. I look at their screenshots. Invariably, the screenshots include at least one image (frequently two or three - out of five!) of their menus.
I think this is because a young developer completes the menus and says, "hey, that was hard! But now it's a real game, not just a toy! I'm so proud of my menus!"
So, here's some advice: your menus are not important. Or, rather, they are important in the same way that a house's structural beams are important. They need to be there, but nobody really cares. A few games (like Riddick) have very flashy menus, but they don't make the game any better and are essentially programmer wank to give the coders something fun to do when chasing down the damn rendering bug has finally gotten to them.
Because menus are both fundamental and somewhat difficult for beginners, I thought I would share some basic advice for how to get it done.
Zeroeth, before anything, I need to make it clear: your menus and your gameplay screens need to play nice. I generally make them the same top-level class and control them in a predictable manner from the main game object. Trying to hammer menus in when you've created your entire code base to blitz right to the gameplay makes your life harder than it needs to be. If you start right up front understanding that menus and gameplay will be trading off control, you can save yourself a load of pain.
Okay, next and first I'm going to cover the basics of menu design. Later I'll cover the basics of menu programming.
Menu design is something that most games do fine, but sometimes you'll stumble across a game - even an AAA game - that does menu design poorly.
The first thing to consider when making your menus are the outside requirements you must adhere to. Most indie devs probably don't have any outside requirements, but sometimes you'll run into something like "in order to be published on the XBox, you have to do X and Y in the menu, and always default to 'no', etc, etc". If you do have these sorts of restrictions, make sure that you take them to heart, even if they are sub-par. In this case, being uniformly sub-par is much preferable to being erratic.
With that said, the actual contents of your menu will depend mostly on your game. Don't feel the need to stick everything on one screen: generally, you want between 5 and 10 options on an "options" screen, 3-6 on a non-"options" screen such as the main screen. Save menus, stat-level-up screens, and score screens are their own special cases, since they have loads of nearly identical elements and only a few real "menu" choices. Anyway, if you need more options than you can really fit without crowding, think about splitting the screen into two or more tabbed/scrolled screens.
Modern games are split between the older "change, then save/cancel" style and the newer "save instantly when you change" style. Personally, I think the save/cancel style is obsolete, and I think you should change the options the instant that they actually change, or as soon as that option loses focus, if the change takes a moment to propagate.
Including a "reset" button is generally a good idea, as is a dedicated "back/exit" button. I don't think I've ever used a reset button, but like the high-priced menu item at a restaurant, it makes all the other things the player could experiment with seem reasonable. So have one.
Even if your game is completely simple, you should save your options settings to a file so they remain true between plays. It's surprising how irritating it is to have to change the settings every time you start the game up. Similarly, even if your game is dead simple, you should have some options to set. Volume, at the very least. Only the most primitive games don't have options menus, and that's only fine if that's what you're aiming for.
When it comes to flashy layouts, the basic answer is "don't". You can theoretically get away with very flashy menus, but in practice it's much too much work for much too little return. Keep your menus simple: menu name on the upper left, game logo on the upper right, menu options striped down in a column, back/exit on the lower left, reset on the lower right. This works for 99.9999% of all indie games.
You may, of course, have a background image that makes it look slick. If you're really feeling your oats, you might have that vertical column of options drift slightly, but keep it a column. The days of fifty options spattered at random across the screen are over.
I hope.
Your main game menu is an exception in two ways. First, it generally doesn't have the menu name, back, or reset: it's normally a single column with the last option being "exit". Second, it can be quite artsy-fartsy if you like. I don't recommend it, but you can use a radial layout, or dodgy positioning, or even scrolling-fading choices. This is all fluff, but it can be worthwhile if you want to make an impression. Just don't do that in the various sub-menus! Keep anything that actually involves complex options or choices as clear as possible. Either way, never include screenshots of your menu as ad copy.
As you develop your menu, you may find you need really complicated menus. For example, if you're building an RPG, you may have to have fifteen stats, ten skills, a portrait, an equip-dummy, an inventory, etc, etc, etc.
Your maximum complexity is going to depend on you. With an in-game menu that the player will access a lot, you can be more complex because it's more important that the data be right there rather than hidden behind a click. On the other hand, even then too much complexity is a bad thing.
Depending on the nature of the game, I frequently use multiple, dockable menu windows instead of a single, really complex one. For example, my equip dummy and my inventory wouldn't usually be a single window: they would be two distinct windows that happen to be up at the same time.
It's really surprising how much easier this makes things. If each dockable menu is "simple", you can create very complex but easy-to-program and easy-to-use interfaces by combining these simpler modules.
...
Second is the actual programming. There are loads of ways to do menu programming, and if you're using middleware that has built-in menu support, this next part won't matter to you. Just do it like your middleware says to: there's absolutely no reason to reprogram the wheel.
If you aren't provided with a decent set of menu tools, it's relatively easy to make your own. I generally make a set of menu libraries for every language I program in. Because menus just have to be functional, not awesome, you can re-use even poorly programmed menu libraries.
If you search on line you may be able to find a menu library for your language. You can also make one yourself. Generally, I do the latter, and here's the technical structure I use:
I make a main game object that wrangles all the rendering and IO. Usually this already exists, and you can just inherit from whatever the object is, or make your own and simply reference it from the existing main object.
The main game object contains a stack of "screen" objects. Depending on the situation and the language, this might be a simple array, or it might be a few explicit members and you have special code for each. Either way, some of those screen objects can be menus, some might be your game screens where the play really happens. The main game object then updates, paints, and sends control objects to those screens: the active screen gets the normal update, paint, and control, while the secondary (but still existing) screens get a special brand that keeps them visible but usually grayed out and frozen.
Remember to paint in the right order: most languages will paint in front, so you have to paint from the rearmost passive screen up to the foremost menu/game screen. If you are using a mixed 2D/3D system, this can get pretty messy, so be careful to understand how, say, a SpriteBatch will screw up a 3D GraphicsDevice.
Each screen has events it can fire, and the game object can catch these events and interpret them. This allows the game object to get rid of a menu screen and create a new active screen, take actions based on your selections, etc. Generally, I have an "empty" event that simply passes the screen object when it fires, and I also have a generic string event that passes the screen object and a string. The former I use for clearing away a screen, the latter for making a selection on it. You may also need one that contains a number as well, for things like changing the volume or the difficulty.
Nearly every language supports an event-driven system like this, and it makes extensibility very very easy. For example, we can easily create a member for the screen class that contains a screen object. Instead of making the main game object control every screen, we can have custom overlays for each screen. This is very handy if you have special menus, huds, or maps that pop up on top of a game screen and depend heavily on the game screen's information.
The fact that the screens are "agnostic", just firing events into space, means that it's also easy to rearrange them. I frequently have very different menu layouts between development, demo, debug, and the rare "release" menu layout.
If your game has complex menuing, such as an RPG, you'll probably need draggable, dockable menus. Some engines have a dockable window system built in, but if you need to make one on your own, it's not actually very hard: there are dozens of tutorials for any language. Just be aware you may need to do it.
If you're using an XBox controller, the player may not really be able to drag your dockable windows. Use them anyway. You can manually place them using your code, and it'll be a lot easier than hard-coding complex, monolithic menus.
Actually rendering the menu text shouldn't be terribly difficult for you, but it is generally better if your menu screen class has an array of options that you can arbitrarily add to, instead of painstakingly scripted line-by-line menu placement. The menu screen should understand how to navigate through them, highlight the one you're on, and throw an event if you select one. You may want to make your line-by-line menu items small classes that render themselves, so that it's easy to do radio buttons, sliders, etc. Often, your development environment will include such items already: no reason to make your own!
This is all very basic, but it's hard to know how basic is basic enough, so there it is. Post additional advice or feedback to the comments.
Monday, April 26, 2010
More on Omnipresent Anonymity
You may remember I wrote this essay on a scifi setting. Since then I haven't been able to get it out of my head, so I'm going to write more on it in a less sci-fi sense.
We publish loads and loads of information to the internet. Common practice is to shake your finger at anyone who posts personal information to the internet.
But it's just impossible to not post personal information to the internet and still participate. There is a fragile layer of anonymity between your anonymous accounts and you. This gets even more fragile if your anonymous accounts are used to communicate with real-life friends, such as a facebook user who calls himself a random string of characters. You don't even have to know the communications: you just have to know that they happen.
Most geeks promote privacy awareness. Go into the options, set everything to private. Hide hide hide!
There are three problems with this. 1) It only takes a few "open" nodes to de-anonymize ("dean") an entire network, and given the lack of incentive, people are likely to remain open. 2) Going "quiet" and hiding away your info cripples the functionality of a social network. 3) It's becoming ever easier to mine even tiny leaks of data. Whether a friend accidentally mentions your name, or someone backtracks your IP address, your anonymity is not guaranteed no matter how "hidden" you try to be.
As our social use of the internet grows ever denser, it will become almost impossible to live your life without posting photos and video of yourself to the internet in the same way that we use email today. It's theoretically possible that some of that might be private, but if even a fraction of it is public, a huge portion of those connected can be deaned (de-anonymized). It's going to get worse and worse as our real social networks become increasingly reflected in our software social networks.
In my opinion, privacy advocates are really grasping at the last fragments of How Things Were. Right now, it's basically possible to keep hiding. I don't know for sure that all of my friends have various anonymous accounts, but they almost certainly do. I know I do. Right now, that's fine: there are very few programs automatically trawling the internet trying to make these connections. There aren't very many things actively trying to dean the internet.
But it's getting easier and easier, both in terms of available data to analyze and in terms of algorithms to do the analysis. It's important that privacy advocates realize that the idea of promoting anonymity from the user side is going to be basically impossible.
So, the problem needs to be turned on its head. The problem isn't "how do you keep users from posting private data", the problem is "how do you keep private data from being abused".
An analogy I liked is the one about public meatspaces. If you and a friend are chatting in public, you might talk about his medical condition. If a stranger then rushed up to try to sell him homeopathic lies targeted at his medical condition, nobody would ever think your friend was the one who was weird: it would be the spy that was weird. If he did it a lot, the police would take him in for being a public nuisance.
So if I'm talking to you on the internet and we mention your medical condition, Google offers us homeopathic lies instantly and automatically, and probably logs that targeted ad for reuse later. Your medical insurer two years from now, if they find that conversation somehow, might deny you coverage based on the fact that you had a "pre-existing condition". There are already rumors of insurers canceling treatment based on social media - such as the depressed person whose treatment was discontinued because she was seen smiling in a picture on one of her friend's social network pages.
Even if it was possible, it's inhuman and dangerous to make us responsible for staying absolutely silent, absolutely hidden. Humans are social beings, the internet is a social medium. Being abused by corporations and repressed by governments is nothing new. We don't generally say, "well, you shouldn't have said that you disagreed with the government!" We generally say, "hey, the government shouldn't be persecuting you just because you said something!"
This is the same situation. Obviously, being force-fed stupifyingly bad ads is not the same thing as being rounded up and blacklisted in McCarthy's Big Red Book, but both stem from the same problem of people outside a conversation listening in and taking action based on what they hear. Conversations that were never intended to include them and certainly were never intended to be definitive, permanent, public statements.
So, there are two basic responses to this.
One is to revamp the underlying architecture to make everything incredibly privacy-aware by default. I think this is a good idea, but I also think it's pretty much impossible, since a social network is inclusive by nature. As social networking becomes the primary use of the internet, it seems unlikely that we're going to create a new network that specifically damages that function. Still, we could do better than we're doing right now.
The other option is to do what we always do: legislate it.
It can be legislated from two sides. One side, probably the easier side, is to restrict contact between entities and use of data gathered on-line. You are allowed to gather data. You can dean the network, find that XRSOXGAL8727 is Jenny Smith. But you aren't allowed to use that information for anything. No targeted ads. No redirecting links. Only when a user explicitly allows this sort of thing is it allowed. Steep fines if you break that rule.
There are a few problems with this. One is that spam is basically impossible to track down. Every day I get spammed with fairly well-targeted spam: my interests are pretty transparent, so spammers target me pretty specifically. A lot of this spam comes from anonymous sources, people I could never track down, people the government would have to spend a fair amount of time tracking down. Still, that's okay, because I'm not trying to stop anonymous spammers. I'm trying to stop Google.
Another problem is that it might be difficult to draw the line between someone who is actually trying to socially contact you and a spammer. For example, if you post about squids and I send you a link to an interesting squid article, I'm not trying to spam you, I honestly think you'll find it interesting. I think that line can be drawn fairly easily - number of entreaties per day per organization or somesuch - but it is an issue that has to be kept in mind.
Also, there is the problem of UNTARGETED spam. When I visit a science site, there are sciency ads. This is not because they know who I am, it's because it's a science site. However, I can forsee a lot of cases going to court that stumble over this distinction. Personally, I would prefer to make it illegal for them to spam me without my permission, targeted or not. But I understand that's an extreme view.
Anyhow, we also have another kind of legislative option: to make it illegal to dean data. To make it illegal to trawl the internet gathering data, tying it together, figuring out who is where, doing what. To make it illegal to watch you as you travel.
Now, this second option is the one I chose for my sci-fi setting, so I sat down to think. In my sci-fi setting, you can tell someone has deaned data because data has a structure, and high-context (non-anonymous) data has a very specific structure, even if it has been reduced to nothing but lists of foreign keys. Because the backbone has largely been replaced by a mesh network of freely available personal wireless routers, a lot of private individuals scan passing traffic for this pattern and report it to the cops if found. This can net them a tidy profit.
If a corporation is suspected of using illegally deaned data, they can also be investigated using a similar pattern-finding tool. This leaves their data private: the feds never see the actual data. This has led to a (so-far fruitless) search for a way to store high-context data without the signature pattern.
That future is a bit dystopian under the covers, and I don't think that method would work in reality. But then I got to thinking:
The problem is caused because there is so much easily-searchable information. However, searching the information causes more easily-searched information.
While the corporations are busily deaning your data, using your private messages to sell you useless crap, you could be busily deaning their data.
This isn't very possible on the current brand of internet. But what if the "next, more privacy-conscious" iteration of things actually tracks patterns of requests instead of simply tracking user connectivity? What if, by fundamental design, it was The Completely Transparent Thing? Instead of privacy, it has anti-privacy. Well, within any given persona: you could still have your anonymous account.
Now, if your anonymous account and your real account are both pinged, you'll know. You can track down the ping-er. Which may also be an anonymous account. It will be immediately obvious if it was chance, or if it was an auto-deaner, or if it was your would-be boss trying to find out if you have a juicy personal life. By attempting to dean you, they effectively dean themselves.
This is not really a good solution, because that level of monitoring reveals way more than you want to have revealed. The time you visited a link blind and found yourself staring at something horrible. The fact that you checked so-and-so's page 80 times in one hour. And, of course, the muddy propagation problems where the SocialReader9 bot visits your page, reads the details, and then gives it to others without you knowing.
I don't think there is a solution, really. Not with current technologies. But I was tickled by the "balance of power" option, where someone attempting to gather information on you incidentally exposes more information about themselves.
I wonder if it could be made to work somehow...
Anyhow, it's a problem that can't be addressed by simply telling people not to put their personal information on-line.
We publish loads and loads of information to the internet. Common practice is to shake your finger at anyone who posts personal information to the internet.
But it's just impossible to not post personal information to the internet and still participate. There is a fragile layer of anonymity between your anonymous accounts and you. This gets even more fragile if your anonymous accounts are used to communicate with real-life friends, such as a facebook user who calls himself a random string of characters. You don't even have to know the communications: you just have to know that they happen.
Most geeks promote privacy awareness. Go into the options, set everything to private. Hide hide hide!
There are three problems with this. 1) It only takes a few "open" nodes to de-anonymize ("dean") an entire network, and given the lack of incentive, people are likely to remain open. 2) Going "quiet" and hiding away your info cripples the functionality of a social network. 3) It's becoming ever easier to mine even tiny leaks of data. Whether a friend accidentally mentions your name, or someone backtracks your IP address, your anonymity is not guaranteed no matter how "hidden" you try to be.
As our social use of the internet grows ever denser, it will become almost impossible to live your life without posting photos and video of yourself to the internet in the same way that we use email today. It's theoretically possible that some of that might be private, but if even a fraction of it is public, a huge portion of those connected can be deaned (de-anonymized). It's going to get worse and worse as our real social networks become increasingly reflected in our software social networks.
In my opinion, privacy advocates are really grasping at the last fragments of How Things Were. Right now, it's basically possible to keep hiding. I don't know for sure that all of my friends have various anonymous accounts, but they almost certainly do. I know I do. Right now, that's fine: there are very few programs automatically trawling the internet trying to make these connections. There aren't very many things actively trying to dean the internet.
But it's getting easier and easier, both in terms of available data to analyze and in terms of algorithms to do the analysis. It's important that privacy advocates realize that the idea of promoting anonymity from the user side is going to be basically impossible.
So, the problem needs to be turned on its head. The problem isn't "how do you keep users from posting private data", the problem is "how do you keep private data from being abused".
An analogy I liked is the one about public meatspaces. If you and a friend are chatting in public, you might talk about his medical condition. If a stranger then rushed up to try to sell him homeopathic lies targeted at his medical condition, nobody would ever think your friend was the one who was weird: it would be the spy that was weird. If he did it a lot, the police would take him in for being a public nuisance.
So if I'm talking to you on the internet and we mention your medical condition, Google offers us homeopathic lies instantly and automatically, and probably logs that targeted ad for reuse later. Your medical insurer two years from now, if they find that conversation somehow, might deny you coverage based on the fact that you had a "pre-existing condition". There are already rumors of insurers canceling treatment based on social media - such as the depressed person whose treatment was discontinued because she was seen smiling in a picture on one of her friend's social network pages.
Even if it was possible, it's inhuman and dangerous to make us responsible for staying absolutely silent, absolutely hidden. Humans are social beings, the internet is a social medium. Being abused by corporations and repressed by governments is nothing new. We don't generally say, "well, you shouldn't have said that you disagreed with the government!" We generally say, "hey, the government shouldn't be persecuting you just because you said something!"
This is the same situation. Obviously, being force-fed stupifyingly bad ads is not the same thing as being rounded up and blacklisted in McCarthy's Big Red Book, but both stem from the same problem of people outside a conversation listening in and taking action based on what they hear. Conversations that were never intended to include them and certainly were never intended to be definitive, permanent, public statements.
So, there are two basic responses to this.
One is to revamp the underlying architecture to make everything incredibly privacy-aware by default. I think this is a good idea, but I also think it's pretty much impossible, since a social network is inclusive by nature. As social networking becomes the primary use of the internet, it seems unlikely that we're going to create a new network that specifically damages that function. Still, we could do better than we're doing right now.
The other option is to do what we always do: legislate it.
It can be legislated from two sides. One side, probably the easier side, is to restrict contact between entities and use of data gathered on-line. You are allowed to gather data. You can dean the network, find that XRSOXGAL8727 is Jenny Smith. But you aren't allowed to use that information for anything. No targeted ads. No redirecting links. Only when a user explicitly allows this sort of thing is it allowed. Steep fines if you break that rule.
There are a few problems with this. One is that spam is basically impossible to track down. Every day I get spammed with fairly well-targeted spam: my interests are pretty transparent, so spammers target me pretty specifically. A lot of this spam comes from anonymous sources, people I could never track down, people the government would have to spend a fair amount of time tracking down. Still, that's okay, because I'm not trying to stop anonymous spammers. I'm trying to stop Google.
Another problem is that it might be difficult to draw the line between someone who is actually trying to socially contact you and a spammer. For example, if you post about squids and I send you a link to an interesting squid article, I'm not trying to spam you, I honestly think you'll find it interesting. I think that line can be drawn fairly easily - number of entreaties per day per organization or somesuch - but it is an issue that has to be kept in mind.
Also, there is the problem of UNTARGETED spam. When I visit a science site, there are sciency ads. This is not because they know who I am, it's because it's a science site. However, I can forsee a lot of cases going to court that stumble over this distinction. Personally, I would prefer to make it illegal for them to spam me without my permission, targeted or not. But I understand that's an extreme view.
Anyhow, we also have another kind of legislative option: to make it illegal to dean data. To make it illegal to trawl the internet gathering data, tying it together, figuring out who is where, doing what. To make it illegal to watch you as you travel.
Now, this second option is the one I chose for my sci-fi setting, so I sat down to think. In my sci-fi setting, you can tell someone has deaned data because data has a structure, and high-context (non-anonymous) data has a very specific structure, even if it has been reduced to nothing but lists of foreign keys. Because the backbone has largely been replaced by a mesh network of freely available personal wireless routers, a lot of private individuals scan passing traffic for this pattern and report it to the cops if found. This can net them a tidy profit.
If a corporation is suspected of using illegally deaned data, they can also be investigated using a similar pattern-finding tool. This leaves their data private: the feds never see the actual data. This has led to a (so-far fruitless) search for a way to store high-context data without the signature pattern.
That future is a bit dystopian under the covers, and I don't think that method would work in reality. But then I got to thinking:
The problem is caused because there is so much easily-searchable information. However, searching the information causes more easily-searched information.
While the corporations are busily deaning your data, using your private messages to sell you useless crap, you could be busily deaning their data.
This isn't very possible on the current brand of internet. But what if the "next, more privacy-conscious" iteration of things actually tracks patterns of requests instead of simply tracking user connectivity? What if, by fundamental design, it was The Completely Transparent Thing? Instead of privacy, it has anti-privacy. Well, within any given persona: you could still have your anonymous account.
Now, if your anonymous account and your real account are both pinged, you'll know. You can track down the ping-er. Which may also be an anonymous account. It will be immediately obvious if it was chance, or if it was an auto-deaner, or if it was your would-be boss trying to find out if you have a juicy personal life. By attempting to dean you, they effectively dean themselves.
This is not really a good solution, because that level of monitoring reveals way more than you want to have revealed. The time you visited a link blind and found yourself staring at something horrible. The fact that you checked so-and-so's page 80 times in one hour. And, of course, the muddy propagation problems where the SocialReader9 bot visits your page, reads the details, and then gives it to others without you knowing.
I don't think there is a solution, really. Not with current technologies. But I was tickled by the "balance of power" option, where someone attempting to gather information on you incidentally exposes more information about themselves.
I wonder if it could be made to work somehow...
Anyhow, it's a problem that can't be addressed by simply telling people not to put their personal information on-line.
Wednesday, April 21, 2010
Gambling and Colored Spinny Things
Well, I wrote a big long post on enemy design, and the only thing anyone noticed was that I lumped skill-based challenges and luck-based challenges into a single challenge type. Caught some flak for that, so I figured I'd explain in more detail why I did that.
Not too long ago, I had them separated - luck and skill, that is. It's patently obvious that they are completely distinct, after all. One is luck, one is skill. You can get better at skill, but you can't get better at luck. So on so on so on.
The problem is that what is patently obvious isn't patently correct, and over time I shifted towards the opinion I hold now, which is that skill and luck are largely interchangeable from a game design standpoint. I don't expect to convince anyone, because it's a patently absurd statement. But I'll give it a shot.
First, to be a little more precise, I don't mean skill in general. I mean physical skill. Precision, reaction speed, spatial awareness. Skills such as tactical analysis, pattern recognition, and math are not really the same category. Those are "information challenges", or whatever term you prefer.
With that in mind, when I design, in my head things move. And they move in specific ways. So if I design a game, I see the fundamental mechanics and imagery boiling or spinning or changing colors as they bounce into each other and lock together. So the framework of a game has a distinct set of characteristics. By paying attention, I can usually produce what seems like more fun play, deeper immersion. Of course, being that I'm just toying around and prototyping, it could also just be wishful thinking.
Either way, the pieces "plunk" together in particular ways. The dynamics of a game, how it moves and spins and changes, is defined by how these pieces fit together. So I think in terms of what each piece of the design adds to the whole.
What I've come to realize is that a mechanic based on luck and a mechanic based on skill both serve the same purpose in this final framework. They both act as a "scattering" agent: they push the player in somewhat unexpected vectors, allowing them to explore the gameplay "terrain" with a quick and interesting feedback loop.
This sets them apart from information challenges, which are a far slower and more deliberate piece that usually forms the "backbone" of the game. The heuristics and thought you use in information dynamics can be very deep and interesting, but they move differently and don't contribute in the same way. The player will tend to "pool" in the valleys of an information challenge, but the velocity he gets from a gamble will often take him up and over various ridges, to new vistas.
They are certainly different from puzzle challenges, which are like little gems in the framework that unfold when you touch them.
The point is that, from a design standpoint, luck and skill serve the same driving role in a game's overall structure. They cause the player to interact with the game's framework in a very similar way. Just because one spins a bit differently from the other is no reason to call them different kinds of things: a penguin is still a bird, even though it can't fly.
They do serve slightly different purposes. Skill challenges can be stacked like a long chain of revolving gears, but doing that with strong luck mechanics will end up grinding itself to pieces. So, in order to use luck mechanics, you need to make sure there's padding between them and the next set of luck interactions, or you lose all agency. That's not as necessary with physical skill, which has a more orderly and agency-filled outgoing vector cloud.
But there's that much deviation within the other kinds of mechanics as well. Mental skill challenges include a variety of types that are just as distinct: memory challenges versus analysis challenges versus spatial challenges versus heuristic challenges... they also have somewhat distinct effects on the game. However, they are all fundamentally the same kind of thing.
That's where I'm coming from: the structure of the game, NOT the player's conscious experience.
Not too long ago, I had them separated - luck and skill, that is. It's patently obvious that they are completely distinct, after all. One is luck, one is skill. You can get better at skill, but you can't get better at luck. So on so on so on.
The problem is that what is patently obvious isn't patently correct, and over time I shifted towards the opinion I hold now, which is that skill and luck are largely interchangeable from a game design standpoint. I don't expect to convince anyone, because it's a patently absurd statement. But I'll give it a shot.
First, to be a little more precise, I don't mean skill in general. I mean physical skill. Precision, reaction speed, spatial awareness. Skills such as tactical analysis, pattern recognition, and math are not really the same category. Those are "information challenges", or whatever term you prefer.
With that in mind, when I design, in my head things move. And they move in specific ways. So if I design a game, I see the fundamental mechanics and imagery boiling or spinning or changing colors as they bounce into each other and lock together. So the framework of a game has a distinct set of characteristics. By paying attention, I can usually produce what seems like more fun play, deeper immersion. Of course, being that I'm just toying around and prototyping, it could also just be wishful thinking.
Either way, the pieces "plunk" together in particular ways. The dynamics of a game, how it moves and spins and changes, is defined by how these pieces fit together. So I think in terms of what each piece of the design adds to the whole.
What I've come to realize is that a mechanic based on luck and a mechanic based on skill both serve the same purpose in this final framework. They both act as a "scattering" agent: they push the player in somewhat unexpected vectors, allowing them to explore the gameplay "terrain" with a quick and interesting feedback loop.
This sets them apart from information challenges, which are a far slower and more deliberate piece that usually forms the "backbone" of the game. The heuristics and thought you use in information dynamics can be very deep and interesting, but they move differently and don't contribute in the same way. The player will tend to "pool" in the valleys of an information challenge, but the velocity he gets from a gamble will often take him up and over various ridges, to new vistas.
They are certainly different from puzzle challenges, which are like little gems in the framework that unfold when you touch them.
The point is that, from a design standpoint, luck and skill serve the same driving role in a game's overall structure. They cause the player to interact with the game's framework in a very similar way. Just because one spins a bit differently from the other is no reason to call them different kinds of things: a penguin is still a bird, even though it can't fly.
They do serve slightly different purposes. Skill challenges can be stacked like a long chain of revolving gears, but doing that with strong luck mechanics will end up grinding itself to pieces. So, in order to use luck mechanics, you need to make sure there's padding between them and the next set of luck interactions, or you lose all agency. That's not as necessary with physical skill, which has a more orderly and agency-filled outgoing vector cloud.
But there's that much deviation within the other kinds of mechanics as well. Mental skill challenges include a variety of types that are just as distinct: memory challenges versus analysis challenges versus spatial challenges versus heuristic challenges... they also have somewhat distinct effects on the game. However, they are all fundamentally the same kind of thing.
That's where I'm coming from: the structure of the game, NOT the player's conscious experience.
Tuesday, April 20, 2010
Interesting Enemies 101
The last couple of posts have made me realized that some of the knowledge I take for granted as "basic" really isn't. So this post is about the basics: what makes a game challenging, what makes enemies fun.
When I design a game - typically a tabletop RPG or board game, but sometimes computer games - there are four kinds of challenges I generally consider.
The first kind of challenge is the puzzle. This is when the scenario set up by the developer has a specific path to resolution. For example, a crate-pushing room. A fetch quest is technically a puzzle, but it's a crappy one.
The second kind of challenge is the information challenge. An info challenge is different from a puzzle because there is no "boolean" solution: there are many paths you can take and the results will vary in different ways. There is typically very little randomness in this kind of challenge, aside from that required to define the scenario. A good example is Civilization city-building: where you put your cities and what you build in/around them is not affected by randomness, but it's not a single-solution puzzle, either.
The third kind of challenge is the gamble. Gambles are typically simpler than information challenges and make up for it by having either randomness or real-time skill be a major component. This is the kind of challenge most enemies present: in an FPS, the accuracy and speed of the play is challenged, while in an RPG weighted dice rolls are substituted for real-time player skill. Same kind of challenge, either way.
The last kind of challenge is a fulfillment challenge, where you allow the player to alter a scenario in ways not usually tied directly to game mechanics. For example, allowing someone to dress in whatever way they want, or to add knickknacks to their house.
Of these four, the gamble is obviously where your enemies fit in easiest. The "standard five" model (eggshell, skirmisher, heavy, sniper, spawner) are built to challenge the general kinds of real-time skill a player can have.
However, it's important not to get too caught up in such a simplistic view. The gamble challenge isn't entirely served by enemies. For example, in Guitar Hero, the gamble challenge is the stream of notes. You don't need enemies, because the stream of notes serves the exact same purpose.
In other situations, the reverse happens, and enemies can (and should) bleed over into other challenge types. For example, a turtle in Super Mario Bros leaves behind a shell when you kill it. The shell is a tool used to turn gamble challenges (hopping on the goombas requires a fair amount of agility) to an information challenge (hitting the lot of them with a turtle shell normally doesn't require such agility).
I think most of the memorable games actually have that kind of very muddy situation, where it's hard to say that something is A or B. The information and gambling challenges often cross over each other. For example, in Tetris, dropping the blocks is obviously real-time skill, but it requires advanced pattern recognition as well, which is an information challenge component. It straddles the two.
Similarly, the strength of a tabletop RPG is that a puzzle challenge often converts over to an information challenge or gamble as the players go outside the expected conditions. The flexibility offered by an actual GM is one of the reasons that tabletop RPGs are still so popular despite their poor mechanical design and irritating interface.
To go a little philosophical, when I'm designing a new game, I lock down some images in my head to use as a kind of vision to drive my design. I say "images" because English is not a very good language: they're not simply images, but processes, potentials, and emotions as well.
Once I have a clear idea of the kind of thing I want to make, I try to come up with a core set of mechanics that will support all four kinds of challenges, or at least the latter three (not puzzles). As I'm doing this, I try to come up with specific situations where I can see the mechanics crossing: interesting play always happens where the mechanics collide. That's the "mixing" of challenge types I'm talking about, although you can also have collisions between different mechanics for the same kind of challenge.
All of this has been a pretty roundabout way of reaching this final point, which is how to make interesting enemies.
The way to make interesting enemies, as you may have guessed by reading about that mixing and colliding, is to make enemies that collide with other game mechanics. This is usually not done in AAA titles because it can make large games hopelessly complex and impossible to balance. But for indie games and mods, it's a must if you want to have interesting play.
As an example, let's look at a side-scrolling action game such as the Contra series. At its core, the navigation on the screen is an information challenge, while the interaction with enemies is a gamble.
If you're designing enemies for this kind of game, you'll probably start by simply considering the Fundamental Five. You create enemies that are eggshells, skirmishers, snipers, heavies, and spawners. But that's pretty dull. The best enemies collide the multiple kinds of challenges, the multiple kinds of mechanics. They create "boundary challenges", where the challenge is unusual because it interacts with multiple kinds of mechanics.
To some extent, this is placement. By putting enemies at specific points in a level, you can make them interact with the level layout, turning navigation from an information challenge into a gamble. For example, a section where an enemy is firing across an upper platform, and the player is required to jump up between the bullets to get up there and hit him. Another common variant is the "roller" which rolls along the top of the platform, then along the bottom and back up to the top in an endless circle.
On the opposite side of things are enemies that are platform navigation, such as a boss that has platforms on him, or a boss that requires you to jump to specific areas to dodge or hit him. It's normally only bosses that are built like this because it takes so long to actually play out the battle.
There's no reason to stick with the oldschool. For example, we can create enemies that can be stood on as if they were platforms, so luring them to a specific point so you can jump off them is important (or using them to cross spikes). Other enemies might only pop up and attack if you're standing on specific areas in the level - wall turrets, for example.
Still more options: enemies that destroy or create terrain, enemies that change the gravity in a region, enemies that deflect shots in unusual ways such that they might be able to hit a sniper if used correctly (or yourself, if used incorrectly).
Also, you can implement new mechanics to give you another thing to butt up against. As an example, if our game features a lot of swinging (Bionic Commando, Batman, Spider-Man) we can introduce enemies that butt into that: enemies that leave grease spots you can't attach to, enemies that cut your cable, enemies that swing, enemies you can swing from, etc, etc. And, of course, don't forget the normal level navigation, which can butt up against the swinging system as well.
There's no problem thinking of these kinds of fun enemies. I can think of them all day. The two problems related to these enemies are both easily manageable, if you keep them in mind.
The first problem is programming. Unless you think ahead, you can find yourself having to write very complex special-case code for every enemy in your game. Make sure to think ahead.
The second problem is complexity. It's easy to swamp a player with too many different kinds of boundary challenges, too quickly. Generally, I try to keep my players at one boundary condition per level. I go up to two if I feel that the boundary condition is suitably transparent. For example, I might use both the enemies-that-swing and the enemies-you-can-swing-from in the same level, because both of those are pretty straightforward. But combining enemies-that-are-platforms with enemies-that-generate-and-destroy-platforms would be sadistic, and only suitable for The Hard Boss.
This is basically an unwavering rule. If you revisit a particular boundary challenge in a later level, you want to make sure to get rid of one of the boundary challenges you were using. The human brain can only comprehend so much simultaneously. Later, if your boundary conditions become a genre, you can start to assume the player is completely familiar with them... but until then, make sure not to swamp the player with too many boundary conditions at the same time, even if they theoretically "learned" them earlier in the game.
To me, these are the basics of enemy design.
Enemies aren't the only thing in the game, however, and remember that those other mechanics aren't just fluff. They allow the player to do something, and that's critical. Level design, how the player moves, what the avatar's actions are, power progressions, etc, etc. All of that has to be considered as well.
But just covering enemy design is plenty for one essay.
When I design a game - typically a tabletop RPG or board game, but sometimes computer games - there are four kinds of challenges I generally consider.
The first kind of challenge is the puzzle. This is when the scenario set up by the developer has a specific path to resolution. For example, a crate-pushing room. A fetch quest is technically a puzzle, but it's a crappy one.
The second kind of challenge is the information challenge. An info challenge is different from a puzzle because there is no "boolean" solution: there are many paths you can take and the results will vary in different ways. There is typically very little randomness in this kind of challenge, aside from that required to define the scenario. A good example is Civilization city-building: where you put your cities and what you build in/around them is not affected by randomness, but it's not a single-solution puzzle, either.
The third kind of challenge is the gamble. Gambles are typically simpler than information challenges and make up for it by having either randomness or real-time skill be a major component. This is the kind of challenge most enemies present: in an FPS, the accuracy and speed of the play is challenged, while in an RPG weighted dice rolls are substituted for real-time player skill. Same kind of challenge, either way.
The last kind of challenge is a fulfillment challenge, where you allow the player to alter a scenario in ways not usually tied directly to game mechanics. For example, allowing someone to dress in whatever way they want, or to add knickknacks to their house.
Of these four, the gamble is obviously where your enemies fit in easiest. The "standard five" model (eggshell, skirmisher, heavy, sniper, spawner) are built to challenge the general kinds of real-time skill a player can have.
However, it's important not to get too caught up in such a simplistic view. The gamble challenge isn't entirely served by enemies. For example, in Guitar Hero, the gamble challenge is the stream of notes. You don't need enemies, because the stream of notes serves the exact same purpose.
In other situations, the reverse happens, and enemies can (and should) bleed over into other challenge types. For example, a turtle in Super Mario Bros leaves behind a shell when you kill it. The shell is a tool used to turn gamble challenges (hopping on the goombas requires a fair amount of agility) to an information challenge (hitting the lot of them with a turtle shell normally doesn't require such agility).
I think most of the memorable games actually have that kind of very muddy situation, where it's hard to say that something is A or B. The information and gambling challenges often cross over each other. For example, in Tetris, dropping the blocks is obviously real-time skill, but it requires advanced pattern recognition as well, which is an information challenge component. It straddles the two.
Similarly, the strength of a tabletop RPG is that a puzzle challenge often converts over to an information challenge or gamble as the players go outside the expected conditions. The flexibility offered by an actual GM is one of the reasons that tabletop RPGs are still so popular despite their poor mechanical design and irritating interface.
To go a little philosophical, when I'm designing a new game, I lock down some images in my head to use as a kind of vision to drive my design. I say "images" because English is not a very good language: they're not simply images, but processes, potentials, and emotions as well.
Once I have a clear idea of the kind of thing I want to make, I try to come up with a core set of mechanics that will support all four kinds of challenges, or at least the latter three (not puzzles). As I'm doing this, I try to come up with specific situations where I can see the mechanics crossing: interesting play always happens where the mechanics collide. That's the "mixing" of challenge types I'm talking about, although you can also have collisions between different mechanics for the same kind of challenge.
All of this has been a pretty roundabout way of reaching this final point, which is how to make interesting enemies.
The way to make interesting enemies, as you may have guessed by reading about that mixing and colliding, is to make enemies that collide with other game mechanics. This is usually not done in AAA titles because it can make large games hopelessly complex and impossible to balance. But for indie games and mods, it's a must if you want to have interesting play.
As an example, let's look at a side-scrolling action game such as the Contra series. At its core, the navigation on the screen is an information challenge, while the interaction with enemies is a gamble.
If you're designing enemies for this kind of game, you'll probably start by simply considering the Fundamental Five. You create enemies that are eggshells, skirmishers, snipers, heavies, and spawners. But that's pretty dull. The best enemies collide the multiple kinds of challenges, the multiple kinds of mechanics. They create "boundary challenges", where the challenge is unusual because it interacts with multiple kinds of mechanics.
To some extent, this is placement. By putting enemies at specific points in a level, you can make them interact with the level layout, turning navigation from an information challenge into a gamble. For example, a section where an enemy is firing across an upper platform, and the player is required to jump up between the bullets to get up there and hit him. Another common variant is the "roller" which rolls along the top of the platform, then along the bottom and back up to the top in an endless circle.
On the opposite side of things are enemies that are platform navigation, such as a boss that has platforms on him, or a boss that requires you to jump to specific areas to dodge or hit him. It's normally only bosses that are built like this because it takes so long to actually play out the battle.
There's no reason to stick with the oldschool. For example, we can create enemies that can be stood on as if they were platforms, so luring them to a specific point so you can jump off them is important (or using them to cross spikes). Other enemies might only pop up and attack if you're standing on specific areas in the level - wall turrets, for example.
Still more options: enemies that destroy or create terrain, enemies that change the gravity in a region, enemies that deflect shots in unusual ways such that they might be able to hit a sniper if used correctly (or yourself, if used incorrectly).
Also, you can implement new mechanics to give you another thing to butt up against. As an example, if our game features a lot of swinging (Bionic Commando, Batman, Spider-Man) we can introduce enemies that butt into that: enemies that leave grease spots you can't attach to, enemies that cut your cable, enemies that swing, enemies you can swing from, etc, etc. And, of course, don't forget the normal level navigation, which can butt up against the swinging system as well.
There's no problem thinking of these kinds of fun enemies. I can think of them all day. The two problems related to these enemies are both easily manageable, if you keep them in mind.
The first problem is programming. Unless you think ahead, you can find yourself having to write very complex special-case code for every enemy in your game. Make sure to think ahead.
The second problem is complexity. It's easy to swamp a player with too many different kinds of boundary challenges, too quickly. Generally, I try to keep my players at one boundary condition per level. I go up to two if I feel that the boundary condition is suitably transparent. For example, I might use both the enemies-that-swing and the enemies-you-can-swing-from in the same level, because both of those are pretty straightforward. But combining enemies-that-are-platforms with enemies-that-generate-and-destroy-platforms would be sadistic, and only suitable for The Hard Boss.
This is basically an unwavering rule. If you revisit a particular boundary challenge in a later level, you want to make sure to get rid of one of the boundary challenges you were using. The human brain can only comprehend so much simultaneously. Later, if your boundary conditions become a genre, you can start to assume the player is completely familiar with them... but until then, make sure not to swamp the player with too many boundary conditions at the same time, even if they theoretically "learned" them earlier in the game.
To me, these are the basics of enemy design.
Enemies aren't the only thing in the game, however, and remember that those other mechanics aren't just fluff. They allow the player to do something, and that's critical. Level design, how the player moves, what the avatar's actions are, power progressions, etc, etc. All of that has to be considered as well.
But just covering enemy design is plenty for one essay.
Wednesday, April 14, 2010
Base Building
Muh brain's on fire! Time to talk about base building.
There is a very underappreciated set of games I like to call the base-building games. These are things like Sim City, Dwarf Fortress, Evil Genius, and the Sims. That last one isn't underappreciated, I know.
These are games where the main point is to build a functioning base of some kind.
They are often lumped together with RTS games and tower-defense games, but both of those are about managing attacks and defenses instead of building a base. They are distinct from the sorts of games I'm talking about, where the whole point is to build a functioning base, not to build functioning defenses or armies (which might be incidentally possible, but aren't the point).
Base building games fall on a spectrum. To the left we have the construction games, which focus more on deep dynamics that allow you to focus on construction for a long, long time. SimCity is the ur-example. There is nothing besides base construction in SimCity: the most non-base-construction thing in the game is setting your budget, which consists of about five variables.
To the right we have base management games, which have shallower dynamics and instead rely on micromanagement to take up the slack. The thing about these is that the micromanagement has almost nothing to do with the base construction. The Sims is the best example on this end. While there is base building (you make a house), the game is actually about painstakingly clicking your little inhabitants through every moment of their day.
Somewhat to the right on this scale is Evil Genius, which features a fairly complex base dynamic but heavily focuses on defending against agents and micromanaging your assets abroad. The trap construction... I don't know whether to consider that base building or not.
Somewhat to the left on this scale is Dwarf Fortress, which has very, VERY good base construction dynamics. But the player spends much of his time designating trees to be chopped down, ores to be mined, shoes to be built... despite the fact that you could rely wholly on base building to result in an interesting game, there is an aspect of micro-management.
All of these micro-managing aspects in all of the games listed have very little to do with the actual construction of your base. Building shoes and cutting trees doesn't matter how your base is laid out. Assigning fifty troops to the Bahamas doesn't change base on base layout. Getting your sims through their morning ablution doesn't care about your base layout.
There is some interaction, sure. If your house is palatial in the sims, it will take your sims an extra thirty minutes to get from the bathroom to the bedroom (because it takes them freaking five minutes to go one tile). Your layout in Evil Genius matters because many of your enemies will try to come in through the front door, but many more will magically pop up in the middle of your base and defending the front door is only slightly variable based on your layout. Etc, etc.
These days, most games tend to be more and more micromanagy. The days when a complex base WAS the game seem to be over in favor of splitting into Tower Defense and Base Micromanagement genres.
However, I think this is not irreversible. Base construction is a deep kind of play, and there's no reason not to use it. The key problem is that most people who make base construction games tend to make boring ones. As an example: there are fully half a dozen space station/space base construction games from the last decade, and the better ones are the earlier ones. As time has progressed, they have gotten shallower and shallower, more and more boring. The designers have forgotten how to make base construction interesting because they've been dazzled by RTS and base micromanagement games.
That would be fine if that was the sort of game they were building, but you can't just take those games and say, "now let's get rid of this irritating micromanagement/base defense part". That irritating part is the main gameplay!
So let's talk briefly about the kind of gameplay that usually makes for good base construction games.
First and foremost, base construction games take place in space. Most base construction games (such as SimCity) take place in two dimensions. A few take place in three dimensions. This dimensionality is the core from which all complexity grows.
Tower defense games know this, and are an excellent example. With a tower defense game, your enemies will follow paths in space, and you set up your turrets in optimal spaces to fire on them. This spatial interaction is the core of base construction, distilled to purity. But instead of interacting with incoming enemies, base construction interacts with base construction.
Where you put thing A and road B matters, because they exist in space and exert a certain influence.
Oversimplifying this to a radius effect is problematic: you either end up with tower defense or Simcity Societies. Instead, you want to quantify vectors and paths for the effects. In most base construction games, the primary path is the road. All your resources and people have to travel along the road (or the hall or whatever), so you build your base to (A) have short roads and (B) have its road needs distributed such that the roads aren't overwhelmed.
(You don't have to use only roads, by the way, but that's the most common setup.)
The other aspect to most base building games is an element of infrastructure. In SimCity this is extremely apparent: you have to hook up wires and run plumbing in addition to the roads. These conduits are distinct from roads because there is no real concern about how much is traveling through them or the range the resources travel. You can put your power station on a far hill and run ten miles of wire, you'll get power just the same as if you had your station next door.
The key to infrastructure complexity isn't in shortening them or balancing their loads, it's in establishing them at all. Can you cross one kind of infrastructure over another? What situations happen when they break down at a random point? That sort of thing.
This is distinct from the "virtual infrastructure" many RTS games use, where you just need to generate enough resource and it is magically allocated to wherever it is needed.
Infrastructure and paths are both core elements of play, and it varies as to what kind of thing falls into which category.
But that's not the limit. There are a few other things that affect play.
One is scaling. As your base grows, you usually run into scaling issues. Sometimes these issues are simply that you have stuff in nonoptimal places, paths that can't handle the strain. Other times whole new elements start coming to the fore, such as pollution in SimCity and nobles in Dwarf Fortress. This scaling is often the primary cause of concern for experts, who carefully build their bases to scale easily right from the first module.
Another is deformations. While a base can be very complex using only self-reference, it is located in space and space has other things in it. It is common to have various resources or hazards scattered around, or even just presence or lack of ground. These will force the base into specific kinds of shapes, and can shake up an expert's carefully-planned optimal layout.
The last I can think of is progress. By introducing new components or having goals with in-world results, things can become available/change state during play. This changes how a base grows and interacts, and adds further late-game complexity.
There is also the aspect of time compression that these games frequently add. If there are individuals in the game, managing their schedules is going to be critical and it's going to take them an hour to go fifty feet. However, this is certainly not a core base construction play dynamic. It's a micromanagement dynamic that's simply become super-common.
Anyway, I think that's enough chattering. I just thought I should write about it because I've built some base-building toys recently, and learned this crap the hard way.
What do you think?
There is a very underappreciated set of games I like to call the base-building games. These are things like Sim City, Dwarf Fortress, Evil Genius, and the Sims. That last one isn't underappreciated, I know.
These are games where the main point is to build a functioning base of some kind.
They are often lumped together with RTS games and tower-defense games, but both of those are about managing attacks and defenses instead of building a base. They are distinct from the sorts of games I'm talking about, where the whole point is to build a functioning base, not to build functioning defenses or armies (which might be incidentally possible, but aren't the point).
Base building games fall on a spectrum. To the left we have the construction games, which focus more on deep dynamics that allow you to focus on construction for a long, long time. SimCity is the ur-example. There is nothing besides base construction in SimCity: the most non-base-construction thing in the game is setting your budget, which consists of about five variables.
To the right we have base management games, which have shallower dynamics and instead rely on micromanagement to take up the slack. The thing about these is that the micromanagement has almost nothing to do with the base construction. The Sims is the best example on this end. While there is base building (you make a house), the game is actually about painstakingly clicking your little inhabitants through every moment of their day.
Somewhat to the right on this scale is Evil Genius, which features a fairly complex base dynamic but heavily focuses on defending against agents and micromanaging your assets abroad. The trap construction... I don't know whether to consider that base building or not.
Somewhat to the left on this scale is Dwarf Fortress, which has very, VERY good base construction dynamics. But the player spends much of his time designating trees to be chopped down, ores to be mined, shoes to be built... despite the fact that you could rely wholly on base building to result in an interesting game, there is an aspect of micro-management.
All of these micro-managing aspects in all of the games listed have very little to do with the actual construction of your base. Building shoes and cutting trees doesn't matter how your base is laid out. Assigning fifty troops to the Bahamas doesn't change base on base layout. Getting your sims through their morning ablution doesn't care about your base layout.
There is some interaction, sure. If your house is palatial in the sims, it will take your sims an extra thirty minutes to get from the bathroom to the bedroom (because it takes them freaking five minutes to go one tile). Your layout in Evil Genius matters because many of your enemies will try to come in through the front door, but many more will magically pop up in the middle of your base and defending the front door is only slightly variable based on your layout. Etc, etc.
These days, most games tend to be more and more micromanagy. The days when a complex base WAS the game seem to be over in favor of splitting into Tower Defense and Base Micromanagement genres.
However, I think this is not irreversible. Base construction is a deep kind of play, and there's no reason not to use it. The key problem is that most people who make base construction games tend to make boring ones. As an example: there are fully half a dozen space station/space base construction games from the last decade, and the better ones are the earlier ones. As time has progressed, they have gotten shallower and shallower, more and more boring. The designers have forgotten how to make base construction interesting because they've been dazzled by RTS and base micromanagement games.
That would be fine if that was the sort of game they were building, but you can't just take those games and say, "now let's get rid of this irritating micromanagement/base defense part". That irritating part is the main gameplay!
So let's talk briefly about the kind of gameplay that usually makes for good base construction games.
First and foremost, base construction games take place in space. Most base construction games (such as SimCity) take place in two dimensions. A few take place in three dimensions. This dimensionality is the core from which all complexity grows.
Tower defense games know this, and are an excellent example. With a tower defense game, your enemies will follow paths in space, and you set up your turrets in optimal spaces to fire on them. This spatial interaction is the core of base construction, distilled to purity. But instead of interacting with incoming enemies, base construction interacts with base construction.
Where you put thing A and road B matters, because they exist in space and exert a certain influence.
Oversimplifying this to a radius effect is problematic: you either end up with tower defense or Simcity Societies. Instead, you want to quantify vectors and paths for the effects. In most base construction games, the primary path is the road. All your resources and people have to travel along the road (or the hall or whatever), so you build your base to (A) have short roads and (B) have its road needs distributed such that the roads aren't overwhelmed.
(You don't have to use only roads, by the way, but that's the most common setup.)
The other aspect to most base building games is an element of infrastructure. In SimCity this is extremely apparent: you have to hook up wires and run plumbing in addition to the roads. These conduits are distinct from roads because there is no real concern about how much is traveling through them or the range the resources travel. You can put your power station on a far hill and run ten miles of wire, you'll get power just the same as if you had your station next door.
The key to infrastructure complexity isn't in shortening them or balancing their loads, it's in establishing them at all. Can you cross one kind of infrastructure over another? What situations happen when they break down at a random point? That sort of thing.
This is distinct from the "virtual infrastructure" many RTS games use, where you just need to generate enough resource and it is magically allocated to wherever it is needed.
Infrastructure and paths are both core elements of play, and it varies as to what kind of thing falls into which category.
But that's not the limit. There are a few other things that affect play.
One is scaling. As your base grows, you usually run into scaling issues. Sometimes these issues are simply that you have stuff in nonoptimal places, paths that can't handle the strain. Other times whole new elements start coming to the fore, such as pollution in SimCity and nobles in Dwarf Fortress. This scaling is often the primary cause of concern for experts, who carefully build their bases to scale easily right from the first module.
Another is deformations. While a base can be very complex using only self-reference, it is located in space and space has other things in it. It is common to have various resources or hazards scattered around, or even just presence or lack of ground. These will force the base into specific kinds of shapes, and can shake up an expert's carefully-planned optimal layout.
The last I can think of is progress. By introducing new components or having goals with in-world results, things can become available/change state during play. This changes how a base grows and interacts, and adds further late-game complexity.
There is also the aspect of time compression that these games frequently add. If there are individuals in the game, managing their schedules is going to be critical and it's going to take them an hour to go fifty feet. However, this is certainly not a core base construction play dynamic. It's a micromanagement dynamic that's simply become super-common.
Anyway, I think that's enough chattering. I just thought I should write about it because I've built some base-building toys recently, and learned this crap the hard way.
What do you think?
Tuesday, April 13, 2010
The Standard Set
I've played a lot of games, and one thing I notice is that the enemies are all very "samey". Regardless of the kind of game, enemies tend to fall into the same five categories: the eggshell, the heavy, the skirmisher, the sniper, and the spawner. Whether the game is a first-person shooter, an RPG, or even a CCG, these hold true.
(Similarly, there are a common set of categories for players. It used to be the D&D standard, now it's the MMORPG standard, but it's the same rut.)
Just to show you more clearly what I mean, let me describe the Dead Space enemies. In dead space you have slow zombies, which are a really weak heavy. A stronger heavy is the rhino-thing.
You have those flying bat-things that make zombies, those are spawners. Another spawner is the fat-belly thing. The exploding arm guys are eggshells, as are the tiny insect swarms. The baby things are snipers, the scorpion-men are skirmishers, etc, etc. All the enemies slot neatly into these five categories.
And Dead Space was well known for its unique enemy design!
So this popped up a question in my head. Is it that there are only five kinds of enemy that can be made, or is it that people aren't very creative?
Let's take a look at another game: Super Mario Brothers.
In SMB just about none of the enemies fall into these categories. You have to really squint if you want to even try. Technically, I guess a Goomba is an eggshell. But what's a turtle? Even if you do decide it fits into a category, the enemy is not about offering a challenge of that type. It's about being a mobile obstacle and resource (as it drops a shell when you kill it).
Ah, there's the key for me.
The five enemy types I've listed are really kinds of challenges you can offer. It turns out that game designers have created a very stable platform for challenges, a nicely modular set-up that we almost invariably follow. It can be easily adapted to suit one-character or teams of heroes, any kind of setting, any kind of power level. It offers enough complexity to make things interesting but not enough to require careful thought. It is ideal for the kind of middle-of-the-road challenge that most games like.
But most of the games I remember best don't use that standard challenge platform. Sometimes they are close to the same kind of game, such as Shadows of the Colossus. Sometimes they are completely different kinds of game with completely different challenge types, such as Katamari Damacy.
So I'm a fan of not using the standard challenge set if you're making a game that can support it. By using an unusual challenge set when everyone else uses a standard one, you can make your game stand out, whether it's a tabletop RPG or a mod for Half Life.
Coming up with an unusual challenge can be difficult because your brain has likely fallen into a rut without realizing it. The key is to create a different fight dynamic. If your fight dynamic is the normal one, you can't change the normal enemy set very easily. Instead, you've got to make your fight dynamic really weird. Shadows of the Colossus and Katamari Damacy are both decent examples, as is the original Valkyrie Profile, the early survival horror games, and many other games that stand out as being unique. Changing the dynamic even slightly can result in very different kinds of enemies, because the challenge to the player is different.
Here is an example that occurred to me. I watched an LP of the new Spider-Man game, and it has some interesting fighting-on-walls stuff. Spider-Man has the unusual ability to stick to surfaces both with web and with his extremities, which makes him one of the few superheroes who can sensically exert huge amounts of force, such as lifting a car.
The combat seemed pretty normal in the game, but it got me thinking: what if the whole point of the game was this stick-to-stuff fighting? What if the point of many of the enemies wasn't to injure you, but to try to detach you from the wall, or make the wall too slippery to grab, or similarly affect your traction?
Suddenly you can play host to a whole new kind of dynamic, where fighting is not simply about attacking and blocking. Adding this new dimension of stickiness not only increases the player's options for attacking, but also increases the number of dimensions that you can create enemies on. Even if you want to use the same "standard five" (plus terrain-effector) enemy types, you can now make an enemy skirmisher-damage or skirmisher-destick, so you suddenly have twelve kinds of enemy instead of six.
Don't underestimate the depth of play that results from this. For example, Spidey may have to choose between a strongly-tethered set of attacks relying on his web-pull abilities and three anchored extremities, a medium-tethered set relying on kicks and punches while one extremity is always gripping, or a low-tether set where he swings or slides rapidly but has no direct grip on the wall and therefore cannot exert much force aside from momentum, and is at risk of being knocked off. This is a lot more depth than the Spider-Man game I saw offered: it just offered the standard set of attack, block, charge.
...
The other half of the coin is that you can make up really wonky settings and combat dynamics, but use the standard set for your actual mechanics. This allows you to ground your insane idea in a strong foundation.
For reference, the "expanded" standard set is the eggshell, the heavy, the skirmisher, the sniper, the spawner, the buffer, the terrain-effector, and the puzzle-enemy. All of these are viable, although the last three are usually reserved for bosses due to their high complexity level. Obviously, this list plays fast and loose, but it should serve to help you ground your play.
So lets say you decide to make a game about school politics. The "fight" dynamic is all about social maneuvering. And you say to yourself, "I really like this idea, but I'm having a hard time figuring out how to make it interesting enough to actually play!"
Well, the answer is to start coming up with enemies that fit the standard set, and a rule set that supports them.
Maybe the eggshell enemy is a lackey, someone who follows a more popular person but isn't popular on their own. The heavy is someone who is well-respected but not very interested in politics, so they move slowly to counter you but hit very hard, socially speaking. The football captain, maybe. A skirmisher moves fast and hits hard - someone who is very socially aware but has few merits to defend with. Say, a queen bitch.
The sniper is someone who excels at hitting your weak spot and using your past failings against you. They probably aren't popular on their own, but they can reveal devastating secrets or horrifyingly brutal insults if you let them. A spawner might be someone with a seemingly limitless supply of cronies, or it might be someone who really understands how to let loose a rumor that will spread across the whole school.
And so on and so on.
The point is that, from this standard set, you can shape your recalcitrant idea into a state where it has suitable depth and complexity.
Anyway, that's my rant on the standard set.
What do you think?
(Similarly, there are a common set of categories for players. It used to be the D&D standard, now it's the MMORPG standard, but it's the same rut.)
Just to show you more clearly what I mean, let me describe the Dead Space enemies. In dead space you have slow zombies, which are a really weak heavy. A stronger heavy is the rhino-thing.
You have those flying bat-things that make zombies, those are spawners. Another spawner is the fat-belly thing. The exploding arm guys are eggshells, as are the tiny insect swarms. The baby things are snipers, the scorpion-men are skirmishers, etc, etc. All the enemies slot neatly into these five categories.
And Dead Space was well known for its unique enemy design!
So this popped up a question in my head. Is it that there are only five kinds of enemy that can be made, or is it that people aren't very creative?
Let's take a look at another game: Super Mario Brothers.
In SMB just about none of the enemies fall into these categories. You have to really squint if you want to even try. Technically, I guess a Goomba is an eggshell. But what's a turtle? Even if you do decide it fits into a category, the enemy is not about offering a challenge of that type. It's about being a mobile obstacle and resource (as it drops a shell when you kill it).
Ah, there's the key for me.
The five enemy types I've listed are really kinds of challenges you can offer. It turns out that game designers have created a very stable platform for challenges, a nicely modular set-up that we almost invariably follow. It can be easily adapted to suit one-character or teams of heroes, any kind of setting, any kind of power level. It offers enough complexity to make things interesting but not enough to require careful thought. It is ideal for the kind of middle-of-the-road challenge that most games like.
But most of the games I remember best don't use that standard challenge platform. Sometimes they are close to the same kind of game, such as Shadows of the Colossus. Sometimes they are completely different kinds of game with completely different challenge types, such as Katamari Damacy.
So I'm a fan of not using the standard challenge set if you're making a game that can support it. By using an unusual challenge set when everyone else uses a standard one, you can make your game stand out, whether it's a tabletop RPG or a mod for Half Life.
Coming up with an unusual challenge can be difficult because your brain has likely fallen into a rut without realizing it. The key is to create a different fight dynamic. If your fight dynamic is the normal one, you can't change the normal enemy set very easily. Instead, you've got to make your fight dynamic really weird. Shadows of the Colossus and Katamari Damacy are both decent examples, as is the original Valkyrie Profile, the early survival horror games, and many other games that stand out as being unique. Changing the dynamic even slightly can result in very different kinds of enemies, because the challenge to the player is different.
Here is an example that occurred to me. I watched an LP of the new Spider-Man game, and it has some interesting fighting-on-walls stuff. Spider-Man has the unusual ability to stick to surfaces both with web and with his extremities, which makes him one of the few superheroes who can sensically exert huge amounts of force, such as lifting a car.
The combat seemed pretty normal in the game, but it got me thinking: what if the whole point of the game was this stick-to-stuff fighting? What if the point of many of the enemies wasn't to injure you, but to try to detach you from the wall, or make the wall too slippery to grab, or similarly affect your traction?
Suddenly you can play host to a whole new kind of dynamic, where fighting is not simply about attacking and blocking. Adding this new dimension of stickiness not only increases the player's options for attacking, but also increases the number of dimensions that you can create enemies on. Even if you want to use the same "standard five" (plus terrain-effector) enemy types, you can now make an enemy skirmisher-damage or skirmisher-destick, so you suddenly have twelve kinds of enemy instead of six.
Don't underestimate the depth of play that results from this. For example, Spidey may have to choose between a strongly-tethered set of attacks relying on his web-pull abilities and three anchored extremities, a medium-tethered set relying on kicks and punches while one extremity is always gripping, or a low-tether set where he swings or slides rapidly but has no direct grip on the wall and therefore cannot exert much force aside from momentum, and is at risk of being knocked off. This is a lot more depth than the Spider-Man game I saw offered: it just offered the standard set of attack, block, charge.
...
The other half of the coin is that you can make up really wonky settings and combat dynamics, but use the standard set for your actual mechanics. This allows you to ground your insane idea in a strong foundation.
For reference, the "expanded" standard set is the eggshell, the heavy, the skirmisher, the sniper, the spawner, the buffer, the terrain-effector, and the puzzle-enemy. All of these are viable, although the last three are usually reserved for bosses due to their high complexity level. Obviously, this list plays fast and loose, but it should serve to help you ground your play.
So lets say you decide to make a game about school politics. The "fight" dynamic is all about social maneuvering. And you say to yourself, "I really like this idea, but I'm having a hard time figuring out how to make it interesting enough to actually play!"
Well, the answer is to start coming up with enemies that fit the standard set, and a rule set that supports them.
Maybe the eggshell enemy is a lackey, someone who follows a more popular person but isn't popular on their own. The heavy is someone who is well-respected but not very interested in politics, so they move slowly to counter you but hit very hard, socially speaking. The football captain, maybe. A skirmisher moves fast and hits hard - someone who is very socially aware but has few merits to defend with. Say, a queen bitch.
The sniper is someone who excels at hitting your weak spot and using your past failings against you. They probably aren't popular on their own, but they can reveal devastating secrets or horrifyingly brutal insults if you let them. A spawner might be someone with a seemingly limitless supply of cronies, or it might be someone who really understands how to let loose a rumor that will spread across the whole school.
And so on and so on.
The point is that, from this standard set, you can shape your recalcitrant idea into a state where it has suitable depth and complexity.
Anyway, that's my rant on the standard set.
What do you think?
Subscribe to:
Posts (Atom)