Stupid Fun Systems

Software Architecture The web socket service provided for you to test your plugin code is written in ASP.NET core 2.0 and can be contained within Docker.   It is comprised of two main classes: the manager class and the middleware class. StupidFunSocketManager This class currently holds a collection of web socket connections so the service can broadcast if necessary.   Note this will only work for demonstration purposes; for production purposes you should leverage a centralized store or leverage an existing cloud based push notification system. StupidFunSocketMiddleware This class contains the code for reading messages sent from the plugin and assigning them to an appropriate adapter for processing.   The adapters would contain the business logic and are designed to work asynchronously, not in the typical request response RESTful fashion that the majority of the internet behaves like.     Activity Flow

Use Case Preconditions The Unity game is built on UWP and .NET standard 2.0. The Unity game already has been authorized to use the web socket service. Postconditions The Unity game can receive messages from the web socket service without sending a request first.     Activity flow Basic flow 1: sending thread. Step Description Software location 1 Unity starts the demo scene. StupidFun.Games.Unity.CommunicationManager.OnEnable(). 2 Unity establishes a connection to the server and starts the sending and listening threads.   For the listening thread, see basic flow 2. StupidFun.WebSocketManager.Start(). 3 The sender thread initializes and begins monitoring the send message queue _sendQueue. StupidFun.WebSocketManager.StartSender(). 4 While the web socket connection is still open: St