After my failure to resolve the inconsistencies in Cloak of Darkness as a test for new IF systems, i started wondering about a new example demo standard for modern IF systems.
From time to time, many people pop up with emergent new IF systems. Some give up, some plod along and some get going, and it would be really great if there was an example demo standard that could be used as material.
So what i had in mind was a kit that consisted of bunch of text files and media including a game specification. There would be no code and the material would not be predisposed toward any specific kind of engine. The kit could be hosted somewhere like the IFDB, the IF archive, the IFWiki or even somewhere like the IFTF.
The kit would contain:
game specification
story text files; locations, descriptions, objects etc.
map layout diagram
location pictures
object pictures or icons (3D models?)
event sounds
scene graphics, animations? audio?
background music/sound
title picture
title music/audio
credits (eg HTML with links)
logo
recommended color themes
fonts (or recommendations thereof)
dialog voice?
A lot of the above wouldnât necessarily be there for version #1 and not all things would apply to all systems, but they could be added to the kit. Some things could be optional and people could contribute updates such as improved pictures, more pictures, sounds etc.
There have been a lot of great mini games, things done for competitions etc. I was wondering if an author out there would be interested in donating (subject to attribution) a work for this purpose. It would have to be something quite small; perhaps only a handful of locations, a few objects at most and a very simple game specification thatâs not necessarily dumbed down, but is easy to understand.
If anyoneâs interested, Iâll try to get something working and build the debut kit.
Iâd suggest making things like images and audio optional, and maybe have a core spec that focusses on the story, while some kind of spec++ would also define the usage of the provided media. This way it wouldnât discourage people from using the kit for engines that donât support rich media.
Some things I would like the story to demonstrate:
Interacting with an NPC, such as having a little dialog and involving the NPC in some kind of puzzle
Conainment and locked containers, e.g. a locked treasure chest with a key hidden somewhere
Reacting differently to the same input depending on how often the input was used to show that the system can keep track of stats
Reacting differently to the same input depending on the location of the player
And something about meta commands. I think at least save and restore should be there (automatically when closing/starting the game and/or as a user command). Others could be transcript, verbose, test, restart, âŚ
An NPC could follow a path through the rooms so that they are not always in the same place.
An NPC could hide inside of an object.
Finding objects should involve looking inside, under and behind other objects.
You could have an event, something that happens after a certain number of turns.
As well as basic doors/containers locked with a key, you could have a latched door you can only open from one side, a safe with a combination lock etc.
Names of objects or NPCâs could change, eg. âA tall manâ could become âMr Bloggsâ after you ask him his name.
Elevators are always interesting as they are controlled by buttons inside and called to a location by an external button. They also demonstrate having the player inside a container which then moves itself to a different location.
Connecting several objects together to create a new object would be a good puzzle.
Dropping/throwing an object and having it land in a different location, eg. off a balcony.
You might consider using Mystery House http://ifdb.tads.org/viewgame?id=clc9a8hnvx79pabw for this purpose. It is a âHi-RES Adventureâ from the 1980âs. It was released to the public domain in 1987.
Regarding the âkitâ list. I agree a lot is optional!
I wanted to at least suggest an aspirational list that might eventually be fulfilled. If assets such as music and animation were collected, they would have to not be essential for making the game. So, for example, you couldnât have a puzzle based on hearing a sound.
It would always be important that the IF be narrative driven, whilst the accompanying media act to add depth.
@jfhs, Yes there ought to be one character in the game, with some, albeit limited, dialog. Letâs say ASK or TELL would work, either by command line or GUI drag-and-drop.
Regarding using âMystery Houseâ as the game, it would be cool, but unfortunately not practical now we have a hit list of requirements for our mini game.
Whatâs needed is the smallest idea for a game that incorporates the requirements in the kit suggestions - certainly a puzzle in itself!
When I asked a similar question a while back, someone mentioned Balances, by Graham Nelson, but I never got around to actually trying it out or looking at the source code.
Iâd echo jkj yuio in emphasizing the importance of keeping the core game simple. Part of what makes Cloak of Darkness work is that itâs easy to whip up an implementation with minimal effort - whereas the idea of reimplementing the entirety of âBalancesâ isnât nearly as appealing.
Ideally, that means designing a single, simple puzzle that demonstrates if and how the system implements the feature list, without being tied to any specific world model. (i.e.: youâre not demonstrating the systemâs ability to implement a specific technical vision of NPC-as-moving-object, youâre demonstrating how the system goes about more broadly giving the player the impression of a moving NPC, as well as what other technical bells and whistles might make it appealing to authors.) Cloak of Darkness is very clever in this regard, hitting a deceptively large number of technical points in a single scene, but with enough flexibility that radically different systems can implement it.
I might also suggest extending Cloak of Darkness rather than entirely replacing it. The IF scene is a nostalgic bunch, so âCloak of Darkness: Advancedâ may have more appeal than a wholly new game.
May I suggest âCloak of Darkness: Revenge of The Bouncerâ?
In the cloakroom, there are two additional objects on the floor: A piece of paper with the phrase, âThe rooster crows at midnight,â and a name tag that says âBig Bossâ.
In front of the door to the bar stands a bouncer. If the player is wearing the cloak, the bouncer canât see him and simply responds âwho said that?â to anything that is said to him.
If the cloak is off and the player is wearing the name tag, the bouncer says, âGood evening boss, let me get the door,â and opens the door.
If the cloak is off and the player isnât wearing the name tag, but they say âThe rooster crows at midnight,â the bouncer responds with âtime flies like an arrow.â
If the player then responds with âfruit flies like a banana,â the bouncer says, âWelcome, right through this door, please.â, and opens the door. Otherwise, he says âscram, buddy, if you know whatâs good for you.â
I like some of these ideas. definitely if an extended COD were designed, a âbouncerâ might be a good character to have.
There could be some kind of âpass-phraseâ as suggested or possibly a physical object like an âinvitationâ. The pass-phrase idea works well with dialog, but for the game to be generic, what will it do when there is no parser input? Having the pass-phrase as a choice make it too easy.
I think to be a success the design needs to accommodate various forms of IF styles including; parser, choice, point-and-click etc.
A simple way to implement a combination lock in a CYOA would be to have ten choices to enter the first number, one of which goes to the entry page for the second number on the âcorrectâ path and all the other choices go to the false path. As each digit is entered you either stay on the correct path or switch to the false path that finishes with a page that says the safe did not open.
I donât believe the demo should avoid features that are impossible in some systems. The example for such a system should simply say that it could not be done and it had to be omitted.
The main purpose of such a demo is to show people how to accomplish various non-standard features in a variety of IF systems so that they can choose the system that best suits them and what they want to do, and then shows them how to implement that feature.
I agree that it should be as small and simple as possible, but by omitting repeats and too obvious options. For example, there should only be one lock that is opened with a key and there should not be any doors that you can simply walk through. Each door should demonstrate a different way to lock a door: a combination lock, a voice command, a puzzle, or a door that can only be opened by going a different way and opening it from the other side.
thereâs at least one extended CoD (15458 bytes source re. 3180 bytes) in the ZILF 0.8 samples, whose seems to me a good base for an extended CoD definition.
A 4228 bytes blurb of it is in McGrewâs Learning Zil, Iâll quote it below is because looks to me a good definition of the implementation: