Hi all and thanks to everyone who contributes to this forum. Until recently, I’d had no contact with interactive fiction since playing Level 9 games on the Atari 800XL in the 1980s. Finding it again, and discovering Inform is magical.
Anyway, in getting to grips with I7 I’m wondering about how to organise the various elements that come together to make a story. Is there a recognised optimum order for setting down, actions, defining rules, describing player information and object and so on. I think I’ve discovered that defining variables before recording details of the objects they relate to is better, but otherwise is there an order that makes the operation more efficient or helps with design.
I’ve had a look at a couple of published games where the author was generous enough to publish the source code (which was a revelation). If this is not a stupid noob question, any thoughts or guidance would be appreciated.
The text Creating Interactive Fiction With Inform 7 by Aaron Reed provides excellent guidance on source code organization. Unfortunately it is out of print. You may be able to find used copies from various sources.
Every once and awhile it is available on the online big box store.
Thanks Wade. The first attempt was just a very short game to play with my Granddaughter which pretty much followed the narrative. I was too naïve even to understand that rules were not room specific. I’ve been through my next project and sorted things roughly into - out of game / mechanics (actions and rules) / People / places / objects. Feel like I’ve moved on massively with the help from this thread.
I’m not sure that I am adding anything here that hasn’t already been said, but I tend to prefer to define all my created actions, synonyms for actions, rules for action responses (particularly rules that will apply throughout the piece), verbs, and kinds of things before the ‘When play begins’ rule or initial location. I put any rule that will apply throughout the piece in that area, putting anything applying to actions in alphabetical order. That way, when I make a change to any of them, I don’t have to hunt a specific rule or line down, I know where it is. Though the Search function does quite well, this way I can also actually scroll up or down and easily find what I need. And beneath each room description, I define each object, one by one, implementing it by going down the actions list in the IDE, deciding which actions will reasonably apply to it. That way I make sure that each object in the piece is as fully implemented as I can make it.
I think it’s really a matter of your preferences, how you organize your code. The compiler is just going to translate whatever you have into computer language, no matter how you slice it. As was suggested above, it’s really about what works best in your mind.
I’m currently busy overthinking this. I can’t decide where objects should be defined.
In the location where they are at the start of the game. Problem: the logic around how the object affects gameplay ends up being away from the object definition.
In the location where they’re expected to be used. Problem: they might be used in multiple locations.
In a completely different part of the code, as a library of objects.
I think that right now I’m leaning towards #2, but would welcome suggestions.
I start with 1 because when I’m writing the game, I write the object where it is.
If an object ends up having a ton of code related to it related to something/somewhere else, I may end up copy-pasting that code to the place it gets used. I tend to leave the object’s core definition lines at the location it’s found.
Moving the definition can have real effects depending on how you’re using section headings, defining the objects ( are any privately-named? ) or whether you’re using the ‘Use unabbreviated object names’ option. If you have similarly-named objects, it can change which object is being referred to in your own programming, within a section, if you use an abbrevation for something. A line of code referring to the object could end up actually creating it if it now appears earlier than the object, giving it the wrong namedness (improper-named vs proper, that kind of thing.) One more point – when testing, you probably tested with the object definition where you first put it. So that’s the case that was tested, and you probably verified a bunch of stuff with the source in that form.
This is a fairly full catalogue of the dangers, but I don’t want to overstate them. Most of the time, you can move things around and all will be fine. But moments of rearrangement can be a subtle source of bugs creeping in, so if you move a lot of things, make sure to back up first and test thoroughly before proceeding.
The only really good reason to use 3. In a completely different part of the code, as a library of objects. is if it’s necessary for technical programming reasons (e.g. you break your game up into multiple files. Now the only way they can all reference all objects is if the objects are centralised.) Otherwise it just makes code harder to read. As Draconis is always saying, you read your code a lot more than you write it. Make sure it’s easy for you to read after the fact.
Another pro of leaving things mostly ‘where’ you thought of them is it might also tend to be a natural reflection of your thought process while making the game, allowing you to retrace your steps or find things easily.
I’m really grateful for your help.