An Ode to Terraforms
The Programmer's Guide to the Hypercastle - Exploring the most technically impressive NFT project to date...
When I first got into NFTs, I was drawn by the core ideas behind the technology, and the endless applications that could be built upon it. But I quickly got sucked into the dopamine hits from trading NFTs and lost sight of what pulled me into the space. After diving deeper into Terraforms, I feel inspired by the ideas rather than the flips. Terraforms is such a dense project and it can be quite intimidating at an initial glance.
Terraforms is both impressive conceptually and technically. It’s pioneering a new medium of art — “code as art”, “runtime art”, “network art”, or “EVM art”. In this post, I’ll attempt to explain what’s going on with this project and why I find Terraforms to be a truly innovative piece of art.
We’ll be peeling through the project layer by layer like an onion, starting from the immediately visible, diving into the abstract forms that cannot be visually seen, and finally, the conceptual implications reflected in the code. Since the post is quite long, please skip ahead to relevant parts you find relevant. Here’s the overview of the contents:
What is Terraforms?
Layer One — The Immediately Visible
Layer Two — 3D Representation
Layer Three — Hyperstructure and Code
a. How tokens are computed
b. Software design and composabilityOn Art
What is Terraforms?
Before we go through layer by layer, let me summarize what I believe Terraforms is today.
At a technical level, the Terraforms contracts attempt to define a data schema or blueprint for what a generic metaverse structure, land, space, or place could look like. It then uses this schema to create a conceptual structure, with all the raw data required to render the structure pushed onto the blockchain. Lastly, it has an API (application programming interface) that includes all the functions necessary to interface with the data and structure.
At an artistic level, it’s an experiment exploring what it means to have an interactable, ever-changing, abstract hyperstructure that’s immortalized by Ethereum. A computer program that invites people to interact and play around with.
If some of that was confusing, don’t worry. We’ll be going through each point more in detail below.
Layer One — The Immediately Visible
The immediately visible is the representation we see on platforms such as OpenSea (defined by the output of the contract’s tokenURI). On this level, each token (“parcel” or “plot” as the creators and community like to call it) is a colourful generative art piece constructed with a unique character set. All the data and algorithms required to render the visual are stored on Ethereum, making this a fully on-chain project (which will be discussed later).
The visual is constructed with a few major components which we’ll briefly go over:
Zone: This defines the colour palette. Many zones draw inspiration from iconic colour palettes in pop culture. For example, the Hypermage zone colour palette draws inspiration from Radiohead’s “Kid A” album cover. Here’s a list of other zones and their inspiration.
Biome: This defines the character set that’s displayed. The team selected a wide range of unique and quirky Unicode characters for the project.
Chroma: This defines the animation type. There isn’t a lot of variety in this trait itself, but after factoring in character cycling speed, animation speed, and where animation is localized, there’s actually a surprising amount of variety in animation.
???: This property contributes to determining whether or not a cell gets its characters changed or cycled through, dictating the flow of movement of the animation. It can be very difficult to visually tell the value of this trait. Interestingly, the variable name in the contract for this field is
resourceNameand the contract has functions to change the naming and contract address.Mode: This defines the state of the visual representation. The tokens are in “terrain” mode by default, but the owner can flip them into “daydream” mode, which turns the token into an interactable drawing canvas. Lastly, you can commit the drawing onto the blockchain, which turns the token into “terraform” mode and changes the display. Once in “daydream” or “terraform” the token’s mode can be interchanged, but will never be able to revert back to “terrain”.
Layer Two — 3D Representation
In addition to the visual that’s displayed on NFT platforms, each token itself is a slice in a bigger structure, hence the community likes to refer to these tokens as “parcels” or “plots”. The visual on platforms like OpenSea is a top-down rendering of this parcel. Together, all the parcels combine to form the larger structure that I’ll call “Math Castle”.
This means that each parcel has a topography as well as properties that define its position in the 3D representation:
Level: This property is seen in the token name and it represents the level this parcel belongs to. Level 1 is the bottom and level 20 is the top
X coordinate, Y coordinate: This can be found both in the name and the properties. It is a coordinate pair specifying the position of this parcel in the level it belongs to.
Topography: The topography isn’t encoded in the properties, instead you have to query it directly from the contract (the function is
tokenTerrain). The more interesting thing is that topography changes over time as cells oscillate up and down. It’s almost as if the entire structure is “alive”. In addition, there’s a built-in decay mechanism that collapses the terrain over time. It’s an interesting play on Ethereum’s eternalness and immutability, as the Math Castle has a built-in lifespan.
Now that we know the parcels together form a 3D world, what does it actually look like? You can play around with the entire structure on this interactive browser visualization built by community member 0x0112. Unfortunately, as of today, there isn’t a time-series visualization of the structure that incorporates the vertical oscillation and decay of the structure which happens over time.
Once zoomed out we see that all the parcels form a virtual world, the project appears so much more impressive. I have many questions about what the creators originally intended the properties to represent. What are biomes and zones supposed to represent? Are they analogous to natural habitats and landscape types? What about the ??? field, and the cycling of characters? Those cells have movement, could they represent liquids such as something like water? But, so far the creators have been mysterious about their intentions and the interpretation is entirely up to the individual.
Layer Three — Hyperstructure and Code
Now we get into the meat of the project. Most NFTs today are cosmetic (ie, links to JPGs) and don’t leverage the true power of the technology in that the NFT token contracts are effectively open-source computer programs. Terraforms, however, is created with that concept foremost in mind. The project reminds me of the classic software engineering meme — for many software, what the user sees (in this case, the visual you see on NFT platforms) is merely the tip of the iceberg hiding a tremendous amount of code (the Terraforms contracts itself). Honestly, this concept applies to art as well—where what you see visually is often just the packaging of a much more complex idea and thought.
The contract for Terraforms is fascinating to read. It’s impressive to me that the core artistic idea and hyperstructure are clearly apparent in code, which is incredibly challenging technically. I saw the term “hyperstructure” in an essay by Jacob from Zora (which I highly recommend reading). In the essay, Jacob defines hyperstructures as “crypto protocols that can run for free and forever, without maintenance, interruption or intermediaries”.
Since I’m not a 3D or game developer, I am no expert in virtual world design and can’t speak for too much on the effectiveness of this data schema and dataset in representing a 3D world. Instead, I’ll talk more about the data, abstractions, design decisions, and functions from a general software engineering perspective.
How tokens are computed
First of all, let’s talk about how the token data that dictates the first two layers above are computed on the blockchain.
The primitive raw data used to construct the layer one visuals are stored in two contracts. The biomes, which are Unicode characters are stored here and zones which are colour codes in hex are stored here (we’ll refer to these as raw data contracts).
Next, there is a contract (we’ll refer to this as the structural data contract) that defines structural constraints, which describes what the 3D shape of the hyperstructure generally looks like. It specifies the topography limitations of every level, how many levels there are, how many parcels are on each level, what biomes and zones are found in each level, and the animation properties for all parcels.
Finally, to add a natural feel to the animation, topography, and layout, a Perlin Noise library is pushed on-chain. To be honest, I didn’t look too deep into how the algorithm actually works since the details of the algorithm are not that interesting to me. But the fact it’s pushed on-chain and well abstracted makes it a black box that doesn’t need to be understood in detail to understand its impact.
To tie all these pieces together, there’s a contract (we’ll refer to this as the rendering contract) that provides functions which take two user inputs and generates any information and animation of a parcel in the structure. The contract uses the raw data, the structural constraints, and the noise mentioned above and does this generation on runtime. This is important because the structure, and thus individual parcels, change slightly over time. Unlike most generative art which has fixed output, you’ll only know what the parcel looks like at the given moment you call the functions. All the user needs to provide is the seed (a randomization number) and placement (a number indicating the position of the parcel in the hyperstructure).
Since the seed is just a number used for randomization, the rendering contract implies there are infinite Mathcastle hyperstructures in existence (ie, you can query with another seed and get a slightly different Mathcastle). It’s kind of like the multiverse, though the hyperstructures all look similar. However, the canonical widely accepted one is the one generated with the seed defined in the core Terraforms contract (the seed is 10196), which finally brings us to the NFT contract.
When minting the collection, the core Terraforms contract will assign each token a placement. Then, as part of the reveal for this collection, a seed number randomized by Ethereum block time is written into the contract, thereby solidifying the conical hyperstructure. Lastly, the Terraforms core contract contains a list of all rendering contracts, with functions to add new rendering contracts.
Design and composability
Now that we understand how everything works from a high level, let’s go deeper into its implications. I won’t be discussing the animation visuals here since that can be an entirely separate post.
Remember how I mentioned there are structural constraints and each parcel’s location in the hyperstructure based on placement and seed? That means the hyperstructure is deterministic, and thus I wouldn’t classify Terraforms as generative art as defined by the market in 2022 (when this blog post was written). The developers here had complete control over what the final structure looked like, modulo minor variances in biome due to the probability distribution. Essentially, the entire collection as a structure can be seen as a 1/1 — each parcel is a puzzle piece in the hyperstructure. I believe Terraforms is the first of its kind in this regard.
In comparison, creators for other generative NFTs only control trait distribution. The collections as a whole have no cohesion (or really weak cohesion). Yuga Otherside Deeds are individual pieces of land tokens that currently don’t form one cohesive world — they’re more like 100k islands.
Next, let’s discuss the rendering contract. As mentioned above, since parcel information is calculated on runtime, the data around parcels isn’t hard coded on the blockchain, allowing for flexibility of randomization and change over time, without compromising on the look and feel of the overall structure. Of course, the developers could’ve just pushed raw data bytes for each parcel and not made it computed on runtime. That would make the collection not very extensible, rigid, and quite frankly, not innovative. Instead, raw data and compute logic is neatly organized and pushed as different contracts, making it possible for future on-chain applications to use.
If we look at the rendering contract, Terraforms could’ve existed without tokenization. All the developers had to do was hardcode the seed into the rendering contract. Instead, they left it open-ended and chose to allow infinite Math Castles to exist at once through the data contract. As such, there’s a separation of the hyperstructure concept from the NFT tokens themselves.
Then, the tokenization of the hyperstructure through NFTs gives people a canonical structure to work with while granting token holders stewardship over an instance of this public domain (through defining the seed). It gives a way for people to “collect” something that’s free to use by anyone. This might not be the most accurate analogy, but collecting the token is akin to collecting a bench in a public park with the token holder’s name on it.
This approach makes Terraforms conceptually interesting and creates positive incentives for developers - the public hyperstructures are relatively decoupled from the financialization of NFTs. If a new developer wants to use any part of the hyperstructure for their own projects all while not directly increasing the value of existing projects, they can simply use an untouched hypercastle by selecting a different seed value. The rendering contract allows developers to spawn independent instances of the hypercastle.
Comparing many other on-chain NFTs, one issue is that the collection as a whole is unstructured and the data is tightly coupled with the NFTs themselves. This means that building software for the collection, such as a game, will create a disproportionate gain for specific holders (ie, tokens with rare traits). For these collections, I’m not confident the incentive structure is well-aligned for new developers with no investment in the collection to come contribute and build. In the case of Terraforms, the hyperstructures are fairer and more inviting to new developers.
Finally, the core token contract contains a list of rendering contracts. This means the team could push new upgrades to the Mathcastle, or even entirely different Mathcastles. However, there’s a function that allows the token holder gets to choose which rendering contact is used for their token. Thus, it’s the token holders, not the team, that have true ownership of how their tokens should function.
The power of Terraforms lies in that the entire data set and functionality are stored on Ethereum. Everyone is provided with an equal opportunity to use Terraforms and the contracts are written in a way that invites people to interact with them.
On Art
I went through all that effort explaining how everything worked together to build context so that we can discuss the argument for Terraforms as Art.
As someone who works in the software industry, I generally see code that’s functional and utility-driven with clear product vs engineering trade-offs. In comparison, the way Terraforms code perfectly communicates an idea is very refreshing. I would describe the code as “aesthetic” and it definitely exhibits expert craftsmanship.
The best painters in history had high deliberation on their choice of materials ( the paint, the paintbrush, the canvas) as well as technique ( realism, romanticism, impressionist, abstract expressionism) to finally realize the artist's idea through the form of a painting. Similarly, the most skilled photographers, sculptors, and musicians leverage the characteristics of their specific medium to communicate an idea, in the process creating historical and culturally impacting art.
For Terraforms, I see parallels. Going through the contract is akin to looking at a painting and inspecting every brush stroke, seeing the artist's intent with every stroke. Every decision is highly deliberate — what data should be queriable, how is everything abstracted to support the desired composability, what does the NFT really represent, and what should be hard-coded to be immutable for security purposes. The concept and code are complex, yet the interface and visuals are simple and elegant. Ethereum, Solidity, Unicode, and colour hex code form the canvas; the software engineering design principles and abstractions form the technique. The end result is beautiful visuals, a hidden hyperstructure, and APIs to interact with it. There’s a term “The medium is the message” coined by Marshall McLuhan, and I believe Terraforms is a piece of art that truly utilizes the medium to its potential.
To some degree, Terraforms (and its medium) is more verbose than other art mediums. Generally, the artist’s intent and ideas underlying the visuals are often more important than the visual itself. Art that’s purely visual can feel decorative or like a facade. However, in existing mediums of art, we often need context through the form of writing to fully understand the intent and idea. In contrast, skillfully written code is self-documenting and clear code communicates a clear thought process. It takes a lot of skill to write good code, but it takes a lot less skill to understand good code.
Once one has some understanding of the code, Terraforms creates a conversation, inviting people to interact with it, play with it, and build on top of it. Unlike physical art pieces which are often stored in vaults, Terraforms are available to anyone to enjoy due to the open-source nature of blockchain. Imagine a world where artworks are interlinked with each other through code.
With Terraforms, I can see coding emerging as a respectable and appreciated medium of art that requires a specialized set of skills to be able to execute. Terraforms is a pioneer in a medium that hardly exists yet, let alone is understood well. As someone who loves art and works professionally as a software engineer, Terraforms resonated with me deeply. Unfortunately, I wouldn’t be surprised if Terraforms (and similar projects in this medium) aren’t recognized for decades since there aren’t enough people with knowledge of intersecting art, art history, and software engineering.
Terraforms is inspiring. It triggers my imagination and makes me wonder what can be achieved in the future, both Terraforms as a hyperstructure and the class of artwork that Terraform pioneers. What do we even call this type of art? Artwork as an API? Runtime art? Network art? EVM art? Tokenized computer programs? Whatever it is, I’m excited for the day when art historians are able to put a term to this type of art, and I can reflect back on this post knowing that I was here early.
Shout out to all the community members who built excellent tools to help understand Terraforms. Also, shout out to everyone that helped me edit and proof read this article!
Awesome piece. Thanks for explaining all of that.