Thursday, October 30, 2014

Screams From The West Iteration 5

As said in the previous post the big challenge for this week was adding networking. I started out by researching and re-factoring the code. I wanted the code to be in the best state it could before starting to add networking aspects to make the process easier. Once I had cleaned up the code it was time to think about how I was going to network the game.

I continued researching on what would be the best way to network my game. In the past I have done peer to peer in both Pew and my Game Networking class. I could have done that here but synchronizing the state of possibly a large amount of spiders could be dangerous using this method. If I were to have the host do this, the easiest way, then it would be way too much upload bandwidth for one person to handle. I later figured that I may have been able to split this work on multiple machines but this could be tricky. I decided that I would try to go with an authoritative server based setup. This way all of the spiders action would be handled on the server and sent to the players. The way an authoritative server works is the players send only their inputs to the server and the server sends the game-state to the players. This is also good because it prevents the possibility of cheating. In peer to peer you are often sending information such as position and damage and health, that all can be hacked into and changed, causing cheating to be realistically easy. With the server, however, sense the only thing being sent is inputs that means they can only change what our inputs allow them to change. This makes cheating much less severe and problematic. Another reason I wanted to do a server based system was that I never explored that way of networking before and wanted to do something new.

So great I figured out I wanted to do server and had all the right reasons to do it. Of coarse now I had to actually implement it. I started out by getting the basic connection working looking what I had done in production 2. I got this working after spending some time trouble shooting. Once I got that working I started implementing a menu system that is essential for a networked game. I decided sense there were going to be many things shared over these screens that I would create a base screen class for all the other menu screens to inherit from. This base class had information such as the back ground texture, various font/style information and positions for constant aspects such as the back button. This allowed me to create a menu manger that switched through these screens easily.

The next thing to do was to get the players in the game spawned and moving. I created a spawner class that had the server use Network.Instantiate on all of the players. That way the server owned all the players and was the one to synchronize their state. I created a class inside the player that held a string id that was unique to each player. This way it was easy to tell still which player was local on the client machines. I created a player input manager that held a dictionary of all player inputs on the server. The clients would send their input on change to the server and the server would save the most recent inputs. This way when I wanted to use inputs in other classes I would reference the most recent inputs from the input manager for that player. On Saturday I worked on this and the player movement so I could see the inputs doing something. I spent a while debugging it but I could not figure out why the inputs were not being correctly sent over. After a spending maybe an hour of debugging without results I decided to stop for the day and continue tomorrow. At this point I was not sure if I had been pragmatic about what I could do; was it really possible for me to network this in just one week?

The next morning I woke up early and decided that regardless of weather or not I can get it all working I wanted to keep trying. I figured out the bug that was haunting me the day earlier in like 30 minutes. From here I gained a huge amount of excitement. I was starting to believe that I could do this, which motivated me to work hard and stay focused for most of the day. After I got the player movements working I worked on networking the spiders. To do this I had the server sent over the position and rotation values of the spiders. On the client I used lerping to make it the values look smooth. I also just had to make sure all of the AI still worked as expected. The next challenging part was getting the projectiles to work.

I ended up doing a bunch of prediction to make the bullets work right. The first form of prediction I did was when I first got the input there was an amount of time it took to get that input. I predict where the bullet would be if it fired when he did the click. I then use a raycast to see if it would have already hit a spider. If it would then I don't fire it and just destroy the first spider hit. Otherwise I fire the bullet and send information to the clients about its initial position and velocity. Then on the client side I predict where the bullet should be given the amount of time given that information and set the velocity to the given velocity. From here I let the clients do the rest of the physics calculations because the velocity is constant. There is very little possibility for the projectiles to become not synchronized here but it is possible. As with almost all networking perfection is not a the goal, its getting as close as you can.

From here it was just making sure to handle all the little networking aspects I needed to handled. There is a long list of those things so I won't bore you with the details. All in all I got the basic functionality down and I was happy. We presented yesterday and everything worked as expected. Kyle also brought the game to testing last night and from what I heard about it there were no bugs that I wasn't aware of. This was a pretty big accomplishment for me to do in a week. I worked hard and it definitely payed off.