Rapid Prototyping by B David Paulsen


Chapter 1 - Acknowledgements and notes

The extension relies on the "Object Kinds" extension by Brady Garvin. A useful and versatile extension, Object Kinds can unfortunately not be found in the Public Library. Instead, you need to download it from its GitHub page, via the address

https://github.com/i7/extensions/blob/master/Brady%20Garvin/Object%20Kinds.i7x

Thanks to Alice Grove and Matt Wighdahl, who provided sanity check, invaluable feedback and much-needed encouragement.

Chapter 2 - The reason for this extension

While Inform 7 is a very good system for creating IF, it's still a compiled language. A natural consequence of that is its lengthy iteration cycle: coding is followed by compilation (often aborted by the discovery of a bug), then testing by reaching a game state, only to discover something is lacking, at which point we go back and do it all over again. This, mind you, is in the ideal bug-free case. Every step of this sequence carries the attendant risk of getting side-tracked, losing steam, or tiring an author by constantly switching between tasks. Rapid Prototyping is an attempt to shorten the loop by giving feedback in a manner reminiscent of REPL type languages like Python.

The extension only provides basic building functionality. Nontrivial behavior such as rules and activities are well beyond its scope.

Using Rapid Prototyping follows a basic workflow. First, you keep the dynamically generated source code under its separate header. Next, you compile a minimal game. While walking through the game, you add and modify the world as needed, until you hit a point where the extension's facilities are inadequate (see above for examples). At that point, you "view source", copy the generated code, and paste it under the prepared header. After having added any complex functionality under its own header, you recompile, and the cycle starts again.

Chapter 3 - How to use this extension

Instead of creating the game and then testing it, Rapid Prototyping aims for a more natural process of designing an IF world: you compile an empty game, then add rooms, things and various other bits and pieces as you see fit. These changes to the game world appear at run-time, and can be interacted with seamlessly. Once you are satisfied with how the world behaves, the "view source" command produces source code that you can then use for refining the next iteration. Finally, by adding the flag "finally" to "view source", you can output source code without the metainformation used internally by the extension.

Note that all examples here use testing correction, which is only needed when using the TEST command to demonstrate functionality.

Example: * Simple test case -- Creating a small room and filling it with items.

"Simple test case"

Include Rapid Prototyping by B David Paulsen.
Use testing correction.

There is a room.

test me with "test surroundings/test sofa/look/view code".
test surroundings with "name location Your Home/describe location/Your home is as it ever was: neat, cozy, and in dire need of cleaning./Well, all right, some would say it's a filthy hovel. But they'd be wrong./".
test sofa with "add container/enterable container/fix container/describe container/You've always had a soft spot for this leather sofa, patches and all.//appearance container Your sofa stands here invitingly./name container sofa that's seen better days|sofa/add thing/name thing patch/fuse patch to sofa".