Week 11 – Postmortem

Working on this project for the past term has honestly been a challenge. I love the potential Swat the Bug possesses; should we keep working on it, this could be an actually unique product. Due to the difficult production (honestly, what game isn’t difficult?), should we continue development?

Of course we should!

This week I also did a bit of work on the game from San Francisco:

• Helped Anna write the outline for the presentation and edited the actual presentation
• Added the pickup points on every weapon
• Tried to make a better light-switch. Said switch has an orange light, but doesn’t flip position upon collision. Jal ended up taking care of this. Thanks Jal.

Lessons Learned

Overall, I’d say the team worked well together. There definitely were moments of communication failures (“stop assuming!”), but we seemed to get through this without too much drama.

For design lessons, I think I learned, first hand, that a designer must wear multiple hats. I enjoyed this immensely. Not just as a bullet point on my resume; that part’s very nice.  I relished the hat juggling because I was helping out the team.

I do wish that certain design decisions had been made clear far earlier in the life of the project. I’m not trying to shift or take blame, but that hampered our progress. Our communication also did slow progress, as did the art production. Next time, someone else should have either filled the art lead role, or taken Anna’s producer responsibilities. She’s fantastic at both, but at multiple points she was overwhelmed with model revisions and the like. The art team though, man, they seriously brought it. Our game looks great.

I also felt a distinct uneasiness of where I stood in the decision making process. The game is Kai-Lin’s baby, but at other times production was much more fluid. I think Kai-Lin also needing to approve everything became a bottle-neck at later points in development as well. And it goes without saying that Jal went above and beyond with this game, being the sole dedicated programmer.

The Road Not Taken

In the future, I will push to have a working, simple prototype as soon as humanly possible. Maybe adopting John Berton’s “rough to fine” mantra of requiring a new pass of the entire project every week. Aka use Scrum development more extensively. I’m also going to set deadline milestones in all my projects going forward (to be fair, we did this), but adopt a mindset of not turning back and redoing earlier decisions once a point in time has been passed. Should we continue development, I’d like to see the game evolve into a number of modes, destructible environment objects, more weapons, and see the return of the beloved mini-games.

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 – POST-MORTEM

Last week I did not contribute very much to the project since the art production has been finished. I pushed all the changes to the master file, such as the textures of paintings and adding magnets and stickers to the scene . In addition, Ning and I are also responsible for taking screenshots in the game, so Anna can use it in the final presentations.

• Meeting ( 1 hour )
• Taking screenshots ( 1.5 hour )

POSITIVE

Thanks to our programmer Joe, now we have a functional game and the networking is working fine. On the visual side, the GUI looks cartoony and cute, which matches perfectly with the story of our game. So overall it has been a great experience for me and I’ve learnt a lot from all of the rest team mates.

NEGATIVE

I think what is missing in our team is a concept artist who can help design the basic looks of our game, including the environments. So everything in the game could be consistent visually.

WHAT DID I LEARNED FROM THE EXPERIENCE?

The first thing I learned from this experience is the ways of modeling in games. Honestly speaking, it’s my second group project of making a game. When I’m modeling for animations, I usually model those assets as more detailed as possible. While in games, when assets do not have to be that high-poly, there are some cheating methods that I can use to model objects. For example, instead of modeling the individual stitching on baseballs, I can just use a texture and a normal map.  By doing that, I can speed up producing the assets.  SCRUM is another thing I learned from this experience, which I’ve never heard before. But it turns out to be really useful in a group project. By SCRUMing, we can get everyone on the same page, and communicate better  as a group.

Week 11 -We’re finished?

This Tuesday (yesterday!) I flew out to San Francisco for a conference. In preparation for my leave, I coordinated with the rest of the team on tasks that we needed to take care of for the final submission. Besides managing tasks and lines of communication, I set to work on the final presentation so that those who will be in class today can just focus on other production-related tasks.

• Work session meeting (2)
• Final presentation outline and Keynote (4.5)

Since this is the last post for the project, the positives and negatives are centered around the entire term rather than for just the week.

Lessons Learned

Overall the team worked well together. Almost all the team members had their moment to shine with regards to their respective role. While we did not assign accountability buddies out right, each team member fell into various grouping. I felt more comfortable assigning a bucket of tasks to two people rather than related tasks to each individual person.

I appreciate that our professor took the time to go over SCRUM and gave me suggestions to help the team remember details about the pipeline. I witnessed the power of checklists although a tad late!

Some of the tasks I assigned were not popular. For example, the bed assignment received negative feedback. While I did explain the purpose of the assignment when delegated to the team members, I understand now to follow up and also explain the results of the assignment.

This class is geared towards 2nd-year graduate students, a term before they have to graduate. Because of the timing of the class, several team members were open to do any tasks that they were assigned. The overall attitude towards the project was something I never experienced before.

The Road Not Taken

There are many decisions I would have made differently. However, the two I will emphasize here is related to scope and vision. I tend to make a backup plan or two based on the scope of the game. I now wish quite badly that I discussed with Tony, Jal, or Kai-Lin a backup plan to the networking. While many team members convinced me that the networking would pan itself out, I see now that I should negotiate and communicate more the need for alternatives. In retrospect, I perhaps should have negotiated more. We can include X feature or Y design based on your visions if we also address my desires to keep the game in scope. Negotiating would be a better method than just letting the scope run rampant or shutting down features that members on the team really wanted.

Another decision I would have made differently was establishing the vision with the product owner–in this case, Kai-Lin. I was unable to make the meetings early on to decide the direction of the game and relied on someone on the team to inform me of the direction. I was under the assumption that Kai-Lin knew what he wanted for the game. The reality of the situation was that nobody had a clear vision. Perhaps the solution was to guide the creation of the vision with Kai-Lin and Jal. My lack of due diligence, in a sense, led to Ethan and Kai-Lin designing a mini-game, a discussion I wish they had with both Jal and me. In future projects, I will seek more guidance and practice more ways to manage a project that lacks a vision.

 

Week 11: Ning Zhang’s Final PPJ

In the final week, I made lots of rendered/screenshot images for the final presentation. I checked all the colliders in our scenes and fixed the problematic colliders. Because the mesh colliders didn’t work for us. So I needed to double check every single object and fixed the objects with mesh colliders. Then I added masses for every object which can move in our game. Besides, I play-tested our game and gave some feedback about the controlling scheme, bugs and so on.

1. Checked all the objects and fixed the colliders (1.5 hours)
2. Add masses to each object (1 hour)
3. Screenshot images for final presentation (2.5 hours)
4. Meeting (1 hour)

POSITIVES:

Finally, our game is done and we have a playable game now. Everything is kind of within schedule. We finished all the art assets before week 10. Then we did some revision and also added some extra stuffs to our scene, for example, the Ambient Occlusion, fridge tags… Then I went to help others’ works. I also acted as a play-tester to provide feedback to the programmer. All of these are good to our team.

NEGATIVES:

The game is still not too good to play. I mean the balance, the control scheme, the lighting… all have room to be improved. There are also some little bugs needed to be fixed. However, we only have one fully-functioning programmer. The production time is only around 8 weeks. So It is acceptable for us to have a game like this.

WHAT HAVE I LEARNED?

In this class, I acted as an artist in our group project. My main work focused on building models, rigging character, painting textures, creating different shaders, and some other designing works. I practiced my modeling skills even though the furnitures are all hard-edge models which are kind of easy to build. I also learned a little bit organic modeling which is about the sleepyhead. Unfortunately, we didn’t use my model in the final. But at lease, I provide the basic shape, structure and rough geometry for the real model. Then I reinforced my rigging skills, which made me learned a lot on rigging a human. Also I helped other members to do work. Such as fixing colliders, researching on adding Ambient Occlusion and taking screenshots. They are not extremely easy. For example, if I want to take a screenshot of the “sleepy swatting”,  I need to drag the prefab to our scene, arrange the sleepy is correct place (lighting condition), and make it in swatting pose. Then I can take screenshot. After that, I still need to go to Photoshop to edit the picture a little bit. But anyway, as an artist, I learned a lot from this project.

WHAT WOULD I HAVE DONE DIFFERENTLY?

If I had experience on organic modeling, we would save plenty of time though. Because I spent around 10 hours on modeling the sleepyhead and revising it. But the final result seemed still bad. So others had to remodel it. Also, if I was more proficient on rigging a human character, I would go to get more work done in advance. Because I watched several tutorials to warm myself up about the process of rigging a human. It is been a while for me to rig again. And if I acted more actively, I probably would get into design team and help promote our game. But anyway, I got enough time for our project in this quarter. I am kind of satisfied with my work~

Week 11 – Post-Mortem Swat the Bug

This was an interesting experience for me because I had never been part of the art team on a game project before.  I felt pretty confident that I knew what I was doing but then quickly realized that there was still a lot to learn.

WHAT WENT RIGHT

I think the slack channel was really helpful.  The communication was helpful and everyone was pretty good about answering quickly.  Once we had Saturday Scrum meetings, things got off to a very quick pace.

WHAT WENT WRONG

I think if we knew the art direction a bit sooner, we could have gotten things off to a better start.  There was a communication gap early on beforehand but we solved this issue in the middle of the quarter.  I wish we could have included more game mechanics but we didn’t get those finalized fast enough.

WHAT I LEARNED

I learned more about Scrum.  I had done it previously in a project but I think the lecture and the experience really helped solidify the ideas behind Scrum.  I definitely learned more about modeling and learned about Maya’s new UV tools.  I’m glad I was able to use those instead of Headus.

As far as what I would change for the future, I will definitely communicate more and double check my work more often.

WEEK 11 – POST-MORTEM

Overall, it was a good experience. I really enjoyed working on art and the initial conceptualization of the game.

WHAT WENT RIGHT

I liked the fact that the team met regularly, and as much as possible, we tried to be on the same page at all times. Earlier on, the communication between all units wasn’t as effective, but, down the line, we were able to communicate better and that was good. Also, the game environment has a fairly polished look and feel, thanks to those who worked on modeling, texturing and lighting, it turned out looking nice, not withstanding the short period we had to create all the assets. Also, working on creating the GUI elements was fun.

WHAT WENT WRONG

I think we would have made a lot more progress if we had known much earlier exactly what our game was. It took us a lot of precious time to get to that point, and I feel like If the game design goals were communicated effectively across the board, much earlier, we may probably have had a more functional prototype than we do now.

WHAT I LEARNED

Scrum! This was my first time of actually seeing this development methodology in action and being part of a team that used it, and this is one of the huge takeaways from in this class. I think it’s a very effective way of keeping track of managing multi-disciplinary design projects. In the future, before working on any project, individually or as a team member, I’d definitely be asking , “What development methodology would be most suitable for this task?”. Also, the Silicon Valley clip that was shown in class made me fall in love with the series and aside the occasional vulgarity here and there, I’ve actually learned a lot from it.

Also, the importance of Team Communication at all points in the development pipeline proved an important lesson on this project. Things started moving forward quicker, once we started communicating more effectively. I’d definitely keep this one in mind moving forward.

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 – Construction

This week has been a very stressful one. I’ve spent my time assigning sounds to weapons, found or edited a couple of new sounds, defined the mass for objects in game, finished the ambient sound script to play three random city sounds at random times, fixed colliders before handing it off to Ning (thanks Ning!), and brought in any remaining materials or game objects. Did some last minute additions like having the paintings be attached to the wall via hinge joint…and will soon be removing or fixing those.

• Sound Implementing (3 hours)
• World object fixes (2 hours)
• Object mass (0.5 hours)
• Sound editing (0.5 hours)
• Work meeting (2 hours)
• 

 

Positive

It’s strangely satisfying to import and assign assets. I’m very proud of the art team and their hard work over these past few weeks – the game, though buggy, looks fantastic. I appreciated Ning keeping us updated as he added rigidbodies to objects.

Negative

It’s unbelievably frustrating that many issues we’ve strove to resolve keep rearing their ugly head. Jal is overworked. The game seems to be so close to completion, but is also looking like a pipe-dream at this point. Additionally, the lighting needs to be addressed. It’s been weeks now, and the dynamic lighting still does not work correctly. Sleepy has his animations now, but his hair and nose are clipping with the camera. [Insert aspect of the game] is broken and needs to be fixed.

Solutions & Suggestions

I don’t know how, but there has to be a way to help relieve Jal’s workload. Try to stay positive.