3.    Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any?

It seemed like we were always behind schedule.  Part of this is probably because we were overly optimistic in creating our schedule; obviously we had no idea the best times to target for milestones so we looked at progress reports from previous quarters and combined them into a single schedule. 

Without looking at the status reports, it’s pretty easy to recall that most of us were stuck on pretty big problems at one point or another.  These included things like: waiting endlessly trying to reproduce a random crash in game (Jeff and Long), figuring out how Ogre likes its animations (Eddie and Jenn), integrating GUI states into full game and Ogre singleton problems (Grace), and working through and around Dotscene management for the arena (Johnny).  And as much as we try to help each other get through the problems, usually the person who knows the most about the problem is the person having the problem; no amount of help from TAs, the professor or other team members can figure them out.



General Course Questions

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

For software methodology, keeping everything separate in its own place was good; even more modularity would have been nice (two files around 1500 lines), however, overall, the structure seemed to work well.  (Recap: client checks input, sends input object each frame to server, server processes input and modifies game state, server regularly sends entire game state to clients)

Decisions by consensus didn’t seem to work (IMO, Jeff) – everyone seemed to be searching for a leader.
Communication seemed to occur best through e-mail and in the lab; forums, aim, and phone didn’t really happen much.  (Maybe one online meeting when we were all busy, but pretty much only to write up the group progress report).
Weekly status reports seemed to work out nicely with the Mambo CMS/blog style webpage.


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

Networking synchronization caused bigger problems than we expected; order of events was sometimes important (and perhaps shouldn’t have been) and causes all sorts of problems.

Getting models and animation into the game was definitely more difficult than we thought it would be.


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?

Some easy way for serializing objects and checking the serialization of objects would be nice (along the lines of java’s …’implements Serializable’).  Serialization errors caused lots of little problems that weren’t always immediately noticeable.
Although easier modeling software was available, we (Eddie) believe that higher quality animations would improve the game's aesthetics and be worth the extra effort, although it would have been nice to have someone in our group that already knew how to use 3DS Max.

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?

Using a game engine, Ogre,  definitely made things easier from the start; just building on the demo programs, it was easy to get things moving around and interacting from the start.  The way Ogre was structured there was a bit of a learning curve to understand the way it structured the game, but it was easy to learn through documentation and examples.  The main downside to using the engine was the transparency; it masked the Direct3D libraries (or OpenGL if we chose that option) into only creating objects to be viewed and moving them/animating them, etc.  Of course, any major gaming company will be using some sort of engine for their game and we don’t feel that it is a great disadvantage in terms of understanding how the game works.

Yes, we would use an engine again.


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

Definitely work to get things integrated sooner; getting to the stage where the only features are being added (vs core components) made development much smoother.
Modeling at least (not as much for animation) should have been up as soon as possible. It helps ensure that some problems in that area won't flare up at the last second.


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

Jeff – Being able to program independently rather than following instructions on an assignment handout was the most important thing.  (so maybe 131B(Ord)).  Also 167 was pretty useful for a basic understanding of graphics and how animation worked at a basic level.  Any class that used C++ would have been useful (is there such a class?) and familiarity with pointers (any Rick Ord class).
Long -- CSE 169: Animation helped tremendously.  Some of the topics covered that helped a lot were linear algebra. quaternions, character animation, rigid bodies , collision detection and particle systems.  People working on the graphics module should definitely take Computer Animation.  In addition, CSE 169 also helped me develop my C++ skills.  Other classes that prepared me well were Networking and Operating Systems.
Jenn -- Courses with large scale programming assignments in unfamiliar/new languages are useful in developing independence and problem solving skills. Classes  such as ECE 111, CSE 131A,B train students to not rely on tutors for solutions. In aggrement w/ long, people doing graphics should take Computer Animation. Otherwise, it's quite a high learning curve to ramp up to in comparison to graphics people who already have the skills.
Eddie -- Again, classes that force us to produce larger projects independently without being spoon-fed by the professors were the ones that helped us the most. Classes that share this view include CSE131A,B, CSE141L, ECE111. CSE167 helped only to familiarize me with the 3d coordinate system; other than that it wasn't too helpful.
Grace -- The best preparation comes from courses that involve working together in teams to complete a final project. One such class was CSE111, where students worked in teams of 5-6 on the design of a software product from initial concept to product release. Other good preparatory courses include CSE131A,B and ECE111 because they entail large scale projects that involve working within a team environment.

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

Jeff – This experience is definitely one of a kind.  Getting to where the game is playable, and knowing that it was the hundreds of hours of work that we put into it as a group made it the most fulfilling project I’ve completed here at UCSD.  As for learning, putting everything together as a group is something we don’t do in school.  Learning to work together was definitely more important than any programming skill gained.
Long -- Using and learning new libraries and API's was a great experience.  A lot of algrotithms used in our game are already solved problems, but learning them and thinking about them on our own was a great experience.  I also learned a lot about C++ and its useful features.  Teamwork also played an important role in such a large scale project.
Jenn -- Ramping up quickly on learning to use a new API's and applications was a good lesson. It's important to be able to search through forums, do your own research, and to figure things out without being spoon fed answers to make progress. It really puts your problem solving skills to the test. Secondly, in correspondence with the other comments, I agree that teamwork and being able to divide up the tasks and then later integrate them together was another integral lesson. Especially because of the size of our project, being able to sit down with the network structure and one by one integrating the other components was a phenomenal accomplishment.
Eddie -- Learning to work in a group and adhere to a set schedule was something that I had to learn this quarter. Although energetic at the beginning, I found myself lagging when hitting problems rather than working harder to work around them. However, we pulled through somehow by the end of the quarter. Close seconds go to learning about APIs required as soon as possible. The sheer number of tools we needed to use in order to produce this game has boggled me. Very naive to this type of programming, I was assuming all we needed was VS .NET and DX when I signed up for this class =).

Course Feedback

 
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?

Game Gems series, collision detection, mathematics for games(?). 
A general C++ book would be good for brushing up on rusty C++…
3DS Max Bible helped lessen the steep curve for our modeling novices.
Not sure which books weren’t useful

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

Have well defined group leadership roles
Get  integrated quickly (yeah, yeah, at the start we didn’t really know what that meant either) Also perhaps it is advisible to start integrating with just the basic functionality of the components. It's important to have a basic integrated structure. You can work on adding additional functionalities later. Its better to slowly integrate  more in intervals versus integrating an entire fully completely module and dealing with a tremendous number of issues at once.

3.    How can the course be improved for next year?

Try to get the demo environment setup ~2 hours before actual demo.
Require ‘final’ binary release due a couple days before demo – not final for demo, but backup for last minute problems.

4.    Was the X-Box a distraction?

Not at all.