Senior Production: Smooth Moves

Hey everyone,

I finished the new lobby system for the game, it works as you would expect any game lobby to work.  The typical start a game, pick a side, and ready up situation. When a player hosts a game, they choose their team and can technically join a game alone, but usually a user joins and prevents them from starting until the new user is ready to play. The new player follows the same procedure that the host follows, they pick their team and then can choose to ready up. While waiting, a user can change their team color at any given time and then ready up. Once all users are ready, the host can start the game.

Another thing I worked on was getting the team lives to work correctly. The focus of the Team lives is that each team has a given amount of lives in a shared pool. When you spawn your team life counter goes down, and when the team lives are at zero, you can’t spawn again. At this point if you die, then you’re dead. This is now how it’s implemented, previously I implemented it so that the team lives were decremented when you died, this created a problem of the team lives showing negative values.

Finally, the last thing that I did was implement network smoothing. The smoothing is an integral part of any networked game, and having this is essential for our game. Before the smoothing the game looked really choppy and ruined the flow of the game when everything around you looks like it’s jittering. The smoothing was implemented simply by tracking the last received rotation and position then using linear interpolation to smoothly transition between the actual position of the character and where the newest position is. This alleviated the jittering and made the game a lot more fun, according to our most recent QA testing results.

I am planning on working a cool metaballs effect for the guns to really help play up the “gooey” feel of the game, stay posted!

Metaballs GIF, Source:

That is all for now!


Senior Production: Changing Back to the Old System


After much deliberation this week, Dan and I have come to the conclusion that it is not worth continuing work on the authoritative server. We originally wanted to use the Authoritative server as a method for control, anti-cheating, and data capture features. We also believed that it would send significantly less data than the old system that I had programmed last semester. However, while implementing the bullets across the network, we realized that with all the work and time spent:

  • We have not made it very far in 3 weeks
  • Many features still need to be implemented
  • We are using basically the same data as previous

The last point was discovered after a quick check between normal gameplay in the existing system. Once we realized this, we sat down and began to list the pros and cons of each existing system. Ultimately, the fact that we understand the older codebase, and that it worked were the main factors is us scrapping our last 3 weeks of work. I do not regret it and I’m glad that we switched back. I do enjoy the fun of prototyping and working new methods, but given the time frame it doesn’t make sense to continue with the authoritative server.

Moving on with the new system, I began to implement a true lobby system that lets you choose and change your team, and set your ready status. The game host will then be able to start. Dan began reworking the shooting system with some new firing modes, like a continuous stream, burst fire, and a goo stream. I also began setting the framework for the planned game modes, such as capture the flag, and king of the hill.

For next week, I would like to begin implementing more  feedback into the game mechanisms so that the players feel more immersed and don’t have to guess whether or not their bullets are hurting the enemy.


Senior Production: Unity Authoritative Server

Hi everyone,

Dan and I have been working on the authoritative server and porting everything over. We really want to make this switch so that we can collect more metrics on the game. We also think it would be really cool to have a replay system for the game where anybody can watch a previous game that has been played. This is good for both the players and the us, the developers. This will let the designers be able to analyze the game and see specific game moments and understand common play tactics to be able to fine tune the game play. We will also be able to implement heat maps with it. So far we have only implemented the movement, shooting, visually showing the vacuuming, and jumping.

The thing with implementing the authoritative server is that we have to implement everything on both ends. This means that we send the input to the server, the server parses the input, and then sends the new positions and players back to all clients so that everything is synced. The best way to think about the authoritative server is that you are watching a video and seeing how your inputs can modify subjective properties of “characters”

That is all for this week.


Senior Capstone: The Wrap-up

These past few weeks have been wild… In terms of development the game is ever evolving and ever flowing. Like water… or goo?

To update you on things that have happened previously… the goo vacuum game has been named! VacuuLab! We finally settled on a name. It works, and rolls off the tongue… Or slides, or slimes, or glops off.. Regardless. With all this networking under my belt I feel as though I am a Networking Ninja Master Code Guru.

All this work, and my neglect to work on a networked game has come together into a harmonious experience that has blossomed into a beautiful flower. In a technical sense there is a lot going on and it’s pleasing to see my work pay off.

We are now on the downward slope for the semester working into the tweaking and the polishing that the game needs. My effort in working towards an easy and smoothly flowing environment starts with refactoring the code. As with all game development, the code that creates the prototype is never pretty. When we started my code was very bad. I’m not saying that now it’s good, it’s probably mediocre at best, but now with the refactor it is manageable. This is one truth about all programmatic development: There will be bad code in a large game. Not all features in the game will have the most defined and planned code. It’s just how rapid development works. While these rapidly developed features may not be the most readable as long as they are functional, you must carry on.

With VacuuLab, this is the case for some mechanics and features. I’m not bothered by it, I don’t necessarily have the time to refactor my code to such a manageable degree… When I am implementing features on features into a very large game I don’t have the time to dedicate to fixing my code and making it look pretty.

Ultimately we will be adding and adjusting features for the game over the next few weeks.