A Night In The Strong

This year’s combination of NarraScope 2024 and The Strong National Museum of Play was a perfect storm. On my long drive home I thought, “What would it be like to set an IF game in this location?”

I’m in the middle of pre-production on my second Inform 7 game so it would be foolhardy of me to start a 3rd game alone when my 2nd game is barely started.

But what about an IF game constructed along the lines of Cragne Manor, where individual authors constructed individual rooms or areas which were then assembled into the final game? I could certainly spare some time to do some meta-design for "A Night In The Strong (just a working title) and coordinate the work of the individual authors, much like Jenni Polodna and Ryan Veeder did for Cragne Manor.

Would you be interested in playing a game set in this location?

  • Yes
  • No
0 voters

Would you be interested in collaborating on a game set in this location, writing a room or area of your choice?

  • Yes
  • No
0 voters

If you were a collaborator, what authoring tool would you prefer to use?

  • Inform 7
  • Twine
  • Other
0 voters

Thoughts? Suggestions? Ideas? Post below or DM me directly, whatever you prefer.

2 Likes

I’d be delighted to participate in a game like this! It sounds like a great idea. I have experience in Inform 7 and Harlowe Twine, but my area of expertise is something nobody would know, so I’m happy to choose any of those two.

1 Like

Note that (and you may know this already) the different Twine story formats (Harlowe, SugarCube, etc.) are very, very different and cannot be combined, so if you go with Twine, make sure to specify which is being used.

3 Likes

For Cragne Manor, everyone-makes-a-room-in-a-mansion/village worked quite well, structurally. Everyone-make-a-room-in-a-museum has a lot of promise too. It’s a flexible and self-contained challenge for participants and, project-wide, can go big or small as required.

1 Like

Another possibility for platform: Get the framework code from Moondrop Isle! (Moondrop Isle)

This is a system that allows different segments of a game to be completely separate programs, but still share inventory and other data through Javscript. One of the strengths of this system is that it allows authors to write their segments in whatever they want, as long as it can access Javascript – most of Moondrop Isle was written in Inform 7, this was ultimately the choice of the individual authors, and there are a couple of exceptions. None of the Moondrop authors chose to write their segments in Twine, but it seems like it wouldn’t be difficult to incorporate Twine segments into such a system, and if you did, different Twine segments could be done in different Twine formats.

3 Likes

@Afterward @nilsf - Would it be possible to get a look at the Moondrop Isle framework code that was used to create the game?

I would be very pleased to share this, but first I want to render it in an appropriately generalized format (and pull out spoilers) and it’ll be a little while before I get a chance to do that.

The gist is this: Bits of game state are saved as tokens in the browser’s localStorage. This happens automatically, so e.g. the key crystalSwordLocation gets set with a value of inventory as soon as you pick up the crystal sword. Whenever you load one of the sub-games, the relevant tokens are read and used to assemble the correct state.

A few properties arise from treating persistence this way:

  • It is helpful/necessary to disable standard save/restore functions that naturally don’t sync with higher-level inter-project state tracking.
  • It is necessary/helpful to disable UNDO.
  • Unlike an Inform game where a save file preserves the entire game state, this system only saves the states you explicitly tell it to save.

These facts, especially the third one, have a considerable impact on the design process. Certain ideas from these old blog posts about a less sophisticated autosaving method apply here as well. I shouldn’t get into too much detail, since I’m supposed to be giving you the gist.

If I don’t come back with a version of the framework for you to look at within what you feel is a reasonable time frame, please bother me about it!

4 Likes

@Afterward - Sounds good. I certainly understand the desire to clean things up and appreciate the additional high-level architecture info. I’ll be happy to continue documenting whatever you give me as long as you give me the basics and I can ask questions.

I don’t know what a reasonable time frame is given other work that you might be doing. Given my current commitments I probably won’t be able to give Strong the meta-design attention it needs until the end of summer (Also, I’m still hoping more people take the surveys so we could get to Cragne Manor levels :crossed_fingers:).

Why don’t we do this: You come up with a date within the next 2-3 months that works with your schedule. DM it to me (or post it here if you want community pressure :wink: ) and if I don’t hear anything by that date I will DM you directly.

Sound good?

Hey look I had some spare time!

Internally we referred to the Inform extension as the “framework,” but the real framework that made the extension (and everything else) work was the JavaScript that @nilsf put together. I took some stuff out of here for spoiler and readability reasons, but also I don’t 100% understand everything going on here, so, don’t treat this as something that should actually work out of the box:

moondrop js by nils.txt (8.8 KB)

I’m much more qualified to discuss the Inform 7 level, so I added a bunch of comments to this version of the framework extension. I also took a bunch of stuff out for spoiler and readability reasons, so don’t treat it as something that should actually work:

moondrop framework by various.txt (25.7 KB)

With basically the entire Moondrop Isle team working in Inform, we all ended up putting a lot of work into improving this extension and figuring out how to use it effectively. A bunch of problems have been solved for the next group of people that puts a game like this together! But I want to be clear that the JavaScript layer, again entirely thanks to @nilsf, makes it possible for these games to link up to Twine (or anything else that can execute JS)—we just haven’t figured out the specifics of how that’s done yet.

3 Likes

I think Mark Marino’s Automatic Fortune Teller is exactly how you’d do it in Twine, just wrapping it in whatever command to run JS code? So for SugarCube:

  • <<run parent.moondrop.goto("arcade.lobby")>> - jump from this game (zone) to the “lobby” room in the “arcade” zone.
  • <<if parent.moondrop.read("COMMON", "shovelLocation")>> then the player has taken it: the value might be “inventory” or it might be another location (maybe the player put it in the backpack or other container)…
  • <<run parent.moondrop.write("COMMON", "shovelLocation", "inventory")>> - move the shovel to the player’s inventory.

@Afterward - Thanks so much for taking the time to do this. Having never dealt with extensions before beyond the usual Includes I figured the first thing I should do is put the TXT file into an Extension project, which I did.

Once I did that the next step was to figure out how to test, debug, etc. an extension. I was stymied by Inform 6M62 but after some forum searching and reading (link link, link) I found out that you have to use Inform 10.1.2 for extension work since 6M62 broke at some point in the past (I’m running things on a Macintosh). That will work out since I plan to move 10.1.12 at some point.

Inform 10.1.12 (v1.82.3)

Inform 6M62 (v1.68.1)

After I’ve had some time to fool around with the code I’ll probably create a post in Technical Development > Inform Extensions that can be used for future questions and discussion about this extension.

Thanks again.

1 Like