soupDilemma – blog blog blog

Choice-based stories using CSS

Wed, 24 Dec 2025 02:27:00 -0500

In this post, I’ll go over how to make a basic choice-based story on a single web page without using any JavaScript or server-side logic. Some knowledge of HTML, CSS, and basic file operations is assumed.

Thanks to Dij for beta reading this post!

Background
The Story File
Making It Interactive
Hiding Information
Conclusion
Footnotes

Background

I’ve been playing Grundo’s Cafe for a little bit, having largely given up on Neopets due to its aggressive monetization. One of the things I remember wanting to do as a kid was finish making something with the Neopian Adventure Generator, which is nothing special if you’re at all familiar with Twine or pretty much any other tool for choice-based interactive fiction – the only state it tracks is what passage the player is on. All the same, it had its charm.

Grundo’s Cafe doesn’t have the Neopian Adventure Generator, but what it does have are pet pages.¹ Pet pages don’t allow JavaScript, and only a limited subset of HTML and CSS. It might be tempting to look at this set of limitations and say there’s no way to make an adventure using a pet page, but would it surprise you if I said that, even with these limitations, we have just as much power as the Neopian Adventure Generator?

The Story File

First allow me to present the HTML file this post will work with, which will not need to change for the rest of the post.

Save the following in a file with any name that ends in .html. How about void-of-doors.html?

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <title>The Void of Doors</title>
        <link rel="stylesheet" href="style.css">
    </head>
    <body>
        <div>
            <p>You awaken in an infinite void. Around you are three doors, <a href="#red">red</a> and <a href="#green">green</a> and <a href="#blue">blue</a>.</p>
        </div>
        <div id="red">
            <p>The red door was made of <strong>FIRE</strong>! AAAAAAAAAA!</p>
            <p>You have been incinerated. <a href="#">Try again?</a></p>
        </div>
        <div id="green">
            <p>The green door was a reverse green screen! It looked blank but was actually a monster!</p>
            <p>You have been eaten. <a href="#">Try again?</a></p>
        </div>
        <div id="blue">
            <p>The blue door was open air! You're falling! Which one of these was the parachute pullcord again?! Was it <a href="#this">this one</a> or <a href="#that">that one</a>?!</p>
        </div>
        <div id="this">
            <p>As you pull the cord, your parachute deploys! You drift gently to the ground. Oh, it's your doorstep!</p>
            <p>You have made it home. :)</p>
        </div>
        <div id="that">
            <p>As you pull the cord, your pocket lawnmower revs up! Why do you carry that again?! You accidentally sever your parachute's ripcord!</p>
            <p>You have splatted. <a href="#">Try again?</a></p>
        </div>
    </body>
</html>

It’s obvious I’ve mustered my great skills as a writer to have brought this diversion to life. But how does it play? Try opening the file in a browser.

… Well, it doesn’t play like much of anything! How are we going to turn this into something more like a game?

Making It Interactive

You may have noticed there are links but they don’t do anything. Or maybe you noticed they do do something – they change the URL hash, which causes the browser to try to scroll to the appropriate passage. But at least on desktop, it’s very unlikely to be able to do any scrolling because of how short it is, and even if you zoom way in it may not be possible to distinguish the passages at the bottom from each other.

So the first step is to make the active passage stand out somehow. This can be done with the css :target selector! If we make a rule using it, it will cause the element pointed at by the URL hash to change. Make a style.css in the same folder as the HTML file, with the following contents:

:target {
    font-size: 200%;
}

Now, refresh the page. You should find that clicking the links does something, namely, it makes one of the passages bigger! Well, it makes most of the passages bigger, but the first one doesn’t get this treatment. Why’s that?

We didn’t give it an id, because it’s supposed to appear even if there’s no URL hash. There’s no id that corresponds to an empty hash, so this one seems to require special treatment.

When should the initial passage stand out? Well, when no other passage does. But how do we tell what the initial passage even is? There are many elements without an id!

It looks like we have to pick an arbitrary rule, so how about this: All the elements directly inside the body are passages, and so if an element is in the body and has no id, then it’s the initial passage.²

Now that that’s decided, let’s try replacing the CSS with this:

body > :target,
body:not(:has(> :target)) > :not([id]) {
    font-weight: 200%;
}

Suddenly there’s a much more complicated selector (the body:not(:has(> :target)) > :not([id]) bit), so let me rephrase it into words: Match any element with no id if its parent is the body element and none of its siblings is the target.

I also changed :target to body > :target even though in this case it doesn’t change anything, to make it more parallel with the other selector. (It will also come in handy during the next step.)

Now, refresh the page, and you should now find that the initial passage is shown large when no other passage is!

Hiding Information

So it’s now possible for the player to tell what passage they’re on, which is a good start. But we’d also like that to be the only passage that’s visible. After all, right now you can cheat by seeing into the future. You can even click a link in any passage the same as if it were the active one!

To fix that, we’ll need to style all the passages that aren’t the active one, like so:

body:has(> :target) > :not(:target),
body:not(:has(> :target)) > [id] {
    display: none;
}

What changed? Let’s go over each part:

body:has(> :target) > :not(:target) – The body part is more specific than before. Actually, the reason it wasn’t this specific before is because body:has(> :target) > :target is redundant. Of course any body element directly containing the target contains the target! But now that our condition has been inverted – we want any element that isn’t the target – it needs to be this specific or else the initial passage will always be hidden. This part of the selector could be worded as: Match any sibling of the target if their parent is the body element.
body:not(:has(> :target)) > [id] – This part, on the other hand, was already specific enough in that regard, so all that was needed was to remove :not to invert it. In words: Match any element with an id if its parent is the body element and none of its siblings is the target.
display: none – The matching elements are hidden and removed from the page flow.

Refresh the page and see how it plays. With any luck, you should be seeing only one passage at a time now!

Conclusion

With this latest iteration of the CSS, the goal of creating a basic choice-based story is accomplished! Each passage is shown when it should be, and not shown when it shouldn’t. But what else could we do with this?

For starters, the URL hash is not the only way a web page can track state without involving JavaScript. For instance, a radio button’s state can be matched with a CSS selector, :checked. If you think of the URL hash as a single “variable” of state, adding in input elements allows you to have multiple!³

Instead of going directly in the body, the passages could go in any element at all. To do so, change both occurrences of body in the CSS to whatever is appropriate. E.g., if you want to put them in a main element somewhere inside the body, change them both to main. That way, you can have a sidebar or the like that persists even as you change passages.

And of course, you probably want to style the page further to your tastes.

That’s all for now. Feel free to use the HTML and CSS in this post as a template for making your own diversions. Enjoy!

Footnotes

In fact, if you have access to Grundo’s Cafe, you can see I’ve already done this on Arity’s pet page :) That said, as of writing, it’s not a proper adventure yet. Please look forward to it. ↩
Alternatively, we could put a class on all of them and select based on that, but I prefer doing it structurally because it makes the HTML less noisy. On top of that, Grundo’s Cafe has a limit on how much HTML you can include on a pet page, so less redundant information is better. ↩
Regrettably, input elements are not part of the subset of HTML allowed on Grundo’s Cafe pet pages. ↩

Musical challenges and a new mini-album

Wed, 03 Sep 2025 01:22:00 -0400

This is a personal musing on music. If you want to get right to the point, here is the link to Challenges on YouTube.

My motivation to make music
Chiptune
Tracks
Final Words
Footnotes

My motivation to make music

After realizing last summer that I hadn’t made nearly enough music lately¹, I challenged myself to post five chiptune pieces as one of my bingo tiles². I picked chiptune in particular because I have ambitions³ of one day making a Game Boy game.

I decided to motivate and challenge myself by asking others for sequences of notes which I would have to use all in a row in the melody. One of the reasons for this is that I find working with constraints to be really useful for stoking the creative flames, which is also one of the reasons I picked chiptune in particular.

The other point of using notes someone else provided was to explore musical scales outside of my comfort zone. The notes tended to strongly suggest a key⁴. I can easily play a beautiful piece in A minor, which is all white keys on a keyboard, and had done just that so many times with such fervor that I cracked the A keys on my keyboard on multiple occasions. But could I play in E minor, another relatively easy key? What about A sharp minor?⁵

The truth is that I could, I just needed to give myself room to explore and make mistakes. Woven into this journey to write five chiptune pieces was also the occasional impromptu piano improvisation session over voice chat, which I did on a Discord server where I felt comfortable expressing myself creatively⁶. This began when I streamed working on a piece and then decided to play piano afterwards, and my friends present enjoyed it so much that the piano became the main point of @ing everyone.

Chiptune

The pieces I made are the first complete pieces I composed in Furnace tracker⁷. Working with a tracker is very different from working with a score. If the score is for conveying the composer’s intent, and it’s up to the instrument player(s) to interpret that intent every time they perform the piece, then trackers are closer to programming the player, who is a computer, than they are to writing down the score.

Chiptune is also more like low-resolution pixel art than like painting, in that, often, you have no choice but to suggest detail in lieu of actually including the relevant details. With Game Boy in particular, which can play at most three tones at once⁸ (plus noise), sometimes it’s necessary to use illusions to convey what you want⁹.

Tracks

The album is appropriately named Challenges and contains five tracks, which I ordered by when I made them.

Dance for me, puppet! was the first of the bunch and is the shortest, iterating three times on a melody and then ending (or looping if you like). I was to use the notes A G# A E Eb D A in it. I played with a different melody before settling on this one, but it ended up sounding close to Megalovania and I wanted to see if I could figure out one that didn’t sound like Megalovania at all. I do believe I succeeded; A friend told me it sounds like it belongs in a Wario game. The span of time from receiving the notes to finishing the piece was about 18 days.

A Night For Ghosts is the second track, a tango, and is designed to loop. You can hear it go through the main melodies twice before fading out in the version I uploaded. This one had perhaps the most challenging notes, C D D# F# A A# B. This highly chromatic sequence greatly limited the places where it could sound natural and fit in. A friend told me it evoked ghosts dancing with roses held between their teeth, which is how it got its name. Its creation spanned about 15 days.

where our bodies meet the sea is an immediately in-your-face metal piece tinged with melancholy. Either it or the final track is the one I’m proudest of. I was given the notes F F C F E F Bb, which are very easy to work with and suggest a major key. I did not go with a major key. As a joke, I was separately given the notes F F F F F F, so, as a joke, I included them as well. There are around five distinct sections with about three different feels to them. I almost cut the second section due to being so very different from the others, but now I can’t imagine the song without it. This one took me significantly shorter than the others to finish, 4 days, which was because I was very motivated and worked on it for hours per day.

Before All Hope Is Lost was conceptualized as the music for a final boss’s second phase. It incorporates the same organ voice as Dance for me, puppet! and uses it very differently. The notes to include were F Bb F D F G# A, which are a little tucked away compared to the others so far but still appear in the melody. The consensus was that the organ-centered section, the “second verse” so to speak, is the most interesting part. This one took me the longest due to numerous troubles and a couple false starts, spanning 23 days.

The Power to Change is another metal piece, even more ambitious in some ways than where our bodies meet the sea, and by far the longest at a little over four minutes. It doesn’t merely have sections, it also conceptually has two parts, which are divided by silence but very much linked. This one has lyrics! However, I threw them out so that listeners could decide what they are for themselves. This song’s creation spanned 17 days.

Oh, did I forget to mention the required notes? They were E E D D C. (Those are the notes of “E-I-E-I-O”.) They were fairly difficult to include in the piece, because I made the decision to write the majority of it in A# minor, a scale that includes only one of those notes. Regardless, I managed to fit them in twice, in two different figures, in a way that I think makes sense.

Final Words

I feel like I learned something new with each piece, and they were all fun to make :) I even loop them when I shower, either all in sequence or individual ones. I think it definitely says that I made music I liked!

I’m looking forward to making even more music I like soon. Actually, I’m thinking of learning to play with the expanded capabilities that the Game Boy Advance sound chip offers over the Game Boy. It has the same channels plus two sample channels¹⁰, which might not sound like much but greatly expands the possibility space. I’ll be challenging myself further to take full advantage of this :)

Well, that’s about all the words I’ve got for now¹¹! Now go, enjoy the album!

Footnotes

A realization spurred by watching Girls Band Cry. I enjoyed it. My main critique of it is the same as for Bocchi the Rock: We’re told the music has certain flaws that the track we actually hear doesn’t have. ↩
The rules are: Come up with 24 tasks you want to do this year, then shuffle them and arrange them on a 5×5 board with a free space in the center. If you complete any line of five tasks (or four tasks and the free space) then you get a bingo. I like it because I get to feel accomplished even though I didn’t do every single thing :) ↩
Vague ideas pingponging around in my head, backed by vague notes. ↩
although sometimes I ignored the suggestion :) ↩
For whatever reason, I find it easier to be creative in minor keys. Every track on the album is in a minor key of some variety. ↩
At one point during this, I expressed something along the lines of “I don’t think I’m very good at piano” to a friend. What a silly thing to say! I was the only one who was hearing me play and didn’t think I was all that good. But don’t worry, I got better! (at recognizing how good I am) ↩
I’ve used trackers relatively little thus far. I made one piece in Pixitracker, but that really has more in common with Mario Paint than with what I’ve come to expect of chiptune trackers like Furnace or MilkyTracker. Which is not to say that it can’t make beautiful music, so much as that its expression space is not necessarily what I’m interested in when I say “chiptune tracker”. I also made a BGM in PICO-8 for tiny terrarium. ↩
Depending on how you interpret “at once”. Plus, it’s possible to create a wavetable that plays octaval unison. I’m not sure if other intervals are possible. ↩
My favorite video on this topic is Ya got TRICKED: That Full Band was really just 3 Channels! ↩
Do you know about the “Hoenn trumpets” in Pokémon Ruby and Sapphire? Those are an example of something that the sample channels allow! ↩
By the way, I want to put these on Bandcamp too. The only reason I haven’t yet is because they’re phasing out support for PayPal in favor of Stripe, and I would prefer not to make a new account on PayPal just to have to also make one on Stripe shortly after. Please look forward to it! ↩

Low-effort WebSocket encryption using nginx

Wed, 16 Oct 2024 14:21:00 -0400

This is a post on adding encryption to a WebSocket server without needing to change its code, using nginx. Some command line knowledge is assumed.

Background
Prerequisites
Serving a static website
Proxying a WebSocket server
Adding encryption
Conclusion
Appendix

Background

Recently, I was looking into making a MUD, and decided I wanted to do it with a WebSocket service. Since it’s usual for modern web browsers to encrypt connections, I also wanted to make sure it supported TLS.

I decided to write the server in Haskell, but the websockets package I saw recommended didn’t support TLS, and the wuss package it suggested to add TLS support didn’t support servers! So, I did a web search to see if anyone else had run into this problem.

One StackOverflow answer suggested adding TLS after the fact using nginx. This sounded much more convenient than having to deal with TLS logic myself, so that’s what I set out to do, and what I’ll explain how I did in this post.

Prerequisites

You’ll need to have nginx installed.

You’ll also need a WebSocket server. For the sake of demonstration, we’ll use websocat, even though it already supports encryption.

On Arch Linux, you can install both of these from the “extra” repository with pacman -S nginx websocat.

On Debian-based systems, you can get nginx with apt install nginx. It looks like the latest websocat releases as of time of writing don’t include a .deb, but the 1.8.0 release does.

For other OSes, check the links above for instructions.

Serving a static website

Let’s start by serving up a single HTML file.

As a bonus requirement, I decided I wanted to be able to run nginx unprivileged (not as root), so let’s make a new directory somewhere convenient and cd into it.

In that directory, make a file called nginx.conf. We’ll add to it over the course of the post, but for now just add the following to it:

daemon off;

This will cause nginx to stay attached to the terminal you run it from, for ease of iteration.

Now let’s make the file we’re going to serve. In that same directory, make another directory called static (this name has no special significance) and a file static/index.html with the following content:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>hello nginx!</title>
    </head>
    <body>
        <p>hello nginx!</p>
        <script src="main.js"></script>
    </body>
</html>

(Don’t worry about the nonexistent script for now, we’ll get to it.)

After a quick glance through man nginx, it looks like we can use the command nginx -p ./ -c nginx.conf to run the server from this directory.

-p ./ says to look for the configuration and other files in the present working directory.
-c nginx.conf says to use nginx.conf as the configuration file.

If we try to run it now, nginx should complain that there’s no “events” section. Let’s add this empty one to nginx.conf:

events {}

Running again, we get open() "/run/nginx.pid" failed. Add:

pid nginx.pid;

Now it should run without errors, but… it doesn’t do anything yet! That’s because we haven’t actually told nginx to be an HTTP server.

The Beginner’s Guide has a perfectly good section on this, whose advice we’ll adapt to our requirements:

http {
    server {
        location / { root static; }
    }
}

Running it now gives open() "/var/log/nginx/access.log" failed, so we’ll add another directive just inside the http block:

    access_log access.log;

You could also just as well put /dev/null in place of access.log if you don’t want to log incoming connections to a file.

Now run it one last time. It should stay running now. Has our hard work finally paid off? Use a browser to visit http://localhost:8000/ and find out! (We didn’t specify it, but 8000 is the default port, per the documentation.)

It loaded a page, right? If so, great! On to the next part! Otherwise, double check that nginx.conf looks something like this:

daemon off;
events {}
pid nginx.pid;

http {
    access_log access.log;

    server {
        location / { root static; }
    }
}

Proxying a WebSocket server

Next we’ll add WebSocket support to our server. There are some special considerations, which fortunately are covered by the WebSocket proxying page in the nginx documentation.

Let’s try using the first example there almost verbatim. Add this inside the server block, i.e., at the same level as the existing location block:

        location /chat/ {
            proxy_pass http://0.0.0.0:8001;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }

Note: If you plan for this website to face the public internet, you will not be allowing traffic to port 8001, because we won’t be encrypting that one!

If you try restarting the server and accessing http://localhost:8000/chat at this point, you should get “502 Bad Gateway”. This means it’s working! Sort of. The backend we told it to redirect to isn’t up.

While nginx is still running, start websocat -s 8001. Then refresh the page and you should get “Only WebSocket connections are welcome here”. This is websocat talking! Now we just need to use it with actual WebSockets.

Now we return to that missing script from earlier. Create static/main.js with the following contents:

'use strict'

var socket = new WebSocket('ws://' + location.host + '/chat/')

// When we successfully connect, send "hello, server!".
socket.addEventListener('open', function () {
    socket.send('hello, server!')
})

// When we get a message:
// - Add it to the page body.
// - If it contains "ping", repeat it back but with all instances of "ping"
// replaced with "pong".
socket.addEventListener('message', function (event) {
    var message = event.data
    var element = document.createElement('p')
    element.textContent = message
    document.body.appendChild(element)

    if (message.indexOf('ping') !== -1) {
        socket.send(message.replace(/ping/g, 'pong'))
    }
})

// As a bonus treat, the New Nintendo 3DS web browser can run this code fine!

Now, reload http://localhost:8000/ and check the output of websocat. You should see “hello, server!” has been received. Try typing various things into websocat’s terminal and watch them appear on the web page! You can even have multiple instances of the page open and they should all receive what you enter.

Your browser console may complain that the script is served as the wrong MIME type. This is probably not a fatal issue, but if it bothers you, add this to nginx.conf just inside the http block:

    include /etc/nginx/mime.types;

We’re almost there! Your nginx.conf should now look like this:

daemon off;
events {}
pid nginx.pid;

http {
    include /etc/nginx/mime.types;
    access_log access.log;

    server {
        location / { root static; }

        location /chat/ {
            proxy_pass http://0.0.0.0:8001;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
    }
}

Adding encryption

Right now, the website, including the WebSocket service, are served unencrypted. Our final step will be to add TLS to them.

Note: Encryption is really easy to mess up. I’m by no means an expert, so please consult other resources for best practices!

For purposes of this post, we’ll be generating a self-signed certificate. This isn’t good enough for a public website, because your browser will tell you it doesn’t trust the certificate, and it would defeat the point if your visitors ignored this warning! For that, you’ll likely want to use Let’s Encrypt or the like, which I won’t cover here.

Now that that warning is out of the way, let’s run the following command to generate what we need, which I cobbled together by looking at man openssl-req:

openssl req -x509 -nodes -subj '/' -out certificate.pem -keyout key.pem

This creates certificate.pem and key.pem in the current directory. Note that key.pem is a private key without a passphrase. As a rule, if someone else gets a copy of your private key, you should replace it as soon as possible.

Now we need to edit nginx.conf once more. Once again, the nginx documentation has some guidance. Just inside the server block, add:

        listen 8000 ssl;
        ssl_certificate certificate.pem;
        ssl_certificate_key key.pem;

Now nginx will use HTTPS protocol on that port, but there’s one other thing: We have to change the 'ws://' in the JavaScript code to 'wss://' to tell it to use secure WebSocket.

Restart nginx once more, double check that websocat -s 8001 is running, and then visit https://localhost:8000/. Your browser should warn you that the certificate isn’t trusted (If it doesn’t, consider switching to one that does!), but go ahead and click through anyway.

You should find… that nothing about the page changed! Mission accomplished!

Conclusion

As suggested by the StackOverflow answer, it was possible to take an unencrypted WebSocket service and add TLS support to it without fundamentally changing any of its logic; websocat -s 8001 was the only command we used to run that part of the setup.

Some things could be improved:

As mentioned, self-signed certificates are generally considered untrusted by browsers. It would be best to have one signed by a certificate authority such as Let’s Encrypt.
It’s generally less confusing to serve on the standard port, which for HTTPS is 443. I chose to use a different port just so I could quickly test as a non-root user, since Linux blocks use of ports up to 1024 by ordinary users.
At least for me, nginx complains that it “could not build optimal types_hash”. As this didn’t actually affect any functionality, I didn’t feel it needed addressing in this post, but nginx does helpfully provide instructions on how to address it.

And of course, the HTML and JS we used were placeholders, as was websocat.

Ultimately my plan is to make a multiplayer browser game and, with this, I’m one step closer!

Thanks to redwing for beta reading this post!

Appendix

Here are the final states of all the files.

nginx.conf:

daemon off;
events {}
pid nginx.pid;

http {
    include /etc/nginx/mime.types;
    access_log access.log;

    server {
        listen 8000 ssl;
        ssl_certificate certificate.pem;
        ssl_certificate_key key.pem;

        location / { root static; }

        location /chat/ {
            proxy_pass http://0.0.0.0:8001;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
    }
}

static/index.html:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>hello nginx!</title>
    </head>
    <body>
        <p>hello nginx!</p>
        <script src="main.js"></script>
    </body>
</html>

static/main.js:

'use strict'

var socket = new WebSocket('wss://' + location.host + '/chat/')

// When we successfully connect, send "hello, server!".
socket.addEventListener('open', function () {
    socket.send('hello, server!')
})

// When we get a message:
// - Add it to the page body.
// - If it contains "ping", repeat it back but with all instances of "ping"
// replaced with "pong".
socket.addEventListener('message', function (event) {
    var message = event.data
    var element = document.createElement('p')
    element.textContent = message
    document.body.appendChild(element)

    if (message.indexOf('ping') !== -1) {
        socket.send(message.replace(/ping/g, 'pong'))
    }
})

// As a bonus treat, the New Nintendo 3DS web browser can run this code fine!

certificate.pem and key.pem don’t have fixed contents. Instead, they’re generated by this command:

openssl req -x509 -nodes -subj '/' -out certificate.pem -keyout key.pem