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.
Thursday, October 30, 2014
Wednesday, October 22, 2014
Screams From The West Iteration 4
This weeks main goal was to get the game and the rest of the team ready to present for stage 2. We had previously discussed having a melee mechanic and jumping spiders but had never fleshed them out. This week we decided that it was important to our game so we decided to add them.
The first mechanic I worked on was the melee mechanic. As you can see in the video above, I create a cylinder in front of the player and swing it. When it collides with the spider, it pushes the spider away from the player. This seamed to work pretty well for what we wanted.
The next thing I worked on was the jumping spiders. I have it so when a spider gets in range of the player he jumps at him. After that he just chases the player as before until he gets far enough away to jump. This made it harder to get around spiders in buildings making the game more challenging and fun.
I also made a full game play video to show off the current state of the game. In this video I already knew where the egg sacs were so I ran through it quickly. This was just so I could show all of the game play in a reasonable amount of time. We used this along with a video of each mechanic during our presentation.
Our presentation went really well. They said that we passed as long as all the documentation is in order. Because of this we decided to proceed with this next week as if we passed. One thing brought up during the presentation though was the fact that we wanted to do multiplayer. Professor Ferguson questioned the need for multiplayer at all so during our meeting we discussed it. Ryan played the devils advocate but we decided that the journey we went through with our previous games was really about the cooperation aspects. Because of this we felt that we would not be doing our team justice to ignore this aspect. So we decided we wanted to do it but with time running out the team asked if I could get it basically working this week. At first I was caught pretty off guard, even though I knew it was coming to a close, I wasn't fully aware how much time we had left. I told the group that I wasn't sure if I could do it. The response was for me to try my best this week and if I was unsuccessful then we would just do single player. I am already starting to reformat my code and research what networking practices would be best for our game so I will let you know in next weeks blog how I do.
Wednesday, October 15, 2014
Screams From The West Iteration 3
This week I added secondary mechanics such as torches and flares, and looked into more AI elements. We now have a flare that allows the player shoot something and see further then he ever could before. We also have a torch that the player can place to have a place permanently lit.
I improved the wandering AI. There was a bug in the AI that was causing the spiders to mass in the center causing distress for the players. I looked into this and now it seams that the spiders wander all over the map equally making the mass of spiders much less likely.
I looked into how I could do walking on walls/ceilings with the current AI system I was using. It turned out not to be possible with unity's navmesh system. There is a strict limit on the slope for navigation meshes so it is impossible to go strait up walls. I talked to Lawson about this during my discipline review. He suggested just to involve simple iterations with walls if we want to do stuff with walls, such as going strait up to a window rather then path-finding around the wall. Based on the feedback of my group though, this is not a huge thing and can be looked more into later in development.
I also started working on a jumping attack. I am currently doing all of my spider movement using unity navmeshagent. This does not allow me to tell the spider to jump. Because of this I will attach a rigidbody temporarily to do my jump physics and remove it to go back to AI after the jump is complete. When I was working on this yesterday I was unsure of how the jump sequence should happen so I talked about it in our team meeting. We decided that we would have the spider jump towards the player a a certain distance, and when it hit something it would stop moving in the horizontal direction and just fall strait down. If the something it hit was the player it would do damage. We also discussed having an animation for the initial jumping off the ground, in the air, hitting the player, and landing.
We were originally planning on presenting for stage 2. At the end of the week we all agreed, however, that it would be better to give ourselves some more time. For stage to we are supposed to demonstrate our core experience and I did not feel we were there yet.
We had talked about definitely wanting some sort of melee system but we have yet to jump into what that exactly entails. We talked about having it not do damage but just knock enemies back. Regardless of what we decide to do with it, I think it is a core part of our player experience.
I improved the wandering AI. There was a bug in the AI that was causing the spiders to mass in the center causing distress for the players. I looked into this and now it seams that the spiders wander all over the map equally making the mass of spiders much less likely.
I looked into how I could do walking on walls/ceilings with the current AI system I was using. It turned out not to be possible with unity's navmesh system. There is a strict limit on the slope for navigation meshes so it is impossible to go strait up walls. I talked to Lawson about this during my discipline review. He suggested just to involve simple iterations with walls if we want to do stuff with walls, such as going strait up to a window rather then path-finding around the wall. Based on the feedback of my group though, this is not a huge thing and can be looked more into later in development.
I also started working on a jumping attack. I am currently doing all of my spider movement using unity navmeshagent. This does not allow me to tell the spider to jump. Because of this I will attach a rigidbody temporarily to do my jump physics and remove it to go back to AI after the jump is complete. When I was working on this yesterday I was unsure of how the jump sequence should happen so I talked about it in our team meeting. We decided that we would have the spider jump towards the player a a certain distance, and when it hit something it would stop moving in the horizontal direction and just fall strait down. If the something it hit was the player it would do damage. We also discussed having an animation for the initial jumping off the ground, in the air, hitting the player, and landing.
We were originally planning on presenting for stage 2. At the end of the week we all agreed, however, that it would be better to give ourselves some more time. For stage to we are supposed to demonstrate our core experience and I did not feel we were there yet.
We had talked about definitely wanting some sort of melee system but we have yet to jump into what that exactly entails. We talked about having it not do damage but just knock enemies back. Regardless of what we decide to do with it, I think it is a core part of our player experience.
Wednesday, October 8, 2014
Screams From The West Iteration 2
So this week we decided that we wanted a complete game flow. That meant having a start screen, a win state and a lose state. I decided to just take the egg sacs that we currently had in the game and make them destructible for the player.
Another thing I looked into was adding an aimer for the player. The way this works is I put an image in the center of the screen to let the player know where he is aiming. From here I do a raycast from the camera point out 300 units into the world. If it doesn't hit anything then the bullet travels in the direction from the player to that end point. If it gets interrupted by ground or spider it goes in the direction of the player to what ever the ray hit. This allows for the player to aim reasonably in a 3rd person view point.
At the end of the week we were able to implement sound. There is a sound for the player shooting that has a reloading sound in it. Because of this I decided to add a delay on how often you can shoot to better match the sound. There is also sound for when you are out of ammo and take damage. The spiders make a walking noise as well as an aggressive noise when they detect you. This allows the player to be more aware of when things are going after him/her.
Overall I felt we made good progress this week. The sound added a lot of feeling to the game.
Another thing I looked into was adding an aimer for the player. The way this works is I put an image in the center of the screen to let the player know where he is aiming. From here I do a raycast from the camera point out 300 units into the world. If it doesn't hit anything then the bullet travels in the direction from the player to that end point. If it gets interrupted by ground or spider it goes in the direction of the player to what ever the ray hit. This allows for the player to aim reasonably in a 3rd person view point.
At the end of the week we were able to implement sound. There is a sound for the player shooting that has a reloading sound in it. Because of this I decided to add a delay on how often you can shoot to better match the sound. There is also sound for when you are out of ammo and take damage. The spiders make a walking noise as well as an aggressive noise when they detect you. This allows the player to be more aware of when things are going after him/her.
Overall I felt we made good progress this week. The sound added a lot of feeling to the game.
Wednesday, October 1, 2014
Screams From The West Iteration 1
So as discussed earlier we decided that the asymmetric multiplayer wasn't really going to work for this project. So what we are thinking now is 4 networked players working together to complete goals in a town overrun with spiders. These goals would be procedurally generated so that the game play would be different every time. Some examples of goals would be saving towns people, destroying the egg sacks, and collecting a certain amount of gold. The player would do this with limited resources starting out only with a few bullets in a gun and a lantern that requires oil to work.
In our current prototype we showed off some of the basic mechanics. This includes having a weapon, a lantern and enemy spiders seen in the last prototype. It has been changed to feel darker and more vast and the lantern also now gives the ability to stun.
Here the spider gets stunned and turns red to let the player know. This will soon be changed to an animation that lets the player know but this was easiest for now. The stun has diminishing returns that last up to 5 seconds and max out at three stuns. The collisions for the stun is not ideal at the moment because I am using a series of ray-cast so that it only hits the first spider rather then all of them. I will improve on this in the upcoming week.
This is a screenshot of the player shooting. As you can see the radius of the circle around the player is larger here then it is when the player is using his lantern. The thought behind this is that the players eyes would adjust to be able to see around himself more than when the lantern was out. The bullet is also lit so the player knows where their bullet goes.
Right now I am using the unity navigation system for the spider AI. This works fine for the prototype but if we want to go further with the AI I will probably need to make my own system. We are thinking of having different spiders that climb on walls and drop from the ceiling. These sort of systems probably won't work using the unity navigation system. This AI would add a lot to the game and is of a decently high risk. Because of this after adding a few more systems to make the game flow complete I will probably be prioritizing the AI.
In our current prototype we showed off some of the basic mechanics. This includes having a weapon, a lantern and enemy spiders seen in the last prototype. It has been changed to feel darker and more vast and the lantern also now gives the ability to stun.
Here the spider gets stunned and turns red to let the player know. This will soon be changed to an animation that lets the player know but this was easiest for now. The stun has diminishing returns that last up to 5 seconds and max out at three stuns. The collisions for the stun is not ideal at the moment because I am using a series of ray-cast so that it only hits the first spider rather then all of them. I will improve on this in the upcoming week.
This is a screenshot of the player shooting. As you can see the radius of the circle around the player is larger here then it is when the player is using his lantern. The thought behind this is that the players eyes would adjust to be able to see around himself more than when the lantern was out. The bullet is also lit so the player knows where their bullet goes.
Right now I am using the unity navigation system for the spider AI. This works fine for the prototype but if we want to go further with the AI I will probably need to make my own system. We are thinking of having different spiders that climb on walls and drop from the ceiling. These sort of systems probably won't work using the unity navigation system. This AI would add a lot to the game and is of a decently high risk. Because of this after adding a few more systems to make the game flow complete I will probably be prioritizing the AI.
Subscribe to:
Posts (Atom)