Ambition, Limits and Priorities

There are many things I would love Project Tourge to become. Some are natural extensions of systems already in the game. Others would require an entirely new layer of networking, persistence, security or content production. Having the idea is the easy part. Deciding whether it deserves the project's limited time and resources is much harder.

This devlog is not a roadmap and none of the ideas below should be treated as a promised feature. It is an honest look at the limits surrounding the project, the possibilities I keep thinking about and why even a good idea may have to wait.

The graphical limits

Project Tourge is built with Unity HDRP. It provides a strong base for detailed materials, lighting, weather and modern visual effects, but no engine offers unlimited graphics for free. Every reflection, light, shadow, transparent surface and piece of geometry has a cost. The game still has to run smoothly while physics, audio, weather and multiplayer are working at the same time.

The target is not to push one perfect screenshot while ignoring the actual drive. Visual quality has to survive movement, changing weather, different times of day and a wide range of hardware. Some effects have to scale down, some need carefully chosen limits and some may simply be too expensive for the value they add.

The larger limitation is content production. There are currently no dedicated vehicle artists, environment artists or map artists on the project. I am building it alone, and detailed cars, roads, buildings, interiors, customization parts and animations all take specialist time. HDRP can render what it is given, but it cannot create an entire open world or a library of production-ready vehicles by itself.

What a zero budget actually means

Project Tourge currently has a budget of zero. There is no publisher funding a large team, no art department producing assets in parallel and no pool of money for licensed cars, music, hosted services or outsourced work. Wherever possible I use my own work, tools I can access and solutions that do not create a bill the project cannot pay.

This does not stop development, but it changes every decision. Time becomes the main currency. Adding one large system can delay several smaller systems that would improve every drive. A feature that depends on permanent online storage may also introduce an ongoing cost long after it has been programmed. The question is never only “Can this be built?” It is also “Can it be completed, maintained and supported by one person?”

Peer-to-peer has strengths and limits

Peer-to-peer multiplayer is a practical fit for the project. It allows players to meet without requiring Project Tourge to operate a worldwide fleet of dedicated game servers. It keeps the cost of a normal session realistic and supports the goal of making the move between offline and multiplayer feel effortless.

The trade-off is that one player's machine has to host and coordinate the session. Connection quality, upload speed, latency and the host's available performance all matter. Every additional state that must remain identical—from a moving car to a loose object in the road—adds communication, validation and recovery work.

Many multiplayer ideas are straightforward to demonstrate between two machines. Making them reliable when players join late, disconnect, reconnect, have poor connections or disagree about the current state is the difficult part. As more responsibility is placed on the host, the session asks more from that player's CPU, network connection and upload bandwidth.

Persistent ownership creates another problem. A central service can act as an authority when two people trade an item, prevent duplication and preserve the result after both players leave. Doing this safely in a serverless peer-to-peer environment is much more complicated. The system has to decide which record is trusted, survive interruptions and prevent one car or component from existing in two inventories at once.

Ideas I would love to explore

Music that leaves the car

I want music to be audible from another player's car when their windows are down. Pulling alongside a friend and hearing their current track would make every car feel more present in the shared world. The audio would need to follow the vehicle, respond to distance and the car's windows, and remain synchronized closely enough that both players are hearing the same moment.

Trading cars between players

Direct vehicle sales, part trading and pink-slip races could give ownership real meaning between friends. The driving part is simple. Safely transferring the winning car is not. Peer-to-peer ownership needs protection against interrupted transfers, duplicated items and conflicting saves. Pink slips would involve in-game vehicles only, not real-money wagering, but the result would still need to be dependable before the system could be trusted.

A player-driven photography gallery

The camera system could eventually connect to an in-game gallery where players share their own Project Tourge photography. That would give creators a place inside the game rather than making every photograph disappear into a local folder. It would also require storage, uploads, moderation, reporting and rules for what can appear publicly—all services that have real technical and ongoing costs.

A marketplace built by players

A player-driven marketplace for cars, engines, components and other items could create an economy shaped by what people build and value. It is also much larger than a menu with a buy button. Listings have to persist when the seller is offline, ownership needs a trusted authority and the economy needs protection against duplication or manipulated data. Without central infrastructure, every one of those responsibilities becomes harder.

Getting out of the car

Being able to get out and walk would change how players experience garages, meets, gas stations and the world around their cars. It immediately creates new questions too. What happens when another player hits you? How should collision, animation, camera control and synchronization behave? How much of the map needs to support a player on foot? A walking controller is easy to prototype. Making the entire game world work around it is not.

Physical interaction with the car

Opening the hood, doors and trunk, operating the wipers and interacting with other parts of the vehicle would make meets, photography and maintenance more personal. Each interaction needs suitable car geometry, pivots, animation and multiplayer state. Supporting it consistently across every vehicle is mainly a content-production challenge, which returns to the project's current art limitations.

A synchronized, reactive world

Real-time synchronized objects, movable props and breakable scenery could make multiplayer drives feel less static. If one player hits something, everyone should see the same result in the same place. The host then has to communicate those changes, late-joining players need the current state and the system needs a sensible way to recover when network updates are lost. A few objects are manageable. An open world full of them can become expensive for the host very quickly.

Possibility is not priority

These systems are possible, and many more ideas are being considered. That does not make them priorities today. The physics, cars, tuning, driving world, performance and reliability have to remain the foundation. A large social feature is not useful if the basic drive beneath it is unfinished.

I would rather build the important systems properly than announce every exciting possibility and leave the core game waiting. Some of these ideas may arrive, some may change shape and some may prove unrealistic without more people, funding or infrastructure. Being transparent about that is part of building Project Tourge in public.

Ambition decides where the project could go. Priorities decide whether it gets there.