Approximately one month ago I started working on what I will call from now on “Weaver”, a text adventure project in Inform 7. As it looks like it will take a bit longer than anticipated to finish the game I decided to bring into being a development log on it. I won’t discuss any specifics, but will talk more about development rationales, design features or simply ideas.
While I do have clear ideas about the structure of the whole game, I do not have a good name for it yet. Barring premature decisions, I have decided to go with a codename: “Weaver”. I expect the name to be the last thing I will decide on, since I cannot know how development and writing is going to turn out. As I have seen the past month, a lot of initial ideas have changed into something else or have been slightly altered. I cannot foresee how much of the structure I have in mind now is going to change, so I feel it is best to leave any naming option open until the last minute.
In the first month of writing Weaver, I implemented most of the mechanics that are going to be used in the first third of the game. I focused less on the actual writing aspect (room and item descriptions, transitions, etc.) and more on the aspect of fleshing out the things you as a player can do. I want to make sure I have a rigid base I can build my story upon.
Some of the mechanics are rooted in reality, which makes it hard to find a compromise between portraying reality in a game and the limitations of game design and puzzles. As such a player might readily accept a never-ending maze (as this idea is clearly rooted in a more fictional universe), but will most certainly have problems or some sort of disconnect when confronted with mechanics applicable to the real world - like physics, mathematics or chemistry. Say you are modelling a world in which gravity is halved. You have to be very careful to establish that fact. Telling outright would be boring, so you need certain subtle remarks. Players expect being put in a world close to their reality, so there will be a disconnect at first.
An even bigger problem is designing a space that is supposed to feel like reality but is actually imagined. A player’s expectations might be subverted in such a way that they stop playing altogether. It is a very fine line between actual reality and imagined reality; if one walks once into the uncanny valley one might never return.
I took a different approach this time to learning a language. Usually I prototype a lot, ending up with about ten different smaller projects. This time I only wrote one prototype and spent the rest working through the documentation. I realised some way into developing this game that I had to look up specific things again in order to use them. I’m not sure whether this is caused by the relatively high volume of the documentation (and forgetting things introduced earlier) or a core aspect of my way of learning.
It is also important to mention that prototyping stories is inherently harder than prototyping pure code. Implementing the Fibonacci sequence will teach you language basics every time. As a domain-specific language, this does not work at all for Inform 7. You will have to design actual puzzles and write actual stories. This is - of course - not a detriment but merely a distinction.
However, I sometimes had the feeling that the documentation did not do a great job of pointing out specific features (and exceptions) of the language. For example, there seems to be a weird way of treating kinds of values as opposed to the way kinds of things are being handled. The former needs special identifiers in certain rules and definitions.
You end up writing Announcing something is an activity on sizes for an activity definition, but then cannot use the same “something” identifier in the actual rules. It ends up being Rule for announcing a size (as opposed to Rule for announcing something). I do get the difference between a kind of thing and a kind of value, but it is confusing to use “something” for the activity definition and not for the actual governing rule.
In month two I shall focus more on fleshing out the text of the game. I expect to finish the room, item and scenery descriptions for every room in the first third of the game. Refining the puzzles and gameplay shall be the goal of month three.