     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Faculty Postmortem: Cal Poly Pomona’s Game Development Course What Went Wrong Time management on the overly-ambitious ambitious project. While a couple of teams were able to fully implement their story ideas and meet all milestones, most team’s games were overly-ambitious for a ten-week course. A few started off with the intention of building and importing models from Maya, 3D Studio Max, and other modeling software packages. When they realized that a great deal of work would be needed for actual implementation of these models in their own games, most teams dropped the idea, and went ahead with simple models of their own. From the beginning, I encouraged the teams to use very simple geometric shapes at first, and if time-permitted, they could then consider utilizing the more advanced models. Only one team (out of 14) was able to nail down every milestone so well that they had extra time before the next milestone was assigned to explore modeling packages.
Technical problems. Each game had three modes: player-against-machine, player-against-player, and kiosk. By far, the most difficult mode for the teams was with kiosk mode. In this mode, all screens, models, animations, AI, collisions, physics, sound effects, and songs for the game would automatically be demonstrated for each level of the game. Once the final level was traversed, then the game would start over at level 1. This challenge tested all aspects of their games and pointed out the difficulty of handling AI, collisions, and physics correctly. A major problem with most groups was the use of a source code control system whereby the team’s code could easily be merged together. Magnifying the problem was the fact that many students had different software packages and versions than the computers in the Software Engineering Laboratory. Frequently, students worked on something at home and found that it did not work at school on a laboratory computer. At least 30% of the student in-lab time was ill-spent with both of these problems. Another technical problem involved the systems teams demonstrated their games on. While all of the computers were 2Ghz P4s with 1GB of RAM, the graphics cards were not up-to-date. Consequently, some teams experienced slow-downs when using the school’s computers. Design. Some teams had a difficult time progressing from their original UML class diagram to actual game implementation. As problems became identified in their original designs, some modified their UML diagrams to better represent what they actually ended up with. While this iterative approach is a good software engineering principle, some teams did not close the design loop by updating their UML diagram. _____________________________________________________ |
|||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|