It’s out. It’s done.

Break;out is weird game jam scale project. It’s a programming game really. I ended up here as I had been noodling around with a language, ulox, and reached a point where I was unsure if the changes/features I was considering were actually going to be useful. The only way to know for sure was to just starting using the language for real.

So let’s talk about some of the perhaps less glamorous parts of a language/library that came up in actual use.

Overlooked Niceties

A grab bag of helpers that were just missing. Telling a collection to grow or resize or shrink to a certain number of size. These could be done imperatively with while and add/remove but it didn’t feel at home in this scripting context. I wanted to be able to be a bit more declarative.

In a similar vein, maps had crud but the lack of ReadOrDefault was hampering. Especially when dealing with results from searches or returns from native functions.

Clumsy looping

There was a lot of for(var i = 0: i < someCollectin.Count(); i+=1){…}, and when they start nesting and using i,j or x,y. A loop keyword and construct was added to simplify a lot of those down to loop(someCollection) {…}. It provides i, and item by default, but can be given custom names.

It removed a lot of clutter/boilerplate, makes clear intention, actually runs slightly faster, and removes a lot of places that would be a chance for a copy paste error.

Tests and Factories

Ulox has testing features, but writing tests around objects that were default expecting to have references to unity objects and to execute logic or synchronisation on those unity objects was a blocker for writing tests around things like the ball or the paddle classes. Mocking in ulox is very straight forward as everything is late bound, but global functions like CreateGoFromPrefab being in an object init would cause objects to be made during at test that shouldn’t be.

While a bit heavy handed the change was to introduce Factories as a standard part of the vm environment. This moved the responsibility of creating the object references between ulox objects and unity objects to the factory, not the object itself. Tests can then just init the objects like normal and mock things. Where as the Breakout class for example can use the Factories to create objects, and if we want to test those methods, we can temporarily replace what the factory does during the test.

Better failure messages

During previous work on the language, while there were informative errors, they lacked a lot of context. When there is an error in a script that’s 10 lines long, the line number was enough to go on. Now with over 10 files being run, needing to know which function and which ‘file’ the error originates from became critical.

Inline data

I really wanted to be able to create a brick layout from an array that you could just look at in text. But that’s wasn’t very intuitive when all you had was new [] and .Add(). A 3x5 level would require 18 lines of code, 15 being a call to Add. Adding inline array creation to the language was surprisingly easy. Detect it’s happening, which is [] vs [1]. Simple enough. Once detected just emit the code to do the Adds in the compiler. User can now do

var lvl = [
[1,1,1,1,1,1],
[1,1,1,1,1,1],
[1,1,1,1,1,1],];

much easier to read.

This also let to adding data source tests to ulox’s native testing features. Greatly reducing the lines of code required for math types.

Game Modes

I wanted to be able to change the game mode and levels via script. Levels were fairly straight forward, we split out the level generation code and run the script to use the level generators in a specific way per level.

Game modes where not unsimple but making a script or class per game mode, allowed to create different games entirely within the scripting system. It’s not a new idea, but putting all gameplay rules in script was a wonderful breathe of fresh air.