Questions from Professor Voelker to answer for final report ( Personal responses we wanted to add in are in bold) :
- In the project review document, start by addressing these main questions:
- Then address these more general questions:
- What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
- What aspects of the implementation were more difficult than you expected, and which were easier? Why?
- 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?
- 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?
- If you had the opportunity to have a member of your group devoted to working on models, textures, and animations (e.g., an ICAM student), would you want to take advantage of this opportunity? If so, would it be necessary to have that member be in addition to the six students in the group, or would it work to have that person as a sixth member?
- Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
- Which courses at UCSD do you think best prepared you for CSE 125?
- What was the most important thing that you learned in the class? (Combine all responses across everyone in the group.)
- Finally, if you wish, I would like you to provide some optional feedback on the course:
And then, finally, you'll be done :-) ... (holy cow, sean looks like john kerry - allen)
-
Our final game concept differed little from our initial game concept. The primary difference is that we originally envisioned the world to take place in a 2D perspective, similar to arcade style fighting games. But due to course restrictions and wanting to take fuller advantage of having a 3D environment in the game, we shifted it to a 3D perspective. Another difference is that originally we thought characters would die by falling, but later decided that it would not contribute much to the gameplay. Besides, we stole the idea of not dying from falling from G1S since we are creative geniuses. Also we did not have enough time to add in more moves such as some more complex combos we had in mind, although we are pretty satisfied with the number we managed to have. Finally, we would have liked to add in cars and explosive objects although we did not have enough time to implement this feature. Overall based on the list of things we wanted to have, we got pretty much all of them done.
Due to excellent planning at the beginning of the quarter by our top software engineers, utilizing various sophisticated software engineering practices and paradigms (sarcasm), we did not have to make any significant alterations to our project design. We also did not come across major software bugs that required modifications to our design.
Seriously though, our design was pretty close to what we originally planned at the beginning of the quarter. Most of the individual components were pretty well encapsulated as we had envisioned, with the common link between them being the actual gamestate snapshots. This allowed us to work quite independently once we defined what information would be available to each module.
For the first half of the quarter, we stuck with our projected schedule as set by the milestone pretty well. Our primary goal was to have the basic modules ready for early integration by Week 4, which included the graphics engine, physics engine, game engine, and networking. We met that deadline and integration went smoothly. Afterwards, each "group" was able to concentrate on its individual parts at its own pace. After integration, graphics engine was a little slow because we had to figure out the proper formats of models that we wanted to load and the formats that we could produce through modeling programs since we were going to make our own models. But after that was sorted out it was no sweat. Physics engine went well in the beginning, but after the addition of lots more animation and graphics, collision detection became slow. So the physics engine was improved by the addition of octree for collision detection. It was not a major setback because we are speedy pigs!
allen: The server/game engine was behind schedule for about the first 4-5 weeks because I was spending most of my time of getting the physics to work. After that, things moved pretty fast once I actually got down to writing actual code for the game engine although I was very worried at first. (Once ROTK came out on the 24th of June, a day to be remembered for sure, progress slowed down a little on my part for some reason :D). The physics was mostly on schedule most of the time because that was where the brunt of my effort was during the first few weeks.
tony: The input logic was implemented before integration. However, towards the end of the quarter, the camera code was upgraded with more coolness, which changed the camera-character perspectives. As a result, the input logic had to be updated as well.
-
Initially we wanted to use Doxygen for documenting our code, but we ended up not because it was extra unnecessary work and required a high learning curve. Our final project was modularized well enough to not require extensive documentation for members of the group to use the different parts. We used XtremeProg to good effect at certain times. Trying to all meet in the lab at the same time did not work out very well, so we had to work more in smaller groups or individually. Most of us had time conflicts, and the only time everyone had time to all meet was close to the end of the quarter.
allen: What allowed me to finish my part in the physics was to liberally adapt/reuse code already written if it was legal and available. It still involved understanding everything inside out in order to adapt it to our code and do any modifications, but it was definitely a boost in the right direction.
For graphics engine, it was more confusing than it was difficult for the implementation of model loading, as there were so many different formats and loaders to do it.
karen: For model creation and animation, learning new programs was a fun challenge. I had to deal with my unfamiliarity with modeling software and the limitations of Milkshape3D, which is what I decided to use for modeling because of the low learning curve with respect to other major 3D software.
allen: This may sound dumb, but for the physics, I did not realize at first how important algorithmic correstness was. A version of the algorithm we used at first was plain incorrect and this caused bugs which weren't really fixable till I used a different version of it. That was a little painful because we kept trying to fix the original problem using hacks and more hacks :) Implementing octrees were simpler than I thought it would be from a high level, but on the low level there were some insidious bugs due to numeric instability. The problem had something to do with the tri in voxel test in gems. On the game engine side, it was a fun challenge to come up with something simple to use and manage the lots of state required.
tony: sound was surprisingly easy because we used OpenAL instead of direct sound. This gave me more time to improve our sound engine by adding in special features. For the input, we used DirectInput. We had two choices, namely using the DirectInput's Action Mapping interface or access the devices directly and then do the mapping ourselves. The action mapping has a confusing interface and lacked flexibility, so we decided to do things our own way and that turned out to be very easy. Not sure why anyone would want to use action mapping. Implementing networking is seriously complicated. We took a lot of the networking code straight out of the directX samples after understanding what they were doing.
The libraries we used most extensively were DirectInput, DirectPlay, OpenAL, and of course OpenGL. We managed to work pretty well using only these libraries, so we do not really see a need for more libraries for a project such as ours. Maybe a model loader library API that abstracts out details for most common formats would have been useful.
karen: I wish I had known more about professional 3D modeling programs such as 3D Studio Max because that would have made my modeling and animation tasks easier and more refined. Milkshape 3D was easy to use, but also frustrating at the same time because of its lack of features and bugs. Other than that, I am thee Photoshop texturer.
We did not use any game engine. Judging from the experience of other groups, it seems that using a game engine, specifically a graphics engine, was sometimes restrictive, so we would still probably have decided not to use one in hindsight. For the physics, we were thinking of using a readily available rigid body simulator, but decided against it. Looking back, our own game engine was probably the best way to go because of the learning experience and the flexibility of coming up with our own engine.
allen: I did look through some engine API's to see how they were designed and used. This gave me some ideas on how to structure the code I was writing.
We would probably not have taken advantage of having a sixth or seventh member of the group as an ICAM major. One reason is that an ICAM major might have been hard to synchronize with other members whose work progression (research, design and planning, initial code, debug) is probably too different from an artistic pipeline. Furthermore, Karen managed pretty damn well creating our level and models :) And we had only five in the group as a matter of fact and it still worked out really well! However, having someone who is musically gifted unlike us (exception: sean who can play 2 chords on the guitar) would probably have been cool in order to come up with cool effects and music, although it doesn't seem that a music major would have had a full to-do list for the whole quarter.
sean: Karen's modeling was awesome AND she contributed excellent OpenGL coding. So having multi-talented students is really what groups need.
allen: the mythical man-month applies here I think. Oh, we could have used a sixth member to go buy us tacos and get us drinks though. Uhm, to eat outside the lab of course.
graphics: we would have decided on a concrete model format earlier. we kept flip-flopping on which format to use before finalizing on a format in the 5th week. karen would like to have found out how to make 3d studio max do her bidding. we wish we could have figured out how to have realistic, but easy to make shadows.
physics: we would like to have made the engine somewhat more powerful to be better able to handle oriented objects, using OBB's instead of ABB's. The algorithm used was not flexible enough from that standpoint.
Also, later in the quarter we learned about more advanced integration techniques instead of the basic euler integration we are using that caused some instability, although it was probably too late to change. Luckily our step sizes were small enough and the physics simple enough that it did not matter much.
game engine: looking back, we would like to have a more robust combat system that was better designed that would be easy to extend and modify. Also, I would have tried to come up with a more powerful way of managing the big amount of state information involved - I would have applied more object orientedness than already there.
sound: we would probably reorganize it a bit because there are some minor problems in how sound effects do not follow a player once it is played. also, we would change it so it would be easier for the sound engine to know what to play.
overall: we would definitely have used some sort of data/constant runtime loading system which allowed us to modify values instead of having to recompile each time. by the time we wanted this in, the time involved overweighed the benefits.
tony:CSE120, CSE12
sean:CSE167, MAE293
allen:CSE12, 30, 100, 131A/B, any course with lots of programming in whatever language.
101, 105, 107 for theory and being able to read and understand algorithms in general.
nikhil:CSE120, CSE169, CSE105
karen:CSE167, CSE169, MAE293
We're not sure if this is what is meant by 'combine all responses from across the group'. Sorry if it isn't!
tony:learning directX you know, and learning about learning new interfaces, and doing research on you know, and uhm ... and ... uhm ... yeah .. oh and uhm... working on the game and the structure and getting to see what worked and what didn't. Oh and I think I learned quite a bit about windows programming too. Oh, I also learned about geometry from Karen. I also learned how to use display lists to embarass sean.
sean: whats the question? .. oh ... How to rely on other group members to do school work for me. This is an essential skill for surviving in the predatory industry of computer programming. Code Reuse is cool!
allen: The greatest lesson I learnt is how to just go out and indepently research and learn ideas by yourself from stuff like papers and books out there in coming up with your own ideas. Learning about simulating physics and interesting data structures (eg octrees) was also really cool and a great way to indirectly learn many other things in general. I learnt Math is king and I should really advance mine. Finally, learning to work well with other people!
nikhil: Very importantly, Nickhill learned how to work with other people very well. Also Nick Hill learned how to do physics and octrees pretty well. Nickhill also learned how to integrate graphical hacks effectively into our game. That Seans chips are tasty ... and FREE .. like beer.
karen: I learned how 3D models made from programs can be integrated into an OpenGL code environment.
-
We aren't sure what books are on the 'recommended' list, so we will just list the books we thought were useful. Sean thought books were interesting but he did not use any of them (He needed the Solid Code book though). Karen read through some stuff but did not find anything that was directly applicable. Nikhil thought the Gems book and his 167 text was useful. Tony found MSDN useful and writing solid code for figuring out seans buffer overflows. Allen found the Gems books great and totally useful (I bought 1 myself), and also '3d math primer for graphics and game development' (parberry, dunn) cause he forgot all his math from before.
karen: Oh yeah, I also bought a bunch of books on game stuff, but didn't really end up using any of them very much because the game did not require them. They were books on 3D Studio, graphics techniques for games, careers in gaming, etc.
allen: The DirectX8 book was not very helpful at all.I found books like 'game coding complete' were really interesting in general just to learn about potential non-programming problems. I used 'OpenGL Game Programming' and that whole LaMothe edited series as a source of ideas at certain times, but could probably have survived without them. Effective C++ is great too just to have an idea of some good ways to do things in C++. The math book was useful if you are like me and forgot everything other than simple algebra.
Decide on your schedule on week 1, and start coding. Plan well or you will suffer later! Don't use a game engine unless you need to do something you can't. Doing stuff yourself is very fulfilling although you might not be able to implement advanced features.
"Lets go eat!" is an important phrase you must learn.
allen: Dont forget that fun is key, you already know this but remember it anyway! Make sure you know why your game will be fun and to have enough time to make it so (bwahaha I sound like picard ... 'make it so' .. uhm nevermind). Make sure people in groups are interacting well, this was really useful for us to get stuff done.
sean: We already mentioned this, but having some kind of text files for doing configuration seems like a really great idea. It makes it easy to tweak features in the game without having to recompile. This method was heavily recommended by the Game Programming Gems 1 book. We looked at it in the beginning of the quarter but didn't do it. It would have been a good idea. Also, while I imagine most graphics people are more talented / knowledgeable than me, I found I had no real good idea how to structure a graphics engine. Looking briefly at the structure of open source projects like the OGRE graphics engine gave me some good ideas on how to get started.
karen: members of the group should go EAT together as much as possible especially if you started the quarter off as strangers. It creates a great group dynamic which enables you to make fun of each other without offending them, like us. It also relieves everyone from the stresses of being in lab all the time and school. Also, it is even better if you don't have a vegetarian in the group (unlike sean)!
tony: we had a very smooth integration. i think what really worked out well for us is deciding from the beginning how each component will communicate. having networking up and running early on makes other parts of the game easier to work on and test. The past team's links to resources were extremely useful to get started. It would have been nice if more of the past team's executables were up for us to play.
The course is determined by the students, so the more motivated (and somewhat minimally intelligent) the students are, the better the course is. Maybe some more free food and more lectures from Prof. Rotenberg would be cool! Other than that, the course is great the way it is.
sean: The environment provided by the class is great already, it's up to the students to take advantage. I'm sure everyone in the class next year will (and all the years after that it's offered). More lecture by other people in the game industry would have been great. This is the best computer science class at UCSD.
allen: The guest lecture by Prof. Rotenberg was fantastic. Extra lectures or maybe some insider talks would also have been nice.
tony: I think a great team is essential. This class needs students who are driven and willing to get things done (and able to decide what needs to get done). The screening process is probably the most important part of the class.
Only sean played the XBox, he is going to play mechassault more at allens home cause he says it is awesome. His productivity declined significantly after he learned how to use the Xbox controller.
sean: Actually, I don't think the XBox had a negative impact on the work I got done. It did provide a little more fun in the lab. I think my teammates didn't like me playing it. Mech Asssault really is great, too. Maybe I should put that under "most important thing" I learned.
allen: The xbox could not be a distraction because none of us had a chance to play because someone was hogging the controller.
karen: But the xbox helped Sean keep his mind away from his hunger.
You found an easter egg! Other stuff we want to say but have nowhere to put!
- allen: Learn math so you can have moments like .... "so thats what runge kutta is good for!", and "wow, matrices are useful huh". I also learned why having extra floating point precision would be useful. My team was awesome, having a great team for 10 weeks is soooo cool. I like to eat food, if you go out for food please contact me. ROTK Extended Edition! Spider Man 2 is gonna rock! Karen, haha I tricked you into cracking an egg!
- nikhil:
- tony: why am i the only one who thinks EXPLOSIVE blood particles kick ass?
- karen: and i almost ate it RAW, i would throw em at your face if that happened. and stop stretching my google shirts. i LOVE to eat too. the only time when we are all in lab is when we need to make plans to go eat. but eating is important, we bonded through eating.
- sean: i don't like food much. also, i wish karen had thrown eggs in somebodies face, that would have been hilarious, unless it had been my face. that still would have been hilarious, though. just not for me.
2.0 ...
Robin: it's IceCube! Oh no Batman, this is terrible. We must stop them before they cause trouble.
Batman: Don’t worry Robin, they’ll be behind bars within a week.
Robin: Holy jumping jelly beans Batman!
Batman: Are you thinking what I’m thinking?
Batman and Robin: KAMPUS KOMBAT!
*Back at the Bat Cave*
Robin: kampus kombat is awesome!
Batman: I’ll take it to the lab to get it tested.
UCSD Spring 2004 CSE125. Allen Ding, Nikhil Dvivedi, Karen Hom, Zhao Yong Liu, Sean Ojakian.
