Hello, this is my post on this board and I’m still fairly new to Inform 7 development, so please forgive me if this is too obvious or in the wrong sub-forum.
I am aware that there are many extensions for I7, but these (by design) seem very narrow in scope, and modular. This makes sense to me, as this lets them work in many projects without many preconceived notions.
But is there a general, one-size-fits-most, generic starter engine for basic Zork/Wishbringer (traditional adventures) style games? I mean, I’ve looked at the published source code for some Emily Short games, and the source for Bronze is pretty close to what I mean, but it’s not particularly “developed” (it’s well done, but not very extremely thorough), if you can see what I mean. And it’s already a game, so it has its own room descriptions, etc.
Is there anyone that has published or is working on such a thing? As I’ve been developing my own game engine, I can’t help but think that I’m reinventing the wheel.
Is developing and publishing my own open source engine a silly idea? Anyone have any experience or stories?
Realize that when you’re looking at source code, that a lot of the stuff Infocom did is already in the Standard Rules (the world-model Inform uses; basically an “extension” that makes doors and rooms and objects and supporters work) and will work out of the box. You won’t see it in the source code because basic world-modeling is built in, and easily replaced with your own more specific model if you wish.
I don’t have this on authority, but I would venture that Graham Nelson’s focus with Inform was to put tools into authors’ hands specifically to create Infocom-esque games. From the scoring, to the death messages, to many default responses, you pretty much have Infocom Construction Set in your hands already. With enough imagination and time you could probably replicate Zork or Wishbringer completely in I7. There were a few Infocom games that did weirder things, (Beyond Zork, Zork Zero) that might take some special tweaking. For example, there’s an existing “Trinity Inventory” extension. I would even say Inform 7 out-Infocoms Infocom, and it boggles the mind to imagine if some of the original Implementors had a natural language tool like this. And for the Beyond Zork style graphical stuff, there are modules such as Glimmr and Vorple.
If you don’t care for Inform, you could also try TADS. The code is not so friendly for a human reader, but many Infocom style games have been accomplished in it.
You could always try to make your own development tools and engine, but unless you have a very specific angle that either makes coding easier (such as Quest), or creates games that do something totally new (see the Texture prototype, or Undum), it might be a whole lot of effort for very little result since Inform already exists. Inform also has a comparatively large user-base, so getting your questions about learning it and doing all sorts of neat things is much easier than with some more obscure tools.
I think you misunderstood where I was going with this.
I’m not looking for something to replace Inform 7. I agree that Inform 7 is capable of replicating Zork or Wishbringer.
What I wanted to do was to pre-create common things that are not in Inform 7 out-of-the-box. Simple things like window behavior don’t already exist. I was looking to create a template, if you want to call it that, of an adventure game framework that is more than just the very rudimentary “take” and “look” that are build into Inform 7.
For example, “drink” is an action, but it doesn’t do anything useful. Eat works, because things already have an edible property, but the drinkable property doesn’t exist. Container size doesn’t exist as a concept aside from carrying capacity, etc.
Not being able to put a very large object into a very small container seems like a very basic thing that almost all adventure games would want to implement. I’m looking to create an engine built for Inform 7 that does all these things, so all the basic things work right away, and people can just jump straight into room/item descriptions, etc.
Maybe everyone has a different approach to writing games, and so some would view this as “too tailored” to work. But to me, it seems that most of these game behave very similarly. So… has anyone attempted it? Or am I just a naive dreamer?
For drinking and liquid handling there is “Dishes” and “Measured Liquid” by Emily Short.
For giving things a bulk that prevents putting a bowling ball inside a matchbox, there’s “Bulk Limiter” by Eric Eve.
For making multiple kitchens and bathrooms “Modern Conveniences” by Emily again.
And yes, as you say, if you make windows work a certain way, someone might find it limiting and want to work these things out on their own. As a general rule, extensions try not to do too much outside of making a concept work while still being flexible. Many people will create stuff on their own, but for really fiddly stuff like measured liquid, or “Computers” or “Plugs and Sockets”…these extensions exist. You should definitely consider creating new extensions if you find yourself always using certain assemblies or have solutions for things.
For example, I have my own extension for movable doors that I haven’t made public outside my own circle. Definitely consider creating these types of extensions and submitting them if you think they would make people’s lives easier.
As HanonO indicated, one major problem with an extension is that people often want to work these things out on their own.
Another problem with an extension that does “everything” is that most people won’t need everything. Being able to pick and choose what you want from a menu of extensions ensures that you won’t bloat your game unnecessarily.
I’d say that you should be looking at the examples in the I7 manual, not the extensions. At this stage.
Extensions tend to be solutions to complicated problems – problems sufficiently complex that they take more than a couple of lines of code. The things you’re talking about aren’t that complicated.
This turns out not to be the case.
That is: it may not come up at all. Or, it might be that a game only has one large object, so you can handle the restriction easily. (“Check inserting the gold sarcophagus into a container: …”) Or, it might be that a game has only one small container – again, you just handle it in one line. (“Check inserting something into the matchbox when the noun is not a match: …”)
Perhaps your game gets more stuff, and now it’s worth expanding the model to say “A thing can be small or large,” with a check rule to prevent putting large things into a small container. This is still easier to write yourself than to build into the standard library, or even an extension.
The Bulk Limiter extension is a step past this: it lets you assign a numerical size to objects, and limits the total bulk of a container’s contents. This is more than a couple of lines of code. (It’s about 40.) So it’s good to have available as a module. But you wouldn’t want that built into the standard library – it’s way too bulky, no pun intended, for most games. (If the Inform manual started out telling authors, “You have to pick a numeric size value for every object,” that would be crap.)
It’s not so much that I need these things for myself. I’ve been coding all these things for my own use, I just thought it was weird that all these things that seem entirely elementary and necessary for a passable game world weren’t bundled together.
Some generic routines to handle some things like “look at floor” or “look at room” seems like it would apply to 90% of Infocom type games, but I guess there’s no demand for an basic engine that implements these things.
I guess maybe text adventures have gotten more avant-garde and unorthodox.
Early version of Inform (I’m talking Inform 5 here) had a generic response to “look at floor” (“You see nothing special about the floor.”) This wasn’t very satisfactory in most games, and it was hard to customize, so it got taken out. Again, a system where every room has a customizable floor object is possible, but probably too heavyweight to standardize.
“Look at room” is a marginal case. It is true that “look at kitchen” is a natural thing to type in the Kitchen, if you’re not petrified by old-school IF standards. (Which, to be clear, I am.) It would make some sense for the standard library to support that. My guess is that it hasn’t happened because – ironically – it would be too large a change for old-school Inform users to cope with. (The Inform default is that rooms are not in scope – they cannot be referred to at all unless the game is specifically written that way.)
On the other hand, “look at room” is not so justifiable. The idea that every game area is a “room” is really adventure jargon, not something that most players should be expected to know. (It’s hardwired into the compiler for historic reasons, but the compiler shouldn’t push that assumption onto players.) If I were implementing this, I’d have library behavior for looking at rooms (and putting things in rooms, etc) but I’d have rooms default to being nameless. An author would have to specify that “room” was part of the name.
Also, you want to think about the overall tone of the game. Every implemented object is an invitation for the player to experiment. Boilerplate objects like “the floor” or “the room” in every location can be distractions from the stuff that the author wants the player to interact with. (Same goes for player clothing.) They are, to a degree, red herrings in the game design. That’s one reason (though not an absolute justification) for the library omitting them.
I think what’s happened is that the authoring aspect has taken a more significant role in IF. We’re less interested in generic contexts and more interested in wholly considered worlds that hide the generics.
Maybe you call that avant-garde, but I would just say the IF authoring community has evolved and has somewhat higher expectations than “look at floor” offers.
Yeah, that’s in the spirit of what I’m talking about.
“Don’t perform implicit actions for doomed tasks” and “Implement Use verb for common actions” are exactly the kind of things I’d just automatically expect any IF I played to have.
Anyone I’ve ever shown a text game to (without any preconceived notions) has tried “use toaster”, etc. So I was looking for something like Player Experience Upgrade but more extensive, but I’m getting the impression that modularity is the order of the day. Which I kind of expect, and it makes sense in the long term, but I thought there might be some “quick set” extension for IF authors that are more into the creative writing than the coding.
I guess I’m over-thinking the need for such a thing.
Okay. I’m all for evolution, yet if I’m controlling an avatar in a log cabin and I ask him “look at floor” and I get “That’s nothing you can see.” as a response, then I find would find that breaks the immersion. I’d expect something at least like, “It’s solid wood.”
How is everyone handling matching these higher expectations with boilerplate objects?
As someone hinted towards earlier, eliminating room names from being printed seems like a good start. But how many people are doing that?
I’m pretty used to mid-'80s IF conventions, so I guess I just assume games are going to be able to cope with either ground or floor, since 99.9% of the time there will be one or the other.
I was impressed with how Emily Short’s Bronze seemed to handle a lot of that generic stuff, but I’m sure there’s more than one way to skin a cat.
I agree that it shouldn’t be bundled into Inform, but as part of a quick start extension, then yeah, I absolutely would expect every object to have a size. To me, Bulk Limiter seems like a no-brainer. Surely 9 out of 10 adventures are going to have a treasure chest or a bag that wouldn’t fit a chainsaw, an apple, 12 gold coins, and a coffee (hot).
I suppose I should just make a list of all the currently available extensions that address these type of issues, and offer them as a recommendation rather than trying to replicate them as an all-in-one package.
My point was that we expect that if you have notable floors, then you should note them. If your game does not have notable floors, then it’s “okay” to have a generic answer. But to be considered a “better” game, handling all the nit-picky details is an author responsibility. Not the game engine library or even its extensions.
More like three out of five. But for the majority of those, “realistic” carrying limits like that aren’t immersive realism – they’re annoying pedantry. Players will complain, if they notice at all.
(BTW, you’re shifting the goalposts a bit there. Spillable hot coffee would be a custom behavior in any system.)
The coffee temperature didn’t have anything to do with my point. It was just a little joke about how IF tends to describe items.
I guess we just disagree on the necessity or desirability of such realism. Either way, I think it’s been established that most authors either prefer the modularity of single extensions or the purity of coding things themselves. Perhaps one-size-fits-all really is one-size-fits-none, as they say. There’s no interest in a generic framework as I conceive of it. I think that answers my initial question.
“Also, you want to think about the overall tone of the game. Every implemented object is an invitation for the player to experiment. Boilerplate objects like “the floor” or “the room” in every location can be distractions from the stuff that the author wants the player to interact with. (Same goes for player clothing.) They are, to a degree, red herrings in the game design. That’s one reason (though not an absolute justification) for the library omitting them.”
This is game design for experienced players and for the convenience of the author. But we know that players can be unpredictable, especially newbies. I think we need to address these red herrings to improve parser accessibility. New players want to look at things like clothing and windows and the floor and the sky even when they are not important or even mentioned in the room description. Not having a reasonable reply is, justifiably, discouraging. I find it very frustrating as an author spending most of my time redirecting actions, creating unnecessary new actions, adding defaults, and creating things, all to compensate for players that try unimportant things. I can’t help but think this is counterproductive, and surely a game engine should do its best to alleviate this. What an author thinks is nit-picky isn’t necessarily so to a new player,and isn’t that the audience we want to try to attract?
I think you’re probably right that there’s not a great deal of interest. For the record, though, TADS 3 does in fact bundle a lot of generic elements into the basic game library – including room parts. The I7 Bulk Limiter extension is, I believe, Eric Eve’s adaptation of a system that is already in the T3 standard library. Objects are given a default size of 1 and containers are given a default capacity of 1000 or something like that, so the feature remains invisible to the author and player unless the author chooses to make use of it.
Graham Nelson has chosen to provide more of a basic meat-and-potatoes library for I7, with the idea that 3rd parties would extend the system in numerous ways. Whether Nelson’s approach is better than Mike Roberts’s is up to each author to decide for him/herself. I7 is certainly a lot more popular than T3, which may hint at an answer. It has to be said, getting started in I7 is easier than getting started in T3, in part because you don’t have all those features to get confused or distracted by.
I expect (and find that players expect) first-level and possibly second-level implementation of nouns mentioned in the room descriptions, but nothing more. If the description looks like this:
…then players will expect implementation for the lights, floor, walls, door, and odor. (The shadows are optional but classy.)
If the description looks instead like this:
…then players will expect implementation for the lights, ceiling, doors, call button, and floor indicator - but not the floor. (In fact, implementing the floor would cause conflict with “floor indicator”, since there wouldn’t be a ready way to disambiguate “yes I mean the floor” without giving the floor a bit more description.)