We want everyone to be able to get their game multi-player capable. So, our tiered offerings start with a feature-rich FREE version. From there, GONet features become even more impressive along with the level of support available.
Tiered GONet offerings
| Feature | FREE | PRO | Premium |
| Auto-magical data sync: | |||
| Transform – position, rotation, scale |  | | |
| Animator Controller parameters | | | |
| Any MonoBehaviour fields ([SyncVar] replacement) | | | |
| Input state (keys, mouse, buttons) | | | |
| Omni-directional from owner to non-owners (server and clients alike) | | | |
| GameObject.Instantiate() is auto-magically networked from the owner/instantiator to all interested parties/machines (optionally use a prefab alternate for non-owners) | | | |
| You control sync settings applied to groups of data items: default and/or user-defined (via profiles/templates, for when you want/need more control) | | | |
| Auto-magically blend smoothly between received values for non-owners: default interpolation/extrapolation and/or user-defined implementation (great for dealing with unreliable “streams”) | | | |
| Event Bus: | |||
| Publish and subscribe to your own omni-directional (arbitrary content between server <-> clients) communication ([Command], [ClientRpc] and [TargetRpc] replacement) | | | |
| Auto-magically sync’d changes also (automatically) publish events to which you can subscribe (e.g., energy dropped below 10 => change avatar material) | | | |
| Transient events – delivered to clients connected to game session when event occurs | | | |
| Persistent events – like Transient event with additional delivery to any clients connecting to the game session after event occurs and will exist in recorded/replay data | | | |
| Any user-defined event class – can be either transient or persistent | | | |
| Promotes industry proven event-driven game architecture and facilitates GONet Record+Replay | | | |
| Serialization Options: | |||
| Default Auto-magical data sync: custom bit packing (with LZ4 compression) | | | |
| Default Event Bus traffic: MessagePack (with LZ4 compression) | | | |
| User-defined custom overrides: if you have special cases or feel you can do it better, by all means, a mechanism to do so is provided | | | |
| Configurable value quantization: choose # bits to occupy and auto-magically quantizes/compresses to fit (great for LOD, see below) | | | |
| Record+Replay GONet Sessions: | |||
| Everything GONet sends and receives is recorded (server and clients alike) | | | |
| Replay the recorded gameplay. Great for: (eSports) In-game instant replay, Location Based Entertainment takeaway not to mention development troubleshooting and bug reproduction (i.e., a “save your bacon” feature) | | | |
| Recorded session data feeds into time series, statistics-based graphs for analysis during development and perhaps more importantly after game is released | | | |
| Level of Detail (LOD) Management: | |||
| Control the Who/What/When/Where/Why/How of data detail | | | |
| Default implementation uses distance to client’s main player controlled GameObject (closer = high data resolution, further = lower data resolution…down to excluded entirely) | | | |
| User-defined custom overrides: decide what causes changes to a GameObject’s data LOD, when it should be applied, how much it affects LOD, etc… | | | |
| Facilitates large worlds and/or large numbers of networked GameObjects and sync’d values (e.g., MMO) | | | |
| Wide Platform/Runtime Support: | |||
| All managed C#, no native libraries | | | |
| Ahead of Time (AOT) compilation support (e.g., iOS) | | | |
| IL2CPP | | | |
| Network Transport: | |||
| High level (just add GONetParticipant to GameObjects for transform/animation and [GONetAutoMagicalSync] to MonoBehaviour fields/properties and you are in business) | | | |
| Mid level (create/publish/subscribe custom events and also fine tune available network settings to meet particular needs) | | | |
| Low level (send/receive/manage data however you need to, but you probably will never need this) | | | |
| UDP (unreliable+unordered) and RUDP (reliable+ordered UDP) | | | |
| Encryption (customized version of Bouncy Castle Crypto API) | | | |
| Configurable channels (optional) | | | |
| Network Topologies: | |||
| Dedicated game server (client-server DGS) | | | |
| Local (LAN): good for location-based entertainment (LBE) | | | |
| Peer-to-Peer (P2P): NAT punchthrough etc… | | | |
| Support: | |||
| Basic tutorials, examples and forum/email back and forth as time/resources permit | | | |
| Fixes to unique and/or uncommon bugs/issues | | | |
| Screen sharing collaboration sessions and more in-depth responses at front of email support line | | | |
| Access to extensive example projects with detailed documentation | | | |
| GONet support team working directly with your team with off-site and on-site options | | ||
| GONet custom feature requests | | ||
| General: | |||
| RigidBody support | | | |
| Run-time authority transition (e.g., client to server for projectiles) | | | |
| Source code (well commented and debuggable C#) | | | |
| Logging: | |||
| Built atop the robust, well-known log4net api/library | | | |
| Writes to Console in editor and to “logs/gonet.log” file in builds | | | |
| Outputs logging level, thread #, system time, frame time and your message with every log statement (if you have ever performed troubleshooting on a networked game, you know this is one of those “save your bacon” features) | | | |
| Used in GONet code and fully available to use wherever you like | | | |