A. In the project review document, start by addressing these main questions
1. Game concept: How and why did your game concept change from initial concept to what you implemented?
- Our game concept did not change very much. We set out to do a kart battle game and ended up with one.
2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
- [Nico] Our initial design entailed armor power ups based on an element/color but we wound up going with random element/color assignment on spawns due to time constraints. The system works out well as players are forced to adapt to their element accordingly. There were also a few items that didn't make the final cut such as a ghost item (drive through walls and be invisible) and a bomb weapon which no one really knew what it should do.
3. 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.)
- Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.
- [Nico] And heap corruptions.
B. Then address these more general questions
1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
- We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities throughout development and provided a way to see what other people were working on. This works out best when all members of the team update. General gameplay decisions were based on votes during meetings.
2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
- [Nico] Memory management mainly. Working with the audio meant attaching sounds to objects that would eventually got destroyed so keeping track of which sounds should be released was a bit painful at first.
- [Amer] I thought that the collision detection would be easier but it ended up taking a lot of resources and I had to remove a lot of my optimizations due to the a speed of the Gatling gun bullets. If I had to do it over again, I would probably implement some different type of hit detection for fast objects.
3. Which aspects of the project are you particularly proud of? Why?
- [Stephanie] Particle systems because they make everything beautiful.
- [Nico] The auditory chaos when 4 players are trying to blow each other up!
4. What was the most difficult software problem you faced, and how did you overcome it (if you did)?
- [Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).
- [Stephanie] Debugging shaders. General debugging approach was to pass in hard coded values to shaders and drew a giant red line in the middle of the world if expected values were received. For whatever reason, some tricks used in tutorials did not work in our code and it took a while to figure that out...
- [Nico] Performance for the audio engine. Since all the sounds in the game are 3D sounds updating every sound all the time was very expensive, so implementing the logic for when, where, and how a sound should play was often frustrating.
5. 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? Finally, 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.
- We counted the lines of code per-project, using this command in powershell:
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count
- Leaving us with this result: (after subtracting out 2 library files)
AudioEngine: 673 Client: 3837 CollisionEngine: 148 GameLogic: 10400 GraphicsEngine: 15830 InputEngine: 552 NetworkingEngine: 774 Server: 1141 Shared: 2659 ----------------------- Total: 36014
- [Welander] Note that collisions logic actually resides in the server, and the collisionengine is unused.
6. In developing the media content for your project, you relied upon a number of tools 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?
- Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop
- Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax
Creating a Model
- 1) Create your model in ZBrush and save it in the default file format for further editing.
- 2) Export as an OBJ file.
- I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.
- 1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)
- 2) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd.
- 3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.
- 4) On the left hand side click Material and pick MatCap White.
- 5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.
- 6) Click on UV Map under Polypaint on the right and select your texture resolution.
- 7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.
- 8) Click on Texture Map under UV Map. Click Create -> From Polypaint.
- 9) You can now export to an OBJ file again using Export.
- Preparing for import into the game engine:
- 1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.
- 2) Export as an OPENCOLLADA *.dae file
- Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.
- 1) Edit your poly. Go to Hierarchy -> Affect Pivot Only
- 2) Rotate the gizmo so that Y is up.
- 3) Export as Autodesk COLLADA.
- 4) Import COLLADA file.
- 5) Export as OPENCOLLADA.
- We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.
- [Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.
- 0) Buy fancy headphones since you are the sound guy now.
- 1) Download free sound clips.
- 2) Edit it down to what we needed (make a loop if necessary) in Audacity.
- 3) Load into game using our asset manager.
- 4) Attach sound to an object or event in game.
- 5) Explode peoples' ears during the demo.
7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch?
- From scratch.
- [Nico] From scratch was awesome and it will be fun to take advantage of pre built engines as well!
- [Amer] I liked it from scratch.
8. For those who used a networking library (e.g., RakNet), 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 did not use a networking library.
9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
- Separate client game logic and server game logic. We have a shared game logic library where the files have mixed client-side and server-side code and it can get gross.
- Test in release mode throughout the last week so we don't have heart attacks throughout the hour before the demo.
- [Nico] Test the audio more with the mega speakers!
10. Which courses at UCSD do you think best prepared you for CSE 125?
- [Welander] I would say Math 155A
- [Stephanie] CSE 167, CSE 110
- [Nico] CSE 190 (3D UI)
11. What was the most important thing that you learned in the class?
- Managing and designing large scale software system.
- Need more C++ in the cirriculum
12. Please post final screenshots of your game on your group pages for posterity.
C. Finally, if you wish, I would appreciate any feedback on the course
1. 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?
- Introduction to 3D Game Programming with DirectX 11: Implementing particle systems using stream out to efficiently support many particle effects.
2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?
- Make your schedule as free as possible.
- Communicate frequently both in person and online.
- Meet and work together in the labs.
- Try to work in at least pairs.
- Plan a few quarters ahead to lighten your course load for spring quarter.
3. How can the course be improved for next year?
- Encourage groups to have structure so that decisions can be made with certainty and increase accountability.