Mikayla’s Phone

So this “work” was conceived, written, and designed by my sixteen year old daughter Angeline. I implemented the user interface.

Angie had a ton of poetry and notes from middle school, a lot of which is pretty typical teenage angst. Some of it is more than that. A little over a year ago, I recognized that the anxiety was more than the usual teenage stuff and offered to introduce her to a therapist. She agreed and has been going regularly since. She’ll tell you it has immensely improved her life and as her father I can say it has immensely improved her disposition. She will always have anxiety (and depression) issues, but she’s building coping mechanisms, understanding triggers, and learning that she’s a pretty amazing person regardless.

She came to me in spring and said she wanted to learn how to make a video game. I asked what kind and she told me about her writing and the basic idea of a lost phone of a seemingly dead teenage girl. I told her she needed to outline everything first. She did that. I showed her Twine and explained how to put everything into a tree of choices. She did that. I did try to adapt Twine to a mobile phone look and feel, but I felt I’d need to learn way too much about Twine. So I just used basic html and jquery.

As we were putting this together, we looked at ways to put it in front of people. We thought about submitting it to SubQ, but I suggested the IFComp and after thinking about it, she agreed it was the best way to go.

We completed the game (it has quite a few rough edges) with 6 minutes to spare.

When I hit the Upload button, you could see the relief in her eyes, almost as if a weight of the past had been lifted. She really had a bad time in middle school. She could finally (mostly) let it go.

We were not expecting anything from the voters, but the reviews we’ve read are accurate and appreciated. We both laughed out loud at “wads of morose poetry” in one review. She read it and said, “He’s not wrong.”

There’s no doubt we could have cleaned up the interactivity quite a bit, possibly added some humor, and made it more of a game. But that was not the goal. It was meant to relay what it’s like, from a real person’s perspective, to be in middle school, to be a young girl, and suffer from anxiety and probably have some spectrum social issues.

Maybe someone will “play” it and realize they’re not alone and that seeking and investing in therapy is a real solution with tangible benefits.

FyreVM and IFPress Status

It’s been about six months since I’ve worked on FyreVM-Web and the infrastructure for ifpress.com. After the most recent developments with Vorple and the clear interest from the community for its progress, I paused to re-evaluate where I spend my time. I think at this point I plan to spend more time on writing than on tool development. This means the status of my tools is going to remain dormant until some nebulous future date.

As everyone knows, platform development is hard and the IF community is somewhat mercurial about shared interests. I tried to enlist a couple of people in helping on the UI side of things where FyreVM is concerned and they flatly replied (paraphrased), “Why should I spend time on this when Vorple is more mature.” OR “I don’t have any extra time for this.”

So at the moment, FyreVM-Web is going to the dust-bin…until I find some future fuel for it or if it gains interest from other capable front-end developers and designers.

On to writing, IF and other things. Cheers.

Vorple and FyreVMWeb

So now that Vorple for Glulx is in beta and looking great, I asked Juhana whether it made sense for the two of us to work together to make Vorple work with fyreVMWeb. Iniatially we both thought this would be a great idea.

However it would seem that Vorple adheres to the existing glk-oriented display paradigms and that’s exactly what FyreVMWeb breaks (intentionally).

Most, if not all of the concepts in Vorple are transferable, but the implementation is likely to be wildly different underneath the covers. The one area that may have overlap is some of the I7 extenstions, but even then it would be file by file decision. More often than not, one platform would be hampered by the others requirements or capabilities.

Vorple extends to Glulx a real web development experience that is very exciting. It may make FyreVMWeb less of a target to many who just want an out of the box development experience. Even so, I still need to find a way to bring the same Vorple UI experiences to FyreVMWeb. I’m just not sure how that will happen.

For the most part, a rough beta of FyreVMWeb is functional. It is not ready for real use quite yet, but getting closer by the day. The sample is running showing the standard beta template..

FyreVM Status Line (I7 Extension)

This extension allows the author to decide which parts of the status line will be displayed. The extension doesn’t say anything about the design or location of the status line, but only which parts should be shown or hidden. The design will be handled by a component in the UI template.

This is going to be common pattern for components in fyrevm-web, as it clearly defines the content, but has no opinion about the design.

In this case, Story Addendum is a new feature of the status line and will require further definition. For now it’s just a placeholder, but my intention was to allow the author to control any parenthetical addendums, such as:

Kitchen (floating in mid-air)

The following is the current documentation from the extension, now on the fyrevm-web github repository:


---- DOCUMENTATION ----

FyreVM Status Line defines which parts of the standard status line are displayed.

These parts include:
- location name
- location addendum
- story time
- story score
- story turn

The author can show/hide any of these with the following statements:

show the location name.

hide the location name.

show the location addendum.

hide the location addendum.

show the story time.

hide the story time.

show the story score.

hide the story score.

show the story turn.

hide the story turn.

The statusline-channel will emit the details in JSON format to be handled by the UI template.

Example:
{ "showLocationName": true, "showLocationAddendum": false, "showStoryTime": true, "showStoryScore": false, "showStoryTurn": false }

This data will be contained in fyrevm.statusLineContent in the browser.

A fyrevm-web Standard Template Emerges

http://plover.net/~dave/fyrevm-web/standard/

 

After a holiday hiatus, the standard template is coming along. It’s not pretty, but the basic functionality is getting closer to my vision.

One of the tasks we completed was reorganizing the github repo so it was strictly fyrevm-web, the I7 extensions, and the eventual I7 build templates. The eventual development of ifpress will be within its own repository.

In this iteration we’re storing arrays of the main content and the commands. In the next iteration we’ll have the full complement of content displayed in the template including hints, help, and multi-session (branching) capabilities.

Then we’ll introduce multi-story housing, external saves, and mobile templates.

And then finally we’ll add a paging template to show that the same data can be used in multiple contexts.

We could still use a professional web designer to help us make this look pretty. If anyone is interested, drop me a note.

FyreVM-Web Builds

As we progress on the development of a “standard template” for fyrevm-web, you can follow the results here.

This is a simple build and deploy process via a Jenkins server. Every time we check in code to the fyrevm-web GitHub repository, Jenkins will pull the latest code, build it, and deploy it.

It’s fairly new at this point (the code and some of the basic react + semantic-ui elements), but we’re about to make huge progress.

Stay tuned!

FyreVM Installed Stories

I just finished the first draft of code that will allow users to install a fyrevm story into their browser. One of the issues that comes up is that local storage has a hard limit of 5mb. I’m looking into using IndexedDB, another browser storage mechanism, but I’m not sure if it’s reliably standard.

I hacked a copy of the loaded story from the Chrome debugger below (in JSON format). The storyFile object is an ArrayBuffer containing the ulx file and the quetzal object is the save game state for turn ‘0’.

As the user continues to play, more turn objects would be appended to ‘turnData’.

The ‘key’ is the IFID from the story itself.

Content types are one of text, json, number, or css. More can be added, but the FyreVMWeb/FyreVMMem typescript files would need to be updated to handle that content…or you’d make any new content text/json and handle any further transformation in your own code.

More coming next week!

newStory
{
    key: "69DE4C7B-CF54-42E4-A6D1-0DEE7197DB6A",
    storyFile: { },
    storyInfo: {
        debugMode: "",
        inform6Library: "6.33",
        inform7Build: "6M62",
        inform7Library: "6/12N",
        releaseNumber: "1",
        serialNumber: "161130",
        storyAuthor: "The IF Community",
        storyCreationYear: "2016",
        storyHeadline: "A basic IF demonstration using FyreVM",
        storyTitle: "Cloak of Darkness",
        strictMode: ""
    },
    turnData: [
        {    bannerContent: "Cloak of Darkness
A basic IF demonstration using FyreVM by The IF Community
Copyright © 2016
Release 1 / Serial number 161130 / Inform 7 Build 6M62 (I6 lib/v6.33 lib 6/12N )
",
             command: "",
             contentTypes: "1296124238,text,mainContent;
                                           1347571796,text,prompt;
                                           1280262990,text,locationName;
                                           1396920146,number,score;
                                           1414090053,text,time;
                                           1145389380,text,deathContent;
                                           1162757191,text,endGameContent;
                                           1414877774,number,turn;
                                           1229866575,json,storyInfo;
                                           1397641044,text,scoreNotify;
                                           1129138004,text,contentTypes;
                                           1229343044,text,ifid;
                                           1515864385,text,bannerContent;
                                           1515864386,text,prologueContent;",
             dateTime: "",
             locationName: "Foyer of the Opera House",
             mainContent: "

You are standing in a spacious hall, splendidly decorated in red and gold,
with glittering chandeliers overhead. The entrance from the street is to the
north, and there are doorways south and west.

",
             prologueContent: "Hurrying through the rainswept November night,
you're glad to see the bright lights of the Opera House. It's surprising that
there aren't more people about but, hey, what do you expect in a cheap demo
game...?

",
             prompt: ">",
            quetzal: { },
            score: 0,
            time: "540",
            turn: 1
        }
]}

FyreVM-Web Templates

The work on a standard reusable template has begun with a target of mid-December for functional completion. Depending on how it looks, I may let a designer friend play with it before releasing, but extensions and documentation will all be published as soon as it’s feature complete.

The standard template will come with several options that are driven by I7 code. Some behavior will be different than most interpreters and this includes:

  • Every turn is saved, along with turn data. This allows the story to be reloaded with history/scrollback/pages and allows the reader to jump to any historical turn and “branch” their play. If a player does page back to a previous turn and enter a different command, the previous line of story is saved as “branch 1” and stored separately from the “running branch”. The player can create as many branches as they wish. The player will be able to add/edit a description to each branch.
  • We’re using ReactJS for the templating system and all of the front-end code will be simple with clear separation of concerns. Each portion of the template will be a self-contained component controlled by the larger template.

Some of the template feature choices include:

  • Story Title Header (optional)
  • Status Bar (optional)
    • Location Name (on/off)
    • Turn (on/off)
    • Time (on/off)
    • Score (on/off)
  • Main Content (required, select one)
    • Scrolling
    • Paging
  • Command Line (required, select one)
    • Embedded
    • Static Footer
  • Menu (required)
    • Install New Story (required)
    • Save Story To File (required)
    • Start Story (required, must have installed stories or will be disabled)
    • General Help (required, provided but modifiable by author)
    • Story Help (optional, generated by I7 extension “FyreVM Story Help”)
    • Story Hints (optional, generalted by I7 extension “FyreVM Story Hints”)
    • About (optional, generated by I7 extension “FyreVM Story About”)

There are many features and options to add, such as turning off the command bar and making a choice-based selection list of links, allowing embedded directional links, embedding magic word links, embedding images, and creating more complex templates. I plan to publish a story with an alternate template and release it next year at some point, possibly for the 2017 IF Comp. Requests for features will be welcome, but I’d also encourage others to try their hand at creating their own components and templates. For anyone with basic HTML, CSS, and JavaScript knowledge, this will not be too difficult.

Ruminations on a burst of Inform 6 coding in Inform 7 times…

You may have seen my post of a very small story on intfiction.org. I spent part of my labor day weekend appeasing a festering lack of creativity by “cleaning up” some old code in Inform 6. I had a zip file of all of the story and I6 library files, along with the 1999 version of infrmw32.

I haven’t been doing a ton of Inform 7 coding lately, but enough in the last year or so that I’m mostly comfortable with its syntax and usage scenarios. In my work life I write mostly C#, so jumping back into Inform 6 was interesting. Most of the basic syntax is easily remembered, but boy those I6 idiosyncrasies are a boat load of fun. Not having static analysis of your code is really frustrating when you find things like:

Object Foo with name 'foo', counter true, has scenery;

And try to check:

Foo.counter();

That little mishap, which will compile and execute, but give you the wrong value, is awesome.

But the most glaring difference is in usability. I eventually got my testing down to quick reruns of code in WinFrotz, but having to plan through all of that, needing to manage code, debugging with print statements, it all makes Inform 7 a huge blessing. One of the reasons I even tackled this was that I had written reasonably decent code, broken into include files, with base classes. Without that, I may have not bothered.

Even so, I can honestly say that for small stories, I might actually use Inform 6 instead of Inform 7. For a Speed-IF type endeavors, it might just be (for me) more efficient use of my time.

Of course for any WIPS I have, it’s Inform 7 all the way. At least now I’ve been given a reminder of some of the benefits.