Actor based approach to a Retro Game in Scala
The project was written in Scala.
To get a local copy up and running follow these simple steps.
The latest versions of the following:
- Scala
- SBT
- Navigate to the Asteroids folder
- Clean and build the project by opening sbt shell
compile- Run the
Mainmethod of Asteroids using:
runThe JAR file will appear in the /target directory.
The Game is Written in a Server-Client based approach using the Actor system.
The Server & Client communicate via a mixture of UDP and TCP, using Strings & Export Objects
-
ExportObject
The ExportObject is one of our main concepts. It wraps an GameObject into a String describing its most important information and then adds a class description to the Object. This allows for easy communication and also allows for pattern matching on receipt.
-
UDP
-
Server => Client
The Server sends a list of ExportObjects, compressed using GZIP and Base64 encoding to the client. The Server does not account for lost packets, but by continuously spamming those packets, one or two lost packets will not have any significant impact on the player's experience.
-
Client => Server
The Server has one receiver to which each client sends its input. The Client sends an input with the following schema:
UUID-'INPUT' where INPUT is 1/0, W-A-D-SpaceThe Server Receiver will then redistribute the packets further. The Clients will spam these inputs every 10 milliseconds.
-
-
TCP
The Connection is set up via TCP, with the following schema:
CLIENT | SERVER client.register.NAME UUID addr'IP'.port'PORT' RECEIVER PORTfrom there on the client can do the following:
- client.start - Inform that the client is ready to start
- client.leave - Inform that the client is leaving
- client.exit - Inform that the host is leaving
- client.ping - Expect a server pong
The advantages of this connection allow for easy setup over the cumbersome UDP setup.
In case a client leaves, it is disconnected from the server and unless it already died also removed from the death messages.
In case a client looses connection it will disconnect itself from the server and the server removes it.
- Important: The Client will first check via TCP whether the server is really not responsive or whether it is just a latency issue.
The Game is fully evaluated server-side via the combination of PhysicsComponentHandler and the PlayerSupervisor , the combination of these run the game. Collisions are also handled by the game engine. If a player dies, they are removed from the game state and instead a death message is added. Every object apart from the player is self-movable by a constant and the player is self-movable by its input.
IMPORTANT: As we here have a mutable state across multiple actors, we ensured thread safety by synchronizing changing methods over the object.
Asteroids are generated by the AsteroidNoiseGenerator, by randomly trying to place an asteroid not closer than 15 points away, 50 times before giving up
For the Graphics we have multiple modular Frames, that each have an Actor that controls them, these are:
- ClientFrame: The main Menu Frame
- GameFrame: The frame used on playing & spectating
- LeaderboardFrame: A Frame constructed from the Database showing the current leaderboard
Additionally: In Order to optimize for speed we used the AdvancedRotationEngine, that caches often used rotations while also cleaning up not often used data
Side note: The reworking of the graphics with the AREngine, decreased CPU load by 30% (i7-1065G7) and RAM usage by 150MB
The Game uses the Actor system with the idea of supervising and spawning, as well as escalating. The Actor system is build on akka, and allowed us to write the game fully asynchronous. In general the stucture is:
- Master (Server/Client)
|- Global Agents
|- Supervisor
|- SubSupervisor
|- GameManagers
In case of cleanups, after an actor is stopped all children will commit suicide. Every Networking Actor has a PostStop in order to ensure, that ports and/or Streams are closed
- Actor System Pattern
- Command Pattern
- Singleton
- Flyweight
- State
- Chain of Responsibility
Because of Akka's supervisor system, the system is able to recover from most problems by restarting parts of itself as needed. This leads to high stability and reliability; Whenever an actor encounters a problem, its supervisor is informed, which then either handles the problem or escalates it to its own supervisor.
The additional TCP connection detects ungraceful client disconnections and the like. Additionally the ping, verifies that a connection can be closed if it dies
One of the biggest advantage of our implementation is that it is easily expandable and can be quite easily modified. By using Scala itself we already speed our code up by an average of 20%, additionally things like the ARE or the common state pattern allow for a nearly bug free and highly efficient execution of the code. Additionally it's fully asynchronous, and if no deadlocks occur then there is nearly no way for a full system crash.
- Better Colliders, right now boundary boxes are used, polygons are created for the CircleColliders, but they are still lacking implementation
- Additional TCP features to ensure even better connection stability, and in the case of a packet clash the possibility to stop the sending
- More player spaceship
- Better menu
During testing we found a potential deadlock on the logging system, when refactoring this issue vanished
Rewrite the GameObjects also as Actors
Use Indigo over Swing
Alex implemented the main structure of the actor system, as well as the basic swing components for the front end. Phil provided the database backend, as well as additional functionality within the actor system. Alex provided much needed optimisation to the code. Both members were involved with research into possible implementations and solutions before each design decision.
- Actor System
- Advanced Rotation Engine
- Pictures instead of circles
- Scala ;)