Guidelines: General

Here are a few pieces of advice to get started the right way with Asmodee.net. They were gathered from our experience working with 3rd party developers on several projects.

Read the Guides

Really. From beginning to end. There are a number of key concepts introduced throughout the various areas of the documentation. If you are in the “TL;DR” mood and prefer to jump quickly on coding using the Sample, you are heading for serious headaches, especially if you want to implement online gaming.

Some concepts such as the Game State, OAuth2 authentication, Asynchronous vs Synchronous Gaming, Event Sourcing, Bot Hot Swap, Security, etc. are so fundamental that you will find yourself in deep trouble if you took the wrong turn early on with the design of your data model or your rules engine architecture. Early mistakes are paid dearly around the end of a project.

Make sure you understand the organisation of the online documentation to find your way around. In addition to this “overall” website, there are a number of sub-sites, each focusing on a specific area of the platform: the REST API, the Scalable Server, and the Unity SDK. Make sure you browse through all of them to understand where to find the information you need. There are important concepts in each of them.

Understand the Code Sample

Very often, as developers learning a new system, we prefer to grab the code sample and use it as a skeleton for starting to code our app. We like this “instant gratification” feeling of having something cool running quickly.

You will get this feeling when using the Code Sample of the Asmodee.net Unity SDK. But don’t stop there, you really need to understand the code. A number of classes are provided to help you code your game, but they are related to the concepts mentioned above. If you don’t fully understand why they are there and what you are supposed to do and why, you won’t succeed in implementing a solid online gaming experience for your users.

Be Wary of Shortcuts

Some concepts can seem like over-engineering and it can be tempting to take shortcuts. Like not using a Player Clock and relying on a simple time-out for each turn instead. Or using only the Multicast protocol to communicate between clients and not using the Commit protocol. Be careful. These were made for very good reasons and you will regret it if you bypass them. In doubt, contact us and we will be happy to explain why some concepts are here or help you come up with a correct technical design.