Notes by Austin Pocus

Patterns

2022-07-18T18:05:55Z

Man, it has been a while since I've written one of these. So I'll dive right in: lately, I'm thinking about how to branch out from the Javascript-centric ecosystem I've been working in over the past few years.

I'm feeling boxed in by my sole use of Javascript as my language of choice. I started to explore languages within the realm of, or adjacent to, the web. Specifically, I've become interested in PHP and Python.

This has led me to start comparing programming languages. As I've thought about designing my own programming language on this blog a few times before, I'm naturally thinking about features and language characteristics that are shared, and those that set a language apart.

What really inspired me to write this post was noticing the features that Python has picked up since I last used it. Structural pattern matching is a fantastic example, borrowing an extremely useful language feature from Rust. How did I miss this?

But what am I getting at here? What's the purpose of this post?

For one, I've missed out on some key developments in programming languages I used to know well, or at least, I thought I knew them. PHP is another great example here -- while I always thought of PHP as a slightly more well-behaved Perl, more geared towards CGI and old-school web dev, that couldn't be further from the truth. Modern PHP, so far, has been surprisingly robust and effective. It draws more comparisons to Ruby + Rails than Perl, especially with frameworks like Laravel.

It's led me to question where I want to spend my time writing code. Is it React frontends? I think I've gotten into a rut there. Maybe Python audio analysis? Or PHP web dev? Maybe a return to Rails?

In any case, I think I need a plan.

The most interesting thing to me, right now, the thing I'm most likely to sink my teeth into and finish, is audio analysis using Python. Specifically, I want to hum or whistle a tune, and translate that into MIDI or sheet music.

Let's narrow that down. I want to whistle and get MIDI. I've done something like this before, but it was honestly half-baked. It was very raw, having a few flaws:

For one, it could only work on pre-recorded WAV files. You had to record a short clip and run the program on the command line. There, it would output raw MIDI. For those unfamiliar with the world of audio files, this is really low-level stuff, something you would feed into an existing synthesizer or digital audio workstation.

There, we would finally be able to hear the product, which was...not the most accurate rendition of whatever was whistled. Sure, the notes would be mostly right, as long as you were within a half-tone or so of the "perfect" frequency. But it had a lot of holes.

So what's the difference this time around?

First, I would love to make this more of a real-time user-friendly application. The app should open a window where you can record, see a visual representation of the notes recorded, and play back any part of the result whenever you like.

Second, I'd like to use some sort of machine learning technology like PyTorch to fine-tune the resulting notes. This could be as simple as fixing individual notes that are sharp or flat, or it could be smart enough to learn how sharp or flat you are over time, or it could learn the difference between an error and an intentional pitch bend (like when a guitarist bends a string).

Eventually, I'd love to see auto-transcription of musical instruments being played, as the notes are being played, a sort of "smart musical assistant AI". But that's a long way off.

Right now, I'd just like to get a solid MIDI signal out of my random whistling. I come up with some neat little melodies every now and then, and it would be great to capture that and maybe turn it into something musical.

Related side idea: a beatboxing translator, an app that takes beatboxing and turns it into a MIDI drum loop. But that's another project for another day! I've got enough to do for now.

Tune in next time -- I should be writing something new within the next few days.

A NES-like Virtual Machine

2022-03-22T20:05:09Z

Yesterday, I was thinking about a layer of Zig between me and the NES. Naturally, this led me to wonder: what if I made a virtual machine that is NES-like, but easier to program?

But first, a soundtrack, because I have this song stuck in my head and you should too:

I've thought about a custom virtual machine a few times before, but not so much in those terms. I think of this apart from those early efforts -- this is more of a fun thought experiment, not necessarily something I'll dive into further.

So what would this virtual machine look like?

The first thing I'm thinking of is the behavior the VM exhibits, followed by the interface it defines to allow us to change that behavior (this might seem obvious, but bear with me -- I'm thinking out loud here).

The VM should let us:

Define shapes, individual pixels, and tiles on the screen.
Animate those graphics, using tiles or pixel transformations.
Detect collisions between objects on the screen and react to them.
Move pixels, groups of pixels, shapes, or tiles in any direction.
React to user input, from the keyboard, mouse, or a controller.
Define "action buttons" that trigger interactions with onscreen objects.
Simulate user input like movement or interaction, to create NPCs and enemies.

That seems like a solid base. The first thing to build would be the graphics -- that's the core, naturally. So how we define the shapes, pixels, and tiles will influence how the whole system works (a perfect opportunity to defer decisions).

From here, how do we interact with this behavior? Do we use a language like Javascript, or Zig, or Lisp, or do we define something new?

Side note: for a long time, since I discovered Lisp-like languages, I wanted to create a custom language that uses something similar to M-expressions instead of S-expressions. Think: fewer parentheses. In other words, a sprinkling of syntax to make Lisp constructs easier to deal with, without sacrificing much in terms of parsing (and macro expressions!).

But this is a tangent, a technical desire as opposed to a user need (and I'm a user in this case, so it's doubly important to think about).

What would the ideal language look like?

It might be Lua. Lua has been used to great effect in the video game industry, so it's a pretty safe bet. Maybe I start with Lua and expand from there? Hypothetically of course -- I'm not actually going to start building any of this yet.

What if we followed the tangent? What would an ideal language look like?

I do like the idea of using some form of M-expression, such that we could:

Remove the outer layer of parentheses so (+ 1 2) could be + 1 2.
Add a little syntactic sugar, like for dictionaries, as in Clojure.

This is getting way into the weeds, but you get the idea. VMs are just fun to think about -- we can create little worlds. And that's the entire appeal of making games, so it seems appropriate. Signing off -- tune in next time, same bat-channel.

Zig as Implementation Language

2022-03-21T22:09:11Z

After a good sabbatical, I'm back and writing. Lately, I've been interesting in the Zig programming language, and how it might relate to NES development and 6502 assembly.

Zig, for the uninitiated, is a small and fast C replacement and glue language. At least, that's how I've been thinking about it. It's like Rust with the restrictions (and memory safety) removed, a tradeoff I favor, since I'm developing games and I want to hack out a concept, not necessarily a production system.

Let's back up. I've been wanting to get back into NES development, making games for the original Nintendo system. It's a sparse environment, to say the least, but I think it can be made better in 2 respects: tooling, and language of implementation.

Let's talk tooling first, since it's the shorter of the two topics, something I've only briefly considered. Graphics and audio tools are plentiful for the NES, but finding something that works well, is updated regularly, integrates with the code you're writing...it's almost enough to make me want to develop modern tools for these old systems.

Almost. Not quite, though. Existing tools work, but the biggest hurdle I'm facing right now is writing 6502 assembly code. Thankfully there are resources, like Rodnay Zaks's Programming the 6502, freely available on archive.org (legally, too!). I've been going through the Nerdy Nights tutorials as well, which are indispensable for actually getting something on the screen.

6502 is great as far as assembly languages go -- much better than modern x86, which is designed to be written by compilers. Even so, it can get tedious, and with the memory and computing limits of the NES, it's not so easy to just use C. There are a lot of things you just can't do, common constructs you can't use.

That's where Zig could come in handy. One of Zig's greatest strengths is that the standard library is optional -- huge for embedded use cases, or limited-resource environments like this. There isn't a 6502 backend as of this writing, but there is a GitHub issue that requests this feature.

So that's one option. Of course, a language tailor-made for 6502 NES development would be ideal. Maybe I can build a set of macros on top of 6502, like a custom assembler...

That's really what I'm moving towards -- not using Zig directly, but rather, as the implementation language for another custom language, geared towards the NES.

First, though, I should probably write a game actually using 6502 directly. I want to be able to make games for the NES more easily, but I need to take the hard route first. Learn my way around.

Maybe I'll make a thin abstraction layer along the way. Who knows...either way, I should take a more minimal approach.

I might pursue this, I might not, but either way it's fun to think about.

Designing Data For Games, Part 3: Dialogue Revisted

2021-12-22T20:35:45Z

I'm building out the make-conversation project to create dialogue trees for "Escape from Valis", generating a Lua data structure from a Javascript object. Here, I'd like to get into the details of dialogue trees and what I've run into so far.

Last time, I came up with a data structure like this:

elderDialogue = {
  start = {
    optionText = "Hi, I'm Foo, Mr. Elder.",
    response = "My father was Mr. Elder. You can call me sir.",
    options = {
      polite = {
        optionText = "Of course sir. Do you know where the secret cave is?",
        response = { -- response can be a table as well as a simple string
          text = "You're a nice kid, here's the map. Not much of a secret, really.",
          item = "thisIsAnItemId" -- this should refer to a canonical item table
        },
        options = {
          sayThanks = {
            optionText = "Thank you!",
            response = "You are very welcome, friendly stranger.",
            ending = true -- this option will end the conversation with this NPC
          },
          walkAway = {
            optionText = "[Walk away]",
            ending = true -- if you walk away there shouldn't be a response
          }
        }
      },
      rude = {
        optionText = "I could, but I'll call you Slappy!",
        response = "Well, you won't get anything from me! Go away.",
        ending = true
      }
    }
  }
}

This data structure, as I noted last time, is a bit repetitive, needs data encapsulation (when there's an item), and so on.

The biggest issue is the nesting. I'd like to define types, using Typescript -- here I'll use a pseudo-Typescript style so I don't have to refer to a manual while I write.

So what exactly is a DialogueTree?

A DialogueTree should have an NPC identifier as the key, and an Options object as the value.

An NPC identifier will just be a slugified string, most likely the NPC name with hyphens in place of spaces, and the special characters escaped.

What is an Options object? Well, it might look like this:

interface dialogueTree = {
  [NPC_ID]: {
    [optionId]: {
      text: string,
      response: Response
    },
    [otherOptionId]: {
      text: string,
      response: Response
    }
  }
}

What is a Response exactly? Maybe this:

interface response = {
  responseType: ResponseType,
  text: string,
  data: any,
  options?: Options
}

Here we have a recursive data structure (which is what I'd expect). React is conducive to recursive structures, sort of. So far, I have code that uses a keys property in the React component to track how to get down to that particular option from the root state object (the DialogueTree type we defined).

What is a ResponseType? That will be defined as an enum of sorts, a union of types in Typescript, that will declare constants that can be used to process the response object in the Lua code.

From here, I think I have a better idea of where I'm headed. I'm going to start by converting my current code to Typescript, and start defining these types formally. Back to it!

Designing Data for Games, Part 2

2021-12-20T21:41:25Z

In part 1 of this series, I wrote about a data structure for dialogue trees. Here, I'd like to finalize that structure and discuss a data structure for RPG quests.

First, some quest music:

I couldn't resist. I regret nothing!

Anyway, in the last post, I thought out a data structure for dialogue trees, and wrote out my thoughts as they came. I ended up with a relatively simple tree structure in a Lua table, where each entry is an option for what the player can "say" which contains responses. These options can lead to other options, and can include parameters for effects on the conversation.

Here, I'd like to think aloud about data for quests.

For those not familiar with role-playing games: a quest is like a "mission" in the Grand Theft Auto games, a goal of some kind. You're given something to do in the game, and if you fulfill that goal, you're given a reward or the story progresses in some way.

Often the state of the world will change if you complete a quest. For example, if you go to the past and steal the secret weapon from King Fuddlepants, he won't be able to use it if you challenge him in the future. That's a bit of a contrived example, but you get the idea.

Quests often involve common components, which I plan on using to design quests. For example, most people absolutely despise "escort" quests, where you help a non-player character (NPC) get to a destination, usually someone who can't help you in battle. The worst part about the NPC escort quests is usually the movement AI...but I digress.

Another common aspect of quests is items. You might be asked to retrieve the Legendary Sword of Power from the Bog of the Dead and return it to the Duke of Dingleberry.

Quests also involve choices in some games. You may choose not to give the sword to the Duke, instead keeping it for yourself, and he might send soliders after you to retrieve it.

Finally, quests have a reward of some kind. Either they give you an item, boost your stats, or progress the story in some way. Sometimes you get no reward, if the quest-giver is miserly.

This gives us a decent structure for quests. We can use the "quest components" or types, like FetchItem, Escort, DefeatEnemy, etc. to handle different quest types with common code. These components should lend themselves to combination. As in, you should be able to say "defeat this enemy, and escort the Village Elder back to the castle", making multipart quests.

So what will the data look like?

First, a quest should have a type, and a data field:

myQuest = {
  questType = Constants.QuestTypes.FETCH_ITEM,
  data = {
    item = Constants.ItemTypes.LEGENDARY_SWORD
  }
}

You can see here I'm referring to a seemingly global Constants variable, which should contain a lookup table of all the item and quest types in the game. It doesn't have to be global at all -- it can be imported as a module.

The purpose of the questType field is what you might expect, to make it easier to split up code between types. The value should be a bit field, so I'll be able to combine different quest types with ease using the bitwise OR operator (the pipe character, |, in Lua and most languages). This will also let me check the presence of a given quest type on a quest with bitwise AND (the ampersand, &).

The data field bothers me because it's sort of a catch-all object and it's badly named. Maybe it should be "details"? I'll have to think on this.

I'm starting to get further along in my thoughts than I'd like -- I need to embody some of these thoughts in code. I may write a "part 3" to this series, in the coming week, but for now I'm going to get "Escape from Valis" ready to open-source (I want to code in the open). Tune in next time!

Designing Data for Games

2021-12-20T01:15:04Z

Designing data structures is one of the most important things we do as software developers -- it informs the structure and cadence of the code that follows.

Here, I'd like to think aloud about data structures for character dialogue and quests in the game I'm making. Let's start with dialogue, since I believe it'll be a simpler data structure.

Dialogue is an interesting aspect of some games. Sometimes it's very straightforward: you ask and the character, the NPC (non-player character) answers. They say the same thing every single time and don't react to anything.

If this were the simple case, I wouldn't need a data structure, except maybe a simple table to associate characters with their lines. If you know me, you know I'm not going for the simple case.

I like games like Star Wars: Knights of the Old Republic or Fallout 4, where you're given many options regarding what you can say to the character, and they in turn respond to what you choose. This can lead to other options, it can trigger a quest or give you an item, it can affect how much the NPC likes you (or not), and options may even go away when you choose one!

The way I'm thinking of dialogue, it can be represented as a tree of sorts. Of course, Lua only has one data structure, the table, which serves as array, hash map, and object all in one. I'm picturing something like this so far (syntax is Lua):

dialogueTree = {
  firstOptionId = {
    optionText = "This is the first option that will be displayed to the player.",
    response = "Well that's neat!"
  },
  secondOptionId = {
    optionText = "This is the second dialogue choice, displayed alongside the first.",
    response = "Yep, I'm getting the picture."
  }
}

If there are options shown after you choose the first option, those should be nested under the first like you'd probably expect (we'll use a real example this time):

elderDialogue = {
  start = {
    optionText = "Hi, I'm Foo, Mr. Elder.",
    response = "My father was Mr. Elder. You can call me sir.",
    options = {
      polite = {
        optionText = "Of course sir. Do you know where the secret cave is?",
        response = { -- response can be a table as well as a simple string
          text = "You're a nice kid, here's the map. Not much of a secret, really.",
          item = "thisIsAnItemId" -- this should refer to a canonical item table
        },
        options = {
          sayThanks = {
            optionText = "Thank you!",
            response = "You are very welcome, friendly stranger.",
            ending = true -- this option will end the conversation with this NPC
          },
          walkAway = {
            optionText = "[Walk away]",
            ending = true -- if you walk away there shouldn't be a response
          }
        }
      },
      rude = {
        optionText = "I could, but I'll call you Slappy!",
        response = "Well, you won't get anything from me! Go away.",
        ending = true
      }
    }
  }
}

You can see how this is starting to evolve. There are a few potential issues with this.

First, there should always be a "[walk away]" option, at least in this game. That could change later -- maybe you shouldn't be able to end a dialogue with your captor, if you've been imprisoned or something, but I'm not worried about that right this minute. It would certainly make the tree smaller and simpler, which would be nice, but let's bear in mind this isn't made for human consumption! This data will be generated by a web app.

That reminds me, we should be able to import as well as export from the web app! I should be able to pipe data back in, modify it, and get the result from the app. This is critical, otherwise I'd have to input the dialogue tree every time or save it elsewhere, which is undesirable. I don't need a database for this app, or shouldn't yet.

The other potential issue is the response structure: it could be a string or a table. This seems fine at first glance but requires either extreme caution at every point you plan to access the field, or a wrapper module that has a getter function for the response...and since this isn't made to be written or read by humans, it's not a huge deal to make it an object all the time, to make the code easier to deal with.

This is getting long, I lost my pace, and the quest data structure will be even more complex, so I'll make a "Part 2" and link it here when it's done.

[UPDATE: Read part 2 here]

Lua as Data

2021-12-17T20:02:09Z

I want to put a bunch of quest and dialogue data in the game I'm working on, "Escape from Valis", but I don't want to write it by hand. What if I could write a Lua data structure using a web app?

The problem

I'm designing a game, "Escape from Valis", and as an old-school RPG, it'll naturally include quests and dialogue. This would have to live in some sort of data structure...so how would I put this data in the system without writing it all myself?

A potential solution

The solution that comes to mind would be to write to a data structure using some application, which would have some sort of configuration interface, right? But, there's a catch.

Lua isn't the best language for full-on application development. Sure, I could build an entire GUI in Lua with some of the libraries out there, but it's needlessly difficult.

What if, instead, I could write a Lua data structure in a language better suited to app development? What if I used my Javascript skills, along with some sort of Lua translation tool, to create a data structure in a web app and write it to a .lua file, much like Tiled does?

The plan

This is entirely possible -- Lua lends itself well to data expression. The "table" data structure, Lua's only compound type, acts as a list, a dictionary, or an object (using "metatables"), all in one neat package.

The format is actually quite similar to JSON, and I discovered through a bit of experimentation I don't even need a Javascript-based Lua VM! I wrote a simple regex or three that replace key characters in the JSON.stringify output, namely the ":" character and the square array brackets, like this:

JSON.stringify(luaData, false, 2)
      .replace(/"(\w+)":/g, "$1 =")
      .replace(/\[/g, "{")
      .replace(/\]/g, "}");

If you're not up on your regexes, the first one simply captures the value in double quotes, and unquotes it, replacing the ":" with a "=". The other two replace the square brackets. Just like that, we have valid Lua!

From there, you can write the contents to a file and trigger a download:

// Code modified from https://stackoverflow.com/questions/13405129/javascript-create-and-save-file
// Licensed under CC-BY-SA 4.0
// where luaState is an object
const fileContents = JSON.stringify(luaState, false, 2)
  .replace(/"(\w+)":/g, "$1 =") // replace quoted properties with bare identifiers and an equals sign
  .replace(/\[/g, "{") // replace square brackets in these two regexes
  .replace(/\]/g, "}");
const file = new Blob([fileContents], { type: "text/plain" }); // create a file object
const filename = "quests.lua";

if (window.navigator.msSaveOrOpenBlob) { // IE10+
  window.navigator.msSaveOrOpenBlob(file, filename);
} else { // Others
  let a = document.createElement("a"); // creating a virtual "link" to download
  const url = URL.createObjectURL(file);
  a.href = url;
  a.download = filename; // this is what sets up the actual file download
  document.body.appendChild(a);
  a.click(); // trigger the download

  setTimeout(() => {
    document.body.removeChild(a);
    window.URL.revokeObjectURL(url);  
  }, 0); // setTimeout(..., 0) will run on the next tick, ensuring the download runs
}

From here, I'll probably have to cover some edge cases. Now that I look at the code, null and undefined would have to become nil to be valid Lua (but that's not a problem in this case). Next, I have to create a dead simple UI using React and Next.js, my weapons of choice. This UI should let me add primitive values to compound objects, nested if I choose.

I need to design a data structure first, though. My next post will most likely cover this in detail.

I Wanna Know What LOVE Is

2021-12-14T04:51:20Z

In this post, I want to tell you about the LÖVE framework, and how I fell in actual love with a language called Lua.

Fair warning: this post is heavy with puns on song titles, rambling technical esoterica, and a slight dose of lunacy.

What is LÖVE?

For the uninitiated, LÖVE (or love2d as I'll call it from here) is an excellent little Lua framework for making games. It's not an engine so much as a set of building blocks.

This has led me down an interesting path regarding Adventure Kit. Really, it could be built entirely on top of love2d, a set of modules that click together nicely and help you build an RPG using love2d under the hood.

I could even potentially wrap or monkey patch the love2d APIs, to make them nicer to work with -- Lua, the lingua franca of the love2d world, is a very monkey-patchable language.

Whole Lotta LÖVE

I'd like to take a brief moment to talk about how awesome Lua is. It's this incredible little language, interpreted by the default implementation but also available in a compiled variety called LuaJIT. It's fast and small -- the whole LuaJIT VM weighs in at a featherweight 115KB. Stick that in your CPU pipeline and smoke it!

Its influences can be felt, if you've worked with a variety of languages. You can see the prototype-based OOP that's reminiscent of Javascript, for one (though Lua is a bit older, probably taking a cue from the Self language).

It has some functional components, too! Functions are first-class objects, like most modern languages. Unlike some modern languages, though, it considers goto not necessarily harmful, but useful. (The book even gives a working example of a state machine using goto!)

The coolest thing about Lua is its incredible strength and speed for its size. It's completely disproportionate...it's like the Ant Man of programming languages. It's highly reminiscent of C (which makes sense because that was part of Lua's origins -- C is the language it was implemented in and whose APIs it borrowed).

The Lua APIs are so simple, the language so intuitive, that I was able to pick it up without reading a guide or book first. The language is that good.

Instead of the laborious process I took when I most recently learned say, Rust, or C++, Lua was immediately apparent. It's clear what the code means, I simply read the example code, mimicked it, googled things as they came up, and I was away and writing code at a good clip within a couple of days.

(Don't worry, I started reading the official book in earnest after I spent a week or two writing Python-esque Lua.)

It's a testament to the quality of the language, the readability and simplicity of most of what you'd do in Lua. It speaks volumes that such a language can be picked up easily.

I mean, you could pick up a simple but less powerful language quickly too (e.g. Markdown, yes it's a language) but what makes this amazing is that Lua is incredibly powerful for all this simplicity in its construction.

But I digress.

The Power of LÖVE

The structure and cadence and flow of Lua weighs heavily in the implementation of love2d. You can see it in the module structure of the library, the APIs, the ecosystem, and how all of these feel when you're using them.

(I realize I'm using some intuitive, touchy-feely terms here to describe very deterministic and non-magical systems. But I feel expressive, and sometimes these things are based in intuition. How it feels to use a system makes a difference.)

The most striking thing about love2d is the sheer number of libraries that build on top of it. It's something I've seen when using tools like jQuery, React, etc. in Javascript, but not quite to this degree.

To get an idea of what I'm talking about, check the awesome-love2d repo on Github. There, you'll see people have built libraries to deal with physics, audio, graphical effects, state management, GUIs...I can't even list all of the things the community has built on top of it!

But I've been working on Adventure Kit, right? You may be wondering:

What's LÖVE got to do with it?

(Got to do with it?) Ahem.

It was suggested to me that, in order to build Adventure Kit, I should first build an actual game that resembles the style I'm trying to target.

As it turns out, this is an excellent method for designing a tool. Who knew.

I'm already coming up with module ideas, as I progress. I have sprite loading, basic movement, physics, tile map loading using the Tiled map format, and a few other odds and ends, like a "run" button I implemented during some testing frustration -- "necessity is the mother of invention"?

But my proudest creation so far is a spritesheet loader that takes margins and padding between sprites into account. This is necessary due to the nature of OpenGL textures, as I understand it -- they "bleed", such that the sprite next to your supposed boundaries will "leak" onto the screen by 1 pixel or so. The solution was to add transparent pixels as padding, so that the first sprite will be rendered in the correct position, the next tile will overlay the padding pixels, and so on.

All You Need is LÖVE

From here, I'll be continuing development on the game, which I've tentatively named "Escape from Valis" (inspired by the Philip K. Dick book of the same name). The gameplay I've planned so far involves plenty of 2D pixelated Fallout-style dystopian action, set in a fictionalized mega-city.

I haven't gotten to the RPG-related parts of the development cycle, but the nice thing about game dev and the love2d framework in particular is: you kind of have to iterate quickly and keep the game playable, lest you fall into a pit of unrunnable code riddled with errors.

It's getting late, or early, depending on your perception of time. Tune in next time, same bat-channel!

Dev Journals 10: Yukon Vengeance

2021-08-30T18:16:09Z

The inspiration for today's title comes from a movie with the same name, but it also refers to a very real problem: I'm kind of in the wilderness here.

The wilderness being Typescript, but also Redux, and most of all, the type of UI I'm trying to build.

Adventure Kit, or at least make-a-quest specifically, is all about visual programming at its core. This requires the design of an intuitive interface, naturally.

Problem is, I haven't really done much actual design work. Sure, I work on the frontend constantly! But I'm working from the designs of others.

Generally I started my career more on the backend, and have been working toward more of a full-stack and frontend-heavy role, as that's where I saw the work going (look at all the "serverless" models now -- still needs backend work, but the focus is definitely on the frontend).

All this is to say, I feel like I'm out of my depth sometimes when it comes to designing interfaces. The problem can be solved, still...it just requires a lot of persistence.

I'll have to go through a few bad interfaces to get to the good ones, and that's ok. Likewise, my Typescript probably won't be idiomatic or the "Right Way" to do things, but it'll improve over time.

Typescript in particular is easier to solve than the design issue. Design takes practice, full stop. But Typescript? Along with regular coding, I just need to read the docs. Or, as the greybeards say, "RTFM" (Read the "Friendly" Manual).

Anyway, if the interface works, even in brutalist form, if my code works, even if it's a bit ugly, that's okay.

After all, I'm learning a few things here, and all at once. And I'm writing it in the open! (Check the latest feature branch for my current code, literally the last code I wrote.)

Writing in the open is deserving of a post all its own. It's changing the way I code! I second-guess things that I would otherwise do without hesitation, like "should I really do [x] to the code?". Or I'll wonder if I should work on this or that particular feature, and so on. Plus, I get a little self-conscious about the code, to be honest.

But forget all that -- I need to work on what needs to be done! And it's not like I'm self-conscious about what I write here, so why should I worry about my code? It's a work-in-progress!

So next up:

First, I need to get quest creation going, allowing the user to build quests using common components.

These components, which I'll write about in another post, basically boil down to quest "parts", like "talk to the villager", "fetch the item", "destroy the monster", and so on.

At first, you'll just build simple quests out of these components, combining them to form parts of a story, writing dialogue and creating special items and dangerous enemies for the player to interact with.

Of course, eventually, I want to get to more macro-level management of in-game resources, including players. But that's something that'll take a long, long time to develop. I need to first develop a very small part of a part of what will eventually be the macro-management interface.

At some point after the quest management interface is at a good place, I'll probably start prototyping more of the macro stuff...but that's later.

I should get back to it. 'Til then, I leave you with the Yukon Song from Calvin and Hobbes. Yukon ho!

The New Style

2021-08-28T19:37:18Z

Adventure Kit needs something to stand out. Now, I have something: macro party management. But what is it? Read on!

Macro party management takes the traditional RPG concept, and flips it on its head.

See, I was going to make a game creation toolkit where you make a traditional game, full stop. You might be able to play around with the party configuration, to make games like Pokemon. You might be able to script quests and pixel-level "cutscenes" ala Final Fantasy VI.

But beyond that, the result would've been a pretty standard SNES-level RPG.

Instead...what if there were multiple characters or parties of characters, whose behavior you could manage at a high level? Where you can tell the fighter characters to go one place and make physical attacks, and you can tell the mage character to hang back and heal the others, but their granular behavior is automated?

Imagine you're the ruler of a kingdom. The queen, king, emperor, grand pubaa, etc. You seek a mystical item, or to destroy your enemy's nation -- the details of the story will be provided by the game creator.

What matters is, there's an overarching purpose to the story, the "main quest". There should be subquests the user defines, some depending on others, and some being side quests entirely...this has been defined in previous dev journals.

You should be able to send different parties on different quests. You should be able to manage resources that the party has. You should be able to define the user's behavior...you get the idea.

More than just a simple resource management game, this could be an entire feudal system in a game. You can have lords below the queen or king, dukes, serfs, or different governmental structures...maybe there's a peasant revolution! Or someone ascends to the throne with an iron fist, and robs the treasury to wage war!

It would be especially cool, if players could start out as an individual fighter and work their way up to being ruler of a kingdom!

This could only happen if there's multiplayer, along with ascension (or descension) of ranks...which gets into a whole web of complexity.

Even so, it's really fun to think about how multiplayer may work in this environment...that's another post, though.

What's happening next is getting into more of the generation of quests, along with management of resources. I'm thinking about splitting up the management of certain resources like parties, gold, items, quests, etc. and making it so you can automate away management of certain aspects...still a lot to think about here.

Mainly, I wanted to record this idea after talking with my friend Dane, and wanted to develop on it a bit and get my thoughts sorted. I'll probably have more to write on the topic later -- for now, check out Dane's latest project, Rasterly!