This sprint didn’t go particularly well. In fact I had so much trouble with the networking code that I had to extend it by an extra week just so I’d have something to talk about in this post, something I haven’t had to do in several months. It’s safe to say that networking in Unity is one of the toughest things I’ve had to wrestle with since I started this project, and it’s the closest I’ve come to just giving up. Partly that’s due to just how little documentation on the new UNET Networking system for Unity, as well as how complicated I made it all by starting to use it after writing a large amount of code.
For anyone reading this thinking about creating a multiplayer game in Unity I’d recommend you to a) wait several more months until there’s a lot more information out there, and b) Start working on the Networking code from day 1 so that the rest of your project is structured around it. I’ve had to disable a large chunk of code to get working what I’ve managed so far, and it’s going to be a painful process to get it all working again.
What I did
Despite all this, I still made some progress. I’ve worked my way through the entire official UNET manual, which was a lot barer than I expected. It gave me enough information to go on for now, but it’s really missing a lot of the more useful stuff that you tend to see in the official video sessions. Hopefully there will be more in the future. In the meantime though I’ve worked my way through all but the last few videos of this excellent Gamer to Game Developer guide on how to use UNET, building a simple multiplayer survival game from scratch. Despite not being the same style of multiplayer game as what I’m trying to make it was the far more useful resource. If you’re planning on making anything from a first-person view, this series is the place to start.
I managed to get my little prototype game working too, where 2 players take turns clicking buttons to change the colour of some boxes. It might sound trivial, but until I could get a basic turn-based program like that working then there’s no chance of getting the rest of the game working. This took far longer than expected because of one simple item which I didn’t notice in the any of the UNET documentation I’ve read. In UNET you can program a variable so that when it’s updated on the server the new value gets pushed out to the same item for each player. You can also create a hook method which executes a method when this value is updated. That’s pretty nice, but what I didn’t notice is that by adding in this hook it stops the value from being updated… A rookie mistake, but now that I know it’s one I’m not likely to encounter again.
I’ve placed down a spawn point for each team, so that when you start the game each player begins in the same position as their team. It’s not perfect yet as they both start facing the same direction, but it’s good enough for now. You don’t choose your team either, it decides based on whether you were the first or second player to join the game. That’s a feature I’ll be adding when I’ve created a custom network interface.
It took a lot of doing, but when you move a character in the game it’s position is updated on the other player’s machine. Currently this sends the last position and moves them instantly so you don’t get to see it moving across the battlefield. That’s something to work on in the near future, but as it’s mostly cosmetic I’ll be leaving that until after I’ve got the rest of the core networking code completed.
What I didn’t do
There’s quite a few tasks I didn’t get around to finishing this sprint. I haven’t finished the entire playlist of videos in the GTGD UNET tutorial, but I’ve only got a few left now. I’ve not begun making the turn-based gameplay work over networking. Until I could get some basic things like movement synced up there didn’t seem to be much point trying to get the more complex areas working. As I’ve accomplished this work already with my prototype it should now be reasonably straightforward to get this working here too.
I haven’t started making the combat multiplayer friendly yet either. Right now a player can still move somewhere and shoot at someone, but the firing animation and damage is only inflicted on the local machine. Damage should be updated on both machines, and you should also see the firing animation take place before this happens.
Finally I still need to take each player to the win or lose screen after the game ends. After everything else is done and dusted, this should be a fairly straightforward task to complete.
What I will do next time
First on the list is to make the game turn-based again. I’ve got the basic idea for this completed already in my little prototype, but transferring that to a larger game is a different task altogether. As part of this I’ll want to disable the UI elements when it’s not that player’s turn.
I’m going to finish off the last few videos in the GTGD playlist too. There’s only a couple left, but as he’s still making them there may be more by the end of this sprint. Should still be doable though.
Next I’ll want to finish up something I left out for the movement. When a player sends a character’s new position to the other player, the player’s position is updated, but they keep facing the same way. It’s a quick fix, but they need to be lined up for when shots are fired.
For the combat I’ll first get the health levels to update when someone takes damage, and die if they run out of health entirely. Then I’ll want to trigger a firing animation on the enemy machine so they can see the shot being taken.
Finally I want to make sure the correct screen is shown to each player after the game ends, whether it’s the win screen, or the lose screen.
This may look like a fairly short list for the next 2 weeks, but after all the trouble I’ve had with networking so far, I’m not going to overwhelm myself again. If I somehow get everything on this list done, there’s plenty more networking tasks and bugs that I could work on before I begin the next sprint.
As always, you can see my current Trello board he