#gridbugs

The ISOs are thinking, conscious lifeforms with DNA-like code, far more complex in their structure than ordinary Programs. They were somehow spontaneously generated by the Grid, and I have previously mentioned that I believe this was caused by Kevin Flynn’s presence, that some of his biological material was somehow absorbed by the Grid, giving it a blueprint from which to generate new lifeforms. I have one theory where this happened simply by Flynn hanging out and interacting with the Grid for an extended period of time, and another theory where it was caused specifically when Flynn created Clu, making Clu the original proto-ISO.

Either way, the point is, the Grid itself, consciously or unconsciously, generated the ISOs from Flynn’s biological structure. My new theory is that this was not, in fact, the first time that the Grid had birthed lifeforms, just the first time that it could create something this complex, since it now had a complex enough blueprint to work from.

The Grid, both in the ENCOM systems and in Flynn’s new system, had always had the potential, and perhaps the will, to generate its own lifeforms, but before Flynn’s appearance, it could only create far simpler creatures, possibly based on the codes of the User-made Programs. These creatures were small, simple-minded, perhaps only with animal instincts, but to compensate for this, there were a lot of them. The Grid’s urge to create life made it generate more and more of these tiny, hungry critters. Swarms of them. They weren’t something the Users had intended for, and they caused problems when they came into contact with Programs. They were a kind of strange glitch. Bugs. Bugs from the Grid. Grid Bugs.

In the beginning of Tron: Betrayal, Flynn’s newly created Grid is beset by huge swarms of Grid Bugs devouring everything in their way, causing all kinds of chaos and destruction. Clu believes that they’re somehow connected to the ISOs. And maybe he’s right. Maybe the birth of the ISOs was preceded by an increase in Grid Bugs generation, as the Grid struggled with the strange new information it had received from Flynn’s genetic code, trying to make sense of it, trying to figure out what kind of new, complex creatures it could generate from it. The chaos these swarms caused were, in a sense, the birthing pains of the ISOs.

(about Sark from Tron 1982)

I said "Come to the Sark side, we have cookies (the kind that spy on your computer)"

It was supposed to be a little throwaway joke

But now it keeps coming up in my mind

....And I keep thinking of this

...That's what "cookies" look like inside the Tron Computer World. Little disguised gridbug spies.

Map Generation in the 7DRL Get Well Soon

I’ll talk about the actual 7-day roguelike game itself eventually, but this dev blog post about using WaveFunctionCollapse to generate levels caught my eye for both the technical results and the description of the process of working with a PCG algorithm.

I’m always interested to see the processes that other developers use: what problems did you run into, how did you approach solving them, why did you make those particular design decisions?

For the use of WFC specifically, the two things that caught my eye here was the emphasis on the image-based pipeline for prototyping with WFC and the use of additional constraints.

In my opinion, one of the most powerful aspects of WFC for PCG development is that the interface can be entirely based on the images you give it. Rather than writing rules or dragging sliders around to find the right numbers, you can use the intuitive interface of painting what you want the thing to look like. In practice it’s a little trickier than just painting an example, since it learns long-distance relationships and particular constraint rules from the image, which can take a little getting used to. But the main point is that an artist, with no understanding of the code, can start playing around with it and gain an intuitive understanding. At the same time, an expert can fine-tune the output with the same image-based interface.

Being able to play with the inputs to a generator is a massive productivity boost. We go from painstaking experiments, moving one knob at a time, to trying whimsical combinations that open new possibilities.

At the same time, the image-based interface does have its limitations: some things are more easily expressed in other ways. We still want to use the image-based interface, but at the same time we want our images to have an additional layer of information: for example, making sure that the rooms we generate are eventually connected with the front door. In this case, some of the added rules were removing the fully-white tile from the adjacency rules and adding some additional border-selection logic. These can be added, and I’ve implemented variations on this myself--but, of course, one of the strengths of WFC is that you don’t need to know the code. (Which is why one of the things I’m working on is trying to find effective ways to express new constraints in WFC, to make it integrate better with a pipeline. But that’s a topic for another day.)

Now this has me wondering whether Gridbugs are capable of the same kind of literally-compressed running or general motion and characteristics.