Erin Odenweller, Tank Group, CMPS 115
Technical and Managerial Lessons from this Project
(or, what I should have thought about more at the time…)
It’s easy to think that a class devoted to a computer game is going to be a dreamy, silly class without any substance. That’s the first, I suppose. I came into the class with a number of lofty ideals about working on a pet project just between ….. but it just doesn’t work like that. My original game idea, that I came to the first day of class with, was a modification of Tetris, based on simple inorganic molecules. Molectris, you see. That flew out the window when the recommendation for "board game" based games was made, and in the making of the groups. It’s hard to set your heart on something and spend some quality time thinking about it when it gets thrown out the window. And the actual lectures and tests for this class weren’t easy either. They required that I study and prepare like any other class. That was a bit of a shocker for the first test. It wasn’t as easy as I expected it to be.
Milestones were a subject of contention in my mind for a long time. I often felt that our group had completed everything, to the letter, that was in the specification document and yet we weren’t approaching a ten by any stretch. It seemed like we were always missing some little detail here and there, and between 2 or 3 details we were losing 2-3 points, which worried me. And often I felt as though the make-ups for those points were essentially trivial, and we got points back after rewording a few sentences or adding a clearer explanation. It took a while to realize that some of the things our group was referring to just weren’t obvious to someone who wasn’t intimately involved in the project. Once we started clarifying our statements to an extreme we were much better off.
From a more managerial point of view, it’s quite difficult to get the whole group together at any given point in time. Since we ran the group in the most "egoless" way we could, we didn’t really make decisions or get much done on things that involved the whole group unless the whole group was present. This led to increasing numbers of last minute integration meetings for milestones and other rushes. We originally had a set schedule to adhere to for meeting times, but as the quarter progressed we strayed more and more from that original schedule. We also had a number of conflicts with people committing to a time and then realizing that they weren’t available when they had said they would be. This became a chronic problem for the group as a whole towards the end of the quarter.
I also think that the group did not evenly divide the work to be done. Our milestones were generally evenly divided, but I think that the code was particularly poorly divided. Specifically, I think that since we used Chris’ library of graphical routines as a basis for Tank, he ended up putting much more time and effort into the code behind this than the rest of us. One of the things that I feel led to this was the short amount of time allowed to actually write the code for the project. Since Chris was the most familiar with the existing code base we divided the rest of the code along lines that would least interfere with his current work on the codebase. This meant that I handled level generation and that Marty and John handled the AI. Though I’m quite happy with the work that we did, I know that from a more personal point of view I feel as though I did not contribute as much as I could have to the game.
This is particularly easy to see when you look at the pseudocode that I had for level generation. I was literally randomly filling a level with wall squares and I had designed a very careful and specific variation on a depth first search to check the "goodness" of the level. I designed the algorithm myself with some input and checking done by the other team members, and got it into pseudocode just fine. However, in the implementation of the algorithm a number of complexities that hadn’t been there before turned up. I ended up scrapping the whole idea and using a much simpler method of randomization, but it isn’t as fulfilling as fixing the bugs and using my pet idea.
Back on the level of the group, we did make a few good decisions that I am still thankful for now.
The first was the decision to get the inspection done early, and to do it on a paper prototype. The ideas and comments we got from the paper prototype inspection were incredibly helpful. We changed a number of fairly basic things about the game because of that input.
The second was using Chris’ game engine. Even though all the engine really did was allow us a nice UI for the game, it made working on the game more enjoyable because we all had something to be proud of that we were working on. That pride kept me going through some of the toughest points in the quarter.
In all, I feel like I’ve had most of my frivolous expectations of the Real World shattered, and I’ve developed a great deal of respect for the people who can seriously make things like the waterfall model work in everyday software practices. So much of what we’ve studied we’ve tried to implement, and yet I think that we barely scratched the surface of the software development process.
Recommendations for Future Classes
(or, what I wouldn’t do again, because it was stupid)