Create reactive, near real-time, Single Page Applications (SPAs) that easily handle concurrency using the Actor Model and are not reliant on the database for the storage/retrieval of state. Multi-player online games are a great example, so that's what we'll build in this course.
The traditional stateless design for web apps can become increasingly troublesome with new classes of web apps and increasing end-user expectations. This traditional approach, where the web application is essentially a stateless front-end and all state is written/read to a database, falls short when we have ever-increasing workloads and requirements for highly responsive, near real-time systems. Add in the requirements for concurrency management, scalability and fault-tolerance, and the traditional approach becomes even less attractive. By combining the features of the Actor Model (Akka.NET) with the capabilities of SignalR and a front-end SPA library, we can more easily create next-generation reactive, stateful, and concurrent SPA web apps. In this course, we'll be using the example of multi-player online games, as these are a great example of reactive concurrency in action.
Building the Player and Game Controller Actors Hi, welcome back. In the previous module we got an overview of the application that we're going to be building, and we got started in Visual Studio by creating our web application project and our class library project to hold our actors. In this module we're going to flesh out the class library project by adding some message classes and some actor classes. In this module we're going to start off by looking at the overall design of the different actors that we're going to be having in our actor system, so we'll look at the actors themselves and the kind of state that they hold, and also the messages that flow between these actors. We'll then jump into Visual Studio and start off by creating all of the message classes that we're going to need in our actors, and then we'll go ahead and create a player actor class, and we're going to have one instance of this actor class for every player that joins the game. Next, we'll create an actor that's going to help coordinate the action in the game, so this actor is going to be responsible for creating child player actors when players join the game, amongst other things. Finally, once we've created our actors, we're going to go and see how we can instantiate an Akka. NET actor system in ASP. NET. So we don't want to create a new actor system on each request that comes in. Instead, we want to maintain the single actor system that's going to be used for all requests, so we'll see how we can do this in ASP. NET.
Hosting Game State in a Windows Service Hi, welcome back to this final module. In this module we're going to see how we can overcome the problem of losing our game state when the ASP. NET application restarts. In this module, we're going to start off with a high-level overview of the concept of lightweight actor systems, and this is where we offload the main work of the application to some actors stored in a different process. In our example, we're going to see how we can store the game state in this process external to ASP. NET. To do this, we're going to start off with a simple console application, and this application is going to have an actor system, and inside this actor system is where we're going to store our player actors. Once we have this actor system running in this external process outside of ASP. NET, we'll go and modify our GameActorSystem class in our web application to point to this remote actor system in our console application rather than storing the player game state inside ASP. NET itself. We'll then fire up a browser, and we'll add a couple of players, and then restart our ASP. NET application, and we'll see that our game state is no longer destroyed, and that's because our game state will be held in this external console application process. While we can run our remote actor system inside a console application, it's usually better to go and create a Windows service. There's a number of benefits to this, including the fact that we don't have to be logged onto the server to host our game state, and we can use the Windows service infrastructure to manage the service.