I started reworking the lobby system for VacuuLab. This sounds like a simple task, but as it turns out it’s really not. I wanted to create a lobby system that has a similar menu flow as many other games, where from the menu you can choose to Join a game, or Host a game. By choosing the options it would take you to a scene with more specific options.
From the Join game scene you would be presented with all the current games, and be able to change game types that you want to play in, and in the Host game scene you would configure the game you want to play and create it.
I can create the game just fine with all the different options I want, but the problem I am facing now is that when I go to list all the games available on the server, nothing shows up. I’m not sure if it’s because I am doing this all across different scenes, or because a configuration option may be messed up, but it’s not working.
I have decided to put the new lobby on the back burner because our current primitive game lobby works, and while it would be cool to get this new lobby in the game, if I have to spend another 8 hours debugging it, then it might not be worth it for now.
This week has been interesting! I’ve been working hard to get a gooey metaball effect for the bullets that come from the gun to make it look like an awesome goo effect. After many hours of work and research I have implemented the effect into the game. I won’t go into much detail into how I did it, I’m going to save that for another blog post.
This week has been filled with understanding and learning the Unity3D graphics pipeline. The biggest problem that I had with implementing this feature was that I didn’t not know how I would actually go about doing this in Unity. I know how I would do it in another language from scratch, but when it came down to the implementation and using separate rendertargets within unity, I was lost. I began using a sample from the Unity Asset Store, Shader Replacement, to assist me in getting familiar with what I wanted to do. I was having a problem where when I rendered my metaballs layer they would show up as white squares rather than the faded gradient I was hoping for. This is where I began to research everything about Unity shaders and what options were available to me get it working. It turns out that properties used in certain shaders (such as _Color, and _MainTex) are available in the same frame in other shaders that operate the same (by use of Tags, like RenderType=”Opaque”). After finding this diamond (in the rough) I was able to pull the feature together.
Recently I’ve been working on simulating our solar system and it has been a difficult endeavor. There are a few big problems that I faced in this project:
Float Point Imprecision
Conversion from actual (metric) values to something smaller
Let’s evaluate each of these items.
Floating Point Imprecision
A float is a 32-bit data type in many languages that allow you to hold decimal data. You may have heard of floats referred to as Singles, this is because floats have a bigger brother known as a double. They are called doubles because it is a 64 bit data type. This allows a double to hold a much larger number, but you have the overhead of using a lot more memory. Due to this, there is a tradeoff in the manipulation of the data. Further, floats are use in many existing libraries and utilities, so now there is build in imprecision. What is imprecision? Imagine working with some really small numbers, something like 1.0 x 10-10 then dividing this number by say 1000. After these operations, the values will be getting so small that you are bound to lose some digits simply because the data type cannot hold numbers of that size. Imprecision is basically a limit on decimal digits, resulting in “unintended” rounding.
Actual Value Conversion
Because of the previous point having been stated about imprecision, using the real solar values is not preferrable because after all of our calculations, much of the data will be cut off. I found this part very difficult because finding a suitable size was nearly impossible. However, in the end I was able to make a decision and for distances, I decided to go with Astronomical Units and for weight, Earth Masses. Getting these values was easy because all I had to do was perform a simple Google search and I could find the AU’s a given planet was from the sun, and their weight in Earths.
To perform this simulation, I am using the Newtonian Universal Gravitation Equation
Because of the units that I chose to use to scale the actual values (AUs and Earth Masses), it was extremely difficult to convert Big G to a number that accurately represents Earth Masses and AU’s. For this I used the good old, Guess and Check method. I just tried values that I thought might work really well for what I was doing. Ultimately I was able to find a value that fit well with my solar system.
This project is programmed in C++ using OpenGL (Libraries: GLFW3, Glut, Glew, and GLM).
Check out the video below to get a better idea of what the project is like
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!
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.
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”
I want to write a short guide on getting a Unity Master Server set up on Amazon Web Services (AWS) on an EC2 Micro Instance. Firstly, Amazon Web Services are free for the first year as long as you are using a one micro instance (5GB image). As long as you do not have unassigned Static IPs or multiple instances running, you should not incur any charges. To get more information on what defines the free-tier you can go here: Amazon AWS Free. Let’s get started!
Go to the EC2 Instances page by clicking “EC2” then when that loads, in the lefthand navigation going to instances.
Click the blue “Launch Instance” button
Create a new Redhat Enterprise Linux Instance under the free tier in the preconfigured AMI’s
After you select it, it should ask about what instance type you like. This is where you skip this step and click on step 5, “Tag Instance.” You will see that an entry already exists, Name. You can go ahead and set the value for that to Unity Master Server for your convenience.
Go ahead and click on step 6: “Configure Security Group”. We need to configure the instance so that we can access the URL. The easiest way to do this is to open the instance on all ports on TCP and UDP. You will see that the instance is open on port 22 for SSH access, now we need to click the Add Rule button and add access via ALL TCP to anywhere on the IP and same with UDP
You do not need to configure anymore options. You can click the blue Review and Launch button then once you’ve review the details, go ahead and launch the Instance.
You should be prompted to create a security key pair or use an existing one. This is VERY important. Do not lose the file you download when/if you create a new key pair! It is imperative that you download this .pem file to a secure location. If you don’t have it, there is no way that you will be able to access your VM.
Ensure that it’s running by checking it’s status in the Instances page. If the instance state is not running, you may select it, right click, and command it to start with “Start” in the “Actions” section
Now that the instance is created, we need to give it a public IP Address. Go to Elastic IPs under Networking and Security in the lefthand panel and create a new elastic IP. After you create this IP is VERY IMPORTANT that it is assigned to a RUNNING EC2 Instance. If you create an Elastic IP that is unassigned you are billed $0.005 every hour until it’s assigned. To assign it, just select it, then right click and go to “Associate Address”
OK. we have a public IP for our instance, and it should be running. Good. We need to set up a way to SSH into the VM and starting messing around with the files. The best thing to do is to download PuTTY and install it
Open PuTTYGen and then open your download .pem file in it (by selecting *.* All Files in the load file dialog). You can then go ahead and hit generate to create a ppk for the key file. You can put a password on it if you like. Just remember this password for later you will need to enter that in the putty console when you connect.
Once that is complete you may open PuTTY and get your public DNS and place that in the Hostname box on the Sessions dialog.
Before attempting to connect we need to navigate to the Connection section on the left and add our ppk into an SSH authorization section as you can see below:
Now go back to the sessions page and you can save this configuration by putting a name like “Master Server” in the box below the “Saved Sessions” text and then then hitting the Save button.
You should be able to connect without a snag. You will be prompted with a user account to log in with. If you type “root” it will tell you the correct user for that vm which could be something like: ec2-user.
My final semester at Champlain College has begun, and I am once again required to write about my experiences in the last half of my capstone class.
This last week was about reworking the networking for the game. Our new programmer, Dan, and I were working together to remedy some of the hacky solutions I came up with while rapidly developing VacuuLab. We decided it would be best to create an authoritative server set up to ease the implementation of game features and be able to monitor the game closely. Having a dedicated server would allow us to control the games and be able to make better decisions for level design and etc.
As far as the development, we have implemented smoothing and simple game play.
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.
Last week went well in terms of development for the game. I was very swamped with work and was not able to do as much as I wanted to do on the game. What I did last week was implement teams and fixed a bullet collision and aiming issue. I also started the implementation of goo depositing and team points.
What I want to do for the game before we seriously try and challenge stage 3:
Revamp the camera and movement so that it feels more natural and smooth
Get a goo shader or effect for the goo characters
Finish implementation of the team aspect and goo depositing.
Iterate the vacuuming to make it extremely interactive and much more involving. I want it to feel like a real struggle!
Add sounds and music to the game
This week should be interesting if I can get enough time to really work through some of these features.