Cloak of Darkness 2: Survey Results

Authoring General Design Discussions
1

As a result of discussion on this thread on Cloak of Darkness, I ran a survey. This is a summary of the results, with a few tentative comments.

IF Systems

Question 1 asked what (if any) IF authoring systems respondents were familiar with?
[table][tr][td]System[/td][td]Percentage[/td][/tr]
[tr][td]Inform7[/td][td]86[/td][/tr]
[tr][td]TADS3[/td][td]42[/td][/tr]
[tr][td]Inform6[/td][td]38[/td][/tr]
[tr][td]TADS2[/td][td]25[/td][/tr]
[tr][td]Hugo[/td][td]14[/td][/tr]
[tr][td]Adrift4[/td][td]8[/td][/tr]
[tr][td]Adrift5[/td][td]6[/td][/tr]
[tr][td]All others[/td][td]10[/td][/tr][/table]

COMMENT: There was nothing surprising here. This wasn’t intended to be a popularity survey, but I wanted to be sure we had a reasonably wide range of views. I think we do. The “others” included a variety of non-parsers systems (such as Undum and Twine)

33 people began answering the survey, but although most people answered this question and the next, only 21 completed all the remaining questions.

The general principle

Question 2 asked whether respondents were familiar with Cloak of Darkness. Everybody was.

Question 3 asked whether respondents supported the idea of a “new sample game that would demponstrate the use and facilities of different IF authoring systems”.

The results were:

[table][tr][td][/td][td]Per cent[/td][/tr]
[tr][td]Great idea[/td][td]36[/td][/tr]
[tr][td]Good idea[/td][td]42[/td][/tr]
[tr][td]No opinion[/td][td]15[/td][/tr]
[tr][td]Not a very good idea[/td][td]6[/td][/tr]
[tr][td]Terrible idea[/td][td]0[/td][/tr][/table]

COMMENT: That seems to suggest a pretty strong consensus among respondents that it’s at least a good idea. Of course, the sample is biased.

The game

Question 4 asked respondents to rate the importance of various basic characteristics of a sample game. The rating was on a four point scale: very important, quite important, not very important, and very unimportant. For the purposes of reporting the results of this and other similar questions, I have converted this scale to a numeric scale, where 1 is “very important” and 4 is “very unimportant”, and I list the results in order of mean rating.

[table][tr][td][/td][td]1[/td][td]2[/td][td]3[/td][td]4[/td][td]mean[/td][/tr]
[tr][td]It should include common things[/td][td]59[/td][td]36[/td][td]5[/td][td]0[/td][td]1.45[/td][/tr]
[tr][td]It should be short[/td][td]33[/td][td]62[/td][td]5[/td][td]0[/td][td]1.71[/td][/tr]
[tr][td]It should be easy to code[/td][td]25[/td][td]35[/td][td]40[/td][td]0[/td][td]2.15[/td][/tr]
[tr][td]It should include difficult things[/td][td]5[/td][td]40[/td][td]42[/td][td]15[/td][td]2.67[/td][/tr]
[tr][td]It should be enjoyable to play[/td][td]0[/td][td]20[/td][td]60[/td][td]20[/td][td]3.00[/td][/tr]
[tr][td]It should be suitable for non-parser systems[/td][td]0[/td][td]20[/td][td]48[/td][td]33[/td][td]3.14[/td][/tr][/table]

Comment: It looks as if the consensus is for a short, simple demonstration that covers the basics of parser-based IF. There is some division of opinion about whether it should demonstrate “difficult things”; perhaps it depends on how you understand “difficult”. Fortunately, specific answers to later questions help us to understand better what people have in mind.

Question 5 asked respondents to comment on a variety of “game world” features that they thought should be included. Again there was a four point scale, and I have converted it to numbers and give them in order of mean rating. Percentage responses are given with the mode in bold. All are rounded to the nearest percent.

[table][tr][td][/td] [td]1[/td][td]2[/td][td]3[/td][td]4[/td][td]mean[/td][/tr]
[tr][td]Objects the player can carry[/td][td]67[/td][td]19[/td][td]10[/td][td]5[/td][td]1.52[/td][/tr]
[tr][td]NPCs[/td][td]57[/td][td]24[/td][td]14[/td][td]5[/td][td]1.67[/td][/tr]
[tr][td]Moving between locations using standard compass directions[/td][td]54[/td][td]23[/td][td]18[/td][td]5[/td][td]1.73[/td][/tr]
[tr][td]Inventory[/td][td] 53 [/td][td]29[/td][td]14[/td][td]5[/td][td]1.73[/td][/tr]
[tr][td]Scenery objects[/td][td]39[/td][td]48[/td][td]14[/td][td]0[/td][td]1.76[/td][/tr]
[tr][td]Objects that can contain other objects[/td][td]33[/td][td]52[/td][td]10[/td][td]5[/td][td]1.86[/td][/tr]
[tr][td]The player’s description[/td][td]43[/td][td]24[/td][td]33[/td][td]0[/td][td]1.90[/td][/tr]
[tr][td]Objects that can have other objects placed on them[/td][td]20[/td][td]67[/td][td]10[/td][td]5[/td][td]2.00[/td][/tr]
[tr][td]Objects the player can wear[/td][td]24[/td][td]53[/td][td]19[/td][td]5[/td][td]2.05[/td][/tr]
[tr][td]Doors[/td][td]19[/td][td]48[/td][td]29[/td][td]5[/td][td]2.19[/td][/tr]
[tr][td]Locks and keys[/td][td]19[/td][td]48[/td][td]29[/td][td]5[/td][td]2.19[/td][/tr]
[tr][td]Objects the player can enter[/td][td]19[/td][td]48[/td][td]29[/td][td]5[/td][td]2.19[/td][/tr]
[tr][td]Objects the player can switch on or off[/td][td]24[/td][td]38[/td][td]29[/td][td]10[/td][td]2.24[/td][/tr]
[tr][td]Things the player can read[/td][td]20[/td][td]33[/td][td]43[/td][td]5[/td][td]2.33[/td][/tr]
[tr][td]Objects the player can eat / drink[/td][td]14[/td][td]33[/td][td]43[/td][td]10[/td][td]2.48[/td][/tr]
[tr][td]Moving using “GO TO” or similar commands[/td][td]5[/td][td]33[/td][td]47[/td][td]14[/td][td]2.71[/td][/tr]
[tr][td]Darkness[/td][td]10[/td][td]24[/td][td]43[/td][td]24[/td][td]2.81[/td][/tr]
[tr][td]Animals[/td][td]0[/td][td]33[/td][td]48[/td][td]20[/td][td]2.86[/td][/tr]
[tr][td]Moving between locations using non-standard directions
(e.g. fore and aft)[/td][td]10[/td][td]20[/td][td]43[/td][td]30[/td][td]2.90[/td][/tr]
[tr][td]Vehicles[/td][td]0[/td][td]25[/td][td]50[/td][td]25[/td][td]3.00[/td][/tr]
[tr][td]Inventory limits[/td][td]5[/td][td]10[/td][td]43[/td][td]43[/td][td]3.24[/td][/tr]
[tr][td]Magic[/td][td]0[/td][td]5[/td][td]53[/td][td]43[/td][td]3.38[/td][/tr][/table]

COMMENT: This helps us understand what people mean by basic. As was suspected, darkness is not thought important, and NPCs are seen as pretty fundamental. My guess is that the “line” between what ought to be included and what really need not be occurs somewhere around the area of reading matter. Everything above that (which, interestingly, includes locks, keys, doors and enterable objects) is a pretty strong candidate for inclusion. It’s from about reading matter downwards that the majority tips against inclusion.

The question invited additional suggestions – but most of them were for things which were dealt with in later questions anyway, especially custom commands.

Speech

Questions 6 and 7 asked specifically about NPC speech. As can be seen from Question 5, most people thought that NPCs should feature. But should NPC speech? And if so, what form should it take.

Question 6 simply asked whether people thought a sample game should include NPC speech. The results were as follows:

[table][tr][td]Yes, probably[/td][td]38%[/td][/tr]
[tr][td]Yes, it’s very important[/td][td]29%[/td][/tr]
[tr][td]Perhaps[/td][td]29%[/td][/tr]
[tr][td]No[/td][td]5%[/td][/tr][/table]

COMMENT: That’s a clear majority in favour of including NPC speech (67% either strongly or somewhat in favour, compared to only 5 percent definitely opposed).

Question 7 asked respondents to rank four possible options for NPC speech if it was included.

The first choice for a clear preponderance of respondents was for the specification to be agnostic, leaving it to each implementation to decide what system to use (45 percent of respondents). The remaining respondents were pretty evenly divided between ask/tell (25%) and menu based (20%) as first choice.

COMMENT: There seems to be a clear majority in favour of having a specification which does require NPC speech, but leaves it to each implementation to decide how to implement speech, with pretty even division of next preferences between ask/tell and menu. In practical terms, this seems to militate strongly in favour of a specification that is agnostic on the point.

Parsing and commands

Question 8: Question 8 asked specifically about demonstrating aspects of parsing. Again I report results using the 1 to 4 scale, in mean order, where 1 is “very important” and 4 is “very unimportant”.

[table][tr][td][/td][td]1[/td][td]2[/td][td]3[/td][td]4[/td][td]mean[/td][/tr]
[tr][td]Creating new actions[/td][td]67[/td][td]33[/td][td]0[/td][td]0[/td][td]1.33[/td][/tr]
[tr][td]Disambiguation (distinguishing
between similarly named objects)[/td][td]52[/td][td]42[/td][td]5[/td][td]0[/td][td]1.52[/td][/tr]
[tr][td]Names for objects that change automatically
for instance “lighted” lamp when lamp is lit[/td][td]14[/td][td]48[/td][td]33[/td][td]5[/td][td]2.29[/td][/tr]
[tr][td]Actions like “remember” that dont refer
to physical things[/td][td]19[/td][td]48[/td][td]14[/td][td]20[/td][td]2.33[/td][/tr]
[tr][td]Synonyms for standard actions (eg cuddle for
kiss)[/td][td]19[/td][td]38[/td][td]33[/td][td]10[/td][td]2.33[/td][/tr]
[tr][td]Demonstrating use of all or most standard
verbs[/td][td]19[/td][td]19[/td][td]33[/td][td]29[/td][td]2.71[/td][/tr]
[tr][td]Using hypertext as well as or instead of
the parser[/td][td]0[/td][td]20[/td][td]33[/td][td]48[/td][td]3.29[/td][/tr]
[tr][td]Letting the player name objects[/td][td]0[/td][td]14[/td][td]38[/td][td]48[/td][td]3.33[/td][/tr][/table]

COMMENT: This produced some of the strongest consensus but also the most division. There’s very strong agreement on the first two points, but proposals to demonstrate the use of most standard actions and to demonstrate verbal synonyms seem to produce a fairly broad split.

Technical and presentational

Question 9: This question asked about other features, which weren’t really about the world model or the parser; they are all really technical features or about presentation. Again, I’ve converted the answers into a 1 to 4 rating where 1 is the most enthusiastic and 4 the least, and lited them in mean order.

[table][tr][td][/td] [td]1[/td][td]2[/td][td]3[/td][td]4[/td][td]mean[/td][/tr]
[tr][td]Customized default responses[/td][td]67[/td][td]14[/td][td]19[/td][td]0[/td][td]1.52[/td][/tr]
[tr][td]Customized error messages[/td][td]62[/td][td]14[/td][td]19[/td][td]5[/td][td]1.67[/td][/tr]
[tr][td]Handling implied actions (eg automatic
opening or unlocking of doors)[/td][td]33[/td][td]33[/td][td]29[/td][td]5[/td][td]2.05[/td][/tr]
[tr][td]Randomized text or responses[/td][td]29[/td][td]38[/td][td]29[/td][td]5[/td][td]2.10[/td][/tr]
[tr][td]Contextual hints[/td][td]14[/td][td]67[/td][td]14[/td][td]5[/td][td]2.10[/td][/tr]
[tr][td]Customisation of scope rules[/td][td]24[/td][td]24[/td][td]48[/td][td]5[/td][td]2.33[/td][/tr]
[tr][td]Time triggered events[/td][td]10[/td][td]52[/td][td]24[/td][td]15[/td][td]2.43[/td][/tr]
[tr][td]Keeping track of player knowledge[/td][td]19[/td][td]29[/td][td]33[/td][td]19[/td][td]2.52[/td][/tr]
[tr][td]Customized status line[/td][td]10[/td][td]33[/td][td]33[/td][td]24[/td][td]2.71[/td][/tr]
[tr][td]Different text styles (eg italic)[/td][td]5[/td][td]33[/td][td]33[/td][td]28[/td][td]2.86[/td][/tr]
[tr][td]Scoring[/td][td]0[/td][td]29[/td][td]43[/td][td]29[/td][td]3.00[/td][/tr]
[tr][td]Coloured text[/td][td]0[/td][td]14[/td][td]38[/td][td]48[/td][td]3.33[/td][/tr]
[tr][td]A graphical map[/td][td]0[/td][td]10[/td][td]33[/td][td]57[/td][td]3.48[/td][/tr][/table]

COMMENT: The “line” between the desirable and the unnecessary here probably falls somewhere around time triggered events. The most contentious item seems to be customisation of scope rules, which doesn’t attract very widespread support, but scores quite highly on average because quite a few of the enthusiasts are very enthusiastic.

Multimedia

Question 10: The final question asked whether a sample game should use multimedia. Almost no respondents thought tht it should be required (only 1 single respondent thought it was important). But a majority (52%) thought that a sample game should offer an “opportunity” to demonstrate if a system provides them, and only a third of respondents were positively opposed to it.

COMMENT: There is clearly no general wish for a sample game that puts multimedia capabilities front and centre, but other things being equal it would be nice if the game provided at least an opportunity for multimedia.

SUMMARY

I think the results largely speak for themselves. There seems to be some sort of appetite for a revised game, and it’s reasonably clear what the most important things it needs to have are. How it gets done, of course, is another matter …

2

My first choice was either ask/tell or menu, though I don’t remember which. I don’t have a particular preference between them. I do have strong hesitations about an “agnostic” specification, because I don’t know how useful it will be to compare the implementaiton of a TADS menu conversation with that of a Hugo “ask/tell” conversation and an I7 “talk to” conversation. So I picked arbitrarily between the other systems and left “agnostic” for last. I’m curious about how many others did something similar, though it seems clear from the numbers you cite that I’m in the minority on this. :slight_smile:

3

Paul. thanks for conducting the survey and presenting the results. I think we should now proceed with this. How about agreeing on a simple game (plot, features) based on the results and, if no-one is willing/has time to make a CoD type of web page, those who anyway have time to code the small game in their programming language of choice could send their contributions to this section (General Game Design) and the codes could be then gathered under one sticky subject that would stay on top, for quick reference and comparison?

4

We never really discussed narrative / gameplay “features” - alternative endings, varying viewpoint characters, flashbacks, and so on - but I guess those are not really things that anyway highlight features of the authoring system.

So: just a very straight up story?

What about settings? In the interest of promoting IF as a somewhat serious art form, and seeing that potentially this is something that will be one of the first things newcomers see, maybe we should stay away from the worst clichés? I’m thinking IF is something people might associate with crude fantasy stories - so maybe we should do something that’s a bit different?

5

Is this something that newcomers will see? That wasn’t true of the original CoD, unless it was a developer-newcomer who specifically asked about comparing languages.

6

Maybe not. It was something I saw early on when I started looking at contemporary IF, but my behavior is not necessarily typical.

Also, I did not mean to say that “genre” fiction can not have literary qualities.

So what do you say? Does the setting matter?

7

It doesn’t matter to me, but then I didn’t fill out the survey. :slight_smile:

8

Setting doesn’t matter at all.

I wish question 5 hadn’t been asked, because I don’t think that any of those things should be included. That territory is covered in CoD1. I think the feature set of CoD2 should be taken from questions 8 and 9.

9

All right, here is a protoproposal which needs fleshing out, just to get this ball rolling. By critiquing it it might iterate towards something usable, so let’s hear those changes and additions.

“Sleeping Dogs”

Locations:
The gate. The protagonist is here.
Exits: north to the garden, south (barred by a grate) to the vestibule.

The vestibule.
Exits: north to the gate (barred by a grate), south to the outer court (barred by a second grate).
When closed, the grates allow throwing things through them, but not (N)PC’s passing.

The outer court.
Exits: north to the vestibule (barred by a grate), south to the inner court.
There is a dog NPC here. The dog moves around at random, never staying in the same place for two turns if it can avoid it.
If the dog is in the same location as the PC, it kills the PC.
If and only if the dog is trapped in one location, it obeys commands.

The inner court.
Exits: north to the outer court.

The garden.
Here are some flowers. Allow “pluck three flowers” and the like. The flowers are both distinguishable and addressable as collective: “x two flowers” will give the distinguishing marks of two of the flowers.
Smelling the unplucked flowers is deadly. Smelling plucked flowers causes sleep till 10 turns after plucking (so smelling after 10 turns has no effect - in fact, they wither after ten turns).
There is a deaf-mute NPC here, with a slate allowing communication. The slate can be named by the (variable) text on it.
There are two levers, linked to the two grates in the game.
By looking south, the dog (and its location) can be seen, wherever it may be.

The game is lost if the PC dies (by sniffing unplucked flowers or killed by the dog), and won if the PC enters the inner court.

(If brevity is a concern, both NPCs can be merged into a guard, but I hope to see different behaviours, e.g. goal-seeking and scripted.)

10

Great start, Biep.

When I said “straight up story”, I didn’t mean straight from north to south… :slight_smile:

Why is the NPC deaf and mute, wouldn’t a normal conversation be more appropriate? And what does the NPC have to say? Tell you about the flowers and the dog?

I get your point about renaming the slab, but maybe we can rename something else… like, you need to crush the flowers in a mortar, it becomes a pulp, and you need to dry it? And you can refer to it as “dry”? Or how about learning to identify the species of flower so you know which one to use? That could be something the NPC can teach you.

Also: don’t you think having three flowers in one room, two levers in one room, and two grates in one room is a bit heavy on disambiguation?

11

Thanks Biep for the game idea.

Some questions:

Why is the gate a location? Isn’t a gate sooner a door type of object? On which side of the gate is the PC actually at the start? Is the gate closed/locked?
Why are there grates between the locations? (And not e.g. gates?) Why is there one gate if the other “doors” are grates?
Why is the name of the game “Sleeping Dogs”? There is one dog in the game, and it is not sleeping?
Why does the dog obey commands only if it is trapped in a location? Why does it kill the PC if it is not trapped? You mean it obeys commands when the PC is not in the same location with it? Or when they are in the same location but the location is closed (=the dog is trapped)? What commands should the dog obey? All of this sounds a bit complicated for a “straight up” example game and could be simplified a bit.

About renaming: the NPC would not be deaf or mute but the PC would be able to ask him/her about the flowers and the NPC would say their names; after that the flowers could be referred to with their actual names.

The map looks like this at this point:

Garden
| (gate)
Vestibule
| (grate)
Outer court
| (grate)
Inner court

(Courts of what? An ordinary house? Something else, like a castle or a mansion?) There are some problems here picturing the environment. Also, a vestibule, as I understand it, is a kind of a lobby, or the first room entering a house: what does a vestibule between a garden and an outer court of a house (?) look like?

12

I have to agree the “dog only obeys commands when it is trapped” idea is not very logical. But I’m not a dog person I guess.

Maybe if it’s a specific location that makes the animal behave this way? A tiger or something that behaves well when it’s in its training ground?

13

That is to allow the dog being visible - the grate must be closed when the dog is in the right place.

The idea is to see how the conversation system can be linked to a non-standard interface. And there is already more standard conversation with the dog.

That was in my mind, but I hope others will invent interesting behaviour. Maybe she scolds the PC for littering when he drops the flowers (and cleans up after him)? Does she have moods?

I took the slate because its name is unpredictable - it can be whatever the user wrote on it, so the system cannot foresee the names. But that doesn’t preclude your suggestions. Or we can allow the PC to name the flowers. And I like your drying suggestion - after N turns the name of the pulp automagically changes into ‘dry powder’.

Actually, I thought of an indefinite number of flowers, and a system to generate unique descriptions - say, from a large set of adjectives that either come from mutually-exclusive sets (colours, sizes) or can be present or absent. The PC can go on plucking till some huge combinatorial number is reached - or memory is full, which will happen way before that.
The interesting thing would be that with present/absent adjectives the flowers can get hard to distinguish - let’s say we have a strong-stemmed fresh flower, a strong-stemmed big flower and a fresh tainted flower (and maybe even a strong-stemmed fresh tainted flower). Here negations might come handy: “Do you mean the tainted or the non-tainted one?”
For the grates one might have the nicety that the ‘north grate’ from one position is the ‘south grate’ from another - especially interesting when commanding the dog who is on the other side of the grate. That would be a different kind of name change.

But yes, for a minimal game one might want to reduce the number of objects that need disambiguation - would changing one lever to a button diminish the amount of code to write? Likewise, one grate might be a fence or so.

But again, I have been sparse in my descriptions, for several reasons, including these:* I hope others will come up with stuff I hadn’t thought of;

  • I don’t know what size of game people have in mind;
  • I don’t know how cutting-edge people want the game to be.
14

Oops, here the non-nativity of my English shows up. I thought of a place like city gates, where one enters under the brickwork of the wall. Can’t one say in that situation “I am in the gate”?
Anyway, let’s change the names of the locations - they don’t matter. With north to the left (for a change), the map is:
Garden - loc 1 | loc 2 | loc 3 - loc 4
The PC is in loc 1; the grate between loc 1 and loc 2 is down, and the dog is in loc 3.

one can throw the flowers through the grate, in order to command the dog to smell (or eat) them, in order to get it to sleep. So both flowers and commands pass, and a grate is open enough for that while still restraining dog and PC.

Yes, that should have been singular. The trick is to get it to sleep, of course.

If not trapped, it will be gone the next turn.

That is why it’s there - to guard the gate.

The latter. Being in the same location with the dog awake would be lethal.

At least “eat flowers”, but why not just any command, showing how the part after the comma in “Dog, ” is interpreted by the dog (as opposed to looked up in a command-action table)?

No problem - my main goal was to move the discussion from abstract to more concrete.

Loc 4 can indeed be pruned. I had it to make the movement of the dog unpredictable, so that seeing the dog was more necessary.

My idea was a castle/mansion. And ‘vestibule’ is probably the wrong name again.

15

I thought of a fierce protecting dog that is accustomed to being trapped between the two grates and being fed there. In a more extended world, there might be two concentrical fences, with dogs between them to prevent people crossing the two fences.
The dog is well-trained and obedient, but also trained to attack and kill (and kept hungry).
Maybe there are Mafiosi living inside?
The situation of burglars throwing drugged meat at such dogs to kill them or put them to sleep is not unheard-of, is it?

16

To throw another idea out there, not (yet) related to Biep’s: A cell phone can be carried (Q5), turned on and off (Q5), and read (Q5), and it introduces a way to converse with an NPC (Q5, Q6). It suggests a new verb (Q8), CALL, with the synonym (Q8) DIAL, that might trigger an implicit SWITCH ON (Q9). Depending on the spec, CALL could apply to a number (something nonphysical; Q8) and/or to people not necessarily in scope (Q9). An incoming call makes a good candidate for a time-triggered event (Q9) and offers a hook for an audio resource (Q10), the ringtone.

17

@ EmacsUser:
The cell phone idea sounds good and covers many of the aspects supported in the survey. So: in the story-to-be, the PC has some kind of dilemma and calls an NPC for helpful advice. The phone could be in the PC’s jacket pocket to begin with; that would cover wearable objects (Q5) and objects that contain other objects (Q5). The short description of the phone could be “switched on/off cell phone” (automatically changing names for objects, Q8).

18

There could be an option to change between referring to it as a “cell phone” or a “mobile phone”. The one object could be almost the entire game! I like the idea.

19

One other reason is to have a readable object. But I like the cell phone idea too - the display of a cell phone is readable too, and there are text messages - which stay in memory and can be recalled on the screen. Maybe the PC watches the dog, and says “Now!” through the phone to a NPC who then shuts the grate.

In the implementation the phone would probably be the NPC. There should be more dialogue - maybe some input about which flowers to pluck (say, the red ones, leading the player to either “pluck 5 red flowers” or “pluck 20 flowers then drop all except the red ones”).

20

Just a general thought: the whole idea of CoD is allowing people to compare implementations in different systems.

That’s easier to do if the code - and the design - contains a number of more or less discrete components, rather than just a few complex parts.

So, on principle I think a basic conversation (with just a regular NPC) is better, simply because it’s maybe a more fundamental building block in IF than a phone or a deaf and mute NPC. But the phone idea sounds cool too, if you think that’s more fun.