<\/div>\nIt didn’t hurt that I had some experience making space ships from floor plans. Back in 2007, I started working on a 3D model of a spaceship based off of some bitmap floorplans designed as headquarters for a Starwars fan-fiction group. The project was never really “finished” because there was never really a goal. It was mostly motivated from “wouldn’t it be cool to have a 3d model of this whole spaceship that we’ve been writing stories about?<\/p>\n
<\/div>\nSo I figured it wouldn’t be any trouble to have the computer build the space ships instead of doing it by hand.<\/p>\n
It Was A Lot Of Trouble<\/h3>\n
Turns out I’m a crazy person, and the project stalled out. But not before producing what I am resurrecting in this article.<\/p>\n
You see, I began working backward to a starting point, simplifying over and over until I had something I could wrap my brain around. The star-trek guys started with the Enterprise C, which was an iteration from the B, which was based on the A which was, from the looks of it, based off a toilet seat cover and some toilet paper rolls. A “shape first” approach. Which, when all you really need is the outside of the starship, is a fine place to begin. Sure you have the problem of having the geometry “read” properly as to scale and function, but those are problems with potential solutions, as I have been attempting to demonstrate with this series so far.<\/p>\n
So, me being disagreeable, I decided to start at the other end. With the internals. I didn’t just want to wave my hands at the problem and say “it has space magic technology that goes “vroom” and “pew pew” when it needs to.” I wanted these ships to make real sense. The Enterprise D had a crew of 1014, but what did they all do? What was the skeleton crew? Sure, there were 4 staff on duty in the sick bay because that makes for good drama when one is a main character, two of them are holding down a patient, and the last one gets killed by the disaster of the week, but I wanted more technical answers. I wanted to be able to perform a calculation!<\/p>\n
So I built a calculator.
\n
<\/div>Well, technically I used a giant absurdly powerful hardware calculator to run a calculator based calculator platform to run a different software calculator to iteratively program another, different, smaller, less powerful calculator. In the engineering business, they call this:<\/p>\n
Re-inventing the Wheel<\/h3>\n
And while it’s often used with a deeply derogatory connotation, and while that connotation was probably appropriate in this case, there are certain advantages to re-inventing the wheel. Sometimes, the wheels you need just aren’t readily available! Sometimes you want to better understand the wheel instead of just buying one off the shelf! And sometimes the wheel you want to re-invent is a super-ordinate meta-wheel which, as it rolls, stamps out other smaller wheels. You also shouldn’t try to re-invent the metaphor.<\/p>\n
Get to the Point Already!<\/h3>\n
But that’s the point, isn’t it? Once I started making a calculator for calculating how many crew cabins you would need in an arbitrary space-ship, I realized it was a very small step to making a calculator for calculating how many abstract production groups you would need in an arbitrary resource network balancing system. So I did that, and it worked fairly well.<\/p>\n
Before further excursions into madness, I’m going to mention that rockets have a bad problem that, while not unique to them, is at least fairly uniquely bad for them, where they need to carry fuel, and the more fuel they carry, the more fuel they need. This calculator was designed to solve just this sort of iterative self-referential problem.<\/p>\n
But then I had a further realization that if the calculator could be based on nodes, which in turn could contain other nodes, then it would be able to calculate everything. And if I could calculate everything, then I could:<\/p>\n
Procgen Everything<\/h3>\n
Don’t you see? It’s all so elegant! The basis of a net-production network undergirds all sustainable systems, and when non-sustainable resources are given abstract trans-finite sources, one can calculate not only the spatial dimensions, but the temporal dimensions as well! N-dimensional computation would be trivial! Every problem had only to be defined as a linearized solution space! And even non-linear solutions could be approximated by a set of discrete linear segments, represented by nodes! The spatiotemporal output maps onto an effectively infinite set of implementations, allowing for style and preference, all based on a single unifying ruleset used to generate the nodes! It could:<\/p>\n
Procgen Everything<\/h3>\n
And you could procgen game mechanics, and time itself, and minds, and stories! The possibilities!
\nDo it!<\/p>\n
Procgen Everything!<\/h3>\n
Ahem…<\/p>\n
<\/div>So, that was ten years ago.<\/p>\n
I still hope to be able to procgen everything. At some point. I’ve written<\/a> in fits and starts about it from time to time, which you’re welcome to read if you like the craziness of the above.<\/p>\n But in the meantime, I’ve made tremendous strides, and today I am happy to announce that the calculator can very nearly handle nested nodes. I mean, it definitely works for nested nodes, but it can only solve one layer at a time, though it should be a fairly trivial to add the ability to…<\/p>\n Ahh, see, there I go again.<\/p>\n