Small IF engine and game built from scratch in just 72 hours for a computer game building contest. Theme had to be “Tiny World”. A bit rough around the edges, there’s a list of things we’d fix if we’d had time. But it is playable I hope.
I should confess to not having played IF since the early 90s, and never writing one. We found writing the text content and adding the puzzles much harder than we’d bargained for, and had to enlist the help of a wordy friend at short notice.
The wooden jetty is where you had expected Dr Strange’s home-made steam launch to moor.
LOOK
There is bottle
GET BOTTLE
could not get bottle - for a list of commands, type “HELP”
Shades of homestarrunner.com/sbemail94.html
Okay, okay, okay, the game doesn’t understand “GET”, it wants me to use “TAKE”. I can handle that.
TAKE BOTTLE
you took the bottle
OPEN BOTTLE
you uncork the bottle; the letter falls out
TAKE LETTER
could not take letter - for a list of commands, type “HELP”
OH COME ON
I’m acting dense for comedic effect here; I was really going to give the game the old college try anyway. But after failing to “i”, “examine hedgehog”, “examine plant”, or “examine novel”, I decided it wasn’t much fun to continue slogging through it. I was having to type “HELP” after every command in order to see what had been implemented. Maybe you should have the list of possible commands always on screen, rather than making it available only through “HELP”.
did you play the illustrated version with the map?
Sorry that you found it frustrating, it’s coded by people who don’t know the norms you were expecting. Given more time it’d have:
better parsing
auto-completion of main commands
more command synonyms, eg get = take = pick up.
The idea of putting inventory and/or help lists on-screen has been mused but I’m concerned it’s starting to go down the road of graphical adventures. We have a lot of graphics compared to 1980s text adventures, but the interface and story is absolutely a text adventure not a point and click adventure. There has to be some trial and error I think.
If the parser recognizes only a handful of commands I think it’s better to have those commands visible, unless of course there’s a “surprising” command that would spoil a puzzle if displayed to the player. The thing with full-fledged parsers is that they tell the player why the command was unsuccesful so even invalid input guides the player towards the right command. If the response is always just “command not recognized” you don’t get the trial part of trial and error.
If anyone has tried the alpha any feedback would be helpful. I’m trying to gauge whether there is sufficient likelihood of a playing community to warrant continuing with the engine.
I think the map interface (illustrated mode) is unique -or is it? And it helps with the spacial dimension so it’s less about drawing your own map.
At the moment the puzzles are mostly hidden in the main JavaScript files so not an easily modable engine. There is a basic quest type puzzle in the prototype, with two ways to achieve it. there’s also basic non-player characters.
Another Feature is being able to flip between illustrated, basic and work panic mode.
There seems virtually zero possibility to getting new users from outside the existing IF world. We’ve had over 12000 visits first few days (thanks to reddit and hacker news) with net average time of about 2 mins (so lots got turned off as soon as they realized it was a text adventure, and/or their browser didn’t work). Lots of encouragement but only from devs not players. So it’s down to people here really.
Is it worth the bother of continuing this engine, making new maps etc? Making it modable, improving parsing, MUDS support, multi-map worlds, dynamic audio…
Unfortunately you really can’t develop a playing community without a well-developed engine. IF players expect synonyms; they expect most commands to be parsed on the first try; they expect to be able to examine the objects mentioned in the room description; they expect the exits to be listed without having to type “exits”, they expect commands that can’t be parsed to give useful feedback. And deservedly so, because there are many game systems that handle all that, and your game is just going to make people think “I could be playing a better-implemented game right now.” (I have Augmented Fourth tabbed, so I know.)
Same for non-IF players. I don’t think your game is making them go “Oh, I just remembered I don’t like text adventures” so much as “Oh, I just remembered what I don’t like about text adventures–you type some text and it doesn’t work and you spend forever trying to figure out what it wants you to say.”
Your prose is also crufty: “I write to inform you of my sincerest apologies for not having made our planned rendezvous. You must forgive me for I am stranded on a small island…” could just be “You must forgive me for not making our planned rendezvous. I am stranded on a small island…”
Aaaand sometimes grammatically incorrect: “There is a plank” and several other sentences lack a period, and the response, “you took the plank”, lacks both a period and an initial capital. “The grass has claimed it as it’s own” should be “its”, while “Its a very heavy iron key” should be “It’s”. “you think This is the way to live’” needs an opening quotation mark. “Crenellation” has two L’s, and so on.
I do like programmer mode! However, in non-graphics modes, the letter should be plain text. I’m unable to see the map in graphics mode (I’m using Firefox 12).
Well we spelt a few words wrong just to give a certain type of person a sense of purpose.
It is a shame the map didn’t load, it is the defining feature I think. Curious that the faux work mode did display though. Can you screenshot both modes as it may help us understand where the compatibility issue is coming from. Or you could always try the illustrated mode in Chrome.
I think one obvious problem with this type of engine is that it requires both artistic and language skills to create decent games. I bet many people who like to write IF cannot draw for toffee.
At any rate, the chances of the dev team putting any more time into this genre are rapidly decreasing. All the noise about a renaissance in IF seems overstated.
I think the recent iOs work Frankenstein by inklestudios just proved you wrong. You just need people good at writing AND people good at graphics/coding. You don’t need a new programming tool, unless it is as promising as inklewriter seems to be. If not, 20 years of zarf, emshort, nelson and so many others’ life can be enough.
There’s something you may not understand about the community you’re posting this in: Just about everyone here is already writing IF with one or another excellent engine that handles text and parsing much better than the Prof Strange engine does. (As you indicated early on in the thread, Prof Strange was written and programmed by people who aren’t actually familiar with the conventions of IF.)
So, when you post here, folks are going to be asking themselves what your engine offers that the engines already available don’t offer. From what I can see, while Prof Strange has pretty much nothing to offer in terms of text processing, there is one aspect of its interaction model that is neat and has real potential: the overlaying of text on the map! (I do see this in both Firefox and Chrome, by the way). If you found some folks to improve the design (typography and so on), and rewrote the engine to use native code to improve performance, I think you could have a pretty neat game, or series of games, built on this feature–in the tablet market, you could probably even have modest commercial success, reaching beyond the current market for the kind of interactive fiction that gets discussed here.
However, I don’t think that the map overlay feature is enough to build an author community on. It would only be practical for games with a certain ratio of text per location. Most games produced by modern IFers wouldn’t work at all using this sort of model for the interrelationship of text and graphics. In other words, I think it would wind up being an engine for producing Prof Strange style games, not for producing IF more generally. Maybe Prof Strange type games would become a thing, and in that case a critical mass of authors wanting to use the engine might appear–but they aren’t likely to be drawn from the pool of people already writing IF. That’s because, again, there are already much better tools for creating the sort of textual IF that the folks here are interested in. These tools are perfect, there are features that people would like to see available in IF engines that aren’t available today (see this thread, for example), but your engine doesn’t address that from what I can see.
In sum, I think what you’ve created in 72 short hours(!) does have potential, but not as an engine for existing IF authors.
(Edited to remove a bunch of first-draft stuff at the bottom that shouldn’t have been in there. Sorry.)
I would put it this way: a new IF system has to grow from “prototype” to “full-featured, street-tested development tool”. And historically, this takes two to four years of work. Not “fiddling around with it occasionally” work, but serious use by a group of game developers who are bombarding you with feature requests and bug reports.
This isn’t us putting obstacles in front of you; this is us recalling what Inform 6, Inform 7, Hugo, TADS 2, TADS 3, etc really went through.
It’s pretty much made up that we aren’t going to bother with the engine any more. The idea of making it NaCl had occurred but tablets represent their own set of issues. The current prototype runs somewhat on an iPad but with mixed experiences. We don’t have any droid tablets to try it on. In general text entry is something tablets are not great at. That leads down the point and click route which is a direction we wouldn’t want to go.
We didn’t even attempt sophisticated parsing. we only had 72 hours and none of the parsers people laud were coded in that 72 hours. I’m sure we could do the parsing if we had the inclination, and in the modern world the whole problem is made a bit easier by masses of memory. Just throw a dictionary at the problem many times
As well as parsing, early enhancements would probably have included:
visible smart help and inventory lists
compass-rose style exit indicator
2-way conversational NPCs
save-game
multiple-map lobby
debug the overlapping text in some situations (only draw text from current room)
text on-screen time can be specified at location/object level instead of global variable
certain tricks to improve performance
Improved command standardisation
better fonts (currently depends on browser)
Better indentation for faux-programming mode (we wasted a lot of time on that in the comp and ditched it due to time)
Possibly go down the MUDS route but haven’t thought that through.
Since we are not developing it further there’s no harm in sharing some of the existing functionality which may be less obvious to people who haven’t played it all-through or delved into the code. I’m sure that there is nothing unique in here but just in case it spurs someone to improve some other engine etc:
Events triggered on X instance of visiting a specific location. E.g. the Baron only arrives on the second time you visit a certain location
Usable objects drawn on map (e.g. the various boats) and treated much like a location
Commands specified both globally and location-specific
running a certain command at a specific location runs a scripted once-only event dialogue/image (e.g. opening the balloon shed roof)
…which can then ‘teleport’ the player to another location
…which can reveal the whole map
…which can unlock specified locations (e.g. the long grass)
…which can unlock specified objects (e.g. the matches can only be seen/picked up after examining the fireplace)
…which can unlock specified results of commands (e.g. lighting the lighthouse lantern has different impacts depending on other actions you have taken)
…which can remove certain constraints (e.g. the octopus blocking the stairs)
Basic non-player characters (NPCs)
…which follow you and/or move randomly
…which are scripted with both specific interactions and filler lines (randomly applied)
Running certain commands changes objects in inventory (e.g. combining two objects makes a diving helmet)
Multiple ways to solve the quest-puzzle
Data input form, e.g. choosing page number of Moby Dick
I’m sorry to hear that; I do think that it would have been neat to see some games with this sort of graphic/text display model out there in the world. And sorry, I was indeed thinking of a button/hyperlink model for the play on tablets. I don’t think it would be a bad model, but it might difficult to implement, since people would want to be able to interact with both text and graphics… (Might be fun too, though!)
I’m not sure the parsing problem is that easy, but you would certainly have a few open-source parsers to look at if you were considering extending it. As Zarf said, building an IF authoring platform has historically taken a long time! (And sorry, I did assume from the general tack of the discussion that maybe you weren’t as interested in the parsing as in this new display model you developed…)
Hopefully someone already working on an engine will pick up on the idea of some sort of map-centric illustrated mode. Enthusiasm for continuing with this genre is considerably less with other members of the team, and given the likely player count I cannot really blame them. There was one other text adventure as part of the Ludum Dare contest, so that’s 2/1402 entries.
Shades of 
