Archive

Programming

Don't Crush Me is a game about pleading for your life with a robotic garbage compactor. It came up many years ago during a discussion in the AwfulJams IRC channel. The recent advent of Smooth Inverse Frequency proved an ample opportunity to revisit the idea with the benefits of modern machine learning. In this post we're going to cover the building SIF in Rust, compiling it to a library we can use in the Godot Game Engine, and then building a dialog tree in GDScript to control our gameplay.

First, a little on Smoothed Inverse Frequency:
In a few words, SIF involves taking a bunch of sentences, converting them to row-vectors, and taking out the principle component. The details are slightly more involved, but not MUCH more involved. Part of the conversion to vector rows involves tokenization (which I largely ignore in favor of splitting on whitespace for simplicity), and smoothing based on word frequency (which I also currently ignore).

Really, one of the "largest" challenges in this process was taking the Glove vectors and embedding them in the library so that GDScript didn't have to read anything from a multi-gigabyte file. The Glove 6B 50-D uncased vectors take up only about 150 megs in an optimal float format, and I'm quite certain they can be made more compact still. Additionally, since we know all of the tokens in advance, we can use a Perfect Hash Function to optimally index into the words at runtime.

With our 'tokenize' and 'vectorize' functions defined we are free to put these methods into a small Rust GDNative library and built it out. After an absurdly long wait for the build to compile (~20 minutes on my Ryzen 3950X) we have a library! It's then a matter of adding a few supporting config files and we have a similarity method we can use:

Now the less fun part: Writing Dialog. In the older jam Hindsight is 60 Seconds, I capped things off with a dialog tree as part of a last ditch effort to avoid doing work on things that mattered. The structure of that tree was something like this...

const COMMENT = "_COMMENT"
const ACTION = "_ACTION"
const PROMPT = "_PROMPT"
const BACKGROUND = "_BACKGROUND"
var dialog = {
     "_TEMPLATE": {
         COMMENT: "We begin at _START. Ignore this.",
         PROMPT: "The dialog that starts this question.",
         ACTION: "method_name_to_invoke",
         "dialog_choice": "resulting path name or a dictionary.  If a dictionary, parse as though it were a path on its own.",
         "alternative_choice": {
             PROMPT: "This is one of the ways to do it.",
             "What benefit does this have?": "question",
             "Oh neat.": {
                 PROMPT: "We can go deeper.",
                 "…": "_END"
             }
         }
     },

I like this format. It's easy to read and reason about, but it's limited in that only one dialog choice corresponds to one action. For DCM I wanted to be able to have multiple phrasings of the same thing without repeating the entire block. Towards that end, I used a structure like this:

var dialog_tree = {
    "START": [ # AI Start state:
        # Possible transitions:
        {
            TRIGGER_PHRASES:["Hello?", "Hey!", "Is anyone there?", "Help!", "Can anyone hear me?"],
            TRIGGER_WEIGHTS: 0, # Can be an array, too.
            NEXT_STATE: "HOW_CAN_I_HELP_YOU",  # AI State.
            RESPONSE: "Greetings unidentified waste item.  How can I assist you?",
            PLACEHOLDER: "Can you help me?",
            ON_ENTER: "show_robot"  # When we run this transition.
        },

        {
            TRIGGER_PHRASES: ["Stop!", "Stop compressing!", "Don't crush me, please!", "Don't crush me!", "Wait!", "Hold on."],
            NEXT_STATE: "STOP_COMPRESS_1",
            RESPONSE: "Greetings unidentified waste item.  You have asked to halt the compression process.  Please give your justification.",
            PLACEHOLDER: "I am alive.",
            ON_ENTER: "show_robot"
        },

        {
            TRIGGER_PHRASES: ["Where am I?", "What is this place?"],
            NEXT_STATE: "WHERE_AM_I",
            RESPONSE: "Greetings unidentified waste item.  You are in the trash compactor.",
            ON_ENTER: "show_robot"
        }
    ],

This has proven to be incredibly unruly and, if you are diligent, you may have realized it's just as possible to do the same "multiple trigger phrases" in the first approach via some simple splitting on a special character like "|".

So how well does it work? The short answer is, "well enough." It has highlighted a much more significant issue: the immensity of the input space. Initially, it was thought that using a placeholder in the input text would help to anchor and bias the end-user's choices and hide the seams of the system. In practice, this was still a wrought endeavor.

All things considered, I'm still proud of how things turned out. It's a system that's far from perfect, but it's interesting and it was plenty satisfying to build. I hope that people enjoy the game after the last bits are buffed out (hopefully before GDC 2020).

Overview

Goose Game, but instead of a horrible goose you are a good dog whose job it is to break up fights at holiday parties. Let's game it out.

Gameplay

Simulated people will run through the motions for a party. Each guest will have a set of desires and some personal goals to achieve. For the sake of gameplay, everyone that can see the dog (player) will attempt to intervene when the player is misbehaving, rather than deferring to a host or someone else.

Visuals

Something visually simple with bright colors and simple geometry. This game should be very easy on system resources and should operate smoothly on low-resource machines or mobile devices. One option:

Low Poly pack by @Quaternius

Audio

High-fidelity, cheerful music with cute sound effects. Human speech and communication should _not_ be real human speech, but should be some sort of non-lexical vocalization like Simlish.

Interesting Challenges

Fundamentally, the interpersonal interactions will drive the game. For replayability (and developer sanity) it is desirable to have conflicts emerge naturally from NPC interactions. Additional household events can add color or fun as discoverables, but the most fundamental piece of the game is the temperature of discourse.

At the close of my earlier update I mentioned wanting to try 'Tracer-style' time travel where only the player moves backwards and everything else stays in place. I gave it a go and got it working, but it wasn't particularly interesting. It was basically just the player moving in the opposite direction. Animation could probably jazz that up, but a more fun idea came to me in the middle of a sleepless night:

Seeing the future.

Trivially, if everything in the world rewinds and the player can make different decisions, that's basically seeing the future. And that's what I built:

It's not perfect. You'll notice that the dynamic cubes retain their velocity after the time rewind happens, but that's solvable.

Here's how it works: there's a global time keeper which records the current tick. The base class has three methods (_process, get_state, and set_state), and two variables (start_tick and history[]).

The global time keeper sends a signal when time starts to rewind. During the rewind process, each tick is a step backwards instead of a step forward. The _process method of the base class checks to see if a rewind is active and, if so, calls set_state(history[global_tick]). If rewind is not active, we append or update the history. There's some nuance to tracking deltas and despawning, but really that's about it. Simple, eh?

"Your theme is... 60 Seconds!"

And so the brain storming begins. I feel like anything that doesn't explicitly involve time-travel of some sort will get dinged by the Theme-Adherence police, and besides, time travel is fun.

I've never made a game with time travel before, but it presents plenty of opportunities to do novel things. At the very least, even if the mechanics aren't original, I can do things like make the player character switch from replay to AI-driven if the player interacts with his/her previous self or force players to avoid interacting with their previous selves by avoiding line-of-sight and such. All of this is predicated on Terminator-style time travel, where the player goes back into a previous timeframe and can never return to their original. Minute Physics calls this "new/changed history" time travel and I'd call it 'forked history' time travel. The other form would be self-influencing time travel, where you happen to see yourself from the future coming in to your present.

I tried a lot of architectures. It began with the simplest thing I thought would work: A controller component would record keypresses and emit signals. The parent object would listen for signals on the child component and act as though it were receiving input. This worked, but it was hard to jump to a specific point in time.

The next thing I tried was a 'global manager'. Each actor had a 'get state' and 'set state' method. In record mode, actors would append to their history. In replay mode, they'd pull from history and set state. Things got complicated when it came to handling travelling backwards in time and then interacting differently. It was easy to go back to a time and replay, but it wasn't easy to go back, replay, and record at the same time. That part was necessary if we wanted to see ourselves and interact in tandem.

The third thing I tried was similar to the first. Each actor would be a deterministic function of time. We 'set time' which consists of taking the time and setting state accordingly. Functions are determined as only a function of the current timestamp. That works fine. After playing with it, however, it's really hard to make puzzles for it.

Shown Here: Player Jumping Backwards in Time and Seeing Other Selves

I'm going to try the Tracer-style time travel thing where the player can go back 60-Seconds into their previous state while the world stays as it is. This is closer to the self-consistent/non-branching timeline.

Thematically, I really want to rip off Zero-Wing and do a terrible translation of the plot. Character has a time-travel device that sends him/her back 30 seconds, but it has a 60-second recharge. The player got a lethal dose of radiation and needs to go back to save him/herself. The goal is to get past unity and into the net-time-gain territory. Either a recharge of 29 seconds or a jump of 61 seconds.