Caution
ARCHIVE REPO FOR PRESERVATION PURPOSES
NOT IN DEVELOPMENT AND VERY OUTDATED
DuneNet (stylized as /djuːn/net) is a complete network solution for building server authoritative games on top of the Unity Engine.
With powerful networking, entity, event and module frameworks, DuneNet allows you to focus on making awesome multiplayer games without having to worry about dealing with the annoyances of UNET.
There are two ways to install DuneNet into your project, using Unity's Asset Store or by manually placing the files into your project's Assets folder.
Installing DuneNet from Unity's Asset Store is the simplest and quickest way to install DuneNet.
Simply head to DuneNet's store page and click on Open in Unity. Unity will then instruct you to select which files you want to import into your project.
It is very important that you import all .dll files for DuneNet to work. These files should always be placed inside the Plugins/ folder of your project for DuneNet.Client, DuneNet.Server and DuneNet.Shared and Plugins/Editor/ for DuneNet.Editor.Client, DuneNet.Editor.Server and DuneNet.Editor.Shared (where exactly the Plugins folder is doesn't matter as long as it is inside the Assets folder of your project).
When you ship your product, if you decided to use two separate Unity projects to separate client and server, you might choose to only ship DuneNet.Server and DuneNet.Shared for the server and DuneNet.Client and DuneNet.Shared for the client. The Editor assemblies should never be shipped with your build (the Unity Editor shouldn't copy them when compiling).
While the Asset Store installation method should be good enough for most use cases, we realise some developers might want to automate their build pipeline and installing packages from the Asset Store might not work very well in that case.
In order to manually install DuneNet into your project, first follow the Asset Store installation installation steps but do not import the package once it has been downloaded.
Once Unity has locally stored the package, you might find the .unitypackage at %APPDATA%\Unity\Asset Store-5.x. You can easily install the package into your project by launching unity with the -importPackage path/to/package.unitypackage command line parameter. This parameter can also be used together with the -batch and -nographics parameters to install the package silently without opening the Unity Editor (very useful for build servers like Jenkins and Bamboo).
Please, do note that it is not advisable to simply copy the assemblies from the Plugins folder as the .unitypackage performs some initialization steps when it is being imported (for example, setting the script execution order for the controllers) that will not be performed if the files are simply copied.
While building server authoritative games using UNET's HLAPI is certainly within the realm of possibility, attempting to do so often comes with headaches and obscure restrictions imposed by Unity that takes the focus away from building awesome gameplay and assets to instead dedicate countless hours to fight against a system that was simply not designed to work with the principle of a server authoritative game.
DuneNet is designed around the idea of having an authoritative server (host) that has control over an arbitrary amount of clients (viewers).
This means that, if you are used to making multiplayer games the Unity way, you might have to rethink a few concepts.
These are the key differences between DuneNet and UNET's High Level API:
| DuneNet | UNET HLAPI | |
|---|---|---|
| Different scenes for client and server | ✔️ | ❌ |
| Synchronized distinct objects for client and server | ✔️ | ❌ |
| Runtime registration of spawnable objects | ✔️ | ❌ |
| Synchronized global events | ✔️ | ❌ |
| Out of the box arbitrary authentication | ✔️ | ❌ |
| Requires the exact same assets on the client and server | ❌ | ✔️ |
| Core functionality extension | Express-like modules | NetworkManager inheritance, overrides and constant casting |
The first step before starting to use DuneNet is setting up the project's structure.
Please, do note that these are our suggestions for a clear and easy to remember project structure when using DuneNet, there is no imposed restriction on the structure other than the ones imposed by Unity's Resources.Load\<T\>().
This is our suggested project structure:
We recommend creating the following folders at the top of your Assets/Scripts/ folder, like so:
Clientside scripts:
/Assets/Scripts/Client/
/Assets/Scripts/Client/Entities/
/Assets/Scripts/Client/StaticEvents/
/Assets/Scripts/Client/Modules/
. . .
Serverside scripts:
/Assets/Scripts/Server/
/Assets/Scripts/Server/Entities/
/Assets/Scripts/Client/StaticEvents/
/Assets/Scripts/Client/Modules/
. . .
Shared code used by both:
/Assets/Scripts/Shared/
/Assets/Scripts/Shared/StaticEvents
/Assets/Scripts/Shared/Modules
. . .
Entity prefabs (usually called simply entity models/assets in other engines) should be placed inside a Resources folder.
This is a limitation imposed by Unity's Resources.Load<T>() method and, unfortunately, there is no efficient way around this.
We recommend creating the following folders at the top of your Assets/Resources/ folder, like so:
Clientside entities:
/Assets/Resources/Client/Entities/
Serverside entities:
/Assets/Resources/Server/Entities/
You might follow whatever directory structure you fancy for assets such as models, textures and materials but we recommend following a similar pattern for those since that makes much easier to choose what gets added to the build and what not.
Remember that the server does not need most assets so with an appropriate directory structure, it should be straight forward to exclude unneeded assets from the server build.
DuneNet is divided into three different components, each of which controls a different aspect of DuneNet.
In order to avoid confusion and permit network context based code separation, each component has two controllers, a serverside controller and a clientside controller.
This is a quick rundown of DuneNet's components and their controllers:
The entity management component provides a reliable and extensive entity framework through its Client.Controllers.EntityController and Server.Controllers.EntityController controllers.
These controllers allow for entity spawning, positioning, parenting and many other regular game object operations, as well as providing authority-based methods to synchronize information between the server and the clients, in the way of Networked Variables and User Messages.
Entities are composed of two classes that derive from Client.Entities.Entity and Server.Entities.Entity, representing the clientside and serverside parts of the entity respectively. Those classes are registered into the entity system using the Shared.Entities.EntityRegAttribute attribute.
The event management component provides a quick and easy way of registering, invoking and synchronizing global events in multiplayer games through its Client.Controllers.EventController and Server.Controllers.EventController controllers. Events are composed of an identifying name and a set of arbitrary variables stored inside a Shared.Events.EventArguments object. Events can easily be registered by attaching the Shared.Events.EventRegAttribute attribute to any public, protected, internal or static method that is part of a class that derives from Client.DuneBehaviour, Client.DuneMonoBehaviour, Client.Entities.Entity, Server.DuneBehaviour, Server.DuneMonoBehaviour or Server.Entities.Entity.
The network management component provides a fast and extensible way of connecting servers and clients. The Client.Controllers.NetworkController and Server.Controllers.NetworkController controllers provide the basic functionality for the network management controller.
The functionality of the network management component can easily be extended by using modules in the form of classes that derive from Client.DuneModule or Server.DuneModule and implement any of their overridable methods.
Modules are chained together in the order they are registered, which allows for sequential processing of the extended functionality. For example, you might choose to implement more than one authentication method and have the module chain fail the authentication if any of the modules generates a negative result.
In order to get you started and familiarized with DuneNet, you will find explained examples for the most common use cases down below:
- Connecting a client to a server for the first time
- Displaying new connections
- Adding a simple module to implement password authentication
- Creating your first Entity
- Simple synchronized FSM with Events
DuneNet is governed by the Unity Store End User License Agreement.
You can find a copy of this license here.
You might contact us at any time using the following contact information. Our average response time is 24 hours.