General Questions

Game concept: To what extent did your game concept change from initial concept to what you implemented? If it did change, how did it change and why?
  • VB - This was what I imagined our game to be.
  • LC - Initially we thought that there would be much more gondola action - steering, gondola to gondola combat, etc., but it ended up that the we traded away most of the time spent in the gondola for exploring around floating islands, player combat, and playing with balloons.
  • MK - I imagined more balloons, more gondola combat, more weapons, and less floating islands. The overall game concept of collecting balloons and flying in a gondola stayed the same though (other than the game objective, which we never really committed to early on).
  • KL - We got the base of the game that I imagined it to be but a lot of the extra planned gameplay elements didn’t have enough time to be put in. Also i thought that there would be multiple players controlling the gondola but only 1 person did in the end.
  • BT - I didn’t expect the gameplay arena to be mostly horizontal; I imagined that the game would mostly involve the players going up, abandoning the starting area altogether.
  • NW - Our game was, at least in my mind, supposed to be composed of two stages: collecting balloons and then the rest being in the gondola fighting the other team. A lot of this changed because we needed ways to balance gameplay as well as to add different features like pvp fighting.
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
  • VB - Our final project design has a lot more extra stuff such as weapons, pvp, and capturing islands. These were added on after our initial design was finished.
  • LC - Our initial design for the game was pretty cutesy, and it ended up being that way, but we didn’t have an initial idea for what the gameplay would be like. We just created the gameplay to suit whatever mechanics we were able to implement in the game.
  • BT - we initially had a lot of ideas for how to balance the game (more balloons at certain times), along with fun gameplay mechanics (“steering” the gondola by animating a giant fan), but we scrapped nearly all of our ideas by the end of the quarter since we were pressed for time.
  • KL - Thought there would be more things going on but a lot of ideas were scrapped because of time.
  • MK - Our initial design didn’t have as much of a focus on player equipped weapons, but we ended up having them since they were straightforward to implement after getting bullet to work. Also, player health was a last-day decision.
Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.)
  • VB - Lagged behind pretty much every week. Had a very optimistic projected schedule in terms of finishing a whole base game within 2 weeks. However, not having our final gameplay decided and documented until week 5 definitely slowed our productivity.
  • LC - The networking infrastructure didn’t take much time to do. We just implemented it week 2 and 3 and it pleasantly slipped into the background as we worked on other stuff. We definitely lagged behind on our gameplay mechanics, as we spent a lot of time working on building the engine and adding smallish features that gathered enough of a critical mass around week 7 to begin implementing gameplay.
  • NW - Figuring out gameplay and bugs played a large part in delaying our schedule. I think unfamiliarity with tools for modeling/animations and libraries like Bullet took a large chunk of our time just to understand.
  • BT - Original schedule was very optimistic. After a few weeks in we were already behind, likely because all of the components of the game (physics, server-client coupling, modeling) all took longer than expected.
  • KL - Original schedule was optimistic. I felt like things started slowing down heavily by week 4. Also, we didn’t finalize how the game would be played for a long time.
  • MK - Everyone’s saying the original project schedule was optimistic, but this is only true for physics. The only major slowdown we had was with integrating bullet physics as this took a while in and of itself in addition to having to backtrack to reimplement character and gondola movement. Otherwise, we were actually pretty ahead of our initial schedule, but our schedule did not reflect everything we wanted to do in the course (we didn’t even have level editing or shadows on it).

Specific Questions

What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
  • VB - we had none lul
  • LC - We were pretty laid back about making decisions as a group, so it was a pretty collaborative process where we just suggested ideas until something stuck. For our software development, we didn’t have code reviews, and that resulted in a lot of surprises for how we thought each other was going to implement some feature, or how we used each other’s interfaces/implementations. This made for some messy code pretty fast.
  • NW - I think we should have had more group meetings where we updated each other on what we were working on and when we would finish them. Another thing is that we should have tried to work together in person more often and kept each other accountable for stuff that needed to be done so we wouldn’t need to worry/stress as much.
  • BT - We didn’t really use a software methodology. We did use git, but we used it haphazardly by making excessive merge commits, confusing commit messages, and very large commits, which made it difficult to track bugs and parse the project’s history. Most of us worked solo or with one or two other people, which worked well for most of the quarter until it came time to combine everyone’s work. Because we didn’t meet often, we didn’t know how to properly integrate our code with the rest of the codebase.
  • KL - I don’t think we used any. We all had like a section of the game and we did all those things solo.
  • MK - Our group meetings weren’t the most fruitful, but I think it’s just because everyone knew their objectives and there wasn’t much of a need to collaborate between roles. Although it didn’t bother me personally, our codebase was a mess which probably slowed productivity.
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
  • VB - Implementing Bullet Physics was quite difficult though I guess not really unexpected. Getting it started and working was surprisingly straightforward (on Macs) but getting what we wanted out of it was difficult due to the documentation being a little too succinct. ZMQ was a lot easier to use for sending/receiving messages than I thought it would be and we faced pretty much no issues after the first 2 weeks with ZMQ.
  • LC - Keeping different components of the server separate from each other became a nightmare. Our physics code became so important to the gameplay that it generally pervaded to all corners of the server infrastructure, and at the same time everything started being implemented in the physics handlers. Keeping this implementation clean was much more difficult than expected, and we didn’t have enough time to do so anyways. Networking was far easier than expected. We plugged zeromq in, and wrote some simple structs and handlers to transmit messages, and that was it.
  • NW - Bullet and just collision response stuff was particularly annoying for me because it would be hard to debug or know what to use. In terms of modeling, it was definitely a steep learning curve but once I got used to the tools and hotkeys, things got a lot simpler. Lastly, switching everyone’s code over from Mac to Windows was terrible… it took ages to figure out why it didn’t work in the first place and there would be tons of uninitialized variables which would break the game.
  • BT - Graphical features like the UI and camera were fairly simple to implement, but near the end of the quarter some subtle graphics bugs popped up which were difficult to find the causes of. We had a shadow map implementation by week 7, but our world was so large that we had to use an advanced shadow map technique such as cascaded shadow mapping for shadows to properly work; in the end we were crunched for time, so shadows never made it into the game.
  • KL - Physics and modeling turned out to be so much more difficult than i thought it could be. Tutorials were pretty hard as well. Audio via FMOD was surprisingly easy to understand on the other hand.
  • MK - Hands down the biggest surprise was the difficulty of rendering the balloon strings. I thought it would take a few hours at most, but I went down a rabbit hole learning about and trying to implement catenary curves only to find out that it involves approximating a transcendental equation and i don’t even know what that means. Animations took a while, but that wasn’t really unexpected. Everything else took about as long as expected.
Which aspects of the project are you particularly proud of? Why?
  • VB - idk i didnt do much
  • LC - I like that the way we set up the networking, we didn’t have to think about it too much. I’m quite proud that our game is cross platform - we developed on Linux, macOS, and Windows, all at the same time.
  • BT - Our game’s title screen and HUD elements look really nice.
  • MK - animations!
  • KL - I like the graphics to the game
What was the most difficult software problem you faced, and how did you overcome it (if you did)?
  • BT - Trying to implement cascaded shadow maps was pretty difficult. I gave up.
  • MK - animations were hard to debug at first. I had to print out matrices and stuff
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.
  • VB - 32,139 total from Github contributors
  • LC - final count 11057 lines of code using `find . -name "*.[cpp|h]" -type f -exec wc -l {} \; | awk '{ sum += $1 } END { print sum }' "$@"`, in our source tree, and manually excluding one header file that we imported into the project from an external library.
  • BT - I personally wrote about 6,064 lines of code, according to GitHub (excluding starter code, such as Makefiles and the GLAD source file generated from the webservice).
  • KL - Using the line count extension on vscode, It looks like I wrote about 1424 lines of code.
  • MK - ~6K

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 in future years 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?

NW - I used Maya for modeling/texturing the characters and the terrain which turned out to be pretty good. It has decently good documentation and video tutorials and it comes free to students with a .edu email so I would definitely recommend getting it before graduating. I watched a couple videos on Youtube which got me started and then I got a bit more familiarized by just experimenting. As for texturing, I used the UV mapping (cutting/splitting along different sections to allow clear color differences and mostly mapping with the ‘Automatic’ option) and colored those in using Gimp. To export, I used the .obj format which was familiar to our graphics crew as well as .dae (COLLADA) which was better for animations.

MK - We had a fairly basic toolchain for loading models, scenes, and animations which comprised of stb_image for loading images, Assimp (v 4.1.0) for loading models and animations, Blender (v 2.79) and Maya for modeling and animating, and a blender add-on called ‘better collada’ for exporting animations from blender. Here’s a summary of the workflow for modeling, level editing, and animations:

Models - create a model in blender or maya -> export as a .obj -> load the model with Assimp and extract info from the Assimp structs for openGL rendering within a ‘Model’ class -> draw the model with a shader depending on the model’s use of textures and/or animations.

  • we had some issues early on with model lighting. When modeling, display the vertex normals and make sure the faces are in the right direction.
  • export the models as a triangular mesh, but if you’re using Assimp, you can also set a flag to have it triangulate the model when it loads

Animations - create or load a model in Blender -> create a rig for this model -> make one or more animations for this model ->export the model as .dae using the ‘better-collada’ exporter -> load the animated model with Assimp -> render the model with a shader that handles animations.

  • better-collada is used because blender’s default collada exporter can only export one animation
  • assimp will only parse the collada file into its structs. You still have to handle them and implement the bone transforms and shaders yourself. Luckily, this tutorial can get you most of the way there http://ogldev.atspace.co.uk/www/tutorial38/tutorial38.html
  • there are plenty of tutorials for rigging and animating in Blender
  • all animations were done in Blender

Level Editing - We only needed to be able to place objects around in a 3d world and export their transform data which we could use to load them into the game. To do this, we had a simple, but sort-of specific protocol where we load objects from a ‘scene file’ which was just a list of to <4x4 transform matrix> mappings. The bullet-physics collision volumes were hardcoded for each object type for ease of implementation, but if we needed more complex volumes, we’d probably store this information in the scene file as well. The scene itself was all designed in Blender, but I wrote a Blender script to export the position and name of each object into our scene file as opposed to exporting the entire scene to a collada file or something similar. This is mainly to allow the use of instancing and for easily setting the position of game objects.

Would you have rather started with a game engine or would you still prefer to work from scratch?
  • LC - Still would rather write the game engine from scratch.
  • NW - I would say from scratch because I feel like I learned a whole lot more than I would have had we used a game engine.
  • BT - I would have rather started with a game engine. No need to reinvent the wheel, and we could have focused on the game instead of wrestling with Bullet and strange graphical bugs.
  • KL - I would have rather started with a game engine until i know that one of the game engines out there isn’t what i need.
  • MK - For future work, it’d probably be better to start with a game engine (especially for prototypes), but this class should definitely be done from scratch. If anything, I feel like it’d be easier to pick and use game engine features with the new insight on how they might work. Maybe there should be another class that uses a game engine?
For those who used a networking library (e.g., RakNet or Boost), a physics library (e.g., Bullet), or a GUI library, 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?
  • VB - after using it for a quarter, we learned quite a bit about these libraries and I personally think that once you know how the code works, it definitely saves a lot of time if your game is an open physics world and you want your game to look fluid within the given time frame. Even though Bullet made me want to cry, I think our game turned out better than it would have if we didn’t use it. ZMQ was easy and straightforward but I don’t think it would be too difficult using your own for that either.
  • LC - Using zeromq was a really good decision, although it took a lot of documentation digging to get it to work correctly on the messaging pattern that we wanted (ROUTER/DEALER), with the server as the router and clients as dealers. We got client IDs, async send/recv, message buffering, and easy reconnections for free. As for Bullet, I would probably use a simpler physics library that was not focused on being so big and complete in terms of its features. It seemed that it was geared for physics simulations, not games that use physics. It would have been nice to generate the collider shape at modeling time, and not at runtime, too, though I don’t know what tools we should have used for this.
  • NW - Although Bullet was a pain, I think it was also nice to have used because of the features it comes along with. Especially in our game with all of its colliding objects (balloons, characters, multiple terrains, projectiles, and scenery). A simpler engine would also have sufficed, but we decided to use the most popular.
  • BT - Because our game has a very particular aesthetic, I think it was worth rolling our own GUI instead of using a GUI library.
  • MK - Bullet was a nightmare, and we should’ve just done physics ourselves
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?
  • VB - It’s challenging to get everyone together at a time because everyone has different schedules. There’s a lot of ups and downs but communication is definitely key since you need to understand other people’s code in order to make sure yours fits in properly.
  • LC - Everyone has their own vision for the game, and it’s important to incorporate everyone’s ideas to keep them happy. This can start breaking down where each member might have their own pet feature in the game engine that they’re working on at the detriment of the project, and it’s important to recognize when this is happening. Another thing I learned was that it was impossible to foresee our group’s different coding styles and philosophies, and by the time we saw each other’s implementations and interfaces, it was too late to change/argue over what was already done. Perhaps the best thing to mitigate the shock of seeing surprising ways to implement stuff is to agree on a common interface for major structures, and sketch out how structures will share their data/interact with each other. This would be a pipe dream, though, and I think the best middleground for this issue would be more time spent in the labs communicating about how we would implement stuff. At our group meetings, it was easy to talk about which features we wanted to work on, but we didn’t have the hard conversations of talking over the actual code.
  • NW - I learned that everyone really has to pull their own weight because sometimes other people might not have the opportunity to learn/understand your code. Working together and making sure everything functions correctly is also something that can get easily neglected. Everyone’s schedules are vastly different and we have different priorities, but this class should still be one of them.
  • BT - I learned that we should have pushed for a minimal working game earlier instead of working on bits and pieces and putting it all together at the end.
  • MK - It was interesting to see how different coding styles, opinions, and design philosophies clashed together for this project. Even though much of this probably could’ve been mitigated early on by ironing out the initial project structure, game design, and style guidelines, I actually feel like this slight conflict yielded some valuable life lessons. I’m sure we all have complaints about each other’s work, but part of the experience is dealing with these conflicts maturely, so I’m glad we have this experience whereas in other classes, people wouldn’t care enough about the project to be affected by differences in programming philosophy.
Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
  • VB - Make group meetings more successful so we can get work down early on.
  • LC - I would perfect the client/server pipeline early early on, before too many features got implemented. It was ugly to remove code on the client that was used to test out graphics or some other features but was also introducing additional state into the game that the server wasn’t keeping track of. The sooner we can get the server to tell the client to do /everything/, like loading in which models, animations, shaders, gui elements, at different points in the game world, the better.
  • NW - Have more group meetings, work in the lab more often, and write better codes.
  • BT - I would have had code reviews from the beginning so we don’t have to spend a lot of time debugging janky code near the end of the quarter.
  • KL - Work more in the labs and maybe have more meetings.
  • MK - I might be alone on this, but I would abandon bullet and roll our own physics.
Which courses at UCSD do you think best prepared you for CSE 125?
  • VB - teamwork
  • LC - group dynamics in a large software project.
  • NW - Having fun and trusting one another
  • BT - Learning about all the things we need to put together a relatively simple game
  • KL - How much stuff actually goes into a game and how complex it is
  • MK - git, ssh keys, teamwork, time management, lots o graphics

Optional Questions

What advice/tips/suggestions would you give students who will take the course next year?
  • VB - Start small and work your way up. Don’t worry too much about all the crazy mechanics you want in your final game early on (although definitely write it down somewhere). It’s much easier to add new things to a working game than to create the final game all at once and wondering which part is causing segfaults.
  • MK - follow your heart!
How can the course be improved for next year?
  • VB - I would have liked if there was more interaction between the groups during the course. Felt pretty isolated between groups, even though we would often see other groups in the lab. Hard to ask for help when we’ve never met the other groups. A midpoint demo might have been cool too to see how all the groups were doing (maybe like week 6/7) and could have possibly helped motivate groups to really get that base game done by the midpoint.
  • NW - Definitely communication between the groups. I felt like we never really had the chance to check out each others’ games or to help one another out. One example would be when people posted on Piazza asking for help and no one really responded… It also would have been nice to see where we were in comparison to other teams too or how they were doing certain things.
Final comments and feedback:
  • VB - Luv u Voelker. Thx 4 the gr8 class.
  • NW - Honestly one of the hardest but most rewarding classes I’ve taken. Definitely worth all of the time and healths though!
  • same
  • same
  • same
  • same