Prototype and Networking
IntroductionIn the current course we are to make a ‘vertical slice’ of a game. We are 7 people in my group; 4 are graphical artists, and 3 are programmers. 1 of the artists are is the lead designer, and 1 of the programmers is the producer. The producer has so far not made any of the code, so I and the other programmer have made the code we have produced so far. The GameThe game is called “A Rat Betwixt”. It is a turn based multiplayer game, where players either cooperate or betray each other based on their objectives and current situation. The game is controlled with input from a smartphone, while the game itself is displayed on a TV (or something similar). Each player can choose a different character, with each character having different skills. Most of the attacks use area of effect (AOE), meaning they damage or effect the surrounding of the target, we have this as a means for the betrayer being able to attack the other players without being recognized as the betrayer. Besides fighting enemies there are also ‘events’, situations for the players to handle. PrototypeWe made a prototype of the game for the first two weeks. We made the prototype using my code from the previous course where I had made a behavior tree, path finding, it was turn-based, and made in Unity, which are features that fits well with the game we’re making now. Before we began making the prototype I made a smaller prototype in a few hours displaying the use of networking. Our prototype was turn based, where every player and AI controlled character has a predefined initiative that decides their turn order. AI and A* path finding were brought in from code I had made in the previous course, with in large part, especially the path finding, was used in the prototype with very little changes. The prototype had multiple attacks and moves. It had networking between server and client working, with the server on a computer and the client on a mobile phone. The client had a minimap where the player can see what is solid and what is other players and enemies. The player clicks on the map to choose where to go. On the client screen were also the selection of attacks/moves. The prototype also had a tilemap editor, which is used in editor mode of Unity, and is used to create a tilemap of what is solid/collidable in the game. We are reusing most of the tilemap editor code for the post-prototype version. I made the initial version, and the other programmer has converted the code for the post-prototype. Post Prototype ProgrammingThis is about the week we began with programming the post-prototype version. We planned how we would restructure the code and began making it. We have by the end of the week, implemented most systems which were present in the prototype, although somewhat different in how they’re structured. NetworkingI’ve been in charge of making the networking work as I had experience with networking in Unity, and it has been fine with me to do so. We shared in making most other things. Networking – PrototypeWe had in the prototype a class called ‘Master’ that had an instance created for each client on every client. The server is a hosting server, it in other words is also a client, so it also has a master for itself. A ‘Master’ creates an instance of either ‘ClientMain’ or ‘ServerMain’, of their respective ‘Master’ on their game instance. The ‘Master’ class also dealt with communication between the server and clients. Networking – ReasoningI chose to do it this way partly because I was unsure about what networking features we would benefit from using, and partly because I didn’t want to complicate the code more than needed for the prototype. Unity provides certain ways of doing networking that requires a ‘NetworkBehaviour’ and ‘NetworkIdentity’ to be used. They need to be on a GameObject instanced on each client and server for each game instance. The script inheriting from ‘NetworkBehaviour’ is ‘Master’ in this case. I believe Unity does it this way as each of those are supposed to be a player, and they’re created as an instance on each machine because each player are meant to be seen on each machine, and can that way more easily sync their properties. This didn’t work well for us because #1 the players are only meant to be seen on the clients on the minimap UI, while they appear as 3d models on the server. #2 The other programmer felt he preferably wanted our code to be seperated from the code dealing directly with Unity. #3 I though of a though reason but forgot it. I chose to do it using this way though because I wanted to see if there was anything we could benefit from using it, as I stated earlier. Networking – Post PrototypeFor the post-prototype, I decided that it was going to control how connecting and disconnecting clients are dealt with by inheriting from Unity’s ‘NetworkManager’ class. This time the server is not a hosting server, as far as Unity regards it. ‘NetworkBehaviour’ and ‘NetworkIdentity’ is now not used at all. When the server starts the scene is changed to the ‘Server’ scene, and when the client starts the scene is changed to the ‘client’ scene. When a server connects, the server creates an id representing that client and puts it plus connection details to a list which is kept on the server. ‘ServerMain’ and ‘ClientMain’ are now called ‘Server’ and ‘Client’ and are attatched to an empty GameObject on the ‘Server’ and ‘Client’ scenes. I was going to make a ‘MessageManager’ class, but instead decided to inherit from Unity’s ‘MessageBase’, calling the class ‘MsgBase’. The MsgBase class contains public ‘SendToServer’, ‘SendToClient’, ‘SendToAllClients’, ‘Recieve’, and ‘Register’ functions. Register must be called statically with the respective ‘MsgBase’ derivative class type as argument to be able to recieve messages of that respective type. Recieve is called when a message is recieved of the respective type.  |