Starbase - Programming In Space? Pre-Alpha YOLOL Guide

There's a new programming video game in development that's caught my eye, and that game is Starbase. In this video, I want to do an in-depth review of what we know so far about YOLOL, the in-game programming language, as well as talk about Starbase's potential for helping beginners learn how to program.

Links

YOLOL Wiki: https://wiki.starbasegame.com/index.php/YOLOL
Devices Wiki: https://wiki.starbasegame.com/index.php/Devices_and_machines
Cylon YOLOL fan group (check out their Discord): https://github.com/Jerald/yolol-is-cylons

Correction @ 8:26 the execution does automatically wrap around again. "The chip will begin executing line 1 again after the last line has been executed (unless the last line contains a goto statement or execution has been paused)". @ 9:46 I'm told we can use parentheses.

If you haven't heard of Starbase yet, it's an MMO, set in space, where gameplay is focused on building spaceships and stations, trading designs and resources, and of course trying to blow up other people's creations.

Starbase is set to be released later this year, with early access hopefully starting soon.

So as an aspiring programmer, why should you be interested in this game?

In Starbase, as you build your ships and your space station, you have access to a wide array of different devices you can install on them. And each of these devices has properties that you, as a player, have access to, both for reading and writing. 

Now to power your devices, you must connect them to a power source, something like a battery or generator. And I mention this because these blue cables that you lay transmit not only power, but also data from every device on the same network. This allows you to add a button device that can control, for example, whether your light is turned on or off. Or, as shown here, a lever that controls the color of your lights.

And this is the part that gets interesting for programmers.

The logic that controls what a button does isn't built into the button itself, rather you must write the logic for it on a programmable chip. And these chips can be used to not only control simple things like a light switch, but to automate all aspects of your ship. You can even automate entire factory production lines to produce salable goods. This is possible because these programmable chips are able to read from and write to every device on the same network. And by changing the properties on those devices you can get work done: whether that's turning on a thruster, or moving a robotic arm, or firing your weapons.

Now for programming these chips, FrozenByte, the developers of this game, have created a brand new programming language that they're calling YOLOL. So let's dig deeper into what this code looks like and how it works.

To make sure you have enough context, I'm going to break down this recently released video from the developers that shows how you might set up a tripwire to make a light blink.

In the first part of this clip, you can see the player is installing a range finder device on his ship that crosses in front of the doorway. After it's installed, he manually adjusts the properties on this device. The first field he's editing is the "RangeFinderOnState". And you can see that you're able to edit both the value, where 1 is on and 0 is off, and you can also change the name of this property. This is important, because this field name becomes the variable name you use to access this property when you're writing your YOLOL script. If you ever forget which property this variable is referencing, you can always look down at the field details and see the "Local Key" to see the original name of this field.

So this player has renamed the "RangeFinderOnState" to just "Range", and the "F" property down here, if the player were to click it, you'd see that this is the "RangeFinderDistance" property. So you can see initially the player turns on the range finder by setting "Range" to 1, and then he sets "F", which is the distance property, to 25 so that the initial value matches the "RangeFinderSearchLength".

The next thing that happens is you can see this laser range finder exceeds the distance inside the cargo hold of this ship. So now when he opens the device tool again you can see the measured distance, the "F" value, has changed to 16. So he decides to adjust the "RangeFinderSearchLength" to 9. So now you can see the beam stops short of the opposite wall.

And this is a good time to point out, too, all the blue cabling inside the ship. These are the power and data cables. The range finder device, the lights, and the chip socket device we're about to see, are all connected to each other and to a power source via this network of cables.

So now we get to see the code controlling these devices. This outer frame is actually the chip socket. The socket is what gets bolted to the ship and is connected via the blue cables to the rest of the network. Inside the socket, where you see this code, is a removable YOLOL chip. These chips are what you write your code on.

Let's take a closer look at this code written here. You'll notice the first line begins with an "if" statement, and it's checking to see if the value of ":F" is less than 9. In YOLOL, you use colons to prefix device fields and external variable names. So this ":F" refers to the "F" field we saw earlier on the ranger finder device. You can also create local variables, ones that exist only in the scope of the YOLOL chip, that won't have this colon prefix.

So we know that ":F" refers to the measured distance of the range finder device. And you can imagine if we had multiple range finders on this network, we could give each one a different field name for the "RangeFinderDistance" property, so that in code we could refer to just the measured distance on one of those devices. Or we could presumably give them all the same field name if we wanted to check all of them at once, but it's still unclear exactly how that would work.

So if the measured distance ":F" becomes less than 9, which is what would happen if someone stepped in front of it, then we have a "goto" statement to skip to line number 2. "Else" we just want to run the first line again. So you can see how this code creates a sort of infinite loop, where it just reruns the first line over and over again, in a holding pattern, until the condition changes. 

And when it does change, and jumps down to line number 2, this ":Light" variable here must refer to the "LampOn" field of the overhead light that will be flickering. And you can see that's achieved simply by changing the value back and forth from 1 to 0.

And this code works because each line of code takes 200 ms, or 0.2 seconds, to execute. So there's a built-in delay between the execution of each statement. And this delay is both useful and limiting at the same time. You can see in this code, when the laser tripwire is broken, that it just alternates the lights off and on on each line. And this will create that flicker effect because we have the 0.2 second delay between each line. And you can actually create longer delays simply by adding blank lines to your code.

But you can imagine there will also be times when you wish this execution would happen faster.

And this isn't the only limitation either. You'll see that this YOLOL chip only has 20 lines available. There's no scrollbar here for more lines, you actually are limited to just 20 lines per chip, and also 70 characters per line. Now the line limit can be overcome somewhat by using multiple chips in tandem, and I want to come back to that, but this character limit is also interesting because it encourages you to keep your variable names small, like we saw with the ":F" property. 

Which I think is going to lead to a lot of sophisticated code, like this manufacturing example, that's incredibly hard to read. So while this is something that could make the game more interesting for experienced coders, it will probably be a detriment for people who are just being exposed to code for the first time. Because it makes code much harder to read.

Let's change gears here as I want to go over the YOLOL language highlights, some of which we've touched on already.

• Code is executed 1 line at a time

• 0.2 second delay between the execution of each line

• Pressing play runs your script once from top to bottom

  • You can use goto to have a script run indefinitely

  • You can pause a script

• Max 20 lines per chip

• Max 70 characters per line

• Execution wraps around from line 20 to line 1 

  • Unless you explicitly change it with a goto

• You're allowed to leave lines blank to add further delays

• Comments exist

• Case insensitive

• Two variable types: decimals and strings

  • No nulls

  • True/False can be used to mean not-zero/zero

  • Three decimal points of accuracy

  • You can use decimals like integers by leaving off the decimal point

  • When you mix variable types, they’re all treated like strings

• External variables and device fields are accessed using a colon prefix

  • :variableName

• You don't need to specify a type when declaring a variable

• Error handling

  • Syntax errors result in the entire line being skipped

  • Runtime errors will only stop further execution on that line when they occur

Now let's look at the list of available operators.

You can see the language uses a basic assignment operator, just the single equals sign. It also has all the basic math operators you would expect, along with the handy increment shortcuts, and a few more advanced math functions, including trig functions. 

For the logical operators there's nothing too surprising. You can use the keywords "not", "and", and "or" to check multiple conditions, and I'm told we can use parentheses to group those together. These, of course, will mainly be used in conjunction with the "if", "then", "else" statements, but will also be useful for assignments.

In place of loops and functions, we'll have to get used to using "goto". And then we have comments, using the standard double slash, and that's pretty much it.

Now let's talk a bit about how you would build a more complex system using multiple YOLOL chips.

There are three different types of YOLOL chips: the cheapest one has a limited set of available operators, up to the most expensive kind which has access to all the fancy trigonometry functions.

There is also a special type of chip called a memory chip. These appear to be vital for multi-chip YOLOL systems. They allow you to store messages for data sharing between the chips, as well as for just normal data storage. They can store up to 10 key/value pairs each.

To join together multiple chips, you can either layout an array of chip sockets like you see here. Or you can use modular device racks, which are purpose built for this function, and are much more compact.

Now by default, each of your YOLOL scripts is going to run in parallel, which can certainly give us a speed boost, but, in a multi-threaded environment like this, we also need to be very mindful of race conditions and other issues associated with parallel programming. This is another aspect of the game I suspect will be difficult for new programmers to grapple with.

But by using the memory chips, it won't be too hard to get multiple chips to run serially instead, and I could see that solution becoming boilerplate code that gets passed around quite often.

The only thing I think I haven't covered yet is the network relays. These are devices that allow you to split up networks into subnetworks by limiting the flow of data to just one direction. I imagine this would be especially useful in a large factory.

If you're having fun imagining what might be possible inside this game, you should check out all the different device types listed in the wiki.

Of all the devices I've looked at, Generators, which are the powerplant for your ship, have the most amount of fields associated with them. So that makes me think they might be really interesting to write code for. As far as weapons go, the missiles I think have the most opportunity for a superior coder to really show off. And of course there's robot arms, thrusters, information screens...

But the thing I'm most excited about are actually the Radio transmitters and receivers. The transmitter can control both the range and frequency of the message it sends. And the receiver is directional, and it can scan across the different wavelengths. 

So there's an opportunity, number one, to connect multiple computer systems together across great distances, which you could do all kinds of crazy things with. And, number two, there's the potential to intercept other players' transmissions, or maybe even send a virus-y signal their way? Which is all speculative, but very intriguing. 

So, for experienced programmers, there's a lot to get excited about in Starbase.

Hardware assembly is something that you don't usually need to think about as a modern programmer, but in Starbase that's going to be half the challenge. And working with limited resources, I think, will give the whole experience a very old school programmer vibe. 

Here we have to worry about memory and speed on a very small scale, which is not typical for most application development these days. And the limited language features, plus the inherently parallel nature of programming in the game, is going to make this feel very different from a day on the job.

But this game can't be successful if it's appealing only to professional coders. It's got to bring new people along as well.

So if you haven't coded much before, and you're wondering what is the potential of this game to teach you real programming skills: well we just don't know yet.

It should definitely help you to think in a logical way, to think about data flow like a programmer does. You'll get comfortable using variables, and manipulating data; with writing if statements.

But it's also missing some key features that you need to know how to use as a serious programmer:

• Traditional loops (that don’t rely on goto)

• Data structures (like arrays and dictionaries)

• Functions

• Classes

These are fundamental concepts that YOLOL won't teach you anything about. And of course, you're also not learning version control, how to use debuggers, command lines, and all the plethora of tools programmers use to get work done.

YOLOL isn't a fully featured programming language, and nobody is going to hire you because you can write YOLOL. 

But it is much more advanced than the types of in-game programming that we usually see inside of a video game. So I'm hoping that this will be something that's fun, and something that gets new people interested in exploring programming further. And I hope it's going to be a good starting point for beginners who haven't been exposed to much programming before.