Oxidation #2 – Pimp My Ride

This entry is part 2 of 4 in the serie Oxidation

Oxidation

Oxidation #1 – Changing Course (1)

Oxidation #2 – Pimp My Ride (2)

Oxidation #3 – Talented Ego (3)

Oxidation #4 – Legacy Please! (4)

Most players see the upgrade. Few ever look under the hood.

Rust already contains a surprisingly accurate explanation of the way Rust itself has been developed.

Build a modular car and the principle is immediately visible. Put it on a lift, open the engine compartment, and the machine stops being one indivisible object. Pistons, crankshaft, carburetor, valves and spark plugs can be replaced individually. Better components change what the vehicle is capable of without requiring an entirely new car.

You can build a garage around it.

And in August 2026, Facepunch made the analogy even harder to ignore. As part of Power Trip, the old garage at Oxum’s Gas Station finally became a working garage. Restore power and the door operates. Drive a car inside and the lift works exactly like the one a player can install at home. A building that had spent years looking like a workshop suddenly became one. (Rust)

So Pimp My Ride requires remarkably little metaphor.

Rust is still built on Unity. But the Rust running today is surrounded by thirteen years of replaced components, custom integrations, outside technologies, abandoned experiments, recovered assets, rewritten systems and increasingly deep modifications.

Sometimes Facepunch replaced something because it no longer performed well enough. Sometimes the technology itself was perfectly useful, but the way Rust was allowed to access it became the problem. Sometimes another company produced something worth adding, and accommodating that new technology forced Rust itself to change. Occasionally an outside company changed the rules strongly enough to make the dependency itself worth reconsidering.

And sometimes a new idea was simply heavier than the Rust that first imagined it.

The player normally sees none of this.

The player sees the car.

The interesting story begins when the hood opens.

The Car Was Already on the Lift

This habit appeared remarkably early.

Only months after Rust entered Early Access, Facepunch was already rebuilding the game beside the version people were playing. In June 2014, players launching Rust were offered the familiar game or an Experimental version. Facepunch described the latter without much ambiguity: it was the reboot they had “made from scratch.” It remained beside the existing game because it was nowhere near ready to replace it. (Rust)

For a while, both Rusts existed together. One was the machine people already knew. The other was the workshop floor.

By October, Experimental had become the normal way to launch Rust, while the previous implementation survived as Legacy. (Rust)

The important part is not merely that Facepunch once rewrote its game. It is what happened afterward.

At the end of 2014, Garry Newman looked back at the reboot and said the team considered it inevitable, but also admitted that they had made a mistake in allowing the new version to wander into new development before recovering the stability, gameplay and performance of Legacy. Their cleaner path, in retrospect, would have been to first rebuild the foundations and only then start branching outward. (Rust)

That is almost a workshop rule.

Replacing a part can recover freedom.

It does not remove the obligation to make the car drive.

Facepunch had already discovered something that would return repeatedly at smaller scales over the following decade: preserving an implementation is not necessarily valuable if the implementation prevents Rust from becoming easier to develop.

But whatever replaces it eventually has to carry the same weight.

Usually more.

The Weight of the Dream

Rust’s development history is full of concepts that never arrived exactly as they were first imagined.

Looking backward, it is easy to classify those images as abandoned ideas. Some certainly were. Directions changed. Designs evolved. Certain concepts were extravagant enough that they simply did not belong in the Rust that eventually emerged.

But concept art has an enormous technical advantage over a finished game.

It weighs almost nothing.

The modular vehicles are an almost absurdly appropriate example.

In July 2015, Howie was already exploring a modular approach to Rust’s vehicles. The early drawings went far beyond simply putting a car on the road. They showed machines with identities already attached to them: utility trucks, improvised combat vehicles, specialized cargo configurations, vehicles carrying equipment that made their purpose immediately obvious.

They looked finished.

Then the idea disappeared for years.

When modular vehicles finally returned in 2020, Facepunch described the job as making those old concepts a reality after roughly five years in what it called “concept limbo.”

But the production vehicles did not look like most of those drawings.

They were simpler.

Much simpler.

That difference has generated an understandable question whenever the old concept art resurfaces:

What happened?

The most interesting answer may be that Facepunch stopped before finishing the vehicle for us.

The early concepts often showed the end of the customization process. The machine already knew what it was. A particular truck was armed. Another was specialized for a particular job. The designer had already decided what belonged on it.

The production system stopped earlier.

Facepunch delivered chassis of different lengths, interchangeable modules, engine components, cabins, seats, storage, fuel tanks and other relatively neutral pieces. The result looked less extravagant than the concept art, but it also left considerably more blank metal.

The concept cars were more finished. The production system was more open.

That distinction becomes obvious once the system leaves vanilla Rust.

A modular vehicle does not have to remain the vehicle Facepunch imagined. Because its basic structure is exposed as reusable pieces, server developers and plugin authors can reinterpret it.

Karuza’s racing system provides an unusually clear example. (https://karuza.dev/)

Using what Rust already supplies, the modular vehicle framework can become something Facepunch never needed to ship as part of the survival game itself: brightly customized racing karts, dedicated courses, different race configurations and global leaderboards.

At that point the old question — what happened to the concept cars? — becomes almost backwards.

They did not necessarily disappear.

Their personalities became somebody else’s decision.

The early concept artist could draw the armed truck.

The production system gave somebody else enough vehicle to build a racing championship.

That is a very Rust-like trade.

A finished object gives the player one answer.

A system can give the player, the server owner or the plugin developer the pieces required to invent several.

And this is where the story returns to the Core, because openness is not free.

A concept vehicle consumes no memory. Its wheels never collide with terrain. Nobody abandons twenty of them around a compound. It never has passengers, damaged engine components, storage, fuel, locks or persistence. It cannot be rebuilt into something its designer never anticipated.

A production system can.

The moment the concept enters Rust, the dream acquires mass.

By the time the Vehicles branch merged into Main in June 2020, Facepunch counted almost 2,500 new or changed files. More revealingly, the public beta was not simply intended to determine whether the cars worked. Facepunch explicitly wanted to understand how the new vehicles fit into the game as a whole.

That is the real difference between a concept car and a production car.

The question is no longer:

Can we make this object?

It becomes:

Can Rust comfortably become a world in which this object exists everywhere?

Once the vehicles became real, all the invisible obligations arrived with them. Their physics became real. Their network traffic became real. Their persistence became real. Damage, decay, repair, fuel, components, roads and lifts became real.

Then the players arrived.

One car becomes ten.

Ten become hundreds across a server.

Vehicles get abandoned in places nobody expected. They get packed into compounds, driven over terrain they were never meant to enjoy, loaded with players and storage, repaired, destroyed, modified and incorporated into systems Facepunch never designed.

And eventually somebody turns them into racing karts.

No development branch can completely reproduce that future.

It can approximate it.

Players manufacture it.

This is why performance problems following a large feature do not automatically demonstrate that the feature was poorly planned. They demonstrate something much more universal about long-lived software: no matter how carefully an idea is designed, its true cost becomes visible only when the real world begins multiplying it.

The same principle applies to Rust’s more extravagant environmental concepts.

Making one enormous, extraordinarily detailed monument is relatively easy compared with building the version of Rust in which that monument no longer looks extraordinary.

A world has to remain believable around it.

The environment surrounding the structure has to carry enough density and quality for it to belong. Terrain has to support it. Rendering has to decide efficiently what deserves to remain visible. Memory has to retain the necessary assets. If the concept depends on AI, physics, vehicles or large numbers of interactive entities, the Core has to carry those too.

A concept therefore asks more than:

Can this be built?

It asks:

Can the rest of the game afford to exist beside it?

That gives many discarded concepts a more useful place in Rust’s history.

They were not necessarily bad ideas.

Some were simply designed for a Rust that did not exist yet.

And some concepts may not have been waiting for Facepunch to finish them.

They were waiting for Rust to become strong enough to carry them.

The modular vehicles demonstrate both sides of that equation unusually well.

The old drawings show how far imagination can travel when it has no technical weight.

The production vehicles show what happens when that idea has to enter a real sandbox.

And the things built on top of them afterward show why leaving some of the dream unfinished can sometimes create more possibilities than finishing it ever could.

The dream gets heavier when it becomes real.

But in Rust, it can also become someone else’s dream once Facepunch hands over the parts.

Changing the Factory Radio

Not every limitation requires an engine transplant.

New car owners understand this. The factory stereo works. It plays music. Then somebody decides they want navigation, Bluetooth, better controls or something that integrates properly with the rest of their equipment.

The original component did its job.

It simply stopped being the component the owner wanted.

Rust’s networking has repeatedly followed variations of this pattern.

RakNet became an important part of Rust’s networking stack, but by 2020 Facepunch described it as an ageing, unmaintained dependency with exploits the team had increasingly needed to patch itself. Valve’s Steam Networking had become attractive enough that Facepunch began implementing it as an alternative.

But the interesting part was not simply replacing RakNet.

Rust was changed so both networking protocols could coexist. Servers could opt in and clients could select the appropriate connection method. Facepunch could therefore test the replacement without immediately committing the entire game to it. (Rust)

That is much closer to the pattern that emerges across Rust’s history than the idea that Facepunch simply wants everything to be proprietary.

When Unity gives Rust exactly what it needs, Facepunch uses it.

When an outside library works, Facepunch can keep it.

When another company produces a better component, they can install that.

What changes repeatedly is where Facepunch wants control to begin.

Recast gives us perhaps the cleanest modern example.

Unity, like several other engines, already uses the third-party Recast navigation library internally. When Facepunch recently replaced Rust’s navigation integration, they did not replace Recast.

They removed the layer between themselves and it.

“We still use the same library, the difference is that we now have full control over it.”

Facepunch specifically contrasted its new arrangement with Unity’s previous black-box integration. Direct control allowed obstacle processing to be moved and budgeted differently, expensive pathfinding requests to be constrained, and navigation behaviour to be designed around the strange conditions Rust creates rather than around the needs of every possible Unity project. (Rust)

In less technical language, Facepunch did not dump Recast.

It freed Recast from Unity’s grip, and apparently the two became much better friends afterward.

The part was fine.

The connection was the problem.

That distinction matters throughout this article because Rust is not a monument to Not Invented Here. Its machinery is a mixture. Unity systems remain where they work. External technologies are brought in where useful. Facepunch sometimes builds its own solution, sometimes modifies somebody else’s, and sometimes simply waits until an existing technology exposes enough control to make a better Rust-specific implementation possible.

Facepunch does not appear particularly sentimental about technology.

The useful part is the part that stays.

The Concept Car That Never Shipped

No part of Rust’s development fits the concept-car analogy better than HDRP.

Beginning in May 2019, Facepunch undertook what it later called a “mammoth task”: exploring a transition from Rust’s existing rendering pipeline to Unity’s High Definition Render Pipeline.

The attraction was obvious. HDRP offered newer rendering technology, increased visual fidelity and, importantly, the expectation of better performance.

Moving Rust there meant updating enormous quantities of existing artwork.

Months went into that conversion.

Then profiling produced the wrong answer.

Facepunch never found the performance improvement it expected.

HDRP was worse. (Rust)

So the transition stopped.

Viewed only from that moment, HDRP looks like one of the largest abandoned technical projects in Rust’s history.

Then look at Rust in May 2021.

The World Revamp transformed terrain, trees, rocks, cliffs, vegetation and significant portions of the island’s monuments. Facepunch explicitly explained that most of those new visuals had been developed alongside the HDRP transition. Rather than discard them when HDRP was cancelled, the team spent additional months porting the work back to the rendering pipeline Rust was already using. (Rust)

The renderer did not survive.

The world it helped create did.

HDRP therefore becomes more interesting than a failed migration.

It was a concept car that never reached the showroom but donated a remarkable amount of its bodywork to the production model.

And that says something important about the workshop.

Facepunch can abandon the destination without necessarily abandoning the useful work produced on the way there.

A detour can still permanently alter the machine.

The Driver’s Computer Is Part of the Machine

Concept artists have another luxury that developers do not.

They do not need to know what computer the player owns.

A conventional PC game can establish a hardware target, publish minimum and recommended specifications, release, and largely leave that target behind.

Rust has spent more than a decade continuing to change after people had already bought it.

That creates a different kind of responsibility.

Every increase in visual complexity can raise the ceiling. Simply allowing the minimum requirement to climb at the same rate would eventually amount to telling existing players that the Rust they bought had outgrown their machine.

So part of Rust’s technical evolution has been an attempt to widen the distance between the bottom and the top.

Facepunch wants enough efficiency that weaker systems can continue carrying the game, while stronger systems receive additional things on which to spend their hardware.

This is why technologies such as NVIDIA Reflex and DLSS are more interesting than checkboxes in the graphics menu.

World Revamp introduced NVIDIA Reflex as an option for reducing system latency on supported hardware. A few months later, DLSS arrived for compatible RTX GPUs. (Rust)

For the player, DLSS was another visible upgrade.

Under the hood, it demanded more.

Rust needed to render internally at one resolution and present the result at another. Facepunch explained that Unity did not support the exact workflow Rust required out of the box. Supporting the NVIDIA feature therefore forced work on Rust’s render scaling and a substantial rewrite of the post-effects stack, producing additional performance improvements along the way. (Rust)

The upgrade was optional.

The plumbing required to support it was not.

That is an important pattern.

An external technology aimed at powerful hardware can force improvements deeper in the machine. Work undertaken to make Rust cheaper on modest hardware can create headroom that stronger hardware spends elsewhere.

The Core has to serve both directions.

And the machines outside Rust continue evolving too.

As storage becomes faster, whatever still happens after storage finishes becomes more obvious. As CPUs become faster, the thread that does not scale becomes easier to notice. As networks become faster, the time software spends preparing, authenticating or reconstructing something becomes a greater proportion of what the player feels.

The strange consequence of faster technology is that it creates pressure for software to become faster with it.

A connection that took ten seconds could once hide quite a lot of work inside those ten seconds.

If the network portion eventually takes less than one, the remaining two seconds suddenly become the problem.

A faster pipe does not remove bottlenecks.

It moves them.

As the world around Rust gets faster, Rust itself has less time to think.

Eventually, the Car Needed Ports

Cars did not remain purely mechanical either.

First you needed to see behind you.

Then you got better mirrors.

Then parking sensors.

Then cameras.

Navigation.

Connectivity.

Mobile applications.

Eventually, even the steering wheel ended up facing a camera back toward the driver.

The fundamental purpose of the car remains recognizable. The number of systems surrounding that purpose changes enormously.

Rust followed a similar path.

Steam began as an obvious part of distribution and player identity, but different Steam technologies gradually became entwined with deeper aspects of Rust. Workshop content, inventories and account services became part of the experience, and eventually Steam Networking could become part of the transport layer underneath it.

Twitch represents a completely different connection.

Watching Rust eventually became capable of producing an object inside Rust.

When Facepunch enabled its first Twitch Drops campaign in November 2020, players could link the necessary accounts, watch participating streams and receive skins in the game. The visible interaction sounded almost trivial. Enabling those items, however, required Facepunch to deploy a mandatory update to both clients and servers. (Rust)

The user saw a reward.

Rust had learned how to recognize something that happened outside Rust.

Rust+ crossed that boundary even further. The companion app allows a phone to pair with servers, display information from the game, communicate with teammates, receive notifications and interact remotely with electrical devices inside a base. In 2021, Facepunch connected Rust+ to IFTTT, allowing events inside Rust to trigger actions in other applications, services and even physical smart-home equipment. (Rust)

A player sees a notification.

Or presses a button.

Or watches a light turn on.

What matters technically is that Rust has learned another conversation.

This is an important part of the Core’s evolution because Rust has not grown only by becoming capable of doing more things internally.

It has also grown by learning how to talk to systems that exist outside itself.

Sometimes those systems provide a service.

Sometimes they provide a component.

Sometimes, as with NVIDIA, accommodating the component exposes something Rust itself could improve.

And every new connection creates another place where the two machines must agree.

Eventually, the car needed ports.

Lots of them.

Sometimes the Road Changes Under You

Not every important technical decision begins with something Facepunch wants to add.

Sometimes the outside world changes first.

In September 2023, Unity announced a new licensing model centred around a proposed Runtime Fee. Qualifying developers could be charged according to installations of games built using Unity.

The reaction across the industry was immediate.

For studios maintaining successful games over many years, the uncomfortable question was larger than the amount of the potential bill. Developers had built products around one relationship with their engine provider and were suddenly being shown that the commercial rules surrounding that relationship could change afterward.

For Facepunch, this was not an abstract dependency.

Rust had been developed on Unity for roughly a decade.

Garry Newman’s response made clear that the amount of money itself was not his main objection.

“The cost isn’t a big issue to us.”

The problem was that Facepunch had never agreed to the new arrangement.

They had built Rust under a different understanding.

Unity had demonstrated that it could change the rules underneath a game that had already spent ten years being built around its technology.

Garry’s conclusion was considerably less subtle:

“Rust 2 definitely won’t be a Unity game.” (Garry)

That was not an announcement that Rust itself was migrating away from Unity.

It did not.

The importance of the episode is different.

For years, Facepunch had opened the toolbox because Rust wanted something more. A system needed additional speed, control or flexibility.

This time, the pressure came from outside the garage.

A dependency can change its own rules.

Engines evolve. Middleware disappears. Services alter APIs. Companies change direction. Licensing changes. An entirely rational technology decision can become a strategic problem years later for reasons that have nothing to do with the software being developed on top of it.

Sometimes you replace a part because the car needs something better.

Sometimes the manufacturer of the part gives you a reason to start looking at the toolbox.

The road can change underneath the car.

Opening the Engine

By 2026, the question of how deeply Facepunch could reach into the machinery underneath Rust had changed considerably.

Spring Clean provides several examples at once.

Facepunch began deploying its own fork of UniTask to reduce task allocations in important server workloads. More dramatically, the same update introduced a terrain renderer built by Facepunch rather than using Unity’s terrain renderer. Visually, the terrain was intended to remain broadly familiar; technically, much more of the work could move toward the GPU, while draw calls and CPU cost were substantially reduced. (Rust)

Built Different gave Facepunch direct control over the Recast integration.

Then Naval revealed something deeper.

Facepunch explained that, during the previous year, it had gained the ability to make custom changes to its own version of the Unity Engine and ship those changes with Rust.

Physics provided the immediate reason this mattered.

Facepunch described physics as a long-standing bottleneck for Rust server performance. The enormous world and the density of colliders inside large player bases made PhysX’s broadphase particularly expensive. With deeper engine access, the team could make targeted changes to PhysX itself and parallelize that work across available job threads.

The performance improvement was substantial enough that Facepunch published the before-and-after result — before adding the wonderfully Rust-like observation that those gains naturally resulted in server player caps rising again.

And the cycle begins again. (Rust)

That sentence could almost summarize this entire article.

The machine becomes stronger.

The available capacity gets used.

The next bottleneck eventually appears.

At this point, the garage metaphor changes.

This is not replacing the radio anymore.

Facepunch is not merely changing what is bolted onto the engine.

They can open the engine bay.

At the same time, work continues on what the public development history explicitly calls the Rust Render Pipeline. As of September 2026, its public testing branch contains more than 450 commits and remains actively developed across deferred rendering, lighting, shadows, water, refraction, post-processing and other fundamental pieces of the way Rust draws its world. (Facepunch Commits)

This does not mean Rust is gradually ceasing to be a Unity game.

That framing now seems too simplistic.

A better description is that Facepunch has progressively gained access to deeper layers of its Unity-based machine.

The interesting question is no longer necessarily whether a particular piece originated at Unity, Facepunch, Valve, NVIDIA or somewhere else.

It is:

Who controls the part, and can it be made to do what Rust needs?

The Ferry Is What You See

Nexus may become the clearest demonstration of why all this invisible machinery matters.

To the player, the concept can be explained almost entirely as a journey.

Wait for the ferry.

Board.

Leave the island.

Reach another one.

Facepunch’s technical ambition is considerably larger. Nexus is intended to cluster independent Rust servers and allow players to travel between them from inside the game. Facepunch originally described the system publicly in 2024 as a way to connect multiple maps without replacing the existing independent-server model. The current roadmap now places Nexus System, Server Transfer and Deep Sea Nexus in 2027, while public development and testing continue ahead of that wider release. (Rust)

The ferry is what you see.

Underneath it, several machines have to agree that the journey happened.

A source server has a player who needs to leave. A destination has to exist and be able to receive that player. The client has to change its relationship with the network. Things belonging to the player have to survive the boundary. Vehicles create further problems because the people aboard them may not finish loading simultaneously.

The old Nexus development history is revealing because it exposes these seams directly.

Facepunch worked on redirects, transfer positioning, authentication, ferry routing, queues, transfer protection and loading behaviour. One change deliberately waits after issuing nexus.redirect before disconnecting the player from the old server so the loading screen has a better chance of appearing rather than leaving the client apparently stalled. Another fixed the wonderfully appropriate bug in which the nexus.transfer command could accidentally transfer the ferry itself along with the player standing on it. (Facepunch Commits)

The recent 2026 work makes the plumbing even more visible. Ferries prefer servers that are online and not full, lock their destination once they stop at the terminal, and can be retired when no valid destination remains. Players arriving through a transfer can bypass the normal queue because otherwise their temporary transfer protection might expire before they finish joining, leaving aircraft or other vehicles in dangerous states. (Facepunch Commits)

None of that is what the player is supposed to be thinking about while standing on deck.

This is where design starts doing engineering work.

The Nexus ferry has been developed within Safe Zone behaviour. That is important not because the ferry has invented a new category of monument rule, but because Safe Zone rules already reduce the number of things players are allowed to do while the transfer is happening. Combat is suppressed. In practice, the ordinary possibility of simply lying down and creating a sleeper is removed as part of that protected state as well.

Instead of engineering answers to every possible combination of combat, death, sleepers and transfer timing, the design narrows the number of states Nexus needs to accommodate while the player is crossing.

Sometimes the cleanest engineering solution is a game-design rule.

The server transfer still exists.

Facepunch has simply given it a boat.

And importantly, that should not be mistaken for claiming that the technical transition is currently invisible. Public Nexus work explicitly includes a loading screen for changing servers and careful timing around the disconnection itself. (Facepunch Commits)

The elegance is elsewhere.

The player has a reason for the interruption.

The connection does not change because a server dialog suddenly appeared.

It changes because the ferry left.

The principle resembles what happens when an online video continues briefly after the internet connection fails. The viewer can keep watching because enough material already exists locally to preserve continuity for a while. The technical discontinuity and the perceptual discontinuity do not necessarily happen at the same moment.

Nexus is obviously not video buffering.

The useful comparison is the experience.

A good transition does not necessarily remove the interruption. It gives the player enough continuity that the interruption stops being the story.

Facepunch does not have to pretend that one server has magically become another.

The player took the ferry.

That is the story.

The machinery underneath can remain machinery.

Still Running

That may be the easiest part of Rust development to overlook.

Updates arrive as things.

A monument appears.

A car arrives.

Water looks different.

AI suddenly behaves differently.

DLSS appears in a menu.

A phone can communicate with a base.

An old garage begins working.

A ferry arrives at a terminal.

Players experience the result.

The development team inherits everything required to make that result ordinary.

And ordinary is much harder than spectacular.

A concept only has to demonstrate that an idea could exist. A production system has to survive real servers, unpredictable players, different processors, different GPUs, different networks, outside services, future updates and combinations nobody had any reason to test until somebody actually tried them.

That is when the dream acquires weight.

Facepunch has spent thirteen years responding to that weight in different ways.

There is no clean history in which Rust gradually replaces Unity with Facepunch technology.

That story would almost be too orderly.

What exists instead looks much more like a real workshop after thirteen years of keeping the same project alive: original parts beside replacements, external components attached through custom integrations, third-party systems kept after their original adapters were removed, forks tuned for specific needs, abandoned prototypes in a corner, good parts salvaged from projects that never shipped, and new equipment connected where no connection existed before.

Even the engine itself can now be opened further than it once could.

And through all of this, the machine is still running.

Perhaps that is why Rust’s modular car is such an unusually good picture of Rust.

The engine does not necessarily have to go.

The components around it remain negotiable.

The stronger the machine becomes, the heavier the dreams it can carry.

And every time Facepunch clears enough room under the hood, somebody eventually finds something new to put there.

Put the car on the lift.

Open the hood.

Find the next bottleneck.

Then keep driving.


References and Further Reading

  • Branching Out — Facepunch, 17 June 2014. Experimental made available beside the existing Rust and explicitly described as a reboot “made from scratch.” Branching Out
  • Experimental Launches By Default — Facepunch, 1 October 2014. Experimental becomes the normal launch path while the previous implementation moves to Legacy. Experimental Launches By Default
  • Devblog 40 — Facepunch, 28 December 2014. Retrospective on the reboot, including Facepunch’s conclusion that it was inevitable but should first have reproduced Legacy’s foundations, stability and performance. Devblog 40
  • Devblog 67 — Facepunch, 3 July 2015. Early modular-vehicle concepts and the intention to create configurable vehicles with utility beyond transportation. Devblog 67
  • Vehicles Beta Branch — Facepunch, 18 May 2020. Modular cars return as a production system; Facepunch explicitly uses the beta to examine how the vehicles fit into Rust as a whole. Vehicles Beta Branch
  • Modular Vehicles Update — Facepunch, 2 July 2020. Five years of “concept limbo,” production release and almost 2,500 new or changed files when the Vehicles branch merged into Main. Modular Vehicles Update
  • Elevator Update — Facepunch, October 2020. Steam Networking introduced as an alternative to RakNet, with Rust supporting both protocols during the transition. Elevator Update
  • Rust Twitch Drop Event — Facepunch, 12 November 2020. First official Twitch Drops campaign; enabling it required a mandatory client and server update. Rust Twitch Drop Event
  • Companion App Update — Facepunch, 4 June 2020. Rust+ server pairing, map and team information, notifications and remote interaction with smart devices inside Rust. Companion App Update
  • Gestures Update — Facepunch, April 2021. Facepunch’s detailed account of the HDRP project, the disappointing performance results and the decision to halt the migration and backport the improved assets. Gestures Update
  • World Revamp — Facepunch, 6 May 2021. Release of terrain, vegetation, rocks, cliffs and monument work developed largely during the abandoned HDRP transition; also introduced NVIDIA Reflex. World Revamp
  • Contacts — Facepunch, 3 June 2021. Rust+ receives IFTTT integration, allowing Rust events to communicate with outside apps, services and physical devices. Contacts Update
  • Wounding Update & Voice Props DLC — Facepunch, 1 July 2021. NVIDIA DLSS integration and Facepunch’s explanation of the render-scaling and post-effects work required to accommodate it. Wounding Update & Voice Props DLC
  • Unity can get fucked — Garry Newman, September 2023. Newman’s response to Unity’s Runtime Fee proposal, focused primarily on the loss of trust and ending with “Rust 2 definitely won’t be a Unity game.” Unity can get fucked
  • Surviving a Decade — Facepunch, 4 January 2024. Public explanation of Nexus as optional clusters of servers permitting in-game travel between multiple maps. Surviving a Decade
  • Naval Update — Facepunch, 5 February 2026. Facepunch explains that it can now ship Rust with custom changes to its own Unity version and documents targeted PhysX broadphase modifications that substantially improved server physics performance. Naval Update
  • Spring Clean — Facepunch, 2 April 2026. Facepunch’s UniTask fork and new terrain renderer replacing Unity’s terrain rendering system, along with further server, networking and memory optimisations. Spring Clean
  • Built Different — Facepunch, 4 June 2026. New player architecture and custom Recast integration; source of “We still use the same library, the difference is that we now have full control over it.” Built Different
  • Power Trip — Facepunch, 6 August 2026. Player Maintained Monuments and the activation of Oxum’s garage, including its powered garage door and functional car lift. Power Trip
  • Rust Roadmap — Facepunch, updated 27 August 2026. Current roadmap places Nexus System, Server Transfer and Deep Sea Nexus under 2027 — Planned. Rust Roadmap
  • Rust Render Pipeline — Facepunch Commits. Active public render_pipeline_testing branch, now containing more than 450 commits covering fundamental rendering systems. Rust Render Pipeline development branch
  • Nexus — Facepunch Commits. Historical public development branch documenting redirects, loading transitions, entity transfers, ferry routing, transfer protection, authentication and numerous edge cases involved in moving players and vehicles between servers. Nexus development branch
  • Nexus Fixes — Facepunch Commits. Current 2026 work including ferry destination reliability, full-server handling, queue bypass for transferred players and transfer-protection behaviour. Current Nexus development work

Source Note

Rust has been developed unusually publicly. This article therefore draws from released updates, contemporary developer explanations, retrospective accounts and public development branches. Features appearing in Facepunch’s commit history or roadmap demonstrate active engineering work and direction; they do not guarantee that the final released implementation will remain identical. Where a player-facing feature is used to explain the machinery underneath it, the article distinguishes documented behaviour from editorial analogy.

Views: 2

Similar Posts