Speedtracer is a fully onchain, longform generative art project. A Solidity algorithm outputs skeuomorphic motorsport racetrack artworks. A daily casual game uses the generated tracks, challenging users to trace the day’s track as quickly as they can. Track owners become stewards of the game, where they may edit the shape of their track, place signage around it, and earn yield from players who mint Race Result NFTs.

This is my artist statement for Optimism Foundation’s We ❤️ The Art contest and a general introduction to the project, my previous work and inspiration.

I don’t consider myself an artist, rather I’ve taken to calling myself an onchain craftsperson. My work is typically aesthetically unremarkable. I instead constrain myself in other ways. I explore skeuomorphism, essentialism and ontology. I express onchain concepts intrinsic to and inseparable from the capabilities and nuances of public ledger blockchains.

Speedtracer smart contracts are deployed to Base. The track generation algorithm is used to create onchain SVGs (tracetracks) that are available to mint on Highlight. The token_id is used as a seed, determining the track shape and color theme. 366 tokens are available to mint for the 2024 season for 0.0875 ETH each.

Speedtracer’s PWA uses the smart contract output to create a daily casual mobile game. Players trace a track as quick as they can without hitting the wall, a fun and challenging toilet game. Competitive players can mint a Race Result NFT to get on the leaderboard, providing the track owner a share of the mint fee.

Speedtracer allows owners full control of their track in a role playing metaverse cartel experience. Make your track fun to play, place advertising boards through sponsors and work cooperatively with other owners to grow the game. Speedtracer’s track and ads editor features use onchain storage to augment the algorithmic output.

Speedracer theme song for your listening pleasure as you read!

I released my first Ethereum project CryptOrchids in March 2021. NFTs were starting to draw some mainstream attention, and I found the criticisms to be misplaced. Rather than a simple receipt pointing at an image, NFTs could be whole ass programs. Not many NFT creators were taking advantage of the Turing completeness of Ethereum smart contracts, but all the tools were available to make living, breathing NFTs.

As noted I am really not an artist in the visual medium sense, so I hired a freelance illustrator to help with the flower images and myself focused on the engineering.

To explore ontology and essentialism, I sought to reduce the concept of a flower to it’s simplest definition, to highlight the thing that makes it a flower and not flour. I chose to focus on photosynthesis, or at least a part of it - a plant’s dependence on water to perform photosynthesis and transport nutrients as it grows. Simply put, plants die without water, and Orchids are notoriously fickle water consumers.

The CryptOrchids contract using the Turing completeness of EVM smart contracts to implement this biological process in its simplest interpretation. Orchid owners must water their flower exactly every 7 days, within a 3 hour watering window, in order to keep it “alive.”

Blockclock was a later, more literal onchain skeuomorphic project I shipped in December 2021. I’d seen some clock-like NFTs take a less skeuomorphic approach, where they were ostensibly timepieces but they uhhhh didn’t actually tell time? That to me is the essence of what we understand as a clock - you look at it and know what time it is.

Blockclocks are onchain SVGs created by Solidity code. They aren’t generative however, the basic design is hardcoded, and the contract will output an SVG that shows the time for the block at which the tokenUri function is called - that’s why marketplaces tend to display a static image frozen at the time the metadata was last cached. Fetching the blockchain state every second would be superfluous given the deterministic nature of the output, so the program is also available in an HTML / Javascript based webpage that is pinned to IPFS and uses your computer’s clock and Javascript to update the displayed time without fetching blockchain data. That IPFS url is in the token metadata as animation_url so is displayed by some marketplaces.

With Blockclocks, we arrive at the tension that my work tends to engage. Blockclocks are visually extremely straightforward. I am proud of their artistic merit — I got lucky with the math and how we’ve decided to understand and express the passage of time and was able to make a nice looking square display that evokes a bedside digital alarm clock.

But Blockclocks compared to a project like 720 Minutes, or Speedtracer compared to something like Ringers, demonstrates how my interest in skeuomorphism creates different constraints. Blockclocks had to look a certain way to perform their core function, and that forces them to be less visually stunning than 720 Minutes.

Speedtracer tracetracks must follow specific rules in order to behave like real-world racetracks and support the game, which limits the emergent properties of the algorithmic output. There is a much smaller possibility of an output like Ringer’s Goose when the algorithm approximates rules like “no intersecting paths.”

I don’t think “utility” is the right term to describe what I try to express in my work. It’s a subtle distinction and specific to how the NFT space has evolved. Most people would agree that the utility of a car is that you can drive it from place A to place B. You could also rent your car out to other people through an app like Turo, and that’s mostly what NFT utility is - staking for yield, access to more NFTs. Money making opportunities dreamed up by madmen who view every object as a financial asset.

When I call myself an onchain craftsperson, I mean to say that I attempt to make useful, skeuomorphic objects that are also visually appealing. It’s form and function. It’s fashion or furniture. I have a deep appreciation for physical objects that do a job well and are well-made, objects that are a joy to use. Lambos look nice of course, but they are also (presumably) extremely fun to drive. The engineering and the aesthetics complement each other to create a Veblen good that is both functional and satisfying to look at.

For Speedtracer, the chief constraint is that the tracks must be suitable for gameplay. Tracks are constrained by a canvas shape, track width and a rule against intersecting paths.

As a mobile-first game, we first define a rectangular shape that tracks should fit, matching the general shape of a mobile phone screen. We don’t want to leave a ton of negative space, so all of the tracks attempt to best-fit the 1200x1950 canvas that scales to the device being used. This necessarily limits the variety of outputs, where every track feels like a path that roughly follows the perimeter of the canvas. This canvas shape lends itself nicely to poster prints, and I hope that collectors are excited about their track as a work of art they’d be proud to display as a physical print, but the process was very much focused on creating playable tracks and iterating on the algorithm to build up the visual appeal of an output without sacrificing the playability.

Racetrack posters filled my mood boards for the project, and a more narrowly stroked path tends to be more visually appealing artistically. The game UI does take some liberties when displaying the track artwork - I remove some background elements that can be distracting to players and tend to harm the performance of the game. But it felt important to not alter the appearance too much between the onchain SVG and how the track looks to players, so I leaned towards wider tracks, and attempted to balance aesthetics by adding some texture to the track pavement through SVG noise filters.

Adding some width to the track further complicates the constraints. A tight chicane or a hairpin turn that doesn’t account for a wider track width creates an awkward output as the expanded width of the track eats into the curvature, creating track elements you wouldn’t expect to see in a real world racetrack, breaking our skeuomorphism. And while some video game racetracks might implement bridges for intersecting paths, in the real world you more often see tracks that create a non-overlapping circuit.

The limited compute of the EVM makes these constraints difficult to implement directly. But the algorithm is designed to approximate and guard against the type of things that break our belief that any individual output could function as a real world racetrack. By considering previous track segments, distance between points, and various angles and past segment data, the algorithm attempts to catch instances where we might say “that doesn’t look right,” and massages the path to make the track more believable as a skeuomorphic object.

Speedtracer is a longform generative artwork; I have not handpicked or curated any outputs. They are entirely determined by pseudo-random prime number seeds combined with the token ID.

The Speedtracer game is designed as a daily casual mobile game. Each day, every user sees the same track, starting from token ID 1 and incrementing each day. The project implements seasons, which gives us the flexibility of updating the track algorithm in the future without impacting previously minted tokens. Season 1 runs from December, 13 2023 to December 13, 2024, so there are 366 tokens available for minting in Season 1 (it’s a leap year).

The algorithm however supports token IDs to really really large numbers, and token owners can generate new tracks in the game that they can play. These tracks cannot be minted, but can be shared by track owners via a QR code that embeds a link. Tracks are available for minting on Highlight, where you can also input arbitrary token IDs to see what the algorithm would generate for tokens beyond #366 with the Season 1 renderer.

Calling Speedtracer’s track generation code an algorithm feels audacious. At a high level its a couple of for loops and some basic heuristics for determining a segment type based on the previous segment, position and distance to the next waypoint. There is some advanced math for building a segment - the code deals a lot with collinearity, or finding a third point that is on a straight line between two existing points. The collinearity helps us achieve continuity, with G2 continuity being a goal between curves.

Continuity

G2 continuity is something that is pretty easy to feel but much more difficult to describe. The basic level of continuity, G0 continuity, is an absolute must have for a racetrack. G0 just means there are no gaps between our segments. A rally track might technically have a jump over a stream or something that would break G0 continuity, but that doesn’t fit our game very well, so the algorithm always outputs paths with G0 continuity.

G1 continuity describes two curves with a common endpoint and tangent vectors lying along the same direction. G2 or curvature continuity describes two curves with G0 and G1 continuity, while also having the same rate of change of the direction. The directions at the joint seem to change with the same speed. The best way I can describe G2 continuity is that you cannot tell where one curve starts and the other ends - they feel seamless, flowy and of one.

Approach

Dmitri Cherniak describes his project Ringers as an exploration of the infinite ways you could wrap a string around a set of pegs. It’s an accessible explanation of a complicated algorithm. You could imagine taking some pegs, sticking them in a board, and then grabbing some yarn and start wrapping it around the pegs.

Speedtracer’s algorithm is similar, but might be better understood as a connect-the-dots type of approach. Speedtracer uses “dots” as waypoints, first selecting a pseudo-random selection of points, and then iterating over them to draw lines that connect them.

But if you remember a connect-the-dots coloring book from your childhood you’ll quickly understand that the manner in which you connect the dots has a massive influence on the quality of the final drawing. If you robotically connect each dot with a hard, straight line, it’s unlikely the image you create will match what the prompt imagines. You’ll want to plan the segments, make sure the lines between the dots curve into each other smoothly in some instances, while a hard right angle might be desirable in other places.

We implement curves in our segments using cubic bezier curves - curve definitions that include coordinates for a start point, end point and two control points, coordinates that “pull” the segment towards them to influence the curvature of the segment. The SVG spec provides two commands for cubic bezier curves - C commands require specifying both control points, while S commands implicitly place the first control point as a reflection of a previous bezier curves second control point. In practice, S commands implicitly create G2 continuity, but too much reliance on S commands creates a meandering, slalom-like track that doesn’t reflect a real world racetrack.

Keeping in mind our existing constraints for track width and preventing intersection, we can start to understand the challenge with the algorithm, and how properties of real world racetracks inform the decisions we make about how to connect our points. We try to balance rhythm and variety, ensuring tracks have some low-speed technical elements, some straightaways or high-speed sweeping curves for passing, and that these elements are sequenced for variety.

Real world racetracks often have signature turns, and the algorithm implements some similar elements in sticky areas of the canvas. I wish I could say the math is fully mathing, but corners that require changing direction can be challenging, so under certain waypoint conditions we massage corners or select complex segments to ensure playability. One such example is every track starts with a straight starting block line and a cubic bezier curve that implements G2 continuity with the starting block to start the track. Later, to close the loop, we reverse the continuity calculation and try to make the final turn curve seamlessly into the start block as racers approach the finish line.

I use verbs like try because the truth is it’s not perfect! It’s been incredibly challenging to try to build up this algorithm to catch all of the edge cases and output believable real world tracks while also ensuring enough variety to even make this worthwhile. The algorithm supports the entire uint256 space - that’s 2^256-1 outputs the algorithm supports, so naturally there will be some unplayable outputs and others that you can immediately imagine engines roaring and tires screeching as F1 cars zip around the track.

Walkthrough

At a high level, here’s how the code works to generate a track -

1. Select Random Waypoints

   1. To create a general shape that uses the perimeter, we first start by dividing the canvas into a 4x6 grid of squares

   2. Within each perimeter square we select a random point - we go across the top, down the right, back across the bottom, then up the left towards our starting section

   3. Sometimes the waypoints are too close, so we simply discard that grid area and move on to the next one, which helps with variety by adding some longer segments

2. Connect the Waypoints

   1. Our waypoints are the dots in our connect-the-dots exercise

   2. We start by connecting the first 2 dots with a straight line - this becomes the starting block on the track

   3. We feed out of the starting block with a cubic bezier curve that ensures continuity with the starting block

   4. As we add more segments, we consider the previous segment, the distance between the current and next waypoint and some entropy to select a reasonable next element

      1. This is where the biggest challenge lies- connecting waypoints with straight lines makes satisfying our constraints simple, but lacks variety or challenge

      2. We use our knowledge of the previous segment’s type, the control point values that impact its curvature, and the available space to choose a best fit segment

   5. As we progress, we sometimes carve out special turns or corners based on our position, where the next waypoint is, and our constraints for track width and no intersection rules

3. Close the loop

   1. Once we get towards the end of the track, we reverse perspective and try to complete the loop with a rhythmic, flowy turn between the final segment and the starting block

If this all feels too complicated, I agree! I’m very much a visual learner, and building debug tools early on was immensely helpful in building up this algorithm. Those debug tools evolved into tools for track owners to edit their track shape. Even if you don’t own a track, you can play with the editor and get a sense of how waypoint selection and segment selection heuristics work and impact the shape of the track.

Season 1 tracks come in 6 different themes, from the most common Base to the rarest Ringers theme. Each track also has one of 4 midline stroke dash arrays, from shorter dash lines spaced far apart, to a solid, continuous midline.

Every track has a pseudo-generated name, specific to the theme. Truly generative text is incredibly challenging to create onchain. Instead, name contracts provide dictionaries of prefix, city and suffix names for each theme. These words are picked and placed together to form a name, so a Desert track might get the name Super Reno Raceway while a Base theme track might be called 1974 Munich Motorway.

The most challenging aspect of working onchain for an engineer is the immutability of smart contracts. CryptOrchids has a typo in IPFS metadata and also a bunch of $LINK locked in the contract that’s been staring me in the face for years. Some NFT contracts maintain an updatable baseUri - implementing that functionality violates notions of self custody, where the contract owner can change the token’s artwork. Baseclock learned from this mistake, but as an onchain project it doesn’t use a tokenUri in the same way as an offchain project. Instead, the NFT contract that stores ownership data points at a rendering contract. Any bugs in the renderer can thus be addressed by deploying a new renderer and pointing the NFTs at the new contract.

But that still violates the premise of self custody - I as the creator can “rug pull” the renderer and render…whatever I want instead of the clock minters purchased. This tension creates tradeoffs - how can we continue to deliver a great experience without introducing these vectors for abuse?

Speedtracer handles this through a renderer middleware contract. This contract allows me as the creator to add new renderers, but they are appended to the existing renderer and are only used for tokens specified by a range. This is how we are able to implement seasons - Season 1’s 366 tokens will always use the renderer that was in place when those tokens were minted. It allows us to iterate on the algorithm and themes for Season 2, while maintaining one collection and not changing the artwork for Season 1 tokens.

The tokenUri output for an individual token includes an entire artwork, but the core of the algorithm’s output is an SVG path definition string. If the Solidity code I wrote is an instruction set for the EVM, then the output of the algorithm is an instruction set for graphical rendering in your web browser or whatever environment is interpreting those instructions in order to display an image.

It’s instructions all the way down, which enables exciting properties you don’t get in a more typical generative artwork, where the art itself is the output and which suggests some sense of finality. Speedtracer is more similar to Autoglyphs than Chaos Roads, both wonderful generative artworks. While Chaos Roads creates a dynamic and evolving audiovisual output that exists unto itself, Autoglyphs creates an instruction set which can be viewed independently as an artwork, but can “be drawn to a screen or even on paper by following the written instructions in the comments of the smart contract itself.” ¹

Autoglyphs instructions may be useful in contexts outside of visual art, but it would require a liberal interpretation of the instruction set to make something approaching a game. Speedtracer on the other hand uses a standard instruction set that can easily be mapped to other contexts. The SVG Path d attribute is key to the project’s composability to create a web based game where track owners can permissionlessly edit the appearance of their NFT and how it plays as a game map.

// Example algorithm output of SVG path d attribute commands
// with one command per line
//
// see MDN's documentation for SVG Path commands to learn more
// https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d

M 199,396 
L 527,327 
C 636,304 648,301 711,497 
C 726,544 741,591 826,442 
C 910,294 925,341 940,388 
S 1061,605 819,779 
S 530,959 636,1126 
S 804,1271 973,1486 
C 1021,1547 1069,1608 789,1559 
C 802,1862 697,1854 607,1630 
L 463,1322 
C 415,1220 401,1203 330,925 
L 348,683 
C 338,577 -40,464 199,396

The Speedtracer game uses the algorithm output to create a traceable racetrack. The game challenges users to trace the track as quickly as they can without crashing into the track wall. Users can play on desktop with a mouse, but the experience is primarily geared towards mobile phones. As a Progressive Web App, Speedtracer can be installed on your iPhone or Android device.

Starting on January 10th with token ID #1, every day the next token is shown to all players. While this isn’t a hardcore competitive game, after each turn the user is shown a sharable card that includes their time (or completion percentage) and an outline version of the track with their speed path laid on top. The share card also displays the device the game was played on, the attempt number, and a QR code that can be scanned to go right to that track.

By using the SVG path attribute directly from the contract, we can use that data to create all of the interactive aspects offchain, for any track, even if a user has edited it. This is the power of keeping the algorithmic output as instructions. We’re able to add a checkered finish line that is positioned along the starting block straightaway. An additional path element is added and offset to show a yellow starting block over top of the track which disappears when the user starts tracing. We have to do some programming to convert web page coordinates to the SVG coordinates, but its pretty simple math.

This would be impossible if we had our generative algorithm output image files that we pinned to IPFS for example - all of the instruction data would be lost, converted into image data. Even the share card uses the algorithmic output from the contract in a different way. Remember, we’re outputting instructions to draw a path shape. These instructions get used in the share card to draw the outline version of the track on top of which we display the user’s speedmap - a gradient SVG path built up from the user’s touches with a speed calculated by time between points.

The Speedtracer game is not a crypto game. It’s a free to play, no login required, casual mobile game. It happens to use crypto rails for track generation and customization, but the people who have the most fun with it have no idea that it’s backed by a public ledger blockchain nor do they care. For track owners who do care and want to be stewards of the game, blockchain tech ensures they are in complete control of their track - maybe you want to make the track look like your company logo, or a ❤️, or maybe you just want to make the track a tiny bit more challenging for players. It’s entirely up to you and doesn’t depend on me running an API or server.

The aspect of Speedtracer that most depends on the unique aspects of public ledger blockchains, and particularly a cheap Layer 2 Ethereum blockchain like Base, is the full custody a tracetrack token owner has over their track. Owning a track gives you complete control over the track design and allows you to capitalize on the attention on your track on race day by giving you control of sponsorships.

Edit Your Track

A track owner can perform a transaction against the Speedtracer contract that replaces the algorithmic output with their own SVG path attribute data. They can later perform another transaction to revert back to the algorithmic output, and can continue updating the track as often as they like.

You could of course do this directly against the contract. Leveraging the known and widely used SVG standard makes this accessible to anyone willing to learn the commands SVG paths use in their instruction set. But the project’s adherence to output as instructions allows us to offer more compelling interfaces for editing that output. Anyone can play with the track editor to see how it works - it’s available at https://speedtracer.xyz/edit/69 (you can replace the 69 with any other token ID). Here’s a screenshot of the editor at writing time. The algorithm isn’t finished, so this isn’t a great track. And the UI could use some cleanup.

The first thing to notice is the algorithm output on the left. We split commands by line so you can better see them all, and you can edit that text to see the track update in real time.

Next, check out the red dots 🔴 on the track - these are waypoints, the dots we randomized at the start of our algorithm that we later connected.

The green 🟢 and blue 🔵 dots are called control points. The math can get a little complex, but you can think of them as pulling the curves of the lines between the waypoints. Some of our segments use self-reflecting S commands, where the first control point is calculated as part of the SVG spec itself in order to guarantee G2 continuity between segments. Other commands used in the algorithm output are C commands, which are similar to S but allow you to specify the first control point, which means you won’t necessarily achieve G2 continuity.

To edit things, you can simply start dragging the waypoints and control points. The red border guide shows the 16:9 ratio section you should keep the track on to fit on the canvas and on phones. Control points can be outside of this area, but the track should stay within it.

Here’s what I came up with in a minute or two of editing. I removed one of the commands down the right side of the track, and went for a more sweeping, curvy design:

If you look closely, you can see that the path data changed to reflect the manipulation I made with my mouse. We’re not editing an image so much as we are editing instructions to make an image. More precisely we’re editing instructions to make a path, which the contract and game UI use to construct the whole track. Its instructions all the way down!

Onchain Sponsors

Another benefit for track owners is the ability to place trackside advertising boards and race result ad units for your track. You can use these however you want! You could eschew raw capitalism and put some of your favorite art on your track (please). You could advertise your own project or company. You can even sell your ad space to third party sponsors - Speedtracer integrates the Delegate.xyz marketplace, allowing you to sell the advertising rights without selling your track entirely. Speedtracer’s analytics are public, so you can use that data to determine the value of these ad units.

Just like track editing, you can update your sponsorships onchain by transacting directly with the contract. But the sponsorship editor, like the track editor, makes this process much easier. You can upload images and drag, resize and rotate them to place anywhere on your track. For the race result ad unit, you can upload an image and specify a target URL that should open when a user taps the ad

None of my previous projects have been terribly successful, so I’ve been making more of an effort to meet the market where it’s at with my more recent work. NFTA is my most recent release, another daily crypto game. There I tried to lean more into what seems to bring people to the space - money making opportunities.

With Speedtracer, the sponsorship opportunities provide one avenue to make your Speedtracer tracetrack a yield bearing asset. A second opportunity capitalizes on the competitive drive we expect some players to have. The game will always be free to play, without any requirement to connect a wallet. I expect the vast majority of casual players to play this way. But competitive players can mint NFTs of their race result by paying 0.0008 ETH.

Half of this mint fee is shared with the track owner. If just 220 players mint a Race Result NFT for your track then you’ve broken even on the 0.0875 ETH cost to mint a tracetrack. You can always link players to your track, allowing players to trace on any day outside of your global race day. So you can run your own contests with incentives to play and mint the result card - the game uses those NFT mints to construct a leaderboard. You could even run a contest, then change your track shape and run another contest - you completely own your track and can use it however you see best to generate some yield.

I’ve struggled to build community and gain traction for my previous projects and hope that track ownership yield opportunities can help align my and track owner interests. Track owners naturally will want to pump their bags, but it goes a step further in terms of marketing the game. With a few hundred track owners able to generate revenue through naming rights and race result mints, we have a community of individuals, myself included, who all want to see the user base for the Speedtracer game grow. We aren’t selling a roadmap and hype, and we’re giving holders ways to profit without exiting the community. By offering a Web 2.0 oriented display ad channel, plus the web3 race result minting, we give community members multiple avenues to help grow the game and their yield - they don’t even need to tell their friends it’s a crypto based game, and perhaps those users eventually onboard with their first crypto wallet when they want to get on the leaderboard.

The most important takeaway for all of the track ownership capabilities is the choice I made to create my art onchain with Solidity. None of this would be possible with a P5 script and finished artworks pinned on IPFS. Using Solidity and the EVM to generate the art creates many challenges, but the payoff is worth it when you start to recognize how the onchain algorithm and instruction output play their role in creating a networked system with art at the core rather than a static offchain object with zero capability for composability or extensibility. Speedtracer utilizes blockchain as a medium far beyond what most generative art NFT projects can accomplish.

The Speedtracer game was launched as a very early alpha in Spring 2023. Just me and a few friends playing and finding bugs. I launched the beta in December 2023, where we added the Race Results NFTs and a Leaderboard, all on testnets. I sent some tracetrack NFTs to friends and early players to start testing track editing and ads uploading. Some track owners organically started offering prizes for their race day top performers which really seemed to rev players’ engines.

The player base is still small, but the most promising metric is that each user plays multiple attempts per track. That suggests people are finding the game fun enough to keep trying when they crash, and to keep improving their times even after they complete a trace successfully. The product analytics dashboard is public so you can look at some of these numbers yourself - stats.speedtracer.xyz.

Starting January 10, Race Result NFTs are available for minting on Base mainnet. Race Result mints will get you a discount for public sale mints. We’ll be doing some giveaways and contests starting then as well.

Speedtracer tracetracks go on sale on mid-January for 0.0875 ETH. 366 tokens are available for Season 1. Holders of my previous projects will have access to an exclusive minting period for a reduced price of 0.07 ETH.

You can explore the algorithm’s long-form output in a few ways.

The explore page at speedtracer.xyz/explore will show you random outputs directly from the contract. This is the fastest and most raw option, but some of the more advanced SVG features the art uses aren’t well supported on mobile browsers.

The mint page on Highlight will also show random outputs. It’s slower but works better on more devices and browsers thanks to an image conversion pipeline.

[1] Hall, M., & Wilkinson, J. (2019). Autoglyphs. Larva Labs. https://www.larvalabs.com/autoglyphs

Speedtracer is a fully onchain, longform generative art project. A Solidity algorithm outputs skeuomorphic motorsport racetrack artworks. A daily casual game uses the generated tracks, challenging users to trace the day’s track as quickly as they can. Track owners become stewards of the game, where they may edit the shape of their track, place signage around it, and earn yield from players who mint Race Result NFTs.

This is my artist statement for Optimism Foundation’s We ❤️ The Art contest and a general introduction to the project, my previous work and inspiration.

I don’t consider myself an artist, rather I’ve taken to calling myself an onchain craftsperson. My work is typically aesthetically unremarkable. I instead constrain myself in other ways. I explore skeuomorphism, essentialism and ontology. I express onchain concepts intrinsic to and inseparable from the capabilities and nuances of public ledger blockchains.

Speedtracer smart contracts are deployed to Base. The track generation algorithm is used to create onchain SVGs (tracetracks) that are available to mint on Highlight. The token_id is used as a seed, determining the track shape and color theme. 366 tokens are available to mint for the 2024 season for 0.0875 ETH each.

Speedtracer’s PWA uses the smart contract output to create a daily casual mobile game. Players trace a track as quick as they can without hitting the wall, a fun and challenging toilet game. Competitive players can mint a Race Result NFT to get on the leaderboard, providing the track owner a share of the mint fee.

Speedtracer allows owners full control of their track in a role playing metaverse cartel experience. Make your track fun to play, place advertising boards through sponsors and work cooperatively with other owners to grow the game. Speedtracer’s track and ads editor features use onchain storage to augment the algorithmic output.

Speedracer theme song for your listening pleasure as you read!

I released my first Ethereum project CryptOrchids in March 2021. NFTs were starting to draw some mainstream attention, and I found the criticisms to be misplaced. Rather than a simple receipt pointing at an image, NFTs could be whole ass programs. Not many NFT creators were taking advantage of the Turing completeness of Ethereum smart contracts, but all the tools were available to make living, breathing NFTs.

As noted I am really not an artist in the visual medium sense, so I hired a freelance illustrator to help with the flower images and myself focused on the engineering.

To explore ontology and essentialism, I sought to reduce the concept of a flower to it’s simplest definition, to highlight the thing that makes it a flower and not flour. I chose to focus on photosynthesis, or at least a part of it - a plant’s dependence on water to perform photosynthesis and transport nutrients as it grows. Simply put, plants die without water, and Orchids are notoriously fickle water consumers.

The CryptOrchids contract using the Turing completeness of EVM smart contracts to implement this biological process in its simplest interpretation. Orchid owners must water their flower exactly every 7 days, within a 3 hour watering window, in order to keep it “alive.”

Blockclock was a later, more literal onchain skeuomorphic project I shipped in December 2021. I’d seen some clock-like NFTs take a less skeuomorphic approach, where they were ostensibly timepieces but they uhhhh didn’t actually tell time? That to me is the essence of what we understand as a clock - you look at it and know what time it is.

Blockclocks are onchain SVGs created by Solidity code. They aren’t generative however, the basic design is hardcoded, and the contract will output an SVG that shows the time for the block at which the tokenUri function is called - that’s why marketplaces tend to display a static image frozen at the time the metadata was last cached. Fetching the blockchain state every second would be superfluous given the deterministic nature of the output, so the program is also available in an HTML / Javascript based webpage that is pinned to IPFS and uses your computer’s clock and Javascript to update the displayed time without fetching blockchain data. That IPFS url is in the token metadata as animation_url so is displayed by some marketplaces.

With Blockclocks, we arrive at the tension that my work tends to engage. Blockclocks are visually extremely straightforward. I am proud of their artistic merit — I got lucky with the math and how we’ve decided to understand and express the passage of time and was able to make a nice looking square display that evokes a bedside digital alarm clock.

But Blockclocks compared to a project like 720 Minutes, or Speedtracer compared to something like Ringers, demonstrates how my interest in skeuomorphism creates different constraints. Blockclocks had to look a certain way to perform their core function, and that forces them to be less visually stunning than 720 Minutes.

Speedtracer tracetracks must follow specific rules in order to behave like real-world racetracks and support the game, which limits the emergent properties of the algorithmic output. There is a much smaller possibility of an output like Ringer’s Goose when the algorithm approximates rules like “no intersecting paths.”

I don’t think “utility” is the right term to describe what I try to express in my work. It’s a subtle distinction and specific to how the NFT space has evolved. Most people would agree that the utility of a car is that you can drive it from place A to place B. You could also rent your car out to other people through an app like Turo, and that’s mostly what NFT utility is - staking for yield, access to more NFTs. Money making opportunities dreamed up by madmen who view every object as a financial asset.

When I call myself an onchain craftsperson, I mean to say that I attempt to make useful, skeuomorphic objects that are also visually appealing. It’s form and function. It’s fashion or furniture. I have a deep appreciation for physical objects that do a job well and are well-made, objects that are a joy to use. Lambos look nice of course, but they are also (presumably) extremely fun to drive. The engineering and the aesthetics complement each other to create a Veblen good that is both functional and satisfying to look at.

For Speedtracer, the chief constraint is that the tracks must be suitable for gameplay. Tracks are constrained by a canvas shape, track width and a rule against intersecting paths.

As a mobile-first game, we first define a rectangular shape that tracks should fit, matching the general shape of a mobile phone screen. We don’t want to leave a ton of negative space, so all of the tracks attempt to best-fit the 1200x1950 canvas that scales to the device being used. This necessarily limits the variety of outputs, where every track feels like a path that roughly follows the perimeter of the canvas. This canvas shape lends itself nicely to poster prints, and I hope that collectors are excited about their track as a work of art they’d be proud to display as a physical print, but the process was very much focused on creating playable tracks and iterating on the algorithm to build up the visual appeal of an output without sacrificing the playability.

Racetrack posters filled my mood boards for the project, and a more narrowly stroked path tends to be more visually appealing artistically. The game UI does take some liberties when displaying the track artwork - I remove some background elements that can be distracting to players and tend to harm the performance of the game. But it felt important to not alter the appearance too much between the onchain SVG and how the track looks to players, so I leaned towards wider tracks, and attempted to balance aesthetics by adding some texture to the track pavement through SVG noise filters.

Adding some width to the track further complicates the constraints. A tight chicane or a hairpin turn that doesn’t account for a wider track width creates an awkward output as the expanded width of the track eats into the curvature, creating track elements you wouldn’t expect to see in a real world racetrack, breaking our skeuomorphism. And while some video game racetracks might implement bridges for intersecting paths, in the real world you more often see tracks that create a non-overlapping circuit.

The limited compute of the EVM makes these constraints difficult to implement directly. But the algorithm is designed to approximate and guard against the type of things that break our belief that any individual output could function as a real world racetrack. By considering previous track segments, distance between points, and various angles and past segment data, the algorithm attempts to catch instances where we might say “that doesn’t look right,” and massages the path to make the track more believable as a skeuomorphic object.

Speedtracer is a longform generative artwork; I have not handpicked or curated any outputs. They are entirely determined by pseudo-random prime number seeds combined with the token ID.

The Speedtracer game is designed as a daily casual mobile game. Each day, every user sees the same track, starting from token ID 1 and incrementing each day. The project implements seasons, which gives us the flexibility of updating the track algorithm in the future without impacting previously minted tokens. Season 1 runs from December, 13 2023 to December 13, 2024, so there are 366 tokens available for minting in Season 1 (it’s a leap year).

The algorithm however supports token IDs to really really large numbers, and token owners can generate new tracks in the game that they can play. These tracks cannot be minted, but can be shared by track owners via a QR code that embeds a link. Tracks are available for minting on Highlight, where you can also input arbitrary token IDs to see what the algorithm would generate for tokens beyond #366 with the Season 1 renderer.

Calling Speedtracer’s track generation code an algorithm feels audacious. At a high level its a couple of for loops and some basic heuristics for determining a segment type based on the previous segment, position and distance to the next waypoint. There is some advanced math for building a segment - the code deals a lot with collinearity, or finding a third point that is on a straight line between two existing points. The collinearity helps us achieve continuity, with G2 continuity being a goal between curves.

Continuity

G2 continuity is something that is pretty easy to feel but much more difficult to describe. The basic level of continuity, G0 continuity, is an absolute must have for a racetrack. G0 just means there are no gaps between our segments. A rally track might technically have a jump over a stream or something that would break G0 continuity, but that doesn’t fit our game very well, so the algorithm always outputs paths with G0 continuity.

G1 continuity describes two curves with a common endpoint and tangent vectors lying along the same direction. G2 or curvature continuity describes two curves with G0 and G1 continuity, while also having the same rate of change of the direction. The directions at the joint seem to change with the same speed. The best way I can describe G2 continuity is that you cannot tell where one curve starts and the other ends - they feel seamless, flowy and of one.

Approach

Dmitri Cherniak describes his project Ringers as an exploration of the infinite ways you could wrap a string around a set of pegs. It’s an accessible explanation of a complicated algorithm. You could imagine taking some pegs, sticking them in a board, and then grabbing some yarn and start wrapping it around the pegs.

Speedtracer’s algorithm is similar, but might be better understood as a connect-the-dots type of approach. Speedtracer uses “dots” as waypoints, first selecting a pseudo-random selection of points, and then iterating over them to draw lines that connect them.

But if you remember a connect-the-dots coloring book from your childhood you’ll quickly understand that the manner in which you connect the dots has a massive influence on the quality of the final drawing. If you robotically connect each dot with a hard, straight line, it’s unlikely the image you create will match what the prompt imagines. You’ll want to plan the segments, make sure the lines between the dots curve into each other smoothly in some instances, while a hard right angle might be desirable in other places.

We implement curves in our segments using cubic bezier curves - curve definitions that include coordinates for a start point, end point and two control points, coordinates that “pull” the segment towards them to influence the curvature of the segment. The SVG spec provides two commands for cubic bezier curves - C commands require specifying both control points, while S commands implicitly place the first control point as a reflection of a previous bezier curves second control point. In practice, S commands implicitly create G2 continuity, but too much reliance on S commands creates a meandering, slalom-like track that doesn’t reflect a real world racetrack.

Keeping in mind our existing constraints for track width and preventing intersection, we can start to understand the challenge with the algorithm, and how properties of real world racetracks inform the decisions we make about how to connect our points. We try to balance rhythm and variety, ensuring tracks have some low-speed technical elements, some straightaways or high-speed sweeping curves for passing, and that these elements are sequenced for variety.

Real world racetracks often have signature turns, and the algorithm implements some similar elements in sticky areas of the canvas. I wish I could say the math is fully mathing, but corners that require changing direction can be challenging, so under certain waypoint conditions we massage corners or select complex segments to ensure playability. One such example is every track starts with a straight starting block line and a cubic bezier curve that implements G2 continuity with the starting block to start the track. Later, to close the loop, we reverse the continuity calculation and try to make the final turn curve seamlessly into the start block as racers approach the finish line.

I use verbs like try because the truth is it’s not perfect! It’s been incredibly challenging to try to build up this algorithm to catch all of the edge cases and output believable real world tracks while also ensuring enough variety to even make this worthwhile. The algorithm supports the entire uint256 space - that’s 2^256-1 outputs the algorithm supports, so naturally there will be some unplayable outputs and others that you can immediately imagine engines roaring and tires screeching as F1 cars zip around the track.

Walkthrough

At a high level, here’s how the code works to generate a track -

1. Select Random Waypoints

   1. To create a general shape that uses the perimeter, we first start by dividing the canvas into a 4x6 grid of squares

   2. Within each perimeter square we select a random point - we go across the top, down the right, back across the bottom, then up the left towards our starting section

   3. Sometimes the waypoints are too close, so we simply discard that grid area and move on to the next one, which helps with variety by adding some longer segments

2. Connect the Waypoints

   1. Our waypoints are the dots in our connect-the-dots exercise

   2. We start by connecting the first 2 dots with a straight line - this becomes the starting block on the track

   3. We feed out of the starting block with a cubic bezier curve that ensures continuity with the starting block

   4. As we add more segments, we consider the previous segment, the distance between the current and next waypoint and some entropy to select a reasonable next element

      1. This is where the biggest challenge lies- connecting waypoints with straight lines makes satisfying our constraints simple, but lacks variety or challenge

      2. We use our knowledge of the previous segment’s type, the control point values that impact its curvature, and the available space to choose a best fit segment

   5. As we progress, we sometimes carve out special turns or corners based on our position, where the next waypoint is, and our constraints for track width and no intersection rules

3. Close the loop

   1. Once we get towards the end of the track, we reverse perspective and try to complete the loop with a rhythmic, flowy turn between the final segment and the starting block

If this all feels too complicated, I agree! I’m very much a visual learner, and building debug tools early on was immensely helpful in building up this algorithm. Those debug tools evolved into tools for track owners to edit their track shape. Even if you don’t own a track, you can play with the editor and get a sense of how waypoint selection and segment selection heuristics work and impact the shape of the track.

Season 1 tracks come in 6 different themes, from the most common Base to the rarest Ringers theme. Each track also has one of 4 midline stroke dash arrays, from shorter dash lines spaced far apart, to a solid, continuous midline.

Every track has a pseudo-generated name, specific to the theme. Truly generative text is incredibly challenging to create onchain. Instead, name contracts provide dictionaries of prefix, city and suffix names for each theme. These words are picked and placed together to form a name, so a Desert track might get the name Super Reno Raceway while a Base theme track might be called 1974 Munich Motorway.

The most challenging aspect of working onchain for an engineer is the immutability of smart contracts. CryptOrchids has a typo in IPFS metadata and also a bunch of $LINK locked in the contract that’s been staring me in the face for years. Some NFT contracts maintain an updatable baseUri - implementing that functionality violates notions of self custody, where the contract owner can change the token’s artwork. Baseclock learned from this mistake, but as an onchain project it doesn’t use a tokenUri in the same way as an offchain project. Instead, the NFT contract that stores ownership data points at a rendering contract. Any bugs in the renderer can thus be addressed by deploying a new renderer and pointing the NFTs at the new contract.

But that still violates the premise of self custody - I as the creator can “rug pull” the renderer and render…whatever I want instead of the clock minters purchased. This tension creates tradeoffs - how can we continue to deliver a great experience without introducing these vectors for abuse?

Speedtracer handles this through a renderer middleware contract. This contract allows me as the creator to add new renderers, but they are appended to the existing renderer and are only used for tokens specified by a range. This is how we are able to implement seasons - Season 1’s 366 tokens will always use the renderer that was in place when those tokens were minted. It allows us to iterate on the algorithm and themes for Season 2, while maintaining one collection and not changing the artwork for Season 1 tokens.

The tokenUri output for an individual token includes an entire artwork, but the core of the algorithm’s output is an SVG path definition string. If the Solidity code I wrote is an instruction set for the EVM, then the output of the algorithm is an instruction set for graphical rendering in your web browser or whatever environment is interpreting those instructions in order to display an image.

It’s instructions all the way down, which enables exciting properties you don’t get in a more typical generative artwork, where the art itself is the output and which suggests some sense of finality. Speedtracer is more similar to Autoglyphs than Chaos Roads, both wonderful generative artworks. While Chaos Roads creates a dynamic and evolving audiovisual output that exists unto itself, Autoglyphs creates an instruction set which can be viewed independently as an artwork, but can “be drawn to a screen or even on paper by following the written instructions in the comments of the smart contract itself.” ¹

Autoglyphs instructions may be useful in contexts outside of visual art, but it would require a liberal interpretation of the instruction set to make something approaching a game. Speedtracer on the other hand uses a standard instruction set that can easily be mapped to other contexts. The SVG Path d attribute is key to the project’s composability to create a web based game where track owners can permissionlessly edit the appearance of their NFT and how it plays as a game map.

// Example algorithm output of SVG path d attribute commands
// with one command per line
//
// see MDN's documentation for SVG Path commands to learn more
// https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d

M 199,396 
L 527,327 
C 636,304 648,301 711,497 
C 726,544 741,591 826,442 
C 910,294 925,341 940,388 
S 1061,605 819,779 
S 530,959 636,1126 
S 804,1271 973,1486 
C 1021,1547 1069,1608 789,1559 
C 802,1862 697,1854 607,1630 
L 463,1322 
C 415,1220 401,1203 330,925 
L 348,683 
C 338,577 -40,464 199,396

The Speedtracer game uses the algorithm output to create a traceable racetrack. The game challenges users to trace the track as quickly as they can without crashing into the track wall. Users can play on desktop with a mouse, but the experience is primarily geared towards mobile phones. As a Progressive Web App, Speedtracer can be installed on your iPhone or Android device.

Starting on January 10th with token ID #1, every day the next token is shown to all players. While this isn’t a hardcore competitive game, after each turn the user is shown a sharable card that includes their time (or completion percentage) and an outline version of the track with their speed path laid on top. The share card also displays the device the game was played on, the attempt number, and a QR code that can be scanned to go right to that track.

By using the SVG path attribute directly from the contract, we can use that data to create all of the interactive aspects offchain, for any track, even if a user has edited it. This is the power of keeping the algorithmic output as instructions. We’re able to add a checkered finish line that is positioned along the starting block straightaway. An additional path element is added and offset to show a yellow starting block over top of the track which disappears when the user starts tracing. We have to do some programming to convert web page coordinates to the SVG coordinates, but its pretty simple math.

This would be impossible if we had our generative algorithm output image files that we pinned to IPFS for example - all of the instruction data would be lost, converted into image data. Even the share card uses the algorithmic output from the contract in a different way. Remember, we’re outputting instructions to draw a path shape. These instructions get used in the share card to draw the outline version of the track on top of which we display the user’s speedmap - a gradient SVG path built up from the user’s touches with a speed calculated by time between points.

The Speedtracer game is not a crypto game. It’s a free to play, no login required, casual mobile game. It happens to use crypto rails for track generation and customization, but the people who have the most fun with it have no idea that it’s backed by a public ledger blockchain nor do they care. For track owners who do care and want to be stewards of the game, blockchain tech ensures they are in complete control of their track - maybe you want to make the track look like your company logo, or a ❤️, or maybe you just want to make the track a tiny bit more challenging for players. It’s entirely up to you and doesn’t depend on me running an API or server.

The aspect of Speedtracer that most depends on the unique aspects of public ledger blockchains, and particularly a cheap Layer 2 Ethereum blockchain like Base, is the full custody a tracetrack token owner has over their track. Owning a track gives you complete control over the track design and allows you to capitalize on the attention on your track on race day by giving you control of sponsorships.

Edit Your Track

A track owner can perform a transaction against the Speedtracer contract that replaces the algorithmic output with their own SVG path attribute data. They can later perform another transaction to revert back to the algorithmic output, and can continue updating the track as often as they like.

You could of course do this directly against the contract. Leveraging the known and widely used SVG standard makes this accessible to anyone willing to learn the commands SVG paths use in their instruction set. But the project’s adherence to output as instructions allows us to offer more compelling interfaces for editing that output. Anyone can play with the track editor to see how it works - it’s available at https://speedtracer.xyz/edit/69 (you can replace the 69 with any other token ID). Here’s a screenshot of the editor at writing time. The algorithm isn’t finished, so this isn’t a great track. And the UI could use some cleanup.

The first thing to notice is the algorithm output on the left. We split commands by line so you can better see them all, and you can edit that text to see the track update in real time.

Next, check out the red dots 🔴 on the track - these are waypoints, the dots we randomized at the start of our algorithm that we later connected.

The green 🟢 and blue 🔵 dots are called control points. The math can get a little complex, but you can think of them as pulling the curves of the lines between the waypoints. Some of our segments use self-reflecting S commands, where the first control point is calculated as part of the SVG spec itself in order to guarantee G2 continuity between segments. Other commands used in the algorithm output are C commands, which are similar to S but allow you to specify the first control point, which means you won’t necessarily achieve G2 continuity.

To edit things, you can simply start dragging the waypoints and control points. The red border guide shows the 16:9 ratio section you should keep the track on to fit on the canvas and on phones. Control points can be outside of this area, but the track should stay within it.

Here’s what I came up with in a minute or two of editing. I removed one of the commands down the right side of the track, and went for a more sweeping, curvy design:

If you look closely, you can see that the path data changed to reflect the manipulation I made with my mouse. We’re not editing an image so much as we are editing instructions to make an image. More precisely we’re editing instructions to make a path, which the contract and game UI use to construct the whole track. Its instructions all the way down!

Onchain Sponsors

Another benefit for track owners is the ability to place trackside advertising boards and race result ad units for your track. You can use these however you want! You could eschew raw capitalism and put some of your favorite art on your track (please). You could advertise your own project or company. You can even sell your ad space to third party sponsors - Speedtracer integrates the Delegate.xyz marketplace, allowing you to sell the advertising rights without selling your track entirely. Speedtracer’s analytics are public, so you can use that data to determine the value of these ad units.

Just like track editing, you can update your sponsorships onchain by transacting directly with the contract. But the sponsorship editor, like the track editor, makes this process much easier. You can upload images and drag, resize and rotate them to place anywhere on your track. For the race result ad unit, you can upload an image and specify a target URL that should open when a user taps the ad

None of my previous projects have been terribly successful, so I’ve been making more of an effort to meet the market where it’s at with my more recent work. NFTA is my most recent release, another daily crypto game. There I tried to lean more into what seems to bring people to the space - money making opportunities.

With Speedtracer, the sponsorship opportunities provide one avenue to make your Speedtracer tracetrack a yield bearing asset. A second opportunity capitalizes on the competitive drive we expect some players to have. The game will always be free to play, without any requirement to connect a wallet. I expect the vast majority of casual players to play this way. But competitive players can mint NFTs of their race result by paying 0.0008 ETH.

Half of this mint fee is shared with the track owner. If just 220 players mint a Race Result NFT for your track then you’ve broken even on the 0.0875 ETH cost to mint a tracetrack. You can always link players to your track, allowing players to trace on any day outside of your global race day. So you can run your own contests with incentives to play and mint the result card - the game uses those NFT mints to construct a leaderboard. You could even run a contest, then change your track shape and run another contest - you completely own your track and can use it however you see best to generate some yield.

I’ve struggled to build community and gain traction for my previous projects and hope that track ownership yield opportunities can help align my and track owner interests. Track owners naturally will want to pump their bags, but it goes a step further in terms of marketing the game. With a few hundred track owners able to generate revenue through naming rights and race result mints, we have a community of individuals, myself included, who all want to see the user base for the Speedtracer game grow. We aren’t selling a roadmap and hype, and we’re giving holders ways to profit without exiting the community. By offering a Web 2.0 oriented display ad channel, plus the web3 race result minting, we give community members multiple avenues to help grow the game and their yield - they don’t even need to tell their friends it’s a crypto based game, and perhaps those users eventually onboard with their first crypto wallet when they want to get on the leaderboard.

The most important takeaway for all of the track ownership capabilities is the choice I made to create my art onchain with Solidity. None of this would be possible with a P5 script and finished artworks pinned on IPFS. Using Solidity and the EVM to generate the art creates many challenges, but the payoff is worth it when you start to recognize how the onchain algorithm and instruction output play their role in creating a networked system with art at the core rather than a static offchain object with zero capability for composability or extensibility. Speedtracer utilizes blockchain as a medium far beyond what most generative art NFT projects can accomplish.

The Speedtracer game was launched as a very early alpha in Spring 2023. Just me and a few friends playing and finding bugs. I launched the beta in December 2023, where we added the Race Results NFTs and a Leaderboard, all on testnets. I sent some tracetrack NFTs to friends and early players to start testing track editing and ads uploading. Some track owners organically started offering prizes for their race day top performers which really seemed to rev players’ engines.

The player base is still small, but the most promising metric is that each user plays multiple attempts per track. That suggests people are finding the game fun enough to keep trying when they crash, and to keep improving their times even after they complete a trace successfully. The product analytics dashboard is public so you can look at some of these numbers yourself - stats.speedtracer.xyz.

Starting January 10, Race Result NFTs are available for minting on Base mainnet. Race Result mints will get you a discount for public sale mints. We’ll be doing some giveaways and contests starting then as well.

Speedtracer tracetracks go on sale on mid-January for 0.0875 ETH. 366 tokens are available for Season 1. Holders of my previous projects will have access to an exclusive minting period for a reduced price of 0.07 ETH.

You can explore the algorithm’s long-form output in a few ways.

The explore page at speedtracer.xyz/explore will show you random outputs directly from the contract. This is the fastest and most raw option, but some of the more advanced SVG features the art uses aren’t well supported on mobile browsers.

The mint page on Highlight will also show random outputs. It’s slower but works better on more devices and browsers thanks to an image conversion pipeline.

[1] Hall, M., & Wilkinson, J. (2019). Autoglyphs. Larva Labs. https://www.larvalabs.com/autoglyphs