🐈⬛Introduction
Made by network game developers with experience.
Last updated
Made by network game developers with experience.
Last updated
PurrNet is still in the early stages! So keep in mind that things could be prone to change, have bugs, or be sub-optimal. We are using it ourselves as well, so we feel confident that it is a ready-to-use system, but it is under constant development and improvement.
Check out the ROADMAP to see what we are currently planning to add. This can also be a good overview of "what is missing" from the system at this point.
Get it on the Unity Asset Store Get it on GitHub
PurrNet is our attempt at the purrfect networking solution... It's a 100% free Unity Networking solution with no pro or premium version, and no features locked behind a pay-gate. You can use it to release, and we ask nothing in return! Read the Unique to PurrNet section to see what we offer above other solutions!
Our mission has been to embrace the natural workflow of Unity rather than fight it, as we've felt other networking solutions do.
Make sure to join our Discord here: https://discord.gg/NP9tP9Qx9R
Similar to other great networking systems like Mirror and Fish-Net, we also use the same modular transport system, allowing for easy integration to any servers, relays or similar.
Our high-level API, allows for super easy and quick network development, with plenty of freedom for you as the developer. Use our Network Rule system, to define how you prefer your workflow and game to function, from fully safe/server auth, to full client auth allowing for the quickest multiplayer development!
Throughout PurrNet and this knowledge base, you'll find the use of a few words quite often. Most commonly: Server Auth and "Everyone".
Server Auth means that only the server can perform the desired action. So if you set the network rules to use "Server", only the server can do the action. If you pick "Everyone" it means that all clients and the server are all allowed to perform the action.
This does technically create an "unsafe" environment, allowing for easy cheating, so this is only recommended for games where cheating is not a major concern. Some good examples are co-op or friendly PvP games.
The biggest focus of PurrNet is ease of use and scalability for the project. This is greatly involving the "Network Rules" Here are some examples:
With most networking solutions you'd typically need to instantiate an object, follow that with a unique spawn call, and ensure that the instantiation and spawn call occur on the server. However, with PurrNet, you just have to follow your Unity experience and simply Instantiate the object... And that's really it!
With the network rules, you can allow "everyone" to handle spawning, essentially allowing all clients to spawn objects by simply instantiating them. If you only want server auth, you merely instantiate on the server, and the rest is still handled... Easy!
And for despawning? It's the exact same thing! Simply call "Destroy()" as you would in Unity, and the rest is automatically networked for you.
With the Network Rules, you can also set up whether the SyncVar or Rpc's allow for everyone to call them. This in turn means that you don't have to ensure that the logic runs over the server, like in other networking solutions. This allows for quicker code writing and an easier workflow to learn.
We even have Generic, Static and Awaitable RPC's which have not been seen before! (as far as we know)
When you spawn and despawn things, you can easily modify on a per-object basis who the default owner of the object is. If the spawning and despawning rules allow everyone to spawn, it is easy to also make the spawning player the owner by simply changing this setting! No extra code is necessary.
Through the network rules, you can also easily allow clients to change the ownership of an object, allowing for easier use than any other current networking solution!
Another great feature of PurrNet is the built-in cookies. This essentially allows for a server's knowledge of a player to remain beyond the connection. If a player disconnects and later connects again, the server is still aware that this is the same player, and can keep the data stored. This is modifiable as to where the data is stored and how persistent it is (Connection, Process, Machine).