After finishing Almost Infinite, it was time to reevaluate the tool/engine and see what to do next.

A huge part of this was realizing throughout the process that we really needed the code that actually made up the nodes to be more dynamic. The node system I wrote was just too verbose and I was getting killed by rust recompile times, so a change was gonna have to be made (after finishing the demo, of course, hehe). I started thinking a bunch about a scripting system, considered JS and Lua, considered making my own DSL etc, and then stopped thinking and worked more on the demo :)

That is, until Thursday before Solskogen, where Blueberry/loonies was staying over at my place. I was mentioning that I wanted something more dynamic but that I wasn't sure an entire scripting language/system made sense, and he suggested I take a look at his 4k tool again.

Now, this tool was nothing new to me; I've seen them use it a few times and it was documented in a Zine article a few years back, but I don't think I had ever looked at it so much in detail. The general gist is that you have operators which are placed on a grid. These operators can do basic things like change a transform matrix, draw an "object" (whatever that means is determined by whichever renderer the tool works with), define variables, basic loops, etc. This grid of operators then gets compiled down to a bytecode, which is then JIT-compiled in the intro and executed.

Now, I'm also not a stranger to grid/operator-based tooling; the screenshot for this entry is actually a shot of my old 4k synth from many years ago, where various synth devices were placed on a grid to determine how they would be routed together. But this system seemed to have the right balance of simplicity and expressivity, and seeing as they've successfully used it themselves for nearly 10 years, it was definitely something I had to take apart.

Anyways, right after the party I started to get to work (been pretty amped on this idea), and at this point, all I've really done is torn out the node system from the current tool (LOTS of code deleted, haha) and prototyped a little grid representation/compiler, but I've got a cube on the screen, so that's rad :) but in terms of how the design will change it's a bit too early to tell; I've done some things on paper that I'll talk about soon (probably next week) and I'll have to implement more to see if they're good ideas. But the current plan is really to adapt that kind of tool/workflow to our 64k engine and see how it goes. If nothing else it should solve some of the workflow problems the tool currently has and still be quite dynamic, without being an enormous engineering effort.

Oh, and I also played around with some technicals that will become the JIT if that ends up happening, which you can see here. Really all it does is dump some hardcoded x86 into memory and call it, but hey, it's a start. The coolest part about that, though, is that I had a bit of trouble getting it to work as I didn't know executable bits of memory had to be page-aligned, so I went to twitter and this super awesome thread of amazing helpfulness by awesome people happened. So cool!!

Until next time :)

Last Edited on Sun Jul 24 2016 16:08:15 GMT-0400 (EDT)