Project Legacy

COP 4331C, Fall, 2014

Modification history:

Project Name: 2D Action Shooter

Team Web site:

Team Members:

• Adam Stack - bigstack80@knights.ucf.edu - web page
• Horia Ionescu - ionescu@knights.ucf.edu - web page
• Remo Gutierrez - Remog@knights.ucf.edu - web page
• Michael Paulsen - Michael.Paulsen@ucf.edu - web page
• Tyler Harbin-Giuntoli - Tyler@knights.ucf.edu - web page
• Ross Pape - ross.pape@knights.ucf.edu - web page

Roles

Analysis

• Assessment of the Quality of the Final Product:
  Our group is happy with what we were able to accomplish throughout this semester. Not only did we learn how to create the documents and planning necessary to complete a large project we also were able to make a working game from scratch. We are most proud of the fact that a user can hop into the game, play multiple levels, pick up in game items and be challenged by our scoring system and ammo limitations.
• Recommended Use of the Final Product:
  The final project is recommended for the use of any individual who likes to play 2D arcade shooter type games. Another great thing about our game is that it can serve a a great learning tool for using unity to create a basic game. This is especially true since our code is publicly available at https://github.com/bigstack80
• Known Problems:
  Some problems that we ran into was creating a character that could be leveled up by assigning experience points to certain attributes. We were however able to increase the characters attributes like health and fire rate through the in game pick-ups though.
• Adherence to Project Plan:
  In retrospect, the project plan as originally implemented by our group was a bit ambitious, though the majority of the features we wanted to use in our game were successfully put in place. That there were certain aspects that were not implemented was partly due to the limited experience of group members in working with the Unity development platform. Understanding its functionality was a big part of learning process, which took place simultaneously as the designing of the project plan. There were many unknown factors that were only revealed as certain issues were dealt with for the first time. The actual process as deviated from the original plan sort of took its course as certain unplanned issues revealed themselves. This in no form should be taken as a failure of the group as a whole. In tackling a project of this type where the group utilized a never before used platform, the value in experience attained in using Unity in conjunction with C# and GitHub source control far outweigh the deviation of goals set.
• Defect Analysis:
  We did a really good job limiting the amount of defects that were found during testing by having the developers help with testing each code change themselves. This made the game more bug free and easier to diagnose issues that we did see.
• Quality Assurance:
  Quality assurance and testing activities as performed by the group were utilized on an as need basis as opposed to a more formalized approach. As the project plan was more of a sketch of the goals we aimed to attain as opposed to a concrete set of guidelines, it was much easier to implement quality checks in a more generalized fashion as opposed to try and set something more specific ahead of time. Considering the approach we used to design this game, our quality assurance activities as performed were sufficient for our needs. To improve on how we implemented our testing activities would have required a different approach to our project plan in general. As no group member had a solid grasp on Unity before beginning this project, our approach to project planning and quality assurance were deemed appropriate for the task at hand.
• Configuration Management:
  Similar to the general approach in design of our project, configuration management practices were not strictly set. A clearer understanding of how certain implementations would have to have been set ahead of time would have been required before a more solid plan for configuration management could be formalized. As mentioned before, the group members’ inexperience at the initial stage of planning made it difficult to achieve this. Considering our approach to tackling the project, appropriate guidelines were set into place.
• Suggestions for the Future:
  If our group was to do a similar project in the future, we would have the benefit of having had experience using Unity to allow for a clearer understanding of what goals could be successfully implemented considering the task at hand. As a suggestion to future project teams that would have tackled this project with the same experience we had at the beginning of this project, different and specific portions of the project should be assigned to each member. As there was no specific team member in our group who had an overall grasp of what such a project would entail, it would be difficult for all members to master every aspect of the project as a whole. A more efficient method would be in tune with an agile methodology where each member tackled a separate portion of the project. Efficient communication between group members is essential. If assigned to work on a project of a much larger magnitude, stronger organization along with appropriate delegation of tasks to individual team members would be key.

Template created by G. Walton (GWalton@mail.ucf.edu) on Octber 8, 1999 and last modified on August 15, 2000.

This page last modified by Adam Stack (bigstack80@knights.ucf.edu ) on 11/24/2014