Bringing bits together

I’ve now got what’s shaping up to be a pretty good UI system:

  • The UI styling is defined via data in space-format (JSONish)
  • The layout of the UI is then defined by a second space-format file:
  • Then the “actions”, in the case above the single button, are defined in a space-script file:

    Basically, the UI Layout says the button will execute the function named “SeedButton”. That function creates a new button that will execute the function named “OutputNum”.

This all works well, surprisingly. The only gap is that every “execution” of the script, or execution of a function in the script, is completely independent of any other execution. Meaning that I can’t store information between button presses, at least not in the script.

To get around this, I’ll likely implement a key-store as a regular Engine Function so that scripts can store information for later use, even when it’s only ever needed by the script.

I didn’t think of this before because I only ever imagined scripting things like enemy behaviour, which would just access and set what it needed to.

Coupled the scripting engine with the UI engine

I’ve now managed to get the scripting engine working with the UI engine. This means that the UI can now be completely defined outside of the game-code, in run-time language files. Should result in quick changes to the game UI when it comes to it; and even modding etc.

Arrays Completed 75%

Arrays can now be declared separately from it’s definition. So

will now work.

I’ve also added two new operators; “array push front”, which looks like
-> , and “array push back” which looks like <- . The idea is that it’s pointing from the left to the left-most element, meaning push front and the alternative pointing from the right to the right-most element.

Next; because arrays are now effectively dynamically sized, I need some inherent way to find the size of an array. Like a .size  member or something…

Arrays Completed 50%

I’ve now finished implementing arrays in my scripting language. For now, they’re not dynamically sized, and they need all their arguments when first created.

I.e. you need to write:

You can’t write

You can otherwise access array elements and update them as necessary. All regular automatic type conversion is handled. So:

Will work. However, it does it a bit of a round-about way. The first element in an array value, everything between the {  and }  is used to determine the type of the array. In the above case it’s a string array.

Then, each subsequent element is type-converted to this type. So this becomes an array of strings.

Then the assignment of a string array value to an int array variable will cause a conversion from a string array to an int array.

If the first element was an int and not a string, only the first conversion takes place.

But, this allows me to keep the any-type to any-type conversion I wanted.

Interpreter Works

The first go at writing an interpreter for my compiled opcodes is working.

Great result. Now I basically have a working scripting engine, I just need to polish up the code and a few little bugs here and there (“-1” is read as “negative one” or “minus one”).

Scripting Language Updates

I’ve managed to put together a scripting language compiler that has the following features:

  • Native data types: bool, string, char, int + float (I need to add vector types)
  • C-like syntax
  • Functions
  • Automatic POD casting. I.e., every data type can be casted to another. This will be true even when I add classes or structs, not sure how…
  • Ability to call “Engine” functions. I.e., you seed the Compiler with possible function calls that can be made of the platform

The compiler converts something like:


Which should be very simple for a Virtual Machine to run through and execute. You can see that no optimization has taken place; I’ll probably think about doing that after getting it to actually run.


I’ve just completed a Lexer in order to produce a stream of tokens for the Parser.

There’s some parts of the Dragon Book which I don’t really understand the reasoning. Such as the Lexer adding info to the Symbol Table… why would it do that? It’s the Parsers job to build a syntax-tree, that seems like the correct place to add symbols. The Lexer is complicated enough just producing a stream of tokens.