• Fighter class ships -Implemented as a squadron.
• Shields -Implemented and integral to gameplay.
• Radar in 3D-Implemented, but didn't like it. Went back to 2D.
• First person view -Would not have worked with our current combat system.
• Teams -Partially implemented, but never fully realized.
• More weapons -Yes, yes, and yes. Particle gun, phaser, and shock cannon. We also implemented mines and remote detonated bombs.
• Warp in animation on respawn -Awesome particle effect plays before ship appears.
• Game Intro -Didn't have time to include video-playback, though a preliminary intro movie was created.
• Space clouds -Sadly, no.
• Multiple Maps/Levels -Done. Each had to be created by hand, but are easily incorperated upon completion.
• AI/Bots -Yes. And they were vicious. AI ships can follow preset paths, and target players in range (very accurately!). They also respond to attack by raising their shields.

• Alternate input (joystick) -Would have been cumbersome with our camera system.
• User Customizable Keyboard controls -Custumizable in an external file.
• Ships show physical damage Alas, no.
• Taunts -Were all verbal (external to game).
• Level Hazards -Not unless you consider walls and AI ships level hazards.
• Other game modes -Race, deathmatch, and domination modes implemented.
• Storyline/Intro -No one knows the real story: They came from across the galaxies to display their warrior prowess...
• Cutscenes -We lost interest.

• Campaign Mode
• 24 channel surround sound
• Ultra High Definition
• Voice Communication
  -Haha. Yeah, right.

• Ships have the ability to boost at high speed in a straight line in order to escape and/or enter those particularly nasty situations.
• All weapons and abilities drained a player's energy, which recharges slowly over time.
• Waypoints were implemented
• Lighting connected to many particle effects.
• Spinnning spotlights on waypoints.
• Our department's mascot bear was included as an asteroid with an extra special explosion.
• David created an excellent particle effect generation utility
• In-game scoreboard
• An advanced targeting system to aid the player. On target lock, opponents are lead automatically, guaranteeing a hit unless the target changes velocity. Target ship model is displayed along with health and energy information on the HUD.

Schedule

General Questions

1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
   Software methodology: Our initial design for needed modules, and how they needed to be connected worked out well; however, our implementation (via only header files, and the use of global functions) caused numerous problems. Furthermore, a style guideline would have been helpful to keep things consistent.
   Group Mechanics: Our group had excellent communication since each member was almost always in the lab. Because of this, people always knew what needed to be done, and little if any time was wasted in job allocation. We were good at doing what what needed to be done while not stepping on each others toes. We carried the task together, helping each other constantly.
   How we could have improved:
   We initially created a lot of code that was not intended to be included in the final version, but instead of replacing that code, we mutated it into what we needed. This caused things to get sloppier than necessary. All code should be considered "the real thing" from the onset.
   We strongly recommend not taking other difficult classes concurrently with this one.
2. What aspects of the implementation were more difficult than you expected, and which were easier? Why? In general, run-time speed was the primary issue. Managing models, particles, and collisions so that they functioned in real-time was always challenging.
   Scene management was huge. Terrible. Awful.
   The program was networked and multi-threaded, making debugging especially challenging, though this was somewhat expected.
   User interface and startup menus was MUCH, MUCH more time consuming than anticipated.
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?
   In the scope of this class, the more you are given, the less you learn. We created everything from scratch, and we are very happy with our results. If anyone had a question, someone in the group would know the answer because someone in the group wrote it. Our recommendation is to create useful tools early(particle tool, user interface tool, menu tool, etc), because they will be useful throughout the project.
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?
   We did not use a game engine, and we are glad we did not. Although we were at times envious of the cool effects provided by game engines such as Ogre, we ultimately felt that we had more control over every aspect of our own game. Using a game engine would have limited our options in more ways than it would have helped. We were able to streamline our server and client to only load what they needed to load, which would have been problematic with a game engine.
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 do not feel that we made any mistakes that were big enough to warrant 'not doing them again.' However, some things we could have done better would have been more organization and less laziness in coding style. We would definately make the particle tool again, every stinkin' time. It would have been useful to read past group reports and play their games at the beginning of the quarter.
6. Which courses at UCSD do you think best prepared you for CSE 125? CSE167-Graphics(Super useful), CSE169-Animation, ECE111-Advanced Digital Design Projects, CSE123a - Networking, CSE112 - Software Engineering, CSE131a/b - BECAUSE YOU SHOULDN'T BE TAKING THAT CLASS IF YOU ARE TAKING THIS ONE. Plus, it is good preparation for the amount of commitment you need to make to this class to succeed.
7. What was the most important thing that you learned in the class?
   
   -Jai - Different people have different skills. Learning the groups strengths and weaknesses and finding a way to make the project succeed despite them was the trickiest and most unpredictable part of this project. In the future, I will be more capable of judging the people I am working with.
   
   -Mark - More of a confirmation than new insight: communication is the most important part of any group project. I really appreciated knowing most of my group members beforehand, because I knew that I could trust them to be responsible. I had a lot of fun working with my team.
   
   -David - There are certain things that you simply cannot do on your own, and asking for help can be incredibly beneficial in terms of time management and stress levels.
   
   -Mani - I learned that making a game is more time consuming than expected. Also, writing code that others can read is essential in a group. Finally, DO NOT TAKE 4 upper division classes your final quarter.
   
   -Andres - The value of communication within a group is amazing. Regular e-mails and contact helped our project more than any other aspect of our group. What's more, watching how some of the other groups worked made me glad that we started with a clear idea and continued to communicate our priorities and progress. In most other classes at this University, it doesn't matter if you communicate because the problem domains are so small, that anyone can figure out what's going on without any help. However, this class taught me exactly why cvs is so important and a number of do's and don't in terms of working in large groups.

Future course recommendations: