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.

A Recursive Variant Type in C++

Because one of my goals is to rely on as few external libraries as possible, I am not using Boost. As a result, there comes times when I need to roll my own, extremely useful, library-like code that isn’t a part of the C++ standard yet.

One of these, is the Variant. A tagged union / discriminated union / sum type, that allows you to store multiple data types in one section of memory. A sort of type-erasure gimmick.

I need a type like his for two reasons so far. The first is that my scripting language, space script, is quasi-type safe. You define variables using your usual data types, but any variable type can be cast to any other type.

I did it this way mostly because I was curious to see how a language like that would behave. Probably not the best idea.

I’ve also allowed my Variant type to be recursive. This means that it can contain members of itself. I’ve done this specifically because my data format, space format, is JSON-esque, and basically every node can contain any number of numbers, strings and other objects etc. That’s the second reason I need a variant type.

This took me quite a bit of screwing around to get right. A lot of the code for the base Variant was taken from someone else’s code that I found online. This code was fundamentally broken though; so I’ve fixed it up and allowed for recursion.

I’ll probably do a write up on this at some point. I like it over the boost::variant primarily because I don’t want a never-empty guarantee. I can’t imagine why I’d want a type that doesn’t allow for null-states.

EDIT: Fixed up some of that code.

EDIT 20/05/2016: Fixed up some more of that code.

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.

Back onto the UI – Flowcharts

Now that my scripting language appears to be complete, it’s back onto the UI programming. Most of it is there, one thing remaining is the “Flowchart”.

It’s not exactly a flowchart widget, more like a “nodes” widget.

flowchart

The idea is the eventually you’d be able to add new nodes, connect and disconnect them as you see fit. Each node also contains a function; the purpose if that you can send data from one end to the other; much like my uncompleted noise-machine.

Eventually, you’d be able to use it for things like displaying a tech-tree; except the Player won’t be able to modify it.

Anyway; it’s not clear from a screenshot, but that above runs at about 25fps on my machine. Completely unacceptable. To be fair there is about 198 individual rectangle draw calls there… it doesn’t seem like it should be slowing things down; but it is.

I need to look into why it’s slowing things down so much; and if it’s just because I’m hitting a bandwidth limit; then it’s time to look into batching the draw calls (which I really should have done from day 1). Hopefully the entire UI can be knocked down to a single draw call. Or if I think about it correctly, maybe I could draw just to a texture, or individual widgets as textures to save some calls.

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.