What can be achieved through css, html and quixe?

I’ve noticed that several parser games this past year have used specialized Quixe websites. CMG had a blue background in Midnight Swordfight, Ryan Veeder has released several games with colored backgrounds, and Pacian’s Superluminal Vagrant Twin uses colored backgrounds and, seemingly, different fonts than the standard font.

How far can you go with this? I’ve seen tons of Twine games, like Candlesmoke or Hannah Powell-Smith’s games that use colored backgrounds and texts, different sizes of text and different fonts.

How hard would it be to have a Quixe game that visually looked just like Candlesmoke? (Larger font, brown text on an image background) I’m just using Candlesmoke as an example of a visually rich Twine game.

Edit: Link to Candlesmoke for reference: http://inurashii.xyz/candlesmoke/

I would assume you can modify the HTML and CSS to your hearts content, but if you want real flexibility, glulx-typescript (fyrevm) would allow you to lay out your web page in any way you want and place the content wherever you want.

You lose the “standard” bit of a status line, scrolling text window, and you have to think a little differently about emitting text, but then again, the standard template of IF could certainly be recreated if that was important.

Can the input channels in textfyre be used to allow graphics to change on the fly (i.e. like changing background color?)

So this is a good problem and I’ll try to explain how FyreVM could solve it…

First, you could do it many different ways. Do you want to change themes? Do you want to change just one css class? Do you want to change the background image? The first thing I would do is decide what happens for this particular “UI change”.

Let’s say we know it’s a background image. This means we’re going to set/change … or if we’re using CSS, ….

We know how to do this with javascript:

document.body.style.backgroundImage = “url(‘myimage.jpg’)”;

Now on the I7 side, we create a new channel:

Include (- Constant FYC_BACKGROUND = (‘B’ * $1000000) + (‘I’ * $10000) + (‘M’ * $100) + ‘G’; -).
To Change the Background:
(- if (is_fyrevm) FyreCall(FY_CHANNEL, FYC_BACKGROUND); -).

Now when we want to change the background, we just do the following:

After doing something interesting:
Change the Background;
say “mynewimage.jpg”;
Select the Main channel.

Now when doing something interesting, the channel “BIMG” will contain the text “mynewimage.jpg”. There are probably simpler ways to write the action that would allow you to just do this:

Change the background to "mynewimage.jpg";

…but I’m just spit-balling here.

Now on the web side of things, the OutputReady() event is going to fire to let you know that all of your channel data is ready to be “handled”. I have it set up to automatically transform channels to the fyrevm global object, so this might come through as:

fyrevm.backgroundImage

Which would allow to do the following:

document.body.style.backgroundImage = “url('” + fyrevm.backgroundImage + “')”;


So now you have a front to back example of how a fyrevm channel, transformed to a client-side fyrevm JSON object, is used to alter the user interface.

I’d like to add that you could use tokens for the background channel and have all of the tokens on the client side. You could have theme names, or style changes, or even pass JSON or XML or HTML from I7. It’s entirely up to the author on how they want to communicate the UI change.

This is very good. I’m not very familiar with all of this, but I have plenty of time to work on it. Will I need a compiler to use the github material and make these changes, or can all the changes you suggested be made with pre-existing files?

Well it’s a work-in-progress. If you’re HTML/CSS/JS savvy, you could probably work through it, but the things missing for general authorial use include having a standard template, just to get you started. So no status line, no scrolling main window, not compatible with any built-in glulx UX effects or anything of that nature. I’ve been building things without a scrolling main window, giving the story a paging implementation, but it all depends on what you want to build. Eventually there will be a “ScrollingWindow” component that you can just drop in and it will append data from fyrevm.mainContent. It’s a little bit more complicated than that, but it’s not rocket science either.

I was in the middle of working on a ReactJS template, but the plain JS version works well enough. I just haven’t posted some of the latest I7 extension code for the fyrevm-JSON transform stuff, which I think is important.

You need Inform 7, a couple of fyrevm extensions from github.com/ChicagoDave/fyrevm-w … 0Cornelson, the glulx-typescript VM, the FyreVMWeb page manager. and a browser.

I use WebStorm as an editor because it has nice debugging, but you can use whatever you want.

I probably should just package up the plain JS version with Cloak of Darkness and then continue with the ReactJS version. I do have another priority for June/July/August, so let me know how you want to proceed. If you’re interested in things now, you may have to get your hands dirty.

I may wait a bit; I’m finishing up my IFcomp game right now with beta testing, so I’ll probably look into it in about a month. Thanks for all the help!

Hi David - I see some of the react code in your tree. What state is it in? How to compile it? Thank you.

The React code is incomplete at this point. The only working code is the plain JavaScript implementation.

Are you volunteering? :wink:

Sorry, don’t know react. Hey, I opened a couple issues over on github. I’m not able to get projects/stop-the-ifpress.fyrevm/example to work very well and trying to figure out where to start with things in general. FyreVMWeb.js has differences between the two examples I’m hoping you can shed light on.

Replied github. The TS error is a glulx-typescript problem with the latest TS compiler. Thilo will take care of that and when he does, I’ll port it to fyrevm-web.

I’d suggest you go ahead and make a pull request for your image change. I like the idea of not needing a web server.