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!
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.