next »

[Bob le Moche]

I think in games such as Dwarf Fortress or the Paradox Interactive games it's probably a mix of not really caring and of aiming for a demographic of players who have more patience (and more gaming experience) than the average 12 year old?
Also, maybe it's satisfying to some players to not be treated like an idiot and to not be held by the hand all the time? To have to figure stuff out by themselves?
It's still probably laziness in most cases though...

[Loren Schmidt]

I like that there are a lot of really valid types of games, and they cover a wide range of player activities.

I think it's interesting how good game developers often have completely different goals and attitudes toward design, but all end up making amazing games anyway.

For me, it's not so much a question of what set of rules is best, as what interesting things can come out of different sets of rules. Game design is really fun because you get to pick and choose your design ingredients depending on what you want to accomplish. Sometimes you pick the wrong ingredients, and they feel awkward or out of place. Other times you don't have a goal at all, and you just pick design ingredients that seem fun and see what they become.

But I think most of the time abstract discussion of game design is more about the social process than about actually making games. It's seductive, and it can be fruitful, but more often than not it's sort of like having inebriated navel-staring philosophy discussions. We're mammals, and being right or marvelling at one's own intellect are very compelling to us!

Dang, now I want to go watch the Ren + Stimpy episode about belly buttons.

[BMcC]

Rule #1: Get awesome. For enjoy.

[Zaratustra]

I wonder if it is an ego problem or if it's just laziness, that there are games which are unable to teach the player how to play it in an enjoyable way.

I think in games such as Dwarf Fortress or the Paradox Interactive games it's probably a mix of not really caring and of aiming for a demographic of players who have more patience (and more gaming experience) than the average 12 year old?

You seem to be under the impression that good interface design, like winning the hockey competition, can be done by anyone with a bit of pluck and elbow grease.

Good interface design is hard. And most programmers don't learn it. It doesn't bother them personally, because they make games they'd like to play, and they like figuring out complicated designs. But once you're a designer, you have to think of your public image.

[Loren Schmidt]

Zaratustra- yeah a lot of people just don't think about usability or streamlining their UI. It's not something that naturally occurs to most people, and it can easily go under a developer's radar. Even developers who are being fairly conscientious can easily make odd decisions by incorrectly imagining what the game will be like to a new player.

[bateleur]

Good interface design is hard. And most programmers don't learn it.

This is true, but there's a second problem which holds back games in terms of accessibility: often it's almost impossible to integrate any kind of learning system without breaking the mood.

In a whimsical game like Little Big Planet it's fine to have voiceovers and even in-game characters breaking the fourth wall and talking about PS3 controllers and button presses and so on. Indeed, the Pod even has a PS3 controller in it in game.

But if your game is a dark game of personal horror where your avatar begins the game locked in a dingy prison about to be tortured for some secret you don't even know then having a bunch of dialogs pop up talking about what all twenty of your controls do is a bit mood breaking. And even trying to discuss the problem is sometimes hard because there will always be some designers who maintain that a game with twenty controls is innately broken.

And if your game has any kind of pace to it, it's similarly hard to find a good moment to interrupt with in-game help.

[ஒழுக்கின்மை (Paul Eres)]

I have an idea for a good approach to this: if the player gets stuck and can't do something, then the game can step in and tell them how to do it, but not until then. In the few games that actually tried that, I think it works well. For instance, imagine if, after failing to make the first jump in Mario 1 several times, the game told you "press B to jump while walking forward in order to jump over holes in the ground". That'd work fine, and it wouldn't bother people who already know it, it'd only be seen by people who don't know how to do it.

[Chris Whitman]

But if it's boring, why would you want it? I've never wanted to be bored. I can understand being engaged by something that isn't fun or pleasant, but is still interesting. Reading the memoirs of a concentration camp survivor isn't fun, but it holds your attention.

I don't mean a game that is boring, I mean a game that uses boredom effectively. For example, a game that includes intentionally boring sequences such as waiting in order to produce some effect.

[Chris Whitman]

But if your game is a dark game of personal horror where your avatar begins the game locked in a dingy prison about to be tortured for some secret you don't even know then having a bunch of dialogs pop up talking about what all twenty of your controls do is a bit mood breaking. And even trying to discuss the problem is sometimes hard because there will always be some designers who maintain that a game with twenty controls is innately broken.

And if your game has any kind of pace to it, it's similarly hard to find a good moment to interrupt with in-game help.

I'm having this problem right now. I'm working on a project with an unusual mechanic, and I'm not sure how to introduce it. I can't put it in some kind of instruction manual, because it is a 'secret' mechanic, but I don't want to have a big flashing sign saying "PRESS SHIFT OR BUTTON 3 ON YOUR JOYSTICK IN ORDER TO DO SOMETHING FANCY."

[ஒழுக்கின்மை (Paul Eres)]

Then do it without buttons somehow. Perhaps give them a menu choice, or make it a mouse click.

[Arne]

Maybe you're talking about Tempo? A game can have some more quiet parts before ... some crescendo pops in. There's also normalization. If a game has the same kind of fun all the time, then it might get boring. Kind of like... getting a super weapon and splatting a whole lot of guys. Fun for a while, but only because you don't normally do that. Ideally you should probably switch between different kinds of fun rather than taking the fun levels down. Like, when you don't have that super weapon, you can fly awesomely. And when you don't fly or have the super weapon, a whole lot of pantyclad babes come running in, grinding against you.


Reading the manual was one of my favorite things when I got a new NES game. Yeah, I did play the game first thing I did, but reading a well made manual could be fun. Zelda 1 and Kid Icarus had great manuals. I think it could be taken further. I think it's a good idea to put some story and art external to the game. This way the player can take the game world with him in a tangible form when not playing the game, learn new things about the game universe, then come back into the game with that. Although, It didn't quite work with the NES because the story in the manuals were always nonsense localizations, and even the JP ones weren't really related to the gameplay.

I think things which the player barely can see should be put into the game. It makes the game seem deeper and less exhaustible. An example could be... random loot. If the same items are dropped with equal chance, then the player will quickly know all of the items and feel that the game has been exhausted. Make a few items really rare, and the player will eventually stumble on them and wonder what else might be hiding out there.

If I see the path ahead of me with a too high definition, the game will start to feel like a To-Do list, aka. a list of chores. I don't like chores. So, I think also hiding paths from the player can be good. SMB3 is a simple example. There were some levels which didn't show up on the map, so you could never be quite sure if you got em all. I prefer a good exploration/sandbox game with customizable victory conditions though.

Also, I like when things happen outside the player's view, it makes me feel that the world is not obstacle course tailored for me. If it's an exploration/adventure game with a background story, then I expect somewhat plausible environments, not nonsense blocks and platforms. (Indiana Jones style games might be excused, because tombs were designed as obstacle courses which should still be functional after a thousands years.)

If enemies and corpses disappear as soon as I turn my back to them, then my sense of accomplishment is reduced. If I have to climb over piles of my victims, I feel like I've accomplished great things! It also useful if the game has an exploration aspect. Trail of bread crumbs and all that. It creates a tangible history in the form of corpses and bullet holes.


If you go for easily prototypeable "fun and accessibility" then you risk going into the first local optimum and get stuck there with everyone else. It's a bit like Dawkins "climbing mount improbable" I suppose. As designers we may have the foresight to go down a bit so we can find an even higher peak, but then of course there are other mechanisms at work making risk taking like this difficult.

[increpare]

I'm having this problem right now. I'm working on a project with an unusual mechanic, and I'm not sure how to introduce it. I can't put it in some kind of instruction manual, because it is a 'secret' mechanic, but I don't want to have a big flashing sign saying "PRESS SHIFT OR BUTTON 3 ON YOUR JOYSTICK IN ORDER TO DO SOMETHING FANCY."

General when turned off by the prospect of making something explicit, I've found that the next best thing is to have a very carefully designed level/area/whatever designed to make the mechanic as 'obvious' as possible.

[Titch]

"We need a shared vocabulary to even begin talking about design at something above a surface level"

I think that's the major part I disagree with. I don't think you need a shared vocabulary to talk deeply about something. If two people know something well, they can talk about it, whether they have commonly accepted words for it or not. I've had a lot of deep game design discussions with people (most recently Jason Rohrer) and we haven't had much trouble communicating.

You may not need a shared vocabulary to talk to Jason Rohrer; but when you are in a room with fourth other people all from different cultural backgrounds trying to design a game together the last thing you want is further confusion over a mechanics. It's one thing for two people to be thinking of two separate and subtly (or even wildly) different versions of the same thing when you are just pontificating. When you are all trying to produce something all those subtleties suddenly becoming horrifically pronounced, which just gets worse when you have to account for technical limitations.

For example, the last big 3D game I worked on. Each character had two abilities, one was a cooldown ability (you used it then it reset over time) the other was an recharged ability (you had to get pickups to gain more energy). It took three meetings of one hour each to get these set up right because the level designer was confused over what cooldown and recharge meant. If there was a common word for describe stuff like that it would have saved three to five hours of discussion, confusion and extra programming.

I think having a standardized vocabulary for a topic has benefits and dangers, and the dangers shouldn't be underemphasized. If everyone shares a vocabulary for a subject, they also usually share a worldview for that subject. Different schools of psychological thought have completely different vocabularies and drastically different interpretations of psychological events; same with religions. At its worst, a vocabulary can be a dogma. It might be best to discuss things using common language, without a specialized vocabulary. If a great idea can't be expressed in common language, without the need for jargon, it's usually not that great of an idea and just has to do with the particularities of the jargon.

As of today date I have not spoken to another person using the same art vocabulary that hasn't had wildly different tastes to mine. I used to study art and graphic design so I used to hang out with a lot of people. Similarly with Cinematography, just because I use the same words to describe camera angles doesn't mean I will suddenly start loving art house movies or anything.

The vocabulary is already developing. It's the way it's developing that worries me. It's being heavily driven by culture and marketing. Imbalance is a term designated for designers to highlight when certain aspects of a game are giving a certain player an advantage. 'imba' is the shortened term of the same word, used by games players on forums to describe when they think they are loosing because the game is unfairly weighted against them. These two things should never be confused as 'imba' isn't based on studying a games basic mechanical workings to expose underlying problems, it's based on opinion. However since 'imbalance' isn't designated as part of a designer vocabulary the clarity between the two things will vanish. Soon everyone will talk about 'imba' and nobody will ever know if it's just based on the opinion or study.

That is why I think it's important that there is an established language of design for games design, created by designers. If my own technical language is going to be perverted and used to warp my world views I would much rather the likes of Chris Crawford and Jason Rohrer where doing it than some spotty WoW playing teenager.

I'll apologise in advance about just providing a couple of less than stellar examples. It's late and I'm a bit tired.

[Bob le Moche]

I'm having this problem right now. I'm working on a project with an unusual mechanic, and I'm not sure how to introduce it. I can't put it in some kind of instruction manual, because it is a 'secret' mechanic, but I don't want to have a big flashing sign saying "PRESS SHIFT OR BUTTON 3 ON YOUR JOYSTICK IN ORDER TO DO SOMETHING FANCY."

I know I just liked to Daniel Cook earlier in this thread but this presentation by him is very relevant to tutorials in particular.
It's a presentation he gave to application makers about how to make apps more easy to learn and use by making them more like games.

One of the examples he gives could I think be particularly useful to you, Cake: In super metroid, the wall jump is a "secret" move in the sense that it's not in the manual and that you start with it at the start of the game without knowing.
The way it's taught to you is that the game makes you fall into a pit, and the only way to get out is to use that mechanic. That would be frustrating if it weren't for the little creatures that you can see wall-jumping out of the pit. This gives you a clear indication as to what it is that you must do to get out, and you eventually learn to wall jump by trial and error, without the need for a tutorial or manual.

That presentation is based on the same idea as Raph Koster's theory of fun (an idea that goes back to way before the invention of video games): That the "fun" in playing games is in the learning. That games are only fun as long as you keep learning new skills and discovering new things about them. The reasons tutorials and manuals are boring to most players is that they are forms of "rote" learning: A much less efficient way to learn than games themselves are.

So in a sense I guess the whole game should be your tutorial. The problem then is that some games assume that the players knows a lot of stuff before playing, which might not necessarily be true for newcomers to the genre. Then they get stuck on the first challenge because these basic mechanics are not properly introduced in the game (in a way that experienced players could easily pass and move on to more complicated challenges).


I also agree that stuff going on without the player knowing is not necessarily a bad thing. I think I'd enjoy dwarf fortress a lot less if it weren't for the whole simulated world that goes on behind the scenes, where the personal history of each individual is fleshed out in a consistent way even before the game begins. That stuff has basically 0 effect on gameplay. But when you see some guy with a missing foot or enter an elf town that has goblin architecture, you know there's an actual complex simulated story behind it and to me that's a lot more enjoyable than the kind of solipsism that you get in most games. Spore was a huge disappointment in part for this reason, I think. The first Fable was guilty of pretty much the same thing, if I remember correctly...

[ஒழுக்கின்மை (Paul Eres)]

It's one thing for two people to be thinking of two separate and subtly (or even wildly) different versions of the same thing when you are just pontificating. When you are all trying to produce something all those subtleties suddenly becoming horrifically pronounced, which just gets worse when you have to account for technical limitations.

Just because we didn't use jargon doesn't mean that we were just pontificating and had subtlety different meanings and were talking about two different things.

It's possible to talk about something without jargon, just by using general English terms. Just like it's possible to talk about cinematography without the jargon of cinematography.

Specific jargon saves a little time, since it can do in fewer words what would take more words in general English, but it isn't essential to communication about specialized subjects. And general English tends to be more flexible, whereas jargon tends to be more specific and rigid.

[salade]

One solution to the problem of players getting stuck is to force them to apply logic from the game to find the solution. for instance, in zelda games, weak points on bosses are generaly their eyes. that way the player knows when he encounters a boss to go for the eye. another example in zelda games is that each dungeon employs puzzles that exploit the new item found in that dungeon. thus it is natural for the player to infer that the new item is required to defeat the boss at the end of the level. the trick is to establish the train of thought that the game employs early on in the game, and then force the player to use it in different ways.

also, the best example of rinku's suggestion, a "do this thing" button, I can think of is the scanning system in metroid prime.

[Hayden Scott-Baron]

Someone once complained about the lack of tutorial for Tumbledrop.  I thought allowing the player to try the level, and succeed/fail based upon the very limited input options, was sufficient.

I like games that let you explore the controls in a safe manner and give you reason to learn the toolset before progressing too far. It doesn't need to bang you over the head though, and tutorial/messages can be written on walls for those people who are struggling to proceed because they aren't understanding the controls fully.

I like 'You have to burn the rope' (and many other games') approach of having text scroll past you in a non intrusive manner. This can be easily achieved in 3D space too.

[Glaiel-Gamer]

"If the player doesn't see it, it doesn't exist"

Funny, I'm designing a whole game around this concept.

[deadeye]

Someone once complained about the lack of tutorial for Tumbledrop.

What?  I'm sorry, but if someone needs a tutorial for Tumbledrop then how did they manage to get to the game in the first place because they're obviously too stupid to operate a mouse.

Just saying

[Bob le Moche]

"If the player doesn't see it, it doesn't exist"

Funny, I'm designing a whole game around this concept.

"The Truman game"?