Final Review

From Group 4
Jump to: navigation, search

Contents

Section A

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

Early on, we decided to concentrate on the main boss battle, thinking we would not have time for the mini-adventure (we were right).


In general, we re-evaluated our player composition in the middle of the quarter and then again in the later half. We originally thought we would only have time for one power (aka the cyborg power) but we re-expanded the powers to allow for 4 players.


With the player re-org and focus on the boss battle the boss became an amalgamation of simpler powers which could be foiled by simple tactics. Players still benefited from cooperation, but it was not necessary as we had originally planned. Initially, we wanted the players to feel overwhelmed by a single, massive beast that was all around the ship. However, our end product came across more as having many separate, smaller entities players had to defeat.


Simpler powers for both the boss and the players meant that there was less synergy between the players, especially in creating opportunities for players to create interesting combos.


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

With the character power reorganization, a main feature that was thrown out was that everyone would have an attack power and a special power. Because we did not define the power specifics (implementation details) and their potential combinations from the start, we had a harder time coming up with possible fighting strategies and combo moves later on. This prevented us from over-complicating the power scheme, and we decided to just do a single power per character. This resulted in lessening the synergy between players.


Our player abilities shifted as follows:

  • Cyborg: Stayed mostly the same, except for lacking an overpowered jump (everyone can jump and wall jump). We allowed everyone the capability for jumping because because it made the game a lot more fun.
  • Shooter: The main attack form became the shooting for the shooter, we removed the harpoon because lesser mobility was compensated by long-range shooting.
  • Mechanic: We first thought of sticking with two types of characters, and then doubling them to get four players. However, we ended up doing all four players instead. The original mechanic was too complex at this point in the quarter, so we moved the shooter’s harpooning ability moved into a separate character. We originally intended for the mechanic to have an attack on a separate button, but when we realized that the players were not going to have any attacks we needed to give the mechanic some attack form. We improvised having the mechanic double damage done to a tentacle because this would allow for more synergy between the characters
  • Scientist: Same as the mechanic, we did not think we would implement a scientist at all. However, once we had three players in, we wanted a fourth one so everyone could be different (instead of doubling one of the powers). To ease development and to show off all of the powers, in the last two weeks we decided to give the scientist a kirby-like power, allowing him to take on the powers of any other characters.


Art-wise, we stayed pretty consistent with the players. The monster evolved throughout the quarter, we kept bouncing between organic vs. mechanic, and towards the end basically went with the last one we implemented. The monster’s tentacles also weren’t as big as we initially thought nor were they grouped together to create a giant mass, which decreased its intimidation factor.


We also made the environment less complicated. This was done by getting rid of the gravity platforms, elevators, and reducing the number of moving platforms that we used. This did decrease people’s movement, but we balanced this out by making the monsters move towards the players.


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.)

At first, we had something very simplistic, just defining the different categories (networking, graphics, music, game engine, art, etc.). Then, every week we would go into specifics of what everyone had done in their area that week and what they were going to work on. If some area needed more people, we would shift around to accommodate that, but it was very improvised and changed week by week.


Once week 5 came around we realized that we needed more structure to our schedule (finding what specific tasks we needed to do, who knew how to accomplish the tasks, and when the tasks needed to be done by). This was particularly important because we had, at this point, a lot of features that were half done, and we wanted to change that. So, after week 5, we re-did a schedule every week to try to fit to the current state of the game and finish all that we had planned. We had weekly to-dos from the start, but now we would also have a sense of the time remaining to finish all tasks. This did not work out as well as we had thought, because we couldn’t stick to the re-created schedules either (hence the having to re-make them every week).


Week 7 we realized we were really behind, and we did not have a sense of what was left to be done, or what we were keeping or throwing out. So we created a subtask account where we could place all the features, categorized by type. This helped us all get a sense of the enormity of what was left. It really pushed us to move forward and continue implementing features (and finishing features we had started). It also forced us to re-think and state what features we were actually going to focus on implementing.


[Bryan] This is why visualizations are really helpful for organization - they helped us to create motivation.


Week 9 was when we finally play-tested the game. Leaving it so late was not a good idea, we noticed a lot of things we needed very late in the quarter. We decided to make a list of all the features/fixes and titled it “Making the game fun”. We then focused on working on that list, and somehow got most of it actually implemented before the demo! =D


Section B

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

We organized our group as an everyone-has-an-equal-voice democracy. This caused some problems. People made decisions on their own without discussing it with the group, designing the feature to fit their own vision. One issue with this was no one had a complete understanding of the overall system; each person understood how their own feature worked, and had no idea how to integrate it with the larger system. We had no designated integrator or architect, which led to inefficiency. Eventually Haro and Suman emerged as the de-facto integration committee, in order to integrate ideas. This resulted in some people’s work getting deprecated, but it helped the project move forward.


[Nathan] Fun fact: We answered these questions in the same manner that we built our project!


[Bryan] Another fun fact: Another way of describing what happened was that we became an anarchy!


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

[Franklin] Network was much easier than expected, if extremely limited. Connecting between the server and client was incredibly straightforward, given Ben Shokati’s guide to Winsock. The way serialization of data was implemented left a lot to be desired - it required much more hard-coding than I would have liked. Oddly enough, this didn’t introduce any significant problems (perhaps a slightly slower development time) other than not realizing that there is a maximum amount of data that the OS can hold before it starts to drop things.


The hardest thing to implement was the event manager that controls the world. In the end, I was able to implement small features that would alter the world state, but otherwise, the larger event management system never got fully implemented and we had to drop it in the end. This is mostly due to the anarchical nature of our system (and lack of communication/documentation).


[Nathan] Collision physics, on the other hand, proved harder than we anticipated. We couldn’t find a solution to non-AABB collision online, and we had no way of detecting fast-moving objects passing through thin, static objects.


[Haro] We also saw some lag in the game, whenever we had more than ~30 objects, and never fully figured out if this was a client or server issue, or if it was collisions or object management or rendering or something else.


[Suman] Rendering models was much easier once we started using the xAnimator library, however we never really evaluated if that was the best choice of library or if we should have taken the time to write our own loader and mesh hierarchy. Looking back, instead of trying to push to get model loading in quickly, I, Suman Malani, wish had taken the time to write my own model loader because I would have more insight on how exactly the rendering worked and would have been able to detect if the lag was from the rendering. Also, I should have attempted implementing shaders because that would have been cool. This being said, I haven’t taken a graphics course and I went into this class believing that the graphics should be done by a graphics person but I was able to pick up a bit of graphics.


[Michael] The implementation of audio in the game actually proved a little harder than expected. Even though we used the FMOD Ex audio library, the actual implementation of the engine into the game resulted in many strange and difficult bugs. Using the version of FMOD we chose made it essential to do all sound loading and playback management instead of relying on the engine itself to handle the audio assets.


[Bryan] In addition, given that we didn’t have an agreed upon plan or aesthetic or feel it was harder to make implementation choices in a manner that promoted transparency later on.


[Justina] Creating models took a lot longer than I thought it would, which ended up with us having to reuse the one character model I made for multiple players.

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

  • The player model was AMAZING! It really changed how the game looked, and made it seem more like a real, finished product. At the beginning, we choose DirectX 9 over 11 because we wanted support for animations and .X, and having the model in with all its animations really made that decision worthwhile.
    • [Haro] Look at its beautiful hair when it jumps and goes up and down!!! =D!!!!!! And the cape! It billows!!!!!!
  • Gravity Switching and the zero-G transitions. One worry we had that this would be a dizzying experience but the zero-G transitions made that easier :)
  • Music- The music fit the game really well, adding a lot of texture to the experience. The game improved so much the moment sound design was added, and the music shot our project to the moon.
  • Having collision boxes update and resize, and work even when the server did not know about the animations. [Bryan] It took a long time to coordinate, but was essential for the program to work.
  • Height maps! Height maps made it possible to have an awesomely slanted arena. Which added much needed interest to the previously rectangular box.
  • The head model!! It looked so awesome!!
  • Managing to get textures working and looking good on the model. Also, managing to rig up the model well enough that animations looked pretty good. :>
  • Start Screen [Bryan] I had the freedom to use whatever aesthetic I wanted, and selected one that really fit with the theme.


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

Physics. Just... physics. All of it. Things moving at what looked like a moderate speed were fast enough to pass through platforms, objects that jumped where the wall met the floor fell out of the world, and so on. We solved the falling-through-the-floor problems by making the floor and walls be heightmaps that extended to infinity, so they would always push you back into place. We couldn’t solve the fast-moving objects problem for other types of collisions, however; we came up with an algorithm that would calculate the nearest point on the object’s path of motion, but this never actually worked. We ended up just making collision boxes a little larger than they needed to be and prayed no one would notice. [Bryan] Our system detected if there was a collision happening instead of if a collision was going to happen in the future.


[Justina] THE MODELS CRUMPLING WHEN EXPORTING TO .X ARGH!!!! It was infinitely frustrating and wasn’t solved until Week 9 which by then was too late to switch back to the old tentacle model, so it was completely frustrating. But the fix was simple (which only just made me angrier I guess :| ), adding a Reset XForm modifier.


[Suman] The lag!!!!!! changing to Release mode fixed it! :D


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 used C++.


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?

[Justina] I used 3ds Max in order to create all the player/monster models for the game. 3ds Max is very handy in a couple ways compared to Blender, but is completely frustrating in others.


To make sure your models come out well, especially if you’re using Panda DirectX in order to export is as a .X file for animations -


First make the model - make sure everything is closed up, there are no free open parts in your mesh.


Then create the UVW map for texturing - texturing made 60% of the model, so texturing is important. I turned off being able to see peel lines and created my own UV lines using the point-to-point seam tool in order to create good ways for the mesh to peel. Then select all the polygons within a seemed off area, and use “pelt map” to get a good initial peel. (search around for tutorials for a little better explanation of pelt :| ) Make sure no polygons are overlapping, and that the shape is generally spread out well enough that there wouldn’t be any strange stretching of textures, then you can render the uvw map and save it as a .psd file or a .png.


MAKE SURE, THEN, AFTER THAT YOU COLLAPSE THE STACK by converting the mesh to an editable poly, so that the uvw map sticks. You can re-attach the uvw modifier and it will still be there, but do that initially so that the uvw is saved.


ALSO, AFTER UVW MAP, ADD RESET XFORM MODIFIER to reset all the transformations on the mesh. This will ensure that the mesh doesn’t totally crumple when convert to .X and into your game. Seriously. :| You can then recollapse the stack to get rid of it if you so wish.


Then if you are doing animation, set up bones (see tutorials for more) just make sure that whether you are using bones or bipeds or CAT, that you pay attention to envelopes and weights to see how much vertices get pulled by a particular bone. Using the Skin modifier + Paint Weights is the best way to make sure your model will animate in the way you want to.


If you are animating with the biped, note that it uses some totally different animation key stuff, you have to look under the motion tab and then Key info - the keys there are what are used for biped (although it seems you can still use Auto Key with parts of the biped - it’s confusing and silly).


Now that I’ve taken the time to use 3ds Max, I would still use it again, cause it does have its benefits, but I can’t help but wonder whether using Maya would have been easier/about the same amount of frustration. Learning to model for a game on the fly is a little difficult.


[Haro] If you want to use xAnimator, realize that it blends different animations together when you switch. So if you have intermediate animations to do the transitions, they won’t work well because it will try to blend with the start of your previous animation anyway. Also, it doesn’t give you full control over the models, and it’s all client side, so the server will not be able to know about (and therefore follow) the animations. This might bring about problems with collisions (as it did with us). Maybe looking at different libraries would have been good.


[Bryan] The animations are loaded in reverse of the way that they are created, so whatever animation that you define first will be loaded last by DirectX. Plan around this by making you export options so you don’t have to delete everything when you add a new animation.


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

The only reason that we would like having something like Ogre would be because we came into this with no idea of potential organizations for our engine. Having more background in this would perfectly solve this problem.


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?

[Franklin] Having completed the network in week 2, I didn’t really discuss networking with any of the other groups. My networking code worked well enough.


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

[Bryan] More structure, intentional assignment of tasks, and definition of what features we want to create (and implementation specifics). Frontloading our work would also be good.


[Franklin] Take more time to plan the features that would be needed for the project. Spend more time on the architecture on the game so it can handle more features and more abstraction.


[Suman] I think we needed more communication on the project as a whole, someone who was finalizing and keeping track of the big picture would have been useful. A more rigid testing scheme, such as enforcing regression tests as well as stress tests before a push would have saved a lot of time. Enforcing a better branching system with git, such as adding a hotfix branch for quick modification and better feature branches (instead of people branches). More documentation on specific functions, either in code or on the wiki and things to watch out for. Also, we should have enforced a no warning rule when you commit.


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

CSE 123 was helpful, but not essential in implementing the network using Winsock. It helped in considering the aspects of networking like packet sizes and a general idea of how to send data between computers. But in the end, I think it would be do-able without having taken CSE 123. CSE 131 and 141 made us intimately familiar with the labs and working long and late hours. This helped tremendously in maintaining morale.


[Haro] Taking graphics would have probably been nice...However, CSE 190 (3D User Interfaces) was sort of helpful because there was a little bit of graphics, input handling, and collision detection in there.


[Bryan] Project classes in general are helpful for each other (discipline, planning, etc)


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

We all learned to step back from our initial project spec and evaluate what was realistic. We also learned to communicate our deadlines, limits, and expectations.


Fun Fact by Franklin: Anarchy as a group organizational philosophy is great for implementing wonderful parts, but an awful way of putting together a whole.


Please post final screenshots of your game on your group pages for posterity.

They are on the wiki’s Screenshots page =D

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?

Game Engine Architecture by Jason Gregory wasn’t terribly useful. Most of the optimization strategies outlined were not applicable to the limited time we had to implement our rather “simple“ game.


If using DirectX 9 please use this book, Introduction to 3D Game Programming with DirectX 9.0 by Frank D. Luna, it was most useful.


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

[Justina] If you are modeling, try to learn up on it before you start the course! It would totally really help :<


[Franklin] For a less stressful time, consider a game that has 2D gameplay brought into the 3D world and no animations for your models.


[Suman] Have fun!!!!!!!


[Haro] Start with a simple idea, really really simple, and then really polish it. Don’t try to do a million features, just focus on a few =) [Bryan agrees] [+ Michael and Suman and Nathan and Justina]


[Michael] FMOD is a really powerful audio library, however, use the FMOD Studio library instead of the FMOD Ex library to save time implementing audio management and playback.


How can the course be improved for next year?

Groups need a separate person for music, modeling, and the graphics engine.


[Suman] It’s absolutely okay to pick up a skill on the fly. If more than one person wants to try modeling/texturing/animating, they totally should but make sure to split up the work and help each other!


[Haro] It would be nice if we had some resources for how to architect a game engine, maybe pros and cons of different designs. [Bryan agrees]