Week 11 – Looking back at the term

For this past week, I reworked the mosquito sound and implemented it into the game. I also programmed the randomization of the suck spots and giving it a time to change over a period of 20 seconds. Other than that, I went over the check list and checked off whatever was finished during the weekend. There wasn’t really much for me to work on since other team members have the remaining tasks left.

• Mosquito buzzing sound (1 hr)
• Suck spot randomization ( 1 hr)

 

POSITIVE

I feel like the team has learned quite a bit from working on this game. Jal learnt a lot with networking and other programming tricks. Zheng, Ning and Josh had a good amount of tricks that they encountered with creating assets for games. Teslim did a great job on the GUI designs and sound. Ethan was very helpful with game design and putting assets and sound in the game. Anna did great in managing the team.

What Went wrong

It took awhile for the game to be made and have a playable build. Some part is my fault since I did not have a clear vision of what the game should look like in the early stages of production. The scope in the beginning was also very large which kind of made a road block to my decisions of what I really wanted and deciding what the core mechanics of the game is. I have learned quite a bit about game designing through this experience. Team communication wasn’t really strong as well as we worked. It got better through the weeks but there were still miscommunications almost every week. Networking is also another huge issue since we constantly have synchronization problems.

WHAT have i learned?

I learned that doing game design is a lot of work and you have to be really clear in your documentation what exactly you want the game to be. I feel like things would be a lot better if I was able to decide things in the early stages but that is too late to regret about it now. Also, communication is very crucial like always and it is bad to assume things.

If I can go back in time and redo this term again, I would be more decisive of things and really sit down and hash out what will be the best for the game and for team members.

Week 11 – Swat The Bug Post-Mortem

GitHub Repository: https://github.com/Kai-L/MosquitoGame

Downloadable Mac Build: https://drive.google.com/open?id=0B4WQ4C_NWsSlM0U5bTZYYThSRlk

Here we are… is the game working? Sort of. I tried my best to get everything that should be working in the game. However, there are still some issues. I spent a lot of time getting the networking to finally work. There seem to be no more issues getting into the game (there was a bug which caused the game to only work if it were hosted by the mosquito but that has since been fixed). Additionally, I spent time trying to get rounds working but then realized how much else I had to do. With the amount of time that it took to get the initial game creation working, I opted to leave the rounds system behind. As you can see below, there were many small things that had to be fixed or added. The lighting values had to be changed as it was too bright at midnight which invalidated the use of the lightswitches. During the process of changing the lighting, I also fixed up the adaptive light script that we were having problems with last week. In addition, I created a script to flicker the bedroom light off if it is moved from the wall. I also added a shader to highlight weapons for sleepy if he hovers the mouse over it. This was decided with Kai-lin as an alternative to a crosshair because we felt that the crosshair would confuse the player into thinking they can swat in any direction.  I also added a script to check who is the local player which helped out in synchronizing things such as the highlighting of the weapons and spawn points.

• Meetings (1 Hour)
• Synchronizations Across Network (3 Hours)
• Creating and Joining Game Fixes (5 Hours)
• Reworked Spawn Points (10 Minutes)
• Win / Loss Screens (1 Hour)
• Rounds Attempt (2 Hours)
• Collider and RigidBody changes (20 Minutes)
• Lighting Changes (2 Hours)
• Fixed Lightswitches (30 Minutes)
• Fixed Mosquito Controls Working Differently On Other Computers (Hopefully?) (1 Hour)
• Flicker Light Off (30 Minutes)
• Check For Local Player (1 Hour)
• Adjusted Ambient Sound Script Which Caused Lag (10 Minutes)
• Highlighting Weapons For Sleepy (1 Hour)

Positives

I was proud to have gotten the networking to the point that it is at. I have always cowered from creating games with networking but this was a good push to set me in the right direction. Obviously the game isn’t perfect, but I have learned a lot in the process and definitely don’t regret the project choice.

Negatives

Synchronizations across games are not consistent. In some cases, this can lead to a game where one of the players has finished the game while the other has not. Things that are not always synchronized: movable furniture, weapon pickups, win/loss conditions. Of course, this is a serious problem and would have to be addressed for a release version of the game.

What have I learned?

I have learned a lot about how to create a networked game in Unity. However, the functionality of Unity’s UNet seems to be better suited to games which don’t require the precision that we needed in this game. For instance, it is very easy to sync simple variables (ints, booleans, etc.) but much more difficult to sync the positions of characters exactly. I also learned a bit about the mechanim system thanks to Kai-lin. This is something that I will definitely be using in the future for 2D and 3D games, instead of programming every single animation like I have been doing.

This game reinforced how important communication is at every step of the way. While I admit I wasn’t always on top of the task board and I could have communicated my concerns more often, the in class lesson on scrum helped me to see how useful organization can be in a group project. As someone who prefers to work alone, this is still something that I will have to work on.

What would I have done differently?

If I had the knowledge that I have now about networking in Unity (or networking in general) I would have made sure to carefully plan out everything that needs to be synced. I also would have advised against the more physics based controls that we attempted to create in the middle of the quarter, as this took up a lot of time. This would have allowed me to spend more time on the networking aspects of the project.

As for the game itself, while I like the concept of the game, I do not think that it’s design is as good as it could be. For instance, the gameplay does not warrant a 6 minute game-time. In order to fix this, I would create incentive for the mosquito to try and hide. This could be in the form of a buff or maybe the goal could simply be changed to surviving as the mosquito. If this were the case, however, we would lose the risk vs. reward of trying to suck blood from Sleepy.

 

Week 10 – Animator, Animations, Checklist

For the past week, I made a checklist of the things that we would need to have our game ready, animated the rest of Sleepy’s animations, imported Sleepy and Mosquito animations into Unity, set up Animators, checked through some assets that team members have and gave Teslim some confirmation on UI assets. I also spent a bit of time reviewing how the Animator works in Unity.

• Checklist (1 hr)
  • https://docs.google.com/document/d/1pj4gNkhyFRQc2CVoUS-MBPOmNvawOS__gmMC1vvT7rc/edit?usp=sharing
• Animated Sleepy Animations (2 hrs)
  • Walk cycle
  • Idle
  • Left Swat
    • Low swat
    • Mid swat
    • High swat
  • Right Swat
    • Low swat
    • Mid swat
    • High swat
• Reviewing how Animator works (~1 hr)
• Imported Mosquito and Sleepy animations into Unity and set up the Animator (3 hrs)

Mosquito Animator Controller

Sleepy Animator Controller 

POSITIVE

The animations and animator for mosquito was pretty straight forward to set up and is working. The Sleepy animation on the other hand requires a bit more work. The whole team is working hard to finish up the game and have it ready for playing. There was a lot of back and forth communication for finding errors in the game and things that are needed to be changed.

NEGATIVE

Sleepy swats was not working with the current setup we have. Having the arm rig and the whole body rig separated leave errors for the Animator. Sleepy’s body will move while the arms will remain in T-pose. So in order to make it work, Jal and I decided that instead of having the arms try to aim at where the camera is looking at, we would just make animations for a high, medium and low swat and the animations would play based on the y-axis of the camera. So I reconnected the arm rig to the body rig and animated the different swat animations. Hopefully this will work.

SOLUTIONS & SUGGESTIONS

There is still testing we would need to do and some last minute bug checks. I hope we can have a playable build functioning very soon.

Week 10 – Programming a Better Bug

This week I made a lot of progress towards the final product of this game for next week. I first set up scripts for the audio for swinging a weapon and hitting something with a weapon. I sent this over to Ethan so he could apply the correct sound to each weapon. Next, I started to create the functionality for the network select screen. Fortunately, I was able to get it spawning in players, but there is a bug in it spawning the wrong prefab. This took a lot longer than expected, unfortunately. Next, I finished up the adaptive light script and added all of the values that Josh had given me. There was some miscommunication on how it should shift so the script has to be altered accordingly. However, it does sync with the clock and transitions to dawn starting at 4 AM. I also revamped the way that Mosquito controls and it feels a lot better. There is no more floatiness so he finally stays still (complete with an idle animation, thanks to Kai-lin!). We also came up with a workaround for the rotation of Sleepy’s swing. In order to do this, Kai-lin created separate animations for 3 different angles. I then wrote code to shift between these animations based on the current camera angle. In addition to this, the animation now syncs over the network!

• Meetings (1 Hour)
• Audio Scripts (20 Minutes)
• Network Select GUI (6 Hours)
• Adaptive Light (1 Hour)
• Mosquito Controls (3 Hours)
• Sleepy Swing Rotation (30 Minutes)

POSITIVE

The GUI Network select screen is almost working! We figured out a workaround for swatting in the camera’s direction! Mosquito controls feel way better! Animations now sync over the network. There is mostly only polish left.

NEGATIVE

Miscommunication between myself and Josh led to the adaptive light not functioning as intended.

Creating a custom GUI for the networking took much longer than I thought it would and still does not function as we want it to. Because of this, I was unable to implement the win/loss screens this week but they are in place to finish for next week.

SOLUTIONS & SUGGESTIONS

Stay focused on finishing the game even if you’re on vacation in San Francisco next week!

Week 9 – Timer, Mosquito, Swings, etc.

This week I managed to get a lot roughly finished that was discussed last week. First off, I created the working clock which is synced across the network. The clock takes 6 minutes to tick from midnight to 6 AM, in which case the game ends. The clock required me to write a custom shader so that the 3D text would not show through everything. Next, I worked on replacing the mosquito with the newer model and created a script for the third person camera. When the mosquito’s camera gets close to any object, it will assume a different position until mosquito has flown away from that object. I also replaced the placeholder UI with Teslim’s assets and gave all of the buttons functionality. Next week, I will work on getting the lobby to work as expected. Lastly, I worked on getting Sleepy to swing towards the camera (again). However, we ran into some more problems with the rig along the way (it’s orientation was reversed on the z axis), which cost some time. In it’s current state, Sleepy can pick up objects and swing with an animation which is set to a default rotation. Alternatively, with “Animate Physics” set to true, his arms rotate and animate towards where the player is looking, but the animation does not play 100% correctly.

• Meetings (1 Hour)
• Sleepy Movement (4 Hours)
• Replacing Sleepy (20 Minutes)
• Picking up Objects (1 Hour)
• Clock (2 Hours)
• Mosquito Controls (2 Hours)
• Replacing Mosquito (10 Minutes)
• UI Replacement and Functionality (1 Hour)

POSITIVE

Every feature of the game is in place, at least in some rough form, and requires polish.

NEGATIVE

Animations still do not sync correctly over the network. Picking up objects sometimes syncs over the network. The rotated animation does not play properly. Networking is still not perfect.

The artists no longer have things to do.

SOLUTIONS & SUGGESTIONS

I feel that a lot of the polish is left to me and it would be great to have some of the people who do not have as much to do to lend a hand if they have Unity knowledge.

Week 9 – Pulling Things Together

This week I and Anna decided upon a color pallet, I continued to import models into the game, continued to put some basic colors on everything, redesigned the room for more maneuverability, fixed colliders, organized the folders in Unity (things got pretty cluttered), started to animate Sleepy before switching jobs with Kai-Lin, and wrote two sound scripts.

• Environment layout, fixes, and texturing (4 hours)
• Sound scripts and attaching (1 1/2 hours)
• Animating (1 hour)

New layout!

One of many objects that now has a texture in game.

Positive

The game is slowly but surely coming together into some kind of being. Building up the environment has been very satisfying, as was scripting. Not nearly on the same level as Joe, but still fun. The team seems to be communicating much more – big plus.

Negative

Having only one dedicated programmer is really becoming a weakness for us. Joe is working his butt off, and we still haven’t playtested. Discovering the Sleepy rig needed to be re-rigged was incredibly annoying, and not a setback that we needed at this stage.

Solutions & Suggestions

I’m not sure what else to offer up here other than everyone needs to work on this as much as possible over the next week.

Week 09 – Sounds and Re-rigs

I’ve spent some time giving Teslim directions of how long sound effects should be and which sound we are keeping in game and which sounds we are cutting this past week. I’ve also started some sound implementation into the game: the radio sound, mosquito buzzing and ambient sound. Jal ran into problems with the Sleepyhead rig and needed it to be fix. We found out that Sleepyhead is actually facing the wrong Z direction and the arms of Sleepyhead should be separated from the body rig. In order to fix all that, I had to quickly re-rig Sleepyhead and animate a simple swatting animation for Jal to work on. I was planning on making a playtesting survey, but I didn’t get a chance to do so.

• Looking through sound asset file and jotting down notes for Teslim (0.5 hrs)
• Sound implementation into the game (3 hrs)
  • Most of time spent trying to get mosquito buzz to decrease in volume over some distance
• Re-rigging Sleepyhead (1.5 hrs)
• Re-weight painting Sleepyhead (0.5 hrs)
• Animating swats for Sleepy (0.5 hrs)

POSITIVE

The environment is getting prettier! Mosquito model is in!

NEGATIVE

We should have been more careful with checking if models are facing the correct Z direction. This can be problematic especially for characters if they are facing the wrong direction. I felt that my re-rigging time could be used for implementing the rest of the sounds into the game and have the playtesting documentation done.

Sound implementation is pretty simple, though I spent quite some time attempting to code mosquito sound fall of rate over a certain distance with the use of colliders. Until I found out that Unity audio has a 3D audio setting where is does exactly what I wanted to. So after finding out about that, it took at matter of few minutes to implement it. However, if a player plays as mosquito, he/she will continuously hear the buzzing sound. Thus, we still need to figure out a way to mute the sound for the mosquito player and not the Sleepyhead player.

SOLUTIONS & SUGGESTIONS

Just got to keep moving forward.

Catching up to work

This week, I’ve spent some time going over the more game design ideas with Ethan and finishing up the GDD. I’ve finalized the decisions for the game mechanics. The two of us also went over things we expect for our play testing sessions and what things we should look for when we play test. I’ve also talked to Jal about programming tasks and listed out all programming things we need to do for the game. Other than that, I spent some time critiquing Ning’s rig and did some final adjustments to his rig before I handed it off to Ethan for animation.

• Worked on updating GDD (1 hr)
  • https://docs.google.com/document/d/1X0ZbPuCJh1D4IEWkfdMMqzpGkB9hFYKz1lb4m9iwbw8/edit?usp=sharing
• Met with Ethan and talk about design and play testing ( 1 hr)
  • https://docs.google.com/document/d/13rY5y3y2X7uMnAMjdOa1mttCs53fe8iTtEeW45OPHDk/edit?usp=sharing
• Critiqued Ning’s Rig (1 hr)
• 
• Slight edits to Ning’s Rig + Re-weightpainted Sleepyhead model (1 hr)
  • Pushed the root joint and hip joints upwards
  • Changed the root controller
• Met with Jal for programming tasks(1 hr)
  • Sleepy Movements (Needs to test with Sleepy model)
    • Swinging of hands
    • Picking up objects
    • Walking/locomotion
  • Mosquito Movements (Done)
    • Flying
    • Sticking on walls
  • Suck Spots (Working but needs randomization/timing set up on Sleepy’s arms)
  • Spawn locations for objects (Done)
  • Networking (Is there but needs improvements)
  • One Hit KO (Done)
  • Sound implementations (Needs to be started)
  • Light Switches (Done)
  • Masses for objects (Using the Rigidbody mass but not yet tested)
  • UI Programming (Not yet started)
  • Round implementation (Not yet started)

POSITIVE

Everything is moving along. I’ll be working more on sound implementations into the game next.

NEGATIVE

There’s still some bottleneck this past week. But now that Sleepy’s rig is done, we would be able to move forward. Hopefully we can get a build working by Friday and have a play testing session.

SOLUTIONS & SUGGESTIONS

It’ll be good for team members to check in with each other frequently and nag at each other to get work done if needed.

Week 8 – Weapon Spawns and More Sleepy Problems

This week, I was unfortunately held back on completing the controls for Sleepy to pick up objects. I was given the new model of sleepy with rough animations and attempted to get his animation to rotate towards the point that he is looking. However, since we are using Legacy animations, it doesn’t seem like a possibility. So, I proposed that we use Mecanim instead. This will require another week to get working, unfortunately. Besides not being able to get this done this week, I was able to accomplish tasks in other areas of the game. For instance, the weapons that we have available now spawn into the stage in random positions. All of the objects in the scene can be moved with each having an appropriate weight (may need to be revised). I also created some placeholder menu scenes with buttons placed according to Teslim’s mockup. I met with Kai-Lin to discuss what we have left to do as far as programming is concerned.

• Meetings (2 Hours)
• Sleepy Movement (5 Hours)
• Weapon Spawns (1-2 Hours)
• Adding Colliders / Rigid Bodies (45 Minutes)
• Adding Menu Placeholders (40 Minutes)

POSITIVE

The level is nearing the end with almost all of the models in place. I believe we are in a good place overall but…

NEGATIVE

This week, I really wanted to have the ability for Sleepy to pick up objects done. However, with the amount of time it took to receive the Sleepy model, we were unable to complete this task.

SOLUTIONS & SUGGESTIONS

This week I was held up by lacking what I needed up until the very last minute (Sleepy model with animations). Additionally, the model was given to me with problems that will have to be addressed in the coming week. Anna already spoke to the team on making sure that we communicate better with one another and I completely agree with that.

Week 8 – Weapon Spawns and More Sleepy Problems

Week 7 – Abandoning Poor Rag-doll Sleepy

As I mentioned last week, I was working with a full rag-doll to attempt to create more fluid swatting animations procedurally. However, as per Tony’s suggestion, I spent a few hours this week with the rag-doll model before decided if I should more forward with it. After creating some decent movement with the rag-doll, I could not get swinging to work properly because of the way that the placeholder model is rigged. Instead of spending more time on this I removed the rag-doll and informed the art team of my decision. As of right now, Sleepy’s development is waiting on the final model so that I can test everything that I have worked on with how he will actually be designed. Additionally, I made small changes to mosquito based on the feedback from last week (he can now stick to walls, instead of sliding down them). I also played with the networking in an attempt to get the animations to sync which unfortunately does not yet work.

• Meetings (1 Hour)
• Networking (2 Hours)
• Mosquito Improvements (1 Hour)
• Sleepy Movement (6 Hours)

POSITIVE

Sleepy controls are now complete and waiting for the new model.

NEGATIVE

 

Using UNet to sync animations is not as simple as imagined, unless your character is using an Animator component.

With delays to receiving the Sleepy model, I was unable to test if the controls for him will work ultimately. For instance, the code for rotating the animation towards the camera was written specifically with the idea that the arms would be detached from the torso.

SOLUTIONS & SUGGESTIONS

With design decisions still not solidified across the board, it is difficult to know what I should be working on. The GDD should be updated to only include aspects that should definitely be in the game.

Additionally, from my perspective, the art team is not producing assets as quickly as they should be. With only 3 weeks left, it would be ideal to be able to work with the “final” models for Sleepy and Mosquito.