Final Report

A: In the project review document, start by addressing these main questions:

Game concept: How and why did your game concept change from initial concept to what you implemented?

Oddly enough, the overall game concept stayed relatively unchanged throughout the quarter. We focused on creating a brawl-type game with hats that provided power ups and we didn’t steer away from that at all. Most of what changed had to do with the mechanics of the game (the type of fighting), and mostly due to time constraints. However, we would say that largely our game idea remain true to its roots.

Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?

The final project design turned out to be similar to our original design in many ways. Initially, though, we wanted a rag-doll like style of fighting but for various reasons (mostly due to the difficulty in implementing this functionality using Bullet) we decided against it. Some minor changes in the game design were due to time such as different map levels, moving objects within the level, and a payment system for DLC.
In terms of code design, the end of quarter involved violating a few design principles due to time constraints but we managed to stay true to our engineering principles for the most part.

Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any?

We managed to stay on track for much of the project. We had 2 major setbacks, once when our entire team was busy/sick for a week. Second time when the game logic team collectively hit a bullet learning curve barrier along with the graphics team hitting an animation learning curve barrier at the same time. Tiffany also encountered some issues with character rigging, which ended up taking a few weeks to solve. However that did not affect the overall progress of game development much. Other than that, most of our progress was really smooth and we were lucky to have had our down time together rather than separately.

B. Then address these more general questions:

What software methodology and group mechanics decisions worked out well, and which ones did not? Why?

Our main methodology was Agile development. It worked very well because we were able to have working functionality quickly. We iterated on what we liked and quickly dropped what we didn’t. Another aspect of our team management was breaking down the big group into two facets networking/game engine and graphics. We worked closely together, sometimes bridges were crossed but for the most part smaller teams allowed us to divide and conquer our tasks efficiently.

We let each sub team have the freedom to design their portion the way they wanted, with major decisions being discussed at our weekly team meeting, though we frequently utilized online communication tools (messenger and slack) as well.

Which aspects of the implementation were more difficult than you expected, and which were easier? Why?

Physics was way more difficult than we expected it to be. We have members in our team with decent understanding of physics, but the poor documentation of the bullet API was the main barrier to the implementation of physics. Setting up animations was also slightly difficult but mainly because of the relative new experience to rigging in Maya. What we found easier than expected was networking code. Our team had a pretty strong systems and networking background, and we fully working network code in the first 2 weeks. This was mainly because boost is a really well maintained networking library and easy to use if you’ve worked with asynchronous patterns before. Animation was also surprisingly easy, as most of them were done in a single night!

Which aspects of the project are you particularly proud of? Why?

Tiffany - Honestly I’m really proud of everything; everyone did an amazing job putting this game together. From an artist’s perspective, I’m happy that all the visual elements in the game are consistent in style. The bright lighting, vibrant colors, and UI really helped with creating a fun and cute look. In terms of my personal contribution, I am really proud of my animations. I don’t have much prior experience in animation, but in one night I was able to create about six smooth animations with no trouble at all!

Tim - I really proud of how the game came out overall. I’m really happy that the animation was able to appear in the game. At first, I was worried that we wouldn’t even have animation but once Tiffany got more familiar with Maya, we were able to include ten unique animations that made our game more fun and realistic. Then, once we added the hats into our game, it made our game complete. It was great seeing all the hats appear correctly on the players especially seeing the propeller hat spin when a player was flying. Overall, I’m happy on how the characters came out with their animation.

What was the most difficult software problem you faced, and how did you overcome it (if you did)?

Victor - Poor documentation. Bullet lacks any real documentation beyond class diagrams and a list of methods for a class. The most shocking moment of the quarter was when looking at a piece Bullet documentation we saw a method with a single line description. Victor was so shocked that he had to leave the room. We overcame this obstacle through sheer trial and error. The process we used was to describe at a high level what we wanted and appended Bullet Physics Engine to the end of the string e.g. “Controllable Characters Bullet Physics Engine”. Then we would traverse the sparse number message boards the query would return searching for examples. We would then modify these examples to suit our needs.

Tim - Getting animation to work was the most difficult. There wasn’t a lot of information on how to do animation especially with ASSIMP so it took a lot of researching to find out how to do it. To overcome this, I broke down the problem into two smaller pieces. The first part was getting the character to pose by using the bone data in the FBX file. Then once the character could be posed, I built an animation tree to try to get the character to animate. I worked closely with Matt from group two as we helped each other out to get animation to run in our games.

If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid?

We did not use any other language besides C++.
We did end up using some very useful libraries-
Client Side:

Server Side:Both:

How many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted.

10804 lines of code. Method: cat | wc
Approximately 6000 lines on the client side, 2000 on server side and 2000 util.

In developing the media content for your project, you relied upon a number of tools ranging from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere?

For modeling and animations, everything was done in Maya 2015 and the student version of Maya 2016, and exported as OBJ and FBX files. Everything was first tested in Open 3D Model Viewer to make sure models and animations looked good before going to the graphics team. Ultimately all model assets used were in FBX format. In order to get the textures for more complex and custom designs, such as the character model and the deerstalker, we created automatic UV maps and took UV snapshots in Maya. The UV snapshots are saved as PNG files and imported into Photoshop to paint before being imported back into Maya as texture color files. We learned that transparency in the texture file might make the model transparent and awkward, so future artists be careful! To model the character from 2D images, Tiffany drew orthographic views of the character (front and side) and imported them to Maya on intersecting planes. The intersecting planes act as guides for 3D modeling. Animations were done by keyframes, with the first and last frames the same for looping animations such as running and punching. Maya has a great rigging tool called HumanIK, which automatically generates a skeleton and an advanced rig for you. The rig helps the animating process smoother. However we had problems getting the HumanIK to load in Assimp so it’s safer to first manually create a skeleton with the joint tool. We were able to get animations with just the skeleton and no IK handles, though it does require a bit more attention to detail (ie. how would the rest of the body move with a lowered arm). Before animating, ensure the skin is bound to the right joints by checking the Paint Skin Weights Tool. Maya is a very advanced tool with a steep learning curve that caused many frustrations, but because it’s so widely used in the industry, the suffering was worth it! I expect a similar experience with 3ds Max and Blender so there’s no escape either way! [Tiffany]

OpenGL is implemented in C and is difficult to get used to as it is not very object oriented. It kinds of pretends to be object oriented, one example being that you make buffers that aren’t really objects but can somewhat be used like objects. It is also really difficult to debug and lots of this gets deprecated and one has to worry about versions. To save whoever reads this time, I strongly recommend using modern OpenGL 4.0, 3.0 being the minimum. This is because these versions use buffers which allows up to utilize the GPU. Even though there are lots of tutorials for the old OpenGL, you will run into difficulties later on if you try to do fancy shaders and lighting. We used GLEW and GLFW, which we installed with NuGet. I would also recommend installing OpenGL with NuGet because it usually guarantee that your OpenGL has been installed correctly. NuGet is the default package manager built into Visual Studio. Another reason to use OpenGL 3.0/4.0 is that the ASSIMP library we used to load models and textures in the game used modern OpenGL. This means that if you do not want to write your own parser to parse obj files, use modern OpenGL. It also helps you to debug ASSIMP when things do not work properly if you know how to trace through the OpenGL code and know how the buffers and generated and how they work.

Would you have rather started with a game engine or would you still prefer to work from scratch?

AJ - While I really liked working from scratch and I believe that’s how this course should work, I really want to work with a game engine like unity in the future. That would allow me to skip a bunch of common steps and the engine would be better suited towards game development with quicker iteration cycles.

Victor - It really depends on the intent of the class. If the intent of the class is to make a great game then an engine should be used. If it’s to learn about networking and software design then no. As long as students are expected to start from scratch there will be an upper bound on quality games that will be of the games made. If a game engine is used, however, the class essentially becomes a class on how to use a game engine.

Eduardo - I agree that that the game engine should be written from scratch if one of the goals of the class is to each software design. Otherwise, it just becomes a course in which a game is made.

Tim - The game engine should be written from scratch. Not only does the class allows you to apply everything you have learned, it allows one to be able to continue to learn and solve unique challenges that arise while making a game.

Cindy - I have worked with a game engine like Unity before and from what I learned from this class, creating the engine from scratch is that it teaches you better software design. In Unity, all I had to do to make a simple game was to create objects and write scripts and make the objects would interact with the world. Also Unity lets you “cheat”. Users can just download objects and scripts from the asset store. This is lazier and worse than using libraries because other users wrote them and there are many users do not write good code unfortunately. So not only do you not learn how to be a better software engineer, you become a worse one by mimicking bad coding from download scripts and probably bad tutorials. There are lots of bad tutorials online. I like Unity and I do still use it, but for a class where we have to use everything we learned previously, it doesn’t really provide much of a challenge or a learning experience.

For those who used a networking library (e.g., RakNet or Boost) or physics library (e.g., Bullet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect?

We used Boost Asio as our networking library and it was a really pleasant experience. We highly recommend its use especially if you’re familiar with any form of asynchronous programming. There were no major issues with boost, some minor configuration stuff like turning off nagle optimization and such.

To communicate over the network, we used Google Protobufs. The biggest benefit was the built-in code generation for the messages which reduced the amount of code that needed to be written and gave us the flexibility to modify our messages without much overhead. We would highly recommend future teams to use protobufs rather than writing their own network messaging code. The only real issue we encounter with Google Protobufs was the initial installation but no issues arose after that.

We used Bullet as our Physics library and it was a slightly rocky experience. Bullet has a high learning curve if you want to do anything more complex than basic rigid bodies in the world. Of particular annoyance was setting up proper character movement which is not very well supported by Bullet and we had to look at open source solutions to get a grasp of what to do. Overall, using Bullet was the correct decision as our game was heavily dependent on player physics and interactions. But our advice would be that if you end up using Bullet, to spend a lot of time reading the Bullet examples and playing around with the api through actual execution since documentation is scarce.

What lessons about group dynamics did you learn about working in such a large group over an extended period of time on a challenging project?

One lesson that we learned fairly quickly was the need for leadership. It was crucial that someone stepped up and guided the team towards the right direction based on the goals we came up with as a team. Even though our team was extremely talented and worked well independently, it was occasionally the case that some of us were unsure of where to go next or who to hold accountable for what.

However, we did a few things that worked well for us, such as organizing our development goals and managing our code development. We kept an issue board that tracked our progress as well as the things that needed to be done. As for code development, we used git and we made sure to follow git religiously in order to keep our code organized even if multiple people were working on different parts. Although both of these sound like simple things, they were crucial in keeping the focus on developmental progress rather than on planning and code cleanup.

Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?

Besides what was discussed above, one thing we could have done differently is concretely define game play earlier in the quarter. We spend most of the quarter refining the basics without exactly knowing how are game was going to work (we knew what we wanted broadly but we didn’t know the specifics). It wasn’t until the latter part of the quarter that we sat and discussed what we wanted.

We could have also met and worked together as a team more. That would have probably increased our productivity and overall output. We skewed to working primarily independently or in subteams.

One of the things we did very well in our opinion were to regularly meet and sync up as a team.

Which courses at UCSD do you think best prepared you for CSE 125?

AJ - CSE 120, CSE 123, CSE 124, CSE 130

Victor - CSE 120, CSE 123, CSE 105, CAT 125, MUS 95G

Eduardo - CSE 120, CSE 123, CSE 124, CSE 131

Tim - CSE 167, CSE 112

Cindy - CSE 167, CSE 169

What was the most important thing that you learned in the class?

Brian - The most important thing I learned in this class is getting work done with a large group of software engineers. Also, I came in with zero knowledge in networking, but now I have a firm understanding and experience thanks to my teammates who walked me through with patience.

Eduardo - Definitely the most important part of the class in my opinion is the ability to work on a large scale project with a large team. This class is the only class that I’ve taken here at UCSD that mirrors the workload and team management of industry or any “real life” project.

Tiffany - My major emphasizes the importance of collaborating with peers from different fields, and this class gave me that experience. Being able to find a common ground for discussion was really important in understanding what I had to do to get my art to the graphics team in the right formats, etc. Maya was also something I’ve always wanted to learn, as it is software that’s commonly used in the entertainment industry, and this class gave me the time to learn it.

Tim - This class showed me the importance of people with different specialties working together. This really emulated a “real life” project where we worked together and were dependent on one another in order to make the best product we could.

Cindy - Working with people is the most important thing I learned in this class. The project is too much for one person so it required working with people and well, working with people requires communication and compromise. It also requires patience.

AJ - While I had worked on large scale projects before, my role in those projects was usually well defined, and my work confined to myself. In this class, I got a much better chance to truly collaborate with other people and integrate our work together on a higher design level than I had ever done before. I prefer this style of collaboration more so than pair programming and I’m glad that it worked well.

Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.

Screenshots below:


C: Finally, if you wish, I would appreciate any feedback on the course.

What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed?

Eduardo - Look online for resources.

Tim -
Getting started with Opengl 4.0: learnopengl.com
Animation: ogldev.atspace.co.uk/www/tutorial38/tutorial38.html
Clouds: http://proceduralclouds.blogspot.de/2014/10/project-specification.html
Shader X4 (resource in cabinet)
Inspiration for Shaders: Shadertoy.com

AJ - I’m sure the books in the cabinet were helpful. I tried to look at some of the game design books and was quite honestly intimidated by the sheer complexity of those books. What I found much more useful were online tutorials on libraries we ended up using.

I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?

Eduardo - Be prepared for the class workload and be passionate about it. Collectively decide on what tools and libraries you want to use. There are a handful of good libraries out there that do the basics, use them (unless you are passionate about remaking them and your teammates don’t mind)!

AJ - For the server side people, focus on getting all the basic networking components done correctly first. For example, make sure you have networking working early, make sure your server and client can talk correctly at scale, make sure you have a good way to send events, etc. Ideally, if you have networking working flawlessly within the first few weeks, game logic and testing will be really smooth.

Victor - Inform them that bullet is not any easier than writing from scratch.

Tiffany - Since three of our designated artists this quarter are ICAM students: For ICAM majors who are also working on senior projects, manage your time well! Include time for dealing with problems on both ends. It really helps if you learn a bit about 3D modelling software and animation before the class starts. Also communicate with your team so you have a clear list of things to do.

Tim - Getting the animations to work was difficult especially since we decided to use OpenGL 4. There are a couple of things I discovered while getting the animations to work. First is using open3mod for checking if animation even worked and was rigged properly. With open3mod using ASSIMP, Tiffany and I used it as a way to check so we knew if we couldn’t load in open3mod, the model would not load correctly in our application. Also, referencing this helpful site for animation (ogldev.atspace.co.uk/www/tutorial38/tutorial38.html), make sure you send the bone transformations to the shader and let the shader handle the position transformations. Then, when making the animation tree, make sure, if you’re using the ASSIMP, that you store things such as aiscene as class variables since ASSIMP variable are deleted once they go out of scope.

Cindy - Work diligently early on, like what you are doing, and be nice, but willing to voice your opinions with your teammates.

How can the course be improved for next year?

Making it more clear to other classes that B220 is reserved only for 125 students. Sometimes tutors would have office hours in B220 making it sometimes impossible to find a computer to work on.

Any other comments or feedback?

Tim - Thank you for a fun and challenging quarter. Had a lot of fun while taking the class and learned a lot :D

AJ - Some software that I would recommend having pre-installed in the lab machines (These are things I ended up installing everyday when I came to the labs) -