Communicating the type of game to the player

Authoring General Design Discussions
1

Hmm … an empty forum. I’ll bite …

I am writing a fairly linear game, originally designed for the IF Art Show; I’m not sure if that will actually happen this year, so the game might end up in Conrad’s “Meta Comp” in July (not that it contains meta references).

The idea is that you are exploring the mental landscape of a teenage boy – you come across Cynicism, Mistrust and other “people” inside the PC’s mind. It is almost puzzleless; there are some things to do, but they are fairly obvious. The main idea is exploration and conversation (the environment isn’t the focus of the game, and there are hardly any objects). A little understanding of the PC’s past is needed to make progress at some points, but most of the information you get out of conversations is not necessary for finishing the game.

What is a good way to communicate to the player that this isn’t a normal IF game? If someone approaches it looking for puzzles to solve and whizzes through it (in about ten minutes), they’ll miss the point entirely. It’s meant to be a thoughtful and reflective experience rather than a puzzle to “solve”.

David

2

Is this supposed to be a conversation-only adventure? Because it sounds like one.

If so then I suggest you write the game in a multiple-choice/CYOA-based interpreter.

Because if you use a parser-based interpreter then players will assume naturally that your game is about typing commands such as “go north”, “examine room”, “take key” or “open door” in order to progress through an environment unless you write a note at the beginning which explains that there’s no environment at all and that the only commands understood are “talk”, “reply” or “say [something]”. But this may confuse players who expect a fully-featured adventure with parser-interface where they can type lots of different commands and expect them to work.

My upcoming Node-X system lets you set up such a conversation-only scenario actually. Inventory switched off, no items/objects, no puzzles, a single location or no environment at all. Just the player making choices during a conversation with a NPC, for example. You know, as if the player was online in a chatroom or talking to him-/herself.

If this is what you are after then the mere fact that you present a CYOA-based adventure is - in my opinion - enough to communicate to your audience that your game isn’t a normal one.

What I mean is: if you force the player to make choices instead of typing commands then you can better direct him/her in a direction you - as author - want him/her to go. You don’t even have to force the player, because if the player sees that this is a multiple-choice textadventure then he/she will make choices naturally and not think about which commands to type. Sounds logical, doesn’t it.

Imagine a textadventure where the only goal is to find the right answers during a conversation. I already had an idea for a game like this actually. Although I don’t know if such adventure already exists or if it’s possible to make such with a parser-based system.

Anyway, I think multiple-choice is the way to go for adventures like that.

Just my 2 cents.

Emilian

3

I’m all for being up-front about your game. Briefly tell your players about the structure, but let them find out the content for themselves. (I feel the same way about the commands in puzzle games: give them the verbs, since finding the right nouns will be enough of a challenge.) In your case I’d suggest prompting the player to view the about text when the game starts, and then just giving them a vague and non-spoilery description, like, “This is a puzzleless game with a strong emphasis on conversation.” But, I wouldn’t mention anything about the whole mental landscape aspect - that should left up to the actual text of the game.

Having said all that, though, I’m sure that even if you didn’t mention anything about the game’s type, people would get it anyway. Players may be surprised when a game with an engrossing story slaps them in the face with an impossible puzzle, but I don’t think finding that it has no puzzles is likely to upset anyone.

I’m not so sure. Maybe I’m weird, but I suffer strongly from the ‘lawnmower effect’. I’ve always found churning through the branches of a conversation tree to be rather tiresome - no matter how well the writing itself flows.

1 Like
4

Well, it’s true that in most games of any genre the conversation system is tiresome and suffers from - how you call it - the “lawnmover effect” where after a certain amount of time the conversation doesn’t deliver any new information, so that the player loses interest.

It’s the same in real life: when you have a conversation with someone and that someone repeats him-/herself all the time or “beats a dead horse” then you become tired and don’t want to listen anymore.

Even commercial games suffer from this problem. For example, in the 3D-FPS/RPG S.T.A.L.K.E.R. - Shadow of Chernobyl (which is one of my favorite games) the developers implemented a conversation system where the player can approach a NPC and ask questions. Now the flaw with that conversation system is that most of the NPCs give you the same answers and that the player himself can only ask the same questions most of the time.

For instance, there is this “famous” question you can ask any NPC you encounter in the Zone of STALKER:

“Can you tell me something interesting about this place?”

Not only that this question itself becomes very boring very quickly. No, any NPC’s answer to it is mostly the same and goes like this:

“No, I don’t know anything about this place … bla bla.”

And IF they tell you something interesting then it is the same information again each time you ask a certain NPC the same question. So the conversation lacks some variation which would have added to the replayability of the game.

There is another well-known and older commercial 3D-FPS/RPG which has a very good conversation system actually. It’s my most favorite cyberpunk-game Deus Ex (which is by the way a great inspiration for my textadventure games)! In Deus Ex when you start a conversation with a NPC the answers and even the player’s questions can vary and depend on whether you have accomplished a certain task before or whether you have a certain item in your inventory or not.

I have already implemented such a variation in version 1.0 of my system Node-X (see “Project Delta: The Course”) where so-called “FlagNodes” can perform checks on the player’s inventory or other values and then branch into an alternate node (page). This technique can be used, for example, to make a conversation with a NPC turn into another direction when the player did a certain thing before.

I don’t know if you guys have noticed it, but in “Project Delta: The Course” I added one situation - using a FlagNode controlling it - where Lt. Walker says “Hey, where’s your beretta?! Have you left it on the table? …” if the player put the beretta back on the table before following Lt. Walker to the target range.

To cut a long story short, I think it all depends how well a conversation is branched and how much variation/replayability it has.

And it doesn’t really matter if the textadventure is multiple-choice or parser-based. Even in a parser-based game things can become very tiresome very soon. For example, when a player gets the same answer over and over again when typing in unknown commands:

[code]>OPEN TRUNK

I don’t know how to do that.

GET INTO CAR

I don’t know how to do that.

F**K YOURSELF

I don’t know how to do that.

…[/code]

It’s really just a matter of variation and “alternate branching” - how it’s called in Node-X - to keep a conversation interesting in my opinion. And by the way, the answers which a parser gives to the player when he/she types a command can also be understood as some sort of “conversation”. And as you know, that “conversation” can become so tiresome in so many parser-based adventures. I really hate when a parser gives me the same answers to the same problem or the same typed commands.

P.S. If I made a parser-based adventure (which I won’t do, because I aim at the CYOA/multiple-choice subgenre only) then the above example would look as follows:

[code]>OPEN TRUNK

You need a key to open that trunk.

GET INTO CAR

You can’t. The car’s doors are locked.

F**K YOURSELF

I shouldn’t do that in a public place. Should I ?

OPEN TRUNK

As I said this trunk can only be opened with a key.

OPEN TRUNK

Are you deaf or something? I said YOU NEED A KEY!

OPEN TRUNK

I think YOU should f**k yourself.

FUCK YOURSELF

Haha, you are too stupid for this game.

GET INTO CAR

The rules are simple: Find the f**king key or quit.

QUIT

Now finally you did something right. Bye-bye, lamer.[/code]

Some people could argue that this technique breaks the fourth wall or is bad, because it insults the player in the end. But you know what, I think such a technique is cool and I hope that someone will implement something like this in his/her parser-based adventure in the future, although I’m aware of the fact that such implementation is hard to code, because the parser would have to keep track of many variables and depend its answers on it.

Emilian

5

I guess, in respect to the original post, creating a CYOA or entirely menu-based game does relieve you of some of the trouble of relaying to the player what kind of game it is, as they can only select from those options that you choose to give them. At the same time, even within that framework, it’s still useful to discuss how to present a game to the public, in terms of blurbs and pitches. Even if you know that you want to play a CYOA game, you may not want to play a horror CYOA game - or you may only want to play a horror one.

I also suspect that an author with a work in progress is unlikely to be happy with the idea of the time and effort needed to convert to a new, fundamentally different development environment - throwing out not just code, but also design work.

To an extent, but even if the character is saying different things, I still find many menu-based conversations tiring. “Select one of these options” can often feel too much like a slightly more flavourful variant of “press space to continue”.

I would argue that this isn’t a function of the conversation system, but is rather dependent on how much time and effort the game devs are prepared/able to put into implementing and testing this kind of complexity.

Relating this back to the original post, if you’re up-front about what commands are relevant to the game, this isn’t an issue. Not to mention that for this example, in TADS and Inform you’d just implement the trunk as an openable container and players could open it and stick items in it to their heart’s content.

Plenty of people have tried to do that sort of thing (at least on small scales). Invariably it just pisses players off when the insulting messages wind up firing for commands that the player believes to be perfectly reasonable. Not to mention that if you’re going to put that much effort into fleshing out your game, you could probably store much more narrative-relevant states than how stupid you think the player is.

6

Hmm. Maybe. But I still like the idea of somehow communicating in-game what kind of thing is expected from the player …

I guess my worry is what happens in the first location – I can easily imagine someone getting frustrated and saying, “What am I supposed to be doing?” – when the answer is, “as much or as little as you like; and when you have finished exploring the options here, continue down the path”.

For this particular game, “ask about (topic)” would be much more suitable than conversation menus.

David

7

One easy method you could use at first is to have the game do things that require a response from the player. So often a game has its intro text and then the player is put in a static room. If instead the game prompted the player to do things, either through an NPC or some environmental action, that could give the player an idea of what they were to do in an otherwise open-ended environment. The trick would be to taper the prompting gradually so in a short amount of time the player was both on their own and armed with the knowledge they would need of how the game works. In a more linear or railroady game you could of course keep up the prompting for a much longer amount of time.

8

Exactly. Menu-based games can help you solve such problems.

It’s a decision the author himself has to make whether to base his game on a parser or multiple-choice interface. Each one has its advantages and disadvantages. I think it depends on what kind of game you want to design. If you feel fine with command-based stuff and think that this is the right thing for your game then do it. Try to communicate your kind of game to player in the best way. Or if you feel better with CYOA then do this instead. Nobody forces you to do use development tools which you don’t feel comfortable with.

Wait, that’s an assumption I cannot stand by now, because I know nothing or very little about David Fisher’s project at this point.

Is the development of this game already in progress or hasn’t it started yet? Which phase is it currently in - planning/conception, coding, beta-testing?

If it’s at the end of coding phase or in beta-testing phase then I agree with you that the author shouldn’t switch engines.

Hmm… did I really say it was the “function” of the conversation system? I don’t think so. What I really meant was the complexity of the conversation. Sorry for the confusion. My english is not perfect. I can express myself better in german.

That’s why I said I won’t do it. I only meant it would be funny seeing someone else creating this “insult the player” IF type. Who knows, maybe if a decent author wrote a game like that it could become a success. But I won’t risk myself, because I’m new to this community and I haven’t published enough IF games yet that I could afford these kind of experiments.

Perhaps a respected person in the IF community could write this type of game. I imagine it would recieve better reception from the IF community than if it was made by an unknown developer. But I’m just guessing.

However, don’t get me wrong. I’m a person who loves to experiment with new ideas and think out-of-the-box. That’s why I code my own CYOA/multiple-choice interpreter, because I believe that there’s still room for experimentation and creation of new game concepts in that subgenre. And I like to be one of those to represent it.

I think there is no rigidness like in the popular parser-based IF genre where certain rules had already been established by the community over the last 10 to 20 years which authors today are not allowed to break unless they want to piss off players and get megaloads of bad reviews, as you pointed out.

Sometimes I tend to call parser-based textadventures “mainstream IF” and CYOA/menu-based ones “underground IF”. And as you know - no matter which industry (movies, games, music) we are talking about - there always was and is more freedom of experimentation in the underground than in the mainstream. The mainstream creates a single rule which works and sticks to it. The underground is independent and can change its “face” more often without suffering consequences.

So I would present such games as “indie/underground IF games”.