Shinryo - new

Inspiration

The challenge of real-world systems where lots of things move and compete at once, for example, Formula 1, Moto-GP, races with silent electric cars, drone fleets delivering packages in bad weather, or city traffic trying to avoid gridlock. We want to make a simple, fast way to simulate all of that without needing heavy tools or weeks of setup. The goal is to build something lightweight and powerful but still useful for testing strategies in racing, logistics, or urban planning. Even the new autonomous racing league in Abu Dhabi is using AI to race, where the hardware remains the same for all cars, but the software stack and algorithms are what will choose the winner.

What it will at least do (more things might come to light)

The simulator lets you model hundreds of moving agents like cars, drones, or delivery robots in real time. It tracks their position, speed, and behavior on a custom track or city layout. Random events like rain, obstacles, or battery drain can happen during the run, affecting performance. A live leaderboard updates every second based on distance, laps, or efficiency. It’s built for quick experiments: test a pit-stop strategy, optimize drone routes, or see how traffic flows under stress. This also can be used for coming up with better strategies in the future to improve efficiency as we collect the data and build on top of it.

How we plan to build this

Rather than going with python or node.js for the main heart of the backend, we'll be using rust or go to save compute resources and be as efficient as possible with low latency and time by using concurrency and parallel processing. This decision will greatly benefit when simulating physics without spending too many gpus and cpus whereas using python would greatly squeeze compute resources when the agents increase on our simulator.

The backend and frontend are completely decoupled in this project so frontend would use html5 canvas or pixijs for 2d rendering while using react and vue for the dashboard. Using websockets for having the two-way communication, as it is way better and faster than old HTTP polling. The leaderboard and details will be updated in realtime using in-memory sorted sets by redis that are built for high-speed changes and leaderboards with constant fluctuations. This also helps us by only using RAM, our intension for low latency and better data structure. We might use kafka injuction with redis streams for massive volume of data and stream processing from kafka and get real-time data access and caching from redis. Use S3 buckets for raw run logs and dataset exports.

Challenges we might run into

Trying to run both kafka and redis together and achieve the least possible latency might make little bit more time-consuming as it is a 24 hour hackathon. And it might be easy to use goroutines for each agent and have them access a shared world map but if two agents modify the same part of the map at the same time without proper mutexes, it might corrupt the simulation state, so we must carefully have proper locks and an error-prone design.

What's next for Shinryo

Refine the idea more and try to come up with better solutions for deadlocks and state consistency. Better message-passing architecture might help it be better than existing solutions.

Built With

• bevy
• bindgen
• gemini
• javascript
• python
• rust
• taichi
• wasi
• webassembly
• webtransport