Friday, January 30, 2015
Two Brothers Iteration 3
Last week I spent a good amount of time working on the networking systems for the game. I integrated networking into the split screen selection system. This way players could join and see each other choose different colors and y-axis inverted over the network. I also spent some time working on the network initialization of players, sending inputs over and working on the movement of the player ships. I was getting close to a point to start showing the basic networking aspects but during yesterdays class we decided networking would not be worth it given our resources. As much as I enjoy networking I agreed with the reasons not to do it. Instead I will start to look into creating AI for the ships in the upcoming weeks.
Thursday, January 22, 2015
Two Brothers Iteration 2
This week I started working on the networking aspects. At first I had some trouble just testing the build because I do not have a controller and there are no keyboard controls. Paul said that he was going to work on adding them this week. Because of that I spent the first week getting a feel for the code base and creating the background systems for networking such as the lobby system. Given this start it seams reasonable that I will have prototype networking up and ready two weeks from now.
Friday, January 16, 2015
Two Brothers Iteration 1
This is the first week I will be working with my new team, Two Brothers. Here is a video of what they had at the end of last semester.
The first thing my team asked me to do was look into weather or not networking is reasonable. There are some definite challenges given the nature of this game. Such as important twitch movement and having trails work over the network. I'll talk with lawson and keep these things in mind to see if it is reasonable.
Thursday, November 13, 2014
Screams From The West Iteration 7
This week the main thing we wanted to focus on was getting rid of the gun without getting rid of the gun. We felt that the gun was taking over the game in a way we did not want. When someone saw our game they saw it as a shooter more than anything else. We wanted the gun originally to be a side mechanic but there were a few things preventing this from happening.
When you first started the game the first thing you saw was an aiming reticle and the ability to shoot. This instantly told our players, hey you should be shooting things. Another thing was that we punished our players for having the lantern out. The lantern provided more light so we said it should burn fuel constantly. This lead to forcing players to have the gun mode out 90% of the time. This, along with spiders roaming around, made it very clear to the player that they should be using the gun as their primary mechanic.
In order to make our game not a shooter we made a few changes this week. We increased the crowd control abilities the player could use on the spiders. We also removed the constant drain of the lantern so that players could keep it out as their primary weapon. We added an investigation state where the spiders stop attacking players to investigate sounds they have heard. We also made the game start with the lantern out so the players would feel that it is more about the lantern then the gun.
The above video shows the increased crowd control I made for the spiders. When the player uses the lantern the spiders now get dazed and then stunned. While dazed they move in random directions for a random increments of time giving a very confused look. It took a while to get these values to look good but in the end I thought it came out nice. The other thing we added is the torches and flares now also stun the spiders. When the torch first gets planted any spiders near it will get stunned. When the flare hits the ground all spiders close to the flare will get stunned. This will give the player more options when trying to escape the spider.
The video also shows briefly the throwing of a glass bottle. We did not have an art asset for this yet so it is just a small rectangle. What it does is that all spiders within a certain distance go towards where it landed. Once they get close enough they resume normal action. We also made a similar thing happen when the player shoots. This will give players more options on how to manipulate spiders out of the way of their objectives.
We felt this was a good step forward but at the end of the week, after our presentation we decided more still could be done. As it is currently the gun still kills the spider. We decided that this was not the feel we wanted so we are planning on changing it so that the gun also just stops the spider briefly like many of or other effects.
When you first started the game the first thing you saw was an aiming reticle and the ability to shoot. This instantly told our players, hey you should be shooting things. Another thing was that we punished our players for having the lantern out. The lantern provided more light so we said it should burn fuel constantly. This lead to forcing players to have the gun mode out 90% of the time. This, along with spiders roaming around, made it very clear to the player that they should be using the gun as their primary mechanic.
In order to make our game not a shooter we made a few changes this week. We increased the crowd control abilities the player could use on the spiders. We also removed the constant drain of the lantern so that players could keep it out as their primary weapon. We added an investigation state where the spiders stop attacking players to investigate sounds they have heard. We also made the game start with the lantern out so the players would feel that it is more about the lantern then the gun.
The above video shows the increased crowd control I made for the spiders. When the player uses the lantern the spiders now get dazed and then stunned. While dazed they move in random directions for a random increments of time giving a very confused look. It took a while to get these values to look good but in the end I thought it came out nice. The other thing we added is the torches and flares now also stun the spiders. When the torch first gets planted any spiders near it will get stunned. When the flare hits the ground all spiders close to the flare will get stunned. This will give the player more options when trying to escape the spider.
The video also shows briefly the throwing of a glass bottle. We did not have an art asset for this yet so it is just a small rectangle. What it does is that all spiders within a certain distance go towards where it landed. Once they get close enough they resume normal action. We also made a similar thing happen when the player shoots. This will give players more options on how to manipulate spiders out of the way of their objectives.
We felt this was a good step forward but at the end of the week, after our presentation we decided more still could be done. As it is currently the gun still kills the spider. We decided that this was not the feel we wanted so we are planning on changing it so that the gun also just stops the spider briefly like many of or other effects.
Thursday, November 6, 2014
Screams From The West Iteration 6
This week the first thing I wanted to do was stabilize the networking. Last week I got basic functionality working, which was great but there was still a lot to be done to get the complete network experience. Kyle was able to quickly get it into testing and get me feedback on what wasn't working. I already knew most of these things were not done but it was nice to get a list of things that did not work.
So I spent most of the week fixing these bugs. This included things like making replay ability. In order to do this I had to make sure that anything that was created or could be destroyed during game play was destroyed at the end of the game. I also had to make sure things that needed to be there that could be destroyed such as pick ups and egg sacs were created at the beginning of a match. This was the most challenging part, the rest of it was just bugs that took some debugging.
After this I wanted to add another goal to show off what we wanted to do with procedural generation. What we decided would be good to add was collecting gold because this would be simple and still show our intentions. There are a bunch of empty game objects around the map where the gold can spawn. The amount of gold that spawns and the amount required are dependent on the number of players. I also made it so the egg sacs spawn at random preset locations and the number of them dependent on the number of players. Later both of these will also depend on difficulty settings.
So I spent most of the week fixing these bugs. This included things like making replay ability. In order to do this I had to make sure that anything that was created or could be destroyed during game play was destroyed at the end of the game. I also had to make sure things that needed to be there that could be destroyed such as pick ups and egg sacs were created at the beginning of a match. This was the most challenging part, the rest of it was just bugs that took some debugging.
After this I wanted to add another goal to show off what we wanted to do with procedural generation. What we decided would be good to add was collecting gold because this would be simple and still show our intentions. There are a bunch of empty game objects around the map where the gold can spawn. The amount of gold that spawns and the amount required are dependent on the number of players. I also made it so the egg sacs spawn at random preset locations and the number of them dependent on the number of players. Later both of these will also depend on difficulty settings.
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.
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.
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.
Subscribe to:
Posts (Atom)