• The web address of this document is: http://www.cs.washington.edu/education/courses/cse490csw/CurrentQtr/Grou ps/Group2/docs/NortFinalReport.html
• Each member of Team Nort shall submit individual final reports in addition to this group report.

Team Nort’s mission statement was well defined from the beginning: create a game based on the light cycle sequence from the movie Tron which would meet the CSE 490 project requirements. The next logical step in our planning was to de termine the feature set that would aid us in achieving our mission. As a group we sat down and brainstormed a list of potential features for our game and then prioritized this list from must-have "basic capabilities" to "wish-list" it ems. The final and most important step involved committing ourselves to this list by putting it in writing; although during the quarter we were forced to make slight revisions due to management requests, time constraints, and implementation details, thes e modifications were minor, and as a result our feature list was our guiding light throughout the quarter whenever it came time to decide what work should be done next. Looking back on our original list in hindsight, though, we realize we did make a crit ical mistake in failing to take into account the target audience and environment in which Nort would be displayed. There are many standard features for any multi-player title released today, such as game configuration and pre-game communication, and we n aturally assumed our game must also have these features in order to be a success. Unfortunately these features were not very visible or appreciated in the short demonstration atmosphere of the colloquium and therefore ought to have been assigned a lower priority.

Team Nort’s lack of planning could be most felt in the architecture of the module interfaces, and the plan for integration. We decided to use a client-server model and divided development into 5 categories: System, Sound, Graphics, Input, and Network. The prevailing thought was that the nature of modularization should make integration simple; after all, modules are inherently self-contained and ought to fit together like building blocks. Unfortunately, it turned out in practice that integrati on was much more complex due to overlap between the various modules, resulting in conflicts and redundancy issues that had to be painstakingly tracked down and resolved, one-by-one. Another difficulty with integration was the controversial design of the system architecture: some group members felt it was too time consuming and difficult to learn and work with in the short time frame of the project. If time permitted and this architecture could have been planned and presented ahead of time, some of the c onflict could have been avoided and integration would most likely have been smoother.

As for module implementation, although some planning was done, really the planning did not facilitate multiple team members working on the same module, causing complex modules, which required more manpower than one person could muster alone, to become a bottleneck for the entire project. Although at first it seemed like a waste of time having to explain and divide work with someone else, now it is obvious that the extra time this would have taken is nothing when compared to the time required to explai n a module to a team member late in development, after it becomes obvious one person cannot do it all.

If we had had more experience with this sort of development or more guidance during the quarter, planning would likely have been less guesswork for us and a more systematic process. We have learned from the experience, though, and now realize the impo rtance of specifying module interfaces and system architecture before actual development begins. In addition, we believe each of these should be periodically reviewed along the way to make sure the design is still correct and that the implementation is c ontinuing to be a true reflection of the design.

While in later stages of the project it might have been helpful to have additional testers available, in general five people seemed to provide sufficient manpower for the project. The use of this manpower, on the other hand, could have been man aged better. When people finished work on their primary responsibilities, they often began working on low priority tasks, something a more even distribution of work would likely have prevented. In addition to this, we began to perceive workload proble ms as the quarter progressed, but it usually seemed to be too late to bring in another person to help out due to the learning curve required just to understand the existing code. Hence, once more we see the importance of familiarizing ourselves such area s of code early in the development in case this knowledge might be required later on. Hopefully now that we have gained some experience we will be able to better estimate how much time a given task will take to complete, and thus distribute work more eve nly in the future; we should also be able to recognize and respond more quickly to any workload problems which crop up during development.

As far as hardware and software resources, more computers running the Windows 95 operating system would have helped, since there was at times a shortage. More importantly, graphics accelerator video cards were a rare commodity; there were only four fo r the entire class to use, and often times one group would seize all of them, making development, and especially testing, difficult for the other groups.

The most difficult aspect of scheduling the project’s milestones was the group’s inexperience with the software tools and projecting the time it would take to learn. With two exceptions, the scheduling was surprisingly accurate. The first exception was graphics integration; we ran into a steep learning curve with Direct3D and Win32 API code, causing a two-week delay in graphics integration. The second exception was testing. Our testing period shrunk to about one week due to the extended graphics integration.

In the original project proposal there were detailed explanations of each of the seven milestones; it turned out to be very helpful throughout the quarter to review what the next step was supposed to be. It is very difficult to estimate what milestone s should be given more or less time if this project were to be done again. While we want more time at the beginning of the quarter to learn DirectX and Win32 APIs better, we also want more time to debug at the end of the quarter. This scheme would leave out time for integration and adding extended features, which turned out to have taken the most time. It appears that our original schedule gave adequate time for all milestones, and next time we would want to stick closer to it in order to leave enough time for testing at the end.

Project progress was measured during the weekly group status reports. We met as a group each week and discussed whether the past week’s goals were met and what the next week’s milestones entailed. This method worked well for us. As far as contingenc y planning, we attempted to leave plenty of time to complete each milestone, but of course there were changes and due dates were pushed back. Nothing could be done to prevent this, except that the code freeze may not have needed to be pushed back as far so that there would be more time left at the end for debugging.

The most difficult area of the schedule was the tradeoff between adding more features and sticking to the schedule which required testing throughout the final week. Since the main functionality of the program and the graphics did not function properly until about the eighth week, it seemed obvious to the team that game enhancement was a necessity over testing. Next time we would want to cut the enhanced features list at a certain point so that we could do a real code freeze and do more testing.

One of the main design decisions is whether to use a client/server network or a peer-to-peer networking model. The client/server (c/s) consists of game state and game updates on the server. The client connects with the server, accepts input, and renders. This gives us, the designers, the ability to evenly spread out the chores at hand. The other option is the peer model, where game state will be stored on each client, and changes to each individual player will be sent around to every other station. We determined for Nort that this was not a feasible constraint, given we wanted everyone to have a game state that was current. This is due to the fact that the light cycles are always moving. Game-state broadcasting is a commonly used networking model, as other real-time games such as Red Alert and Quake use a similar model to avoid glitches during game play.

Based on Team Nort’s experience, we would choose the c/s model once again, where the server need only handle how the game works itself. In Nort it contained all of the collision detection code, speed modification functionality, basic light cycl e positioning, and the explosion sequence reference counts. The game state portion of the overall project can be modularized, and Matt L and Kent handled the task. In a future project, where a heavier emphasis might be put on graphics versus system code , we would probably take one of the server guys and apply him towards the client side. Our client basically handled all rendering of the scene and was completed by Keith and Brett. A fifth person is needed to handle the networking between both sides, an d Matt V handled this module in our project. Five people appears to be enough to handle the project; however if only one person works on a module and suddenly becomes unavailable, like if Matt V had not always been available, organizational problems migh t appear until someone versed themselves in the code of the absent person.

Once we had chosen a design and assigned the various modules to the group, we then had to make decisions about the individual component implementation. In developing a game, the team must make decisions about what algorithms and tools to use. Clearly , as it was a goal of our project, we chose to use the DirectDraw and Direct3D libraries for the graphics rendering. Even though the Tremor group used OpenGL, we chose to use Direct3D since we wanted to learn about the entire DirectX SDK. The alg orithms for creating the visible jet trail were chosen with the constraints that memory usage should be low, because if less dynamic memory was used our rendering times would be faster. In most games the problem of remembering where the walls have been m ight not exist, and when objects appear the world, at some point, they usually disappear.

We also used DirectSound and DirectInput for user interaction. These two libraries proved very helpful and would definitely be used again in future projects. As far as the server code was concerned, algorithms were chosen based on time. The server l oop consisted of three elements: receive and process input from clients, broadcast updates, and wait. Obviously having a waiting element meant that we had a lot of leeway in creating the game-state code; if the code was slow, simply reduce the wait. If we were writing another game, this would be an acceptable model, considering that we only had ten weeks of time. The wait parameter actually turned out to give us more problems than we anticipated, as explained later in the report. In a peer-networking situation, this would have been absolutely unacceptable. Changes in a peer-to-peer system need to be as fast as possible so that rendering can take place. Forking of individual system and rendering threads could be used to offset the slowdown.

An interesting fact of our final product is that there was relatively little code sharing. This means that our code was rather efficient in the sense that we never really needed to reproduce code segments. However, in a future project, one could assu me that basic code elements such as player status might be sharable. For example, assume a player had an inventory in a c/s situation. Clearly this inventory would be needed on the client and the server, because when the user wanted to look in his satch el, the client needs to show what is in the inventory. The satchel, or inventory class could be used for both the server and the client, with small changes to the classes being derived from the base class for each situation.

The biggest problem Team Nort had with testing was a lack of time. Since our ship date was fixed in the middle of the tenth week of the quarter, we had no choice in our decision of whether or not we were prepared to release. In our origina l planning, we had scheduled to have a code freeze about a week before our ship date with liberal beta testing during the last week. Unfortunately, we hit a few snags in development that took a few weeks to resolve, as explained in the Scheduling section . Even when graphics were finally integrated, it took about another week to get the performance up to speed. The net result was that our plans for doing detailed systematic testing turned into a less organized effort. We were not able to run detailed t esting scripts and instead relied on individual module testing and informal testing sessions among group members. Ideally, we would like to have been able to do formal alpha and beta testing as described in the milestone schedule.

An unfortunate aspect of our game development was our inability to get the program running soon enough so as to give people outside our team time to play with our beta release. We also implemented non-essential game elements during the final days befo re release that did not have enough time to be tested fully. This probably would not have been so important except that the wait (sleep) parameter was not tested enough, and it is the likely cause of the program nearly freezing during our demonstration.< /P>

Another important testing issue that the team could have focused more on is multiple hardware systems. Due to the school’s lack of Windows 95 computers, we were somewhat limited in this area. If many people download our software, it is entirely conce ivable that some stability issues will arise that we did not see when testing that is related to the hardware.

Where we succeeded as a team was in our seriousness in fixing a bug when one showed up. Starting about a week before our ship-date, even though other issues were still being worked on, the team's attitude towards bugs changed. Before, when we came ac ross an error, we would just make sure to remember it but not necessarily tackle it at that moment. During the last week, we shifted a lot of our concentration in stability. When an error showed itself, we would make sure we tracked it down (sometimes a s a group, sometimes individually).

Ultimately the quality of the product we released is acceptable. The major problem with the program exists in only a few modes of play. The game is definitely playable and fun with the majority of its configurations. With more time, bug-fix versions would be distributed as feedback and bugs found by the audience of Nort players would be received.

The success of our team's communication was not a constant. The phases of our communication can be broken into the two halves of the quarter. During the first half, we did not communicate more than a few times a week. It was not a problem , since each team member was working on his individual module of the game, and we were optimistic about our release schedule. Kent and Matt L were working as a team on the System module and interacted frequently. Sometimes team members felt lost or unsu re about the status or interaction with other modules. Weekly status reports really helped.

When graphics integration began to give us trouble in the middle of the quarter, our level of communication increased dramatically. We still didn't see each other much face to face, but it became common to have over forty group email messages a day in our inboxes. Due to our increased communication, we were able to ultimately meet our ship date.

Towards the end of the quarter, we started working more together at the lab. It became apparent that it was often much more efficient to be in the same area working then individually at home. As questions arose, we were able to ask each other for hel p. While we still were able to do this though email, it was much more effective when in person. The team learned the value of working together; not just on a project as a whole, but even in solving particular coding issues.

One major stumbling block was our schedules outside of CSE 490. Other classes, jobs, and family made it difficult for us to all find times where we could meet. As stated earlier, many issues are resolved more efficiently when handled face to face. I t seems that this problem was specific to our college environment. If this project was our full-time professional job, we obviously would not have had as much outside interference with our schedules.

A possible solution for next time is to have more required class time. It would have helped both the team and the instructors if there was more formal communication. It helped to receive suggestions during the Tuesday meetings, and it helped to have more group interaction. More formal meetings would be beneficial.

Sometimes we may have been a bit too optimistic in our individual declarations of being able to do something quickly or the ease in which something could be done. It is probably part of human nature, but it is sometimes difficult to ask for help when one is having problems. This is especially true when working with one’s peers. It makes sense that when pride and self-image is not an issue, one is more willing to risk asking what he or she believes is a stupid question. It is important to maintain r espect and to take risks when communicating.

Our team was well defined from the start. We all knew that most of us had no experience in building such a game, but that we all had interests that we wanted to explore. Keith enjoys graphics, so he was one of the main Graphics module writ ers, and he imported the 3D models. Matt L had programmed in Windows before, so he helped developed the System module and game logic, as well as integrated the Sound module. Matt V adapted DirectPlay network code into the game. Kent helped build the Sy stem module and researched DirectInput to build the Input module. Brett created the Sound module, helped create the Graphics module, and maintained the Team Nort web site. The division of labor was clear until a given person was done or stuck with their portion of the project. In retrospect, one thing that should be done on future projects is the assignment of secondary tasks with the knowledge that some tasks will be completed before others. For example, we knew that the System, Input and Sound modul es would probably be completed before the graphics were complete, so the secondary tasks, like model conversions, should have been assigned to one of the people who would have finished early.

The organization of the team itself was good. There was a good knowledge base around each module. Earlier in the development process there could have been more team members devoted to graphics. One of the most difficult parts of working in a team is not knowing everything that is happening at once, even within one’s own module (if multiple people are working on it). Understanding code written by others is essential so that it is possible to contribute to other parts of the project when they need mo re work. If we had to do it all over again, it would be good to provide better module documentation and tutorials or explanations to the group.

Did we have all the information needed to do our job? Yes, as far as team dynamics are concerned. For the most part, people were around to ask questions, or could be contacted easily via email. In the future, during integration, it would be very hel pful to have every team member whose code is involved to be present in the lab and grind through it until it is complete.

Although we had our rough edges and argued once in a while, the team worked well together. The tough parts of working together were during integration of graphics and system code. Miscommunication, lack of understanding each other’s code, and lack of understanding Windows functions were the root of the problem. Before and after the period of integration, the team worked very well together. It is important to note that our group decided to not elect a single leader, but to make decisions together. At times it might have been better to have a leader who could make solid decisions that the rest of the group could follow. It seems that at various points throughout the project each of us was the team leader.

In retrospect, we love our game and our end product. If we could do it over now that we understand DirectX and Win32 API code better, we would make it better. We feel bad that we disappointed our audience when the frame rate became too slo w at the colloquium, and as proud as we are of our accomplishment in spite of this, this will forever keep some of the gloss off of it. We feel our presentation problems were caused by a lack of performance evaluation under the constraints of the present ation and by a poor decision made to demonstrate a feature which we knew had declining performance as it was used. In the future we will be more conservative when it making sure we provide enough time for testing and when it comes to our willingness to & quot;risk it all" on a newly added feature.

Perhaps the biggest thing to improve future products is to remember a very simple maxim: what the audience sees is all that matters. Our audience does not know or care how our code looks, what code we can reuse, how difficult something was to a chieve, etc.; all they care about is whether it looks and sounds good and is fun to play. When adding a feature, we should have considered more closely how much adding that feature would improve the quality of the final product. In short, we should have spent more time examining our work in general through the eyes of our target audience.

Our system of bug tracking actually worked quite well for us. What was our system? One team member developed a bug database in MS Access for us to use, but our group was small enough that direct communications via email were enough for us to get bugs tracked down and taken care of without the additional overhead of the database. The database looked great and was fully functional, but it simply wasn’t necessary for our purposes.

Source code control, on the other hand, was definitely an issue for us during the quarter. The first problem was that the tool we chose to use, MS Visual Source Safe, was unfamiliar to most team members and everyone was anxious to get to work on the p roject and no one wanted to spend time learning how to use it. Another difficulty we had was that we didn’t have enough policy guidelines ahead of time as to what our directory structure would be for the project. This impacted both our development envir onment and our source control directory structure; we had talked about what types of files to add to source control and which to leave out, but we hadn’t specified where files should be added. We ran into a situation mid-quarter where the same fil es were checked in at multiple places, so no one knew which files were the correct ones to check out and modify. Yet another problem was that Source Safe makes it very easy to "shoot yourself in the foot" when it comes to setting working folder s, requiring the Source Safe administrator for the class to spend time throughout the quarter helping multiple groups in the class getting this straightened out.

How could we have avoided these problems? We are happy with Source Safe as the source control tool and would use it again, so we do not feel the problem lies there. Probably the most important thing we should have done, though no one really wanted to do this, was to invest some time at the start of the project for the purpose of educating ourselves on how the tool worked and what pitfalls were out there. In addition, we should have spent more time in the design stage deciding how our directory struc ture would look and deciding on a more complete policy on where files would be checked in, etc.

Our development environment, MS Developer Studio, was a solid environment for our compilation, linking, and debugging, with enough ways to do things that all of us learned from one another how to better use it. Of course there was the occasional messa ge that "This program has performed an illegal instruction and will be shut down" immediately upon starting the program, but this was rare and not a significant problem in the scheme of things. We did run into a couple of complications, though.

One was that our project was composed of a static library in addition to the main project, which complicated the build process. The use of the static library was justified as a logical separation between game independent and game dependent source, wit h the reasoning was that the game independent source would change rarely, so it would not have to be build often and changes to the game dependant source would not require rebuilding the game independent source. A problem with this idea, though, was that the development process was short enough that there was never really time for the static library to stabilize, and hence group members did find themselves rebuilding it often. While the result is we now have a game independent library of source to work with for the future, this will not help us with the particular product we have released, which is really what counts; perhaps this issue should be chalked up to a difference between a real world company, which makes multiple products and so depends on cod e reuse, and 10-week class in which all code can be considered disposable.

Another problem was we originally intended to use a global include file so that deciding what files you needed to include would be brainless, but we simply couldn’t get the technical details of this working, and so it just ended up being a big pain and a waste of time, unfortunately. Were we to face another project, this would be something we would want to try out ahead of time with some test cases to make sure it is feasible before we assume it will be possible to do in the project.

Because our application was non-windowed, this also made our debugging much more difficult. We took a couple of approaches to overcome this deficiency. One was that through the use of #defines we made it easy to change between windowed and non-window ed mode, thus whenever possible we would use full-screen, windowed mode to work out the bugs, but release in non-windowed mode for speed. Unfortunately there were several debugging issues in non-windowed mode that were not issues in windowed-mode, hence necessitating our next tactic: logging. We developed a very simple, yet extremely useful logging utility for keeping track of what was going on as our program executed since we couldn’t step through it. This logging utility turned out to be critical to the success of our project. What we really would’ve liked to do was use Developer Studio’s "remote connection" facility, which would allow us to execute our binary on one machine while we debugged it on another, thus we would have been able to debug in full-screen mode. Should we face another non-windowed project in the future, we will approach management and seek assistance with this, explaining how much development time would decrease were this available to us.

Perhaps a final thing to note was our emphasis on compiler warning level. While some members of the group thought it important to use the highest warning level, some members felt this amount of checking was unnecessary and created undue overhead. Our decision in practice was to let this slide, and our final build will not build in the highest warning level. For future projects, we should discuss this issue ahead of time and decide as a group what to do so that we don’t have to deal with in the later stages of development, when all such issues should have been dealt with ahead of time.

As for coding standards, a few members pushed for them at the outset, but the group never got together and said "Yes, we want to do this", so as a result we really didn’t have any coding standards. For the most part this was okay because we respected personal property of code, but it did make it difficult to read and understand another person’s code when we wrote with a different style. The worst example of this was when we had multiple people working on one section and it required reformat ting the entire module so that it was readable to both people. This is another issue where programmers typically both are in too much of a hurry to start building to take time to do and which they dislike since it is inherently a restriction on the creat ivity of their own particular style, but we believe it would have made things easier for us if everyone’s code looked the same so we could better focus on content without being distracted by differences in appearance.

The only other tool we definitely needed was a model conversion tool for turning 3Dstudio models into DirectX models. We got around this during the quarter by sending our models off to Okino, which kindly agreed to perform the conversion for us using their PolyTrans tool, and if it wasn’t for their generosity we would have been out of luck. We recommend the department purchase this tool for future quarters of the course, as it is very useful.

The only real qualm we have with our product was the performance problem seen at the demonstration. While we would have liked to have added even more features, we feel good about our product with its current feature set.

We definitely accomplished some great things with our product we can feel good about. We shipped on time. The product we shipped is stable. It looks and feels like we imagined it would at the outset. We implemented many of the "features" w e hoped we would be able to get done. Our code base is ready for future tinkering. We formed new friendships, and learned to work better in groups. Most important, we now have a reservoir of knowledge about how to design software systems.