0xDEADBEEF PRESENTS UCSDOOM
FINAL PROJECT REVIEW
|
A. Main Game Implementation 1. Game concept: How and why did your game concept change from initial concept to what you implemented? We were surprised that our initial game concept didn't change very much. From the beginning, we had high hopes as far as being able to integrate things such as AI and team battles, but we had always planned on the foundation of a first person shooter. Although we ran out of time to really get these other ideas incorporated into our game, our solid basic first person shooter concept was carried out very strongly. 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? Structurally, our final design was very similar to our initial design, with the exception of slight alterations taking place on our server side. Such changes were necessary to allow to reasonable update rates and decent gameplay. Conceptually, our final project design is right inline with our initial design. We had a post apocalyptic UCSD, players fighting against each other with combinational weapons (all 20 of them), and it was all packaged in a fun, relatively stable game. 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.) Throughout the quarter our group remained significantly ahead of schedule with the exception coming from modeling (this being primarily due to the fact that no one in our group knew how to model before, and for the most part, we still don't). As far as code and game dynamics, we were always at least a half week ahead of schedule. B. Then address these more general questions: 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? As much as we could, we tried to maintain a modular style of software development which in the end was a significant reason for always being ahead of schedule. When we did need to incorporate the different modules together, we put in some long hours in the lab, however, in many cases this activity was kept to a minimum through the use of modular testing (for instance, even before we had networking, we had a server object within our client which then allowed for quick and efficient integration through the network when that module was setup). 2. What aspects of the implementation were more difficult than you expected, and which were easier? Why? The integration of client and server was made out to be the moment of truth for the course, so we had prepared ourselves psychologically for a frustrating debugging/integration time at that point, however, it never really came (due mostly to excellent organization and modular testing/development). So, network integration between client and server was the easiest. On the other hand, server dynamics and overall organization was more difficult than we had expected, due in large part to the relatively complicated weapons system which was the focal point for our group. We had so much stuff going on in the game that we really had to spend a good amount of time optimizing the server and better synching it with the client. This was a side effect we hadn't really anticipated at the beginning of the project. 3. In implementing your project, you relied upon a number of tools, from the DirectX libraries to modeling software. Do you see the opportunity and need for new libraries and/or tools that would make project development easier? A simpler, more user friendly modeling environment would have been most useful to our team. Although Milkshape is fairly straight forward, it lacks the power we needed for many models. On the other hand, 3DS Max was overly complicated to learn and really slowed down our modeling efforts. Modeling was definitely something that could be made easier. Additionally, we found Direct3D documentation to be relatively limited and not very programmer friendly. It also would have helped to have more functionality from DXUT and D3DX math functionality. 4. For those who used a game engine, would you use it again if you were starting over knowing what you know now? Do you think the restrictions on what to use from a game engine are reasonable? For those who did not use a game engine, judging from the experience of groups that did, would you rather have used one? Our group chose to bite the bullet and do everything ourselves from scratch, which really allowed us to learn more of the intricacies to game/game engine design. If we had to do this project over again, we still wouldn't use a game engine because we feel it's more important to learn the "behind the scenes" stuff than to necessarily produce a groundbreaking graphically-amazing game. 5. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? We would have insisted on having a modeler in our group from the get go to speed up our game development because, for us, that was really the slow part and the one we were most nervous about. That being said, everything else we did was right on point and we still feel that the actual coding/organization/conceptual layout time was as efficient as it could have possibly been. 6. Which courses at UCSD do you think best prepared you for CSE 125? It seems like the group really felt most prepared for this class from CSE 120 and CSE 167 (namely, operating systems and graphics). However, even having some C++ coding experiences from these classes and some slight background as far as the necessary mathematics, we really learned almost everything as we went. More or less we had to learn everything from scratch: Direct3D, RakNet, and modeling software. 7. What was the most important thing that you learned in the class? The general team design experience was the most important thing we learned through the class. Team dynamics, project organization, conceptual planning, and backup planning were central things that we all took away from the software design experience (we even learned something about politics, both within our group and through watching events in other groups). C. Finally, if you wish, I would like you to provide optional 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? Special Effects Game Programming with DirectX, and Real Time Collision Detection Programming were the only books our group really consulted in making our game. More importantly, we found most help online and through the DirectX help files (MSDN also has this documentation, although it&s far more cumbersome to look through). Some of the DirectX tutorials on Microsoft's DirectX page (submitted by hobby coders) were helpful. The best resource, however, came from a site called toymaker.info, which had information and code samples for everything from animation, particle effects, sprites, rendering options, etc. 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? The best advice is to start and test early (hopefully in a modular fashion). Additionally, we found it helpful to have integration does as soon as possible (for us that came at the end of third week/fourth week). Once those parts are done, things start moving and looking really cool really fast. On a more humorous note, try and have someone experienced in modeling! 3. How can the course be improved for next year? More food in the lab and bring the X-Box back to the lab, we got jacked this year! Apart from that, everything was amazing, from the guest lectures to the great TA and the incorporation of industry professionals both in lectures and demonstrations. |