Dammit! I knew this would happen. Sigh.

So I was thinking about the cyberpunk game again. My idea, not the Cyberpunk 2077 one. One aspect that is central to the idea is that players can construct “apps” which they can use, deploy, or sell on the marketplace. I don’t know how to set up an in-game parser to allow users’ to write some kind of pseudocode that is translated to action, but if there was a way to keep the construction in a silo, maybe parsing wouldn’t be so bad.

I thought of a node-based system, kinda like the one shown here in this absolutely batshit-crazy pile of spaghetti:

That’s a little excessive, and is from 3D software Houdini, so not officially relevant to our study except as an example of a node-based system. Take an Advil and let’s move on.

Inspired by The Matrix Online

Oh MxO. You were a game before your time, which happened to be timely, but too early. In MxO you’d find code fragments in the world which could be used to make combat moves which could then be chained together to make those sweet, sweet Matrixy moves in battle. I figure that using such a paradigm, we could allow users to construct their own apps using code blocks.

There would be four basic types of blocks, but each one sub-specialized.

INITIALIZATION

The init block would be used to set things up. It would determine if executing the rest of the app would be worthwhile, and if so, set the app’s initiative order as well as other variables which would be used throughout the encounter. In any app, the init block would be only one that would be called just once, and would always be the first block.

Although called “initialization”, the actions implied by this block wouldn’t do anything on their own. It would actually be initiated when an event is fired, like a player entering a room or a player triggering an app loaded into her cyberdeck.

INPUT

Input would pull in data from an external source. For an NPC app set to guard the port between the firewall and a target mainframe, the input could be to scan the player who entered the room to compare their username to a whitelist. The whitelist would be a file stored in the firewall’s configuration and contains names of users who are authorized to pass. The result of this information gathering would be passed to the next block.

LOGIC

Once the input has been received, it’s up to this block to determine how to act on it. In the previous example, if the player is on the whitelist, then the guard app would terminate further processing. If the player was not on the whitelist, then the logic would hand off to the next node.

ACTION

Action nodes do stuff. Sometimes it’s combat stuff, but it doesn’t have to be. In our example, the guard app would have identified and targeted to the player, and this step would attempt to apply damage to that player. However, an action can also create, delete, move or copy a file from one place to another, send a message to a sysop, or something else that I haven’t completely thought out yet.

In the system, we would have different flavors of most blocks. An Input block might be “Check Whitelist” or “Expect Password”, but no single block would have both. The Whitelist block would look to the path (or the game approximation of “a path”) specified by the player during construction for a file (or the game approximation of “a file”), would open that file, and would compare the invader’s name to those in that file. The result would return TRUE if the user is found, and FALSE if the user was not found, and that value would be passed to the LOGIC to act on. For the Password block, the player would get a popup asking for the password set by the person who built the app and at this point, we shoot off on a tangent because if the player has brought a password cracker app with them, they could use it here if they didn’t know the password. Again, a success would return TRUE and a failure would return FALSE and that value would be passed to the LOGIC node to determine which action to take.

This block-variation is important because while whole apps can be sold on the market, code blocks could also be sold (and might be the preferred option, really). Code blocks also have versions and variations. Versions are improved over time, but like all software can introduce new bugs with each variation. Versions have different stats where stats are available, such as higher damage dealing ACTION block.

This is the general flow of an app, and once the action has been executed a player could tack on another Action — such as write to a log — or execute another Input step — is the target I just attacked still alive? — and then another Logic step — If so, loop back to the first INPUT step. Otherwise, terminate execution. Branching and looping ability is important. Consider a player hacking into a firewall who the guard app has determined is an intruder. After the gatekeeper app attacks, the player takes a turn and deploys an app which spoofs a user on the firewall’s whitelist. As the guard app loops back to the first Input step after it’s final Action (attack) step, it compares the user-spoofing-another-user to the whitelist, and this time the player passes the inspection. The guard app stands down, and the player didn’t have to waste cycles fighting a fight he might not have won.

This looping option is important because we don’t want to have to chain this check in a linear construct, as each block in an app contributes to the RAM and PROCESSOR usage of the machine in which it’s installed. If a player wanted to make a supermassive catch-all attack-and-pie-making app, he could! But it might not run on his current cyberdeck, or it might be the only thing that can run. A player would end up having to make a decision between a really awesome, pretty effective loadout, or a Swiss Army knife survival kit for who-knows-what that might save a her bacon when hacking a tough node.

This is really just a quick pseudo-examination of what a node-based programming option could be like. I was surprised that I was able to logic my way out of creating more blocks, which means I probably would be surprised that I actually need more blocks should I try and build something like this for real. I like the ideas here, and I think a node-based model would make the process more accessible to all players, rather than having to learn some kind of fake programming language.