Three Hundred :: Mechanic #118
  Squidi.net Sites:     Webcomics   |   Three Hundred Mechanics   |   Three Hundred Prototypes
 Three Hundred
   - Index Page
   - About...
   - By Year

 Collections
   - Comp-Grid
   - Procedural
   - Tactics
   - Tiny Crawl
   - Misc


 
PreviousMechanic #118Next

  Mechanic #118 - Net Hacker - Code Cowboy
Posted: 06/13/11

It's Net Hacker, but you have to program your own tools.


  Code Cowboy

I really wanted to make a programmer game. That is, a game where programming was an integral part of playing the game, but something where you aren't simply modding an existing game. Programming is fun. Some of my greatest gaming memories were programming game elements for various MUDs, MUSHes, and MOOs back in the day. But modding represents a niche segment of unofficial support. The player doesn't create the mods. They play mods that other people built. Only a select few actually did the modding. I wanted a game that was about programming.

Pairing that concept up with a cyberspace hacking game was obvious. The other games in this series of Three Hundred entries all factor in some sort of design or creation aspect on top of what would otherwise be a pretty normal dungeon crawling RPG. After all, hackers aren't just cutting up monsters. They are taking apart systems, breaking them, or building them even better. And that's what this game is about. Almost insanely so.

When I realized that I could combine programming with the [#020 - Control Panel] concept, it all sort of clicked into place. This isn't just a game about programming. It's a game about hacking. It's a game that requires you to be smart, to be ingenious, and to be creative.


  The Basic Link

Like the other Net Hacker ideas, you play a cyberspace hacker that navigates around various faux-internet servers as you attempt to bypass security and steal data to sell to the highest bidder. Similarly, you are given a control panel into which you can install chips that represent processes. The difference is, you will write the code that creates these processes.

[cowboy1.png]

Fig 118-1. Two code chips, linking an input to an output.

Each chip contains a single program that communicates with the "outside world" via one or more inputs and outputs, called a Data Storage. Each Data Storage is an array of a known, static size comprised of a single data type (integer, string, byte, etc). The chip that produces an output owns the Data Storage and is the only one that can change the contents of it. There may be multiple input links to a Data Storage, so that several chips may read data from the same source at any time. These inputs and outputs are declared in the chip's program and are referenced by name.

Changes to the Data Storage are broadcast to the listeners. For instance, if value[3] is changed by the owner, all listeners will have a procedure called on them that tells them which input has changed, which index, and what the new value is. This is pretty standard listener stuff. The important thing to remember is that one chip creates a block of data that only it can change, and multiple other chips can listen in to these changes when linked to it.

[cowboy2.png]

Fig 118-2. Chips can have multiple inputs and output links.
You declare the inputs and outputs in the chip's program and then position the various links on the outside of the chip. These illustrations are low res, so there was no room, but each link should also have a label declaring what each link's name is. The chip's size can be changed at will, with larger chip sizes being required for a larger number of links.

[cowboy3.png]

Fig 118-3. Links can be made using wires.
Just to make linking a little easier, you can run wires between links. I'm actually wondering if maybe I should just go all wires, and leave the massive cell-sized links out of the equation altogether. Anyway...

All of this would mean nothing if there was no way to bring new information into the system, or being able to take finished data and do something with it. This is where sensors, controls, and screens come in. These are special, pre-made chips that link your code to the outside world in some way. Sensors create output Data based on the world around your character. Controls, like buttons or switches, are chips with a manipulatable element on top. The output of a control is generally the state of the control (ie for a button, output is an integer array with one element that is 1 or 0 depending on the state of the button). Finally, screens allow you to output text and graphics to the surface of the chip.

This takes on a very basic model-view-controller approach where you take data from the model (sensors, controls) and output it to a view (screens) by writing a controller that converts the output data from one into the required input data of the other. Obviously, this can be very basic, such as converting the 1 or 0 output from a button to a number between 1 and 100 for a gauge. But you can also do some complicated stuff, combining a bunch of sensors together and writing an AI character that plays the game without player input.

Below is a brief overview of some of the more notable sensors and screens.


  Sensors

  • Radar
    The radar gives you a specific overview of your surroundings. It's a string array of size (width * height + 2). The first two values are the width and height of the respective area (as strings). Better radar chips give you larger areas. Some may include more details about the area. The remaining values are a two dimension grid of strings, where each string is a specific name of whatever is found in that cell ("WALL", "ENEMY", "CONSOLE", etc).
  • Pinger
    A Pinger is an active sensor, in that it takes as input coordinates to a specific cell (ie -3, 4 will ping a cell 3 squares to the left, 4 squares to the north). This will return a series of strings that describe that object in detail. For instance, if you were to ping a square that contained an enemy, it might return the strings "ENEMY", "SENTRY", "GREEN". If you ping a control console, it will return "CONSOLE", "DATA ACCESS", "LOCKED". The idea is that you combine the radar with the pinger to create a detailed view of your surroundings.
  • Proximity Sensor
    The Proximity Sensor will change into whatever object is at the specified location adjacent to the player's avatar (so, you'd have a North Proximity Sensor which would change into whatever is directly above you). While it has no inputs or outputs itself, it will take on the inputs and outputs of the object. If you move or the sensor otherwise changes, it will break any links it previously had.

    This will allow the player to interact with his surroundings. For example, if you stand next to keypad, the sensor will change into the keypad, adding an input for typing in 4 numbers between 0 and 9, and one output which will return various stimuli as those numbers are typed in (such as a pattern that changes depending on whether the digits are right or not). The idea being that you decipher the stimuli to crack the code.

    The four proximity sensors should be outside the main control panel, on the edges, rather than chips themselves.

  • Radio
    A radio is a sensor that can be tuned to a specific frequency using input 2. Input 1 and Output 1 allow the programs to send and receive signals on that frequency. You can use this to remotely control enemies, jam communications, or receive encrypted details about the server you are hacking into.
  • Brain
    The brain is entirely output. Basically, you send it a single string, like "GO NORTH", "ATTACK EAST", or "DOWNLOAD SOUTH FILE", and it will cause the avatar to perform that action. At the very least, you'll need four buttons connected to a chip that will convert them to movement actions to navigate the world. Having world interactions through something like this allows the ability for chips to control the avatar as AI.
  • Buttons, Input Bars, and Sliders
    Controls allow you to directly input data into the system. Pushing a button will output a single integer of 0 or 1 depending on whether the button is pressed or not. Input bars allow you to type in text and hit enter to send the text to an output. Sliders have a value between 1 and 100.


      Screens

  • Console
    A console is just a stream of text. It has only a single string input which will be appended to the current text buffer at the end. Consoles keep a small buffer of previous text that can be scrolled up to see. Combine with an input bar to create a command line interface.
  • Map
    A map is a two dimensional grid of graphical objects. Depending on the type of map, it could be ASCII values or icons or even colors. Each one takes a specific sized array of values, and it is up to the programmer to make sure that the values are correct. For instance, you can hook up a radar to an ASCII map to create a roguelike interpretation of the world around you, or you can hook up a radar and a pinger to an cyberspace-style icon map to create a detailed graphical representation of it. You can use these to visualize data.
  • Gauges
    A gauge is simply a representation of data. Most of them take a value between 1 and 100, though some, like LED lights, simply take a 1 or 0. Again, use this to visualize data quickly and effectively.


      Files

    A fourth kind of object is a File. These are small chips that have only an output that consists of an array of values. For instance, a text document might be an array of characters, or strings, while a binary file might be an array of bytes. You can read from a file and then, for instance, output the contents to a text console. Many files will be encrypted in some way, so it may require undoing rot13 or shifting every letter one space. Maybe listening in on radio broadcasts will clue you into what encryption is being used.

    Files are collected by commanding the avatar to download them. A chip representing that file will be created and named on your control panel. Once you have the file, it will be up to you to figure out what to do with it. Files can be created through a File Maker chip. It takes an array of values and will create a chip with that same array as data on the control panel.


      You Build EVERYTHING Yourself

    [cowboy4.png]

    Fig 118-4. Build your own nervous system.
    The idea behind this entry is that you build everything yourself. Even when you first begin, your initial task will be to set up buttons and hooking up a map screen to the radar in order to see and interact with the world. There should be enough leeway that each programmer can do it the way they wish. For instance, you could use an ASCII map to see the world and just type in your brain commands directly into an input bar. Or you could create a very elaborate graphical mapping of the world that keeps track of previous locations, allowing you to scroll around and see the world around you. You could make a minimap that is uncovered as you explore instead. If you wanted, you could hook up some arrow buttons to a map and play a game of Tetris. Examine the details of a file using a hexadecimal mapping in an ASCII map window.

    You build these things and as you get more competent and more creative, you can do more with it. I expect every player's control panel to be completely different, as each player prioritizes and then builds his tools to suit his needs. But more than that, the world around you is fed to you in bits and pieces, and it is up to you to figure out how it all works.

    Looking for a specific file? There are four files all with the same name. Hook them up to a text console. Three are grocery lists. The last one is encrypted. Using a hex examination of the file, you realize that every other byte is a letter. You produce a chip that decrypts the file and outputs it to a File Maker. Now you have the unencrypted file to sell on the black market.

    A key panel will open a gate. You realize that every time a key is pressed, it is broadcast on a radio broadcast and receives an answer. You can listen to the answers and try to hack the code, or you can simply broadcast your own answers, tricking the door into thinking it has been unlocked.

    You don't have to start from scratch every time. You can save chips and configurations of chips for later. By making the inputs generic enough, you can anticipate solutions you'll need later. For instance, you can create a program that will output a specific set of number to a specific radio frequency. Or you could create a general purpose command line tool that allows you to type "SEND 140.14 1 2 3 4 5". Once you've created a really special viewport to the world, share it with others. Create a variety of viewports to see the world in different ways and switch them out as needed.

    You start with nothing but a blank control panel. By the time you've won the game, you'll have hundreds of tools, refined in the field, that you wrote yourself.

     

     





  • Copyright 2007-2014 Sean Howard. All rights reserved.