Trying to outTwine myself...

Inspired by Merk’s fantastically impressive (and super-fun!) Hallowmoor ([url]https://intfiction.org/t/hallowmoor-official-announcement/5939/1]), I’m hoping I can do something at least a tenth as complex. The first thing I’m trying to figure out is how to divide my game area into three panes. The main game text window would be on the left and roughly 75% of the window’s width, the other two would be on the right, one above the other, and contain, for example, status and inventory information (for now, I just want to get the panes in place so I can play around with them).

The source for Hallowmoor (also kindly linked in the above thread) clearly holds the information I need, I’m just not smart enough to extrapolate it from all the other crazy impressive stuff in there. Is there a tutorial on how to do this somewhere? If not, there needs to be.

This is actually one of the big drawbacks of Twine. The tool only really allows you to edit two distinct areas of the game: the StoryTitle area (the sidebar div), and the Passages area. It doesn’t let you create separate panes for, say, inventory or flavor text. If you don’t know much CSS/HTML then I recommend sticking with two panes - not three.

I’ve checked out Hallowmoor’s source, and I don’t think he created the panes within the twine tool. The html looks too custom - I suspect he generated the html file, and then went in and edited the html itself in order to get the separate panes, or created some custom javascript macros, or maybe modified the SugerCane theme itself (I’ve never tried that).

In order to have separate panes within the tool, I’ve always hijacked the StoryTitle and used it to display in-game information. You can put variables in the StoryTitle passage, but since that area doesn’t refresh each time you click a link you also need to add <> to your passages every time you want it to update.

You could feasible create two boxes out of the StoryTitle pane - I haven’t tried it yet, and you’d need to know quite a bit of CSS in order to get it to work well with different sized windows and different browsers. I’ve done something kind of similar by putting information inside a blockquote or a table, and then styled the blockquote/table with CSS to get the desired look.

@mostly useless
Sorry – I somehow missed your post originally.

Create a passage that contains the HTML for the additional two panels (or two passages - whatever you want to do). For example, look at Hallowmoor’s “StatusBar” and “Map” passages. Also, look at any “class=” and “style=” definitions, and refer to the “Styles” passage for what it’s doing. You can put percentage heights on your divs, and even anchor them where you want (set “right” and “top” in CSS for the top panel, and “right” and “bottom” for the bottom panel). You’ll also have to set CSS on the “#passages” CSS so that it doesn’t extend too far to the right. Finally, you’ll probably want to hide the sidebar.

Now, once you’ve got the passages that create the HTML for your two extra divs (panes), you need to make sure they’re called just once. The best place I found for that is in the “StoryMenu” passage. You can check mine, and see where I display those passages at the end of it. It doesn’t matter if you really add sidebar links at all. You can just put those <> macros there.

What you’re doing is creating additional “zones” on the screen, that you can then update in Javascript.

Updating is pretty easy. Let’s say you give your div an ID of “Inventory”. In Javascript, you’d do this:

$(“Inventory”).innerHTML = “Whatever”. The “Whatever” can be anything you want. For the purposes of an actual inventory list, I would recommend creating it as a normal Twine variable which you set before calling your update macro. You can see how I do this in the “Inventory” passage. However, I’m just showing the results at a passage. For your purpose, instead of doing this at the end:

<<print $inventory>>

You’d call a custom macro:

<>

“updateInventory” would be a Macro in Javascript (for example, look for “macros[‘showstatus’]” at the top of my “JavaScript” passage). A simple macro to update your already-existing Inventory div would look something like this:

macros['updateInventory'] = { handler: function (place, name, params) { $("inventoryDiv").innerHTML = state.history[0].variables["inventory"]; } };

Not much to it. If you’re having trouble, I could probably whip up a shell that does your three windows, and includes the macros for updating your two additional frames. Although if you can figure it out, you’ll probably have more fun. :slight_smile:

@Liz England

The middle thing. Custom Javascript macros, and custom HTML. But all of it’s done within the Twine engine. There isn’t any editing of the HTML. Well, there was at first, but just because I wanted the “share” links to open in a new window, which Sugarcane doesn’t do. Ultimately I did make that change in the Sugarcane template so I wouldn’t have to keep editing my HTML after building, but everything else is just done with CSS, HTML, and JavaScript stuffed into Twine passages where needed.

I’m working on a new game in Twine, and I’m finding it easier to build some of the stuff I did in each passage into JavaScript code directly. For example, in Hallowmoor I call an “UpdateStatus” macro pretty much in every passage of the game. I’m moving that into the history “display” code so that it happens automatically every time a new passage is shown. I’m also setting the “main” passage title (for “going back” after looking at inventory, etc) in that same routine, so it doesn’t have to be manually set in every passage.

FYI, some of the stuff you did in Hallowmoor is provided in Sugarcube:

motoslave.net/sugarcube/

…this includes management of saved games and getting rid of the URL bits. It also has a nicer design out of the box than Sugarcane.

Haven’t spent much time with it or Twine yet, though…

It seems like Twine has a wealth of resources out there, but it’s all fragmented. I never knew about Sugarcube. (Update) And kind of too late to start over on my WIP, since there appears to be a number of incompatibilities. Still, good to know that it exists!

I wonder why it’s still based on TiddlyWiki rather than being extracted. Does the wiki really make everything simpler, or does it complicate other things?