• Type
  • Player vs. Player fantasy game where each team of mechs (vampires/crusaders) is given a certain objective to complete in order to win each round.
• Goals
  • Attacking team objective: Have most kills before time is up or kill all members of the other team while all shrines are in possession
  • Defending team objective: Have most kills before time is up without being completely slain during enemy team all-shrine possession
• Unique aspects
  • Daytime/nighttime will apply certain effects to each team. Daytime: extra bonuses for crusaders and persistent health diminishing for vampires. Nighttime: extra bonuses for vampires and restricted vision range for crusaders
  • During a night-round, crusaders will be attacking with all shrines initially belonging to the vampires; if all shrines are in possession of the crusaders, vampires cannot respawn
  • During a day-round, the vampires will be attacking with all shrines initially belonging to the crusaders; if all shrines are in possession of the vampires, crusaders cannot respawn
  • 4 rounds of day/night rounds, if tie, 5th round will be a twilight deathmatch where the only objective is most kills within the time limit
  • Villagers can be eaten by vampires for certain buffs
• Features
  • REQUIRED:
    • PvP Combat, multiplayer over a network
    • Procedurally generated buildings
    • Light sources
    • Shaders
    • Animation
    • Parsers
    • Culling
    • Basic models and art
    • Basic sounds
    • Basic music
    • Health and damage system
    • Logic for day/night rounds
    • Unique features and game objective implemented
  • WOULD BE NICE:
    • Advanced graphics and rendering
    • Fancy splash art
    • Pretty UI/typograhpy/layout
    • Advanced/different maps
    • Slight player customization (different color armor etc)
    • Additional spontaneous roles during the game
    • Optimization
  • STRETCH:
    • Custom music
    • Easter Eggs
    • Mini-bosses for bonuses during rounds
    • Some form of in-game communication
    • AI for towers/shrines/villagers
    • Detail in map (food on tables, bunnies in grass etc.)
    • Some UCSD reference inserted like a giant Voelker miniboss

• Management Roles
  • Wesley Lau - administrator for the Trello board
• Decisions
  • Decisions will be make on a consensus basis. If any contention occurs, the majority opinion will persist.
• Communication
  • Facebook chat/group
  • Lab meetings
  • Trello organization board
• Milestone tracking
  • Milestones by week will be set using a Google doc for scheduling
  • Each week, the Trello board will be populated with scheduled tasks for that week to track any schedule deficiencies
  • Any schedule-slips will be reallocated to future weeks and evaluated to prevent future slips
• Weekly reports
  • Group reports will be generated in a team meeting in the lab
  • Individual reports will be written by each respective person before the group report is created
  • Jesse Qin - compiles and pushes all reports to the website

• Development Roles
  • GAMEPLAY: David Wang [lead], entire team
  • GRAPHICS: Hubert Hsiung, Wesley Lau, Michael Mullen
  • NETWORK: Yuhong Hu, Jesse Qin, Brandon Ustaris
  • GAME LOGIC: Yuhung Hu, Jesse Qin, Brandon Ustaris
  • ART: David Wang
  • WEB: Jesse Qin
• Tools
  • Maya
  • Blender
  • Visual Studio
  • Photoshop
  • Gimp
  • OpenGL
  • XCode
  • Google Drive
  • Trello
  • Dropbox
  • Github
  • Garageband
  • Reaper
  • Audacity
• Testing
  • Unit tests for back-end (especially parsers)
  • Toward the end, play-throughs of the video game
  • User testing with people outside of the team
  • Shader testing
  • Server testing
• Documentation
  • Documentation will be initially recorded in a Google Drive
  • Official documentation will be on GitHub as well as the website

• High Level
  • Week 2 Milestone
    • All graphics using unified classes
    • Model animation planning setup
    • Successful packet communication between basic client/server
  • Week 3 Milestone
    • Connect back-end and front-end on the same computer
  • Week 4 Milestone
    • Connect back-end and front-end over a network
  • Week 6 Milestone
    • Baseline (core features) back-end game loop and client/server complete
    • Baseline font-end graphics complete
  • Week 7 Milestone (BIG milestone)
    • Baseline game complete and playable over a network
  • Week 8+ Milestone
    • Improving graphics
    • Optimization
    • Testing
• Weekly Detail
  • Click here to see Google Spreadsheet

GOTO: WEEK 2 WEEK 3 WEEK 4 WEEK 5 WEEK 6 WEEK 7 WEEK 8 WEEK 9 WEEK 10

• We originally planned on having humans in the game for the vampires to feast on and have the crusaders protect them, but due to time constraint, we couldn't implement this feature. Another major feature that we didn't add from the initial concept was having different weapons that you could pick up; we ended up resorting to having a few default attacks that players could cycle between to reduce the complexity of implementation. Lastly, we originally intended on having multiple shrines to capture as a core mechanic of the game, but resulted to only having one that provided a hub for healing. Overall, the initial concept of the game was a lot more complicated and intricate than what we ended up producing. This was likely because we underestimated how much time it actually takes to add, test, and debug new features. Overall though, we followed the baseline game concept with Vampires vs. Crusaders and changing bonuses based on daylight/nighttime.
  
  Another note was that our initial game concept wasn't as concretely laid out as it could have been. We sort of pooled together a lot of things we thought would be cool, but didn't necessarily filter things out appropriately to set out a strong baseline achievable concept.

• Our initial design was very fuzzy, not very well defined. The reason for this was that all the team members constantly pitched in ideas that made our game seem cooler, but there was just too much ideas to get a good sturdy design in place for our game. Thus, our final project contained a portion of our initial design, but definitely not even close to the full image we had in mind for our game.
  
  Initially, we only came up with general concepts of vampire, crusaders and humans, but we never really defined them. We went back and forth from initially making them all melee to defining vampire as primarily melee and crusader as primarily range.
  
  On the art side, the vampire and crusader mechs were roughly the same as I imagined. Compromises were made in terms of design and the amount of polygons that existed within each model. I would’ve liked to work more on the environment to fit a dystopian, ruined city vibe but rigging and animations took a lot of time.

• Overall, in terms of actual checkpoints. We were doing pretty well up until we needed to merge the back-end team with the front-end team. This was probably our biggest crux of the quarter. Once we had that roadblock, we ended up about a week or two behind schedule until the very end when we pushed the pedal to the metal.
• Mixed responses for this one!
• "We are probably pretty behind schedule since we had to pull so many all-nighters in the last 2 weeks, and the actual merging of code didn’t really start until week 6 or 7. We spent a lot of time trying to figure out ways to parse files (fbx animation is a nightmare)."
• "Actually, things were not too far off from our schedule. I was surprised because people tend to overestimate how fast they can get things done, but we held onto our schedule better than with most other projects I have been in."
• "I know a lot more could've been done"
• "Things speeded up a lot faster when we actually had a basic game implemented"

• We divided our team into front end(graphics) and back end(networking/ gameplay), which worked out pretty well. Some members had a little bit trouble using Git, but we managed to merge everything in the end and it was a great learning experience! Communication and helping each other out in a team is very important.
  
  As far as tools went, we all used Visual Studio. That was great because we could actually push the solution files for our project to github and so all the settings to make the project run smoothly were saved with our project making it easy to simply pull from the repository and run the game.
  
  Things that did not work out so well was working on different branches for a lonnnggg time constantly saying “we’ll merge it later”. When we finally had to merge, a lot of code had to be retyped and new bugs popped up.
  
  We also implemented an Agile methodology where we had a core idea but we were also flexible in terms of creation.

• For graphics, FBX animation parsing was the hardest to implement in my opinion (Wes did a great job implementing it). We originally tried to use Open Scene Graph to parse the fbx files, but we didn’t want to use OSG for our entire project, so we had to try to manually parse it, which was really troublesome.
  
  In terms of networking and the server, we initially thought that the tutorial on networking solved all our network problems, but it turns out that we needed to do much more to get our network running without bugs. We had assumed that a packet would always get transferred over in one piece, but it turns out it’s possible for a number of bytes to arrive that is not a multiple of the packet size. Finding and handling this bug was a real pain and was never completely solved.
  
  Server/Game logic was actually easier to implement than expected because we had assumed that we would need to deal with rotating bounding box collisions and such, but our game worked just fine by simply using our player's position and checking that with bounding boxes of other objects. In general, things could be simplified a lot more due to the simplicity of our game.
  
  For art, getting the models to work with the game engine was one of the biggest problems for since it required a lot of tweaking before we got something running. Something that would run fine in Unity wouldn't run correctly in our game engine for example.

• For graphics, Bump Mapping was a great feature. Not because it was difficult to implement, many members just simply never tried it before, and the result was pretty great, especially combined with Toon shading. We were also really happy when we got animations working because it took so long to figure out. Once we had that, we were able to add in the really awesome animations and models of the Mechs that David created. Our models were probably some of the most complex but it was so cool to see in the end!
  
  Another thing that we were proud of was that the game was actually fun to play. The real-time fast paced game with really unique mobility moves and attacks really added an aspect of skill and strategy to win - this ended up being really enjoyable. We really tried to be as creative as possible with how each character could be played and the result from that was something to be proud of.


• "I’m proud of my teammates for being able to pull this together, we never had reason to argue or fight and everyone had a great attitude. I love the models that I ended up with, and I feel like they can be even better. I feel like with the game engine foundation that was laid out, we’re now able to focus on detail and the environment if we were to keep working on it." <3

• For graphics, one of the most difficult problems was the different file formats we have to play with. For animation, as I mentioned above, fbx was extremely difficult to parse. We initially started with dae files and tried to move onto md5/md2 and 3ds. Even after we settled with fbx files, we have to decide on whether we should use OSG or not. For image parsing, we also shifted among Assimp, stb_image, and ppm parser.
  
  For the network, receiving packets turned out to be a real pain. After getting data to correctly show up in packets, we would find an occasional bug where health bars didn't match up on the different clients. This of course didn't make sense because the server sends the same info to all clients. It turned out that we were processing the packets in the incorrect order and so instead we reversed the order that we read the packets from our receive buffer which fixed that problem but then introduced a new one. There were times where a number of bytes would be sent which was not divisible by our packet size, so we would end up incorrectly reading ALL packets of that receive from the server loop and lose out on a whole cycle of updates from the server. This was particularly bad when this happened with initializing the game because then certain buildings would not show up or the game would not even start. We got around this by making sure we started at a place at the end of the buffer that was divisible by the packet size, but that means that we lost some packet data at the end of the receive buffer. We did not have enough time to fix this bug.

• C++ was fine since many group members were comfortable with the language. In general, the consensus was that life could have been made a lot easier if we decided to use a few more libraries and engines (particularly mentioned was a physics engine). We pretty much built things from scratch which was a great learning experience but limited the final displayable result in the end.
  
  As far as recommending for the future, we think that C++ is fine to use so we would recommend going ahead and using it. Before coding though, we would recommend doing some research on good coding practices in C++ to best organize your code before it becomes a giant behemoth.

• Using xargs in the git folder with all the code, the resulting number for lines of code turned out to be: 18152


• The command in particular was: git ls-files | xargs wc -l. We used it on both the client and server folders where all the code resided and subtracted out any lines from files that were not pertinent to the count.

• As far as the networking went, the back-end team was pretty pleased with Winsock.


• David Wang: Unless you have someone as good as Wes in importing Fbx files, I would probably stay away from that file format if you’re working in Maya. I found a way to export Md5 files from fbx files in blender with a python script, but that takes a little searching. I remember Md5 as being a much easier alternative, though by the time we figured that out, Wes already solved the fbx issue. .dae files cause bone issues in Maya and obj files are for static meshes only. If you do plan to export FBX files, animate in Maya LT through their game exporter. From there you’re able to export multiple “takes” for one model in one fbx file. This saves memory and time loaded in the beginning of the game. Running “select -hi” in Maya LT’s python script allows you to select all of the bones at once for keyframing. You’re welcome future animator.


• Wesley Lau: For graphics, animation was a pain to figure out. I first had an initial model loader that just got the static models to load fine, but extending it to animation was the frustrating part. Anyways, there is not a lot of documentation out there, but perhaps I will post up the code for our animation loader up online if any future 125 students want to see how our pipeline (code-side) worked. Here are the steps that I took after receiving the fbx model file from David:
  • Using ASSIMP, I loaded all the mesh, bone, and animation data
  • At least start drawing the initial mesh (bind pose)
  • Take the bone matrices of each mesh and apply the necessary calculation to animate them while running an animation timer
  • Draw onto screen using VAO or vertex3

• Most of us would have preferred to work from scratch from the perspective of a learning experience, though we all agree that starting with a game engine would have placed a lot more flexibility and focus on game design. So in the end, it boiled down to whether or not we were interested in implementing software or designing a game. As such, we had some mixed opinions.


• Hubert Hsiung: While I didn’t necessarily work with the game physics, I would still prefer to work from scratch since it teaches you how all these engines work (and I also have a strong hatred towards bullet engine). Also, with my experience working with other large scale game engines, the project will take too little time to finish with the convenience of these engines. On the other hand though, having a game engine will save the students a lot of time on implementation and instead will give them a lot more time on game design.


• Yuhong Hu: Well, since this class is about software design and implementation, it’s better to start from scratch, just to get the experience of building something from scratch. However, I do prefer to use game engines because I think maybe that’s how game is made nowadays. It will be another type of experience. Then the focus would be making games instead of building software. It really depends on what experience this course wants to offer.


• Wesley Lau: I would still rather work from scratch. The implementation methods are so unlimited and now that we have done it once, I feel more prepared to do it again next time. The way that we can design our system to be anyway we want versus a game engine is so freeing, although there are some challenges that stand toward an end goal. Given more time, we could have refined each part of our game.


• Brandon Ustaris: I was actually working on a Unity project while this was all happening and… I choose Unity. Using a pre-existing game engine just allows you to get things done so much faster. It allows you to focus on adding features to the game rather than fixing functionality with our self written code.


• David Wang: I definitely would’ve preferred to use a game engine for animation purposes. Though not many people can say their group created their own game engine, so it is definitely an accomplishment.

• Our team did not use any physics libraries. We think that animations could have looked a lot more real if we utilized one and probably would have saved time instead of figuring out some things on our own. Our game didn't turn out to be that physics heavy though so that's probably we why didn't opt in to use one. Openscenegraph would’ve been great from the artist standpoint since it made it a lot easier to implement world objects and lighting.
  
  As far as networking we would use winsock again definitely. It was easy to use but we just didn’t look into everything carefully enough which was the reason we got bugs. Moral of the story: Don’t just follow tutorials blindly!

• Meeting often is definitely a requirement, meeting way more than once a week.
• Everyone should learn git or some kind of version control; when many members are still having issues merging work because of that it slows down the pipes a lot. Should teach everyone how to commit and push often to avoid missing functionality and headaches with merging. Incremental change is pretty key.
• Every person should be assigned a specific role, more than just basic front-end/back-end/art teams. There also be a concrete group leader put in place at the very start to official make decisions and drive progress. Otherwise, deadlines become soft and he schedule lags.
• Communication is key!
• SPEND LOTS OF TIME IN THE LABS TOGETHER!

• A lot of us agree that we should have definitely reached the baseline game setup point a lot sooner; essentially, having all the pipes open with adding graphics, models, animations etc. into the server-client code. We spent way too much time early on working in separate branches and not experimenting with how things would merge together.
  
  We also should have done a lot more work at the beginning. The first two weeks were sort of wasted away because of a false sense of security... while 10 weeks seems like a long time, it's pretty short in reality for producing a quality video game from scratch.
  
  We definitely liked the way we split up the teams for work efficiency, but again making sure the different teams merged together earlier would have helped things out a ton.
  
  As far implementing models and animations went, we would have stuck with fbx knowing that we would eventually come through with a working importer. Modeling would have been a lot faster along with rigging and animating and thus there would have been more time to create assets for the world.
  
  I think the main lesson here in terms of doing things differently is to experiment with a pipes a lot and as early as possible in the quarter.

• CSE167, CSE165, CSE168, CSE169, CSE190 (Advanced Graphics), CSE120, CSE131, CSE110, CSE160A-B


• Wesley Lau: CSE131 compilers definitely helped prepare a lot. This course taught me a lot about design aspects such as inheritance that I could translate over to a lot of our client-side objects in 125. Also taking graphics classes like 167 helps jumpstart a lot of OpenGL knowledge (although you will end up learning more by implementing things for this class), depending on which library you use for OpenGL or DirectX.


• Jesse Qin: Wish I had taken some graphics courses like CSE167 before CSE125!

• The single most important thing we pretty much agreed on was working with a team to produce a huge project like a video game. This was far unlike any other group project in all other courses at UCSD and really teaches the true importance of teamwork. There was no way that we could have gotten anywhere without every single member working hard, contributing, and communicating with each other and that kind of experience is really hard to come by in a college course.
  
  Other mentions:


• More advanced GLSL functions and techniques
• Client/Server Communication
• Workflow for a game modeler, rigger, animator, asset creator and the necessities of working with other programmers.

• See Gallery!

• To add: http://gameprogrammingpatterns.com/contents.html
• Don't need to remove anything! The recommended list was really useful.

• Really hash out how you plan to keep their deadlines and progress in check, whether it is having a team lead or sub-team leads etc. We initially set out with a simple democratic everyone-checks-each-other system but it really wasn't concrete enough to avoid schedule lags.
• Finish game design early and stick with it, unless facing extreme technical difficulties.
• Decide what tools you gonna use and really study them in the first two weeks.
• Don’t make EVERYTHING from scratch. If someone has done it, use their approach.It will solve your problem. For example, I had a bug on circular dependency. All i did to solve the bug is to find examples that can avoid this error. Also, study the patterns (how people actually make a game loop).
• Expect to spend a lot of time, choose your file format wisely if you’re going the rigging route.
• Definitely recommended to take a graphics course beforehand!

• Thoughts from everyone:
• Good course, better presenters maybe... a lot of them had a monotone voice.
• The course could offer some base code/ example code instead of completely from scratch. We could read simple base/example code for network structure, game loop, objects, etc. Even if the group decided not to use them, it would be a great reference. I believe there are a lot of the works already done out there and we can learn from those examples.
• I don’t know… this was the best course ever
• I thought the course was fine, maybe go over the group notes of previous groups during the first week of class.
• I think it would be cool to have one or two mid-quarter type get together with all the groups to see how far everyone has made progress. This would help encourage everyone to reach the level of the furthest group and also stir some advice-seeking.

• Seriously the best class ever! Worth every hour work!
• Hubert Hsiung: Hi.
• David Wang: Rumspringa!!!!!!