# TastSong/CrazyCar: Unity Multiplayer Racing Architecture > CrazyCar is a Unity-based online racing game project combining QFramework, Addressable, HybridCLR, Spring Boot, MyBatis, Vue, and KCP or WebSocket networking. It suits developers seeking a customizable foundation, although the repository describes the project as still in development. **TastSong/CrazyCar** — 网络联机游戏解决方案---Unity制作的联机赛车游戏，服务端为SpringBoot + Mybatis Plus；后台为Vue + Element；游戏端采用QFramework框架，Addressable+HybridCLR实现热更新，支持KCP和WebSocket网络。 - Repository: https://github.com/TastSong/CrazyCar - Stars: 1,845 · Forks: 370 - Language: C# - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/tastsong-crazycar ## CrazyCar's Unity Racing Foundation TastSong/CrazyCar addresses the engineering work behind an online racing game rather than providing only a car controller or a small networking sample. The project combines a Unity client with a Spring Boot server written around MyBatis, a Vue and Element administration interface, and a network layer that can use KCP or WebSocket. Its intended users are developers who want to modify an existing multiplayer racing structure into a customized game. The README documents account registration and login, avatar and equipment hot updates, timed racing, two-player matches, version control through the administration system, and user information management. The client also has a single-player switch on the login page, so the project is intended to support local play as well as networked play. This combination can reduce initial work when a team already wants to build around these technologies, although it does not provide a small or narrowly scoped integration. The repository lists QFramework as the client's application architecture, Addressable for resource updates, and HybridCLR for hot fixes. The client uses Unity's newer Input System and the URP rendering pipeline. Android and iOS clients are linked by the README, although the iOS download note says that certificate problems require contacting the author separately. The repository therefore presents a broad game sample rather than a turnkey client package for every build target. ## KCP, WebSocket, and Racing State Flow CrazyCar's network architecture offers two documented transport choices: KCP and WebSocket. KCP is described in the README as a reliable UDP networking library built on Java's Netty implementation, while the project also uses a Unity WebSocket plugin. The choice matters because the two approaches affect deployment, transport behavior, and client configuration. The README does not state which protocol is selected by default, nor does it specify packet formats, latency targets, reconnect behavior, or a server capacity model. The repository describes synchronization as physical synchronization. This means that game state is synchronized as physical movement rather than being limited to messages that only update interface state. The client and server therefore need to agree on vehicle movement, race state, player inputs, and session events. The README does not document the authoritative simulation model, input validation rules, anti-cheat behavior, or the exact boundary between server authority and client prediction. The server side is organized under CrazyCarServer and includes Spring Boot and MyBatis. The administration client appears under CrazyCarBackground and uses Vue with Element. This separation gives the project a conventional split between the game client, backend service, and management interface. It also creates several integration points. A change to account data, race configuration, version records, or equipment state can involve the Unity client, Spring Boot API, MyBatis persistence layer, and Vue administration interface. For a networked race, the likely flow includes client input, vehicle simulation, synchronization of physical state, and server-side race coordination. The README confirms physical synchronization and the two supported transports, but it does not provide a detailed message sequence. Teams that need authoritative results, reconnect recovery, or strict anti-cheat enforcement should inspect the technical documentation and server code before treating the demo flow as complete. ## Addressable, HybridCLR, and Version Enforcement The update strategy is one of the clearest reasons to inspect CrazyCar as an engineering base. Addressable is used for resource hot updates, including avatars and equipment according to the feature list. HybridCLR is used for hot fixes. The separation is meaningful because Addressable addresses managed content delivery, while HybridCLR addresses executable code updates. However, the README does not document how build artifacts are hosted, how versions are signed, how clients discover updates, or what happens when an update is incomplete. Version enforcement is listed as a completed feature. The project also exposes version control in the administration interface. Still, the README does not identify the endpoint used by the client, the version comparison rules, the supported upgrade path from v9.4.0 through v9.6.0, or whether a failed update leaves an older client usable. Those omissions matter for any team considering a live game deployment because a hot-update mechanism is useful only when its distribution and recovery procedures are understood. The repository has a ProjectOptimization directory with separate documents for Addressable, network synchronization, batching, LOD, mipmaps, and package-size optimization. That indicates optimization work is treated as a separate engineering concern rather than being hidden inside the main gameplay code. However, the README does not provide measured package sizes, memory targets, or before-and-after performance data, so those documents should be reviewed before drawing conclusions about production efficiency. The repository also records v9.4.0 as a major update that introduced HybridCLR hot fixes on the client and upgraded MyBatis Plus on the server. That release note confirms that the update architecture changed during development. It does not establish that every update path is backward compatible, so upgrades should be tested against the exact release being deployed. ## CrazyCar Quick Start and First Local Evaluation The README links to a start video, a quick-start document, a technical document, and a design document. It does not include the installation commands or the contents of those linked documents in the repository README. Consequently, there are no verified package names, ports, environment variables, or startup commands that can be reproduced safely from the README alone. A new user should begin with the repository's [README_QuickStart.md](./README_QuickStart.md), then use [README_Dev.md](./README_Dev.md) for technical setup. The README specifically warns that the project is still in development, that the online database may be reset periodically, and that `mater` is not a release branch. It recommends using the latest release for local testing. That makes the release artifact, rather than an arbitrary branch, the appropriate starting point when the goal is to evaluate the documented build. The README also gives Android and iOS download links and a sample account identifier. The iOS experience requires contacting the author because of certificate issues. These links provide an installation path for evaluating a client, but they do not explain how to configure the client against a locally hosted Spring Boot server, initialize the database, or run the Vue administration interface. The linked quick-start and developer documents are the first files to verify before attempting a full end-to-end run. A correct local tutorial requires the actual configuration values from the server and client project files. That limitation is important for evaluation: a client download can show the game's interface without proving that the backend, database, and administration interface can be operated together. ## CrazyCar Scope, Trade-offs, and Alternatives CrazyCar is a broad reference architecture with a significant surface area. A team adopting it inherits Unity client work, Java server code, database access, an administration interface, networking choices, asset delivery, localization, mobile input, and multiple game modes. That can be useful if the desired product is similar to the documented racing game. It is a poor fit for a team that wants a narrowly scoped networking library, a simple car physics example, or a backend that can be deployed without a Unity-specific client. The repository identifies future work including a creative workshop, an Actor-based ECS server rewrite, replays, post-processing effects, friends and private messaging, UI work, AI improvements, and stronger data security. The planned ECS rewrite is particularly significant because it indicates that the current server architecture may change. Creative workshop, replay, and friend features are listed as future support rather than completed functionality. A real alternative is to build a smaller Unity networking stack directly around the project's selected transport or use a dedicated game backend framework. Such an approach would reduce the number of subsystems to maintain, but it would require implementing the racing rules, persistence, administration features, and update workflow separately. CrazyCar is the more practical choice when its sample implementation is close to the target product. A smaller custom stack is more practical when the team needs a different gameplay model or a backend that does not depend on Spring Boot, MyBatis, Vue, QFramework, Addressable, and HybridCLR together. The trade-off is reuse against control. CrazyCar provides a larger set of connected features, including account management, race modes, equipment, and hot updates. A smaller stack provides fewer inherited assumptions but leaves more application work to the adopting team. The choice depends on whether the documented architecture matches the intended game more closely than the team's own design. ## CrazyCar Maintenance, Licensing, and Adoption Boundaries The repository is not archived, and its last push was on 2026-06-12. The recent releases include v9.6.0 on 2026-05-11, v9.5.0 on 2024-08-11, and v9.4.0 on 2023-12-22. The release notes identify v9.4.0 as a major update that introduced HybridCLR hot fixes on the client and upgraded MyBatis Plus on the server. The repository therefore has recent recorded activity, but the README still explicitly describes CrazyCar as being in development. The project uses the MIT license. That identifier permits use and modification under its terms, but the repository's third-party components and downloaded assets may carry separate licenses. The README references Unity packages, external libraries, plugins, fonts, and Unity marketplace assets. Any adoption should check the license and distribution terms of each included component rather than assuming that the top-level MIT identifier settles every dependency question. The main operational cost is integration cost. The project combines several update systems and deployment components. The README does not document backup procedures, database migrations, observability, authentication hardening, disaster recovery, or server scaling. It also does not claim that the online database is permanent, since the database may be reset. For those reasons, CrazyCar is a credible starting point for a customized racing prototype, not evidence of a production-ready service. The upgrade path also needs attention. The gap between v9.5.0 in 2024 and v9.6.0 in 2026 does not by itself indicate that upgrades are difficult, but it means a team should compare release notes and project configuration before moving from an older build. The presence of a newer release does not replace verification of client compatibility, server persistence, and update delivery. ## Conclusion Adopt CrazyCar when you need a customizable Unity multiplayer racing prototype and can work with a broad stack and an in-development project. Do not adopt it as a finished commercial racing game without validating deployment, asset delivery, protocol behavior, database handling, and licensing first. The latest release is v9.6.0, and the repository's last push was on 2026-06-12. ## FAQ ### What is TastSong/CrazyCar used for? TastSong/CrazyCar is a Unity online racing game project with a Spring Boot and MyBatis server, a Vue and Element administration interface, and KCP or WebSocket networking. It demonstrates timed races, two-player matches, login and registration, equipment updates, and user management. ### How do I install and run CrazyCar? The README links to README_QuickStart.md for the start video and setup guidance, and to README_Dev.md for technical documentation. The repository README does not provide verified local installation commands, ports, or environment variables. ### Does CrazyCar support Android and iOS? The README links to Android and iOS client downloads. It states that certificate problems require contacting the author separately if you want to experience the iOS version. ### Which network protocols does CrazyCar use? The project lists KCP and WebSocket as its supported network transport protocols. It describes synchronization as physical synchronization, but the README does not specify the default protocol or detailed reconnect and latency behavior. ## Sources - [Issues](https://github.com/TastSong/CrazyCar/issues) - [License: MIT](https://github.com/TastSong/CrazyCar/blob/master/LICENSE) - [README](https://github.com/TastSong/CrazyCar/blob/master/README.md) - [Releases](https://github.com/TastSong/CrazyCar/releases) - [TastSong/CrazyCar on GitHub](https://github.com/TastSong/CrazyCar) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tastsong-crazycar