Gamasutra: The Art & Business of Making Gamesspacer
Faculty Postmortem: Cal Poly Pomona's Game Development Course
View All     RSS
April 25, 2017
arrowPress Releases
April 25, 2017
Games Press
View All     RSS






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Faculty Postmortem: Cal Poly Pomona's Game Development Course

July 13, 2006 Article Start Previous Page 2 of 4 Next
 

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.


Student-Created Main Selection Screen

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.


Article Start Previous Page 2 of 4 Next

Related Jobs

Lionbridge Technologies
Lionbridge Technologies — Bellevue, Washington, United States
[04.25.17]

Sr. Business Development Director-Digital Services (#4066)
Lionbridge Technologies
Lionbridge Technologies — Bellevue, Washington, United States
[04.25.17]

Sr. Business Development Director--Games -(#5802)
Lionbridge Technologies
Lionbridge Technologies — San Jose, California, United States
[04.25.17]

Senior Web Interface Developer (#6449)
Everywhere
Everywhere — Edinburgh, Scotland, United Kingdom
[04.25.17]

Character Artists and Animators





Loading Comments

loader image