HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2010T2 CrusNitor Final"

From IS480
Jump to navigation Jump to search
Line 172: Line 172:
 
   
 
   
  
The statistics we can derived from the number of bugs metric will allow us to forecast on any possible delays that we may encounter during the course of the project. However, due to the
+
The statistics we can derived from the number of bugs metric will allow us to forecast on any possible delays that we may encounter during the course of the project. However, due to our intent of completing all the required components in order to achieve a stable and playable game by Code Freeze milestone, we had been more focused on the development work initially and had worked on the show-stopper bugs in the initial stages of the bug metric documentation. We did more extensive testing from the Code Freeze milestone onwards as we seek to refine our application. During these testing phases, we documented more bugs, as shown in the diagram below.

Revision as of 05:15, 18 April 2011

IPhone4 screen1.jpg

Project Progress Summary

Click here to view our Main Wiki Page.
Click here to view our Facebook Poster Day / Game Demo Day.
Click here to view our final presentation slides.

Project Highlights

Slowdown in Arts Asset Production

A week after our mid terms presentation, we experienced a slowdown in the production of the arts assets from the design team. This is because every member of the design team were busy with their own current jobs/projects on hand. As a result, the arts asset development came to a trickle and caused us some bottlenecks in our development work. At that point of time, we only had the paladin animation on hand. It severely affected our progress and caused delays in our project schedule. The effects of this problem on our schedule will be discussed later on in the Planned vs Actual portion of the Project Management section.


We have already highlighted this problem as part of our risk assessment done for our project. We defined the likelihood of this risk occurring as high, for we expected it to happen given our unfamiliarity with game development lifecycle. When this risk occurred and affected the progress and schedule, we executed the mitigation strategies that we had defined for this problem. Among the steps that we had taken:


  • For the problem of falling behind schedule, we began to put in overtime work. We work longer hours and meet up on extra days to catch up with our schedule.
  • We divert our attention and resources by working on the other components of the project. This is done by expanding the foundational works in preparation of receiving the arts assets, such as stabilizing the libraries, architecture and engines further.
  • We also improvised as and where we can. Given that we do not have any enemy assets at that point of time, we reused our paladin asset. We colored the asset black and used as the enemy characters. As we had designed the application to be data driven, we can easily replace these black paladin assets with the enemy assets when they are developed in the future by changing its reference to the database of assets without changing anything within the codes.
  • We worked much more closely with the design team by having more correspondence with them. This allows us to understand their situation better and also relay our own deliverables so that they are able to appreciate our situation. We met up more often and at times, we worked together on site, side by side with each other in order to accelerate our development work.
  • We re-scope certain portions of our projects in order to have more realistic deliverables for IS481. It is important to note that we are still intent on meeting the original scope after the tenure of our IS481.

Low Frame per Second (FPS) Performance

During our mid terms presentation, Professor Jason had expressed his concern on the low FPS performance of the game. He was worried that it might be a big problem that if remained undetected, could affect our application in the later stages and cause us to revert our codes. While initially we dod not think that it is an issue, we followed up on his feedbacks and worked on finding the source of the FPS performance. We had traced the cause to the memory leaks that had occurred within the execution of our application. On hindsight, this issue could have been a serious problem if we had let it go unchecked. Finding the source of the problem raise the awareness and importance of memory management in our development work. We were more careful and attentive to memory leaks issue, allowing us to keep to our aim of producing a stable and working application.


Project Challenges

While challenges can be frustrating, we believe that challenges presents as opportunities for us to learn rather than an obstacle for progress. The following are the summary of the challenges that we had experienced during the course of our project.

Management of external stakeholders

This is the first project whereby we have to manage an external stakeholder (the design team) that is critically involved in the development of our project. The design team is made up of an artist, an animator and a designer. Given the diverse talents and background, it was initially daunting for us SIS students to work with people from background and disciplines outside of the SMU curriculum. We weren't sure if we will be able to speak the 'same language'. Furthermore, it was a challenge to manage our diverse schedules for common time slots to meet.


We feel that it had been a good learning experience. We are able to do what we are taught to do, which is to find the middle grounds of communication between the technical and business aspect of projects. Furthermore, it is also our first time managing a real life outsourcing situation of a core component of our project. We also learned to work with personnel of different backgrounds, behaviors, skill sets and working styles. We are glad to have been able to experience this challenges during the course of our project.


Technology and Complexity

The concepts we introduced for our project were new and not prevalent yet. Thus, we had very little sources of references, in terms of networking and message passing and queueing between devices. Furthermore, it is our first foray into game development. It was extremely challenging to develop the architecture and build our own libraries from scratch. Further adding on to this challenge is the usage of the programming language Objective C, which we are very unfamiliar with and took time to familiarize with its syntax, which is very different from the languages that we have been exposed to in SIS.

The workaround to this challenge is to build up our foundational skills and knowledge in the domains mentioned above. The pair programming methodology helped a lot in helping the weaker coders within the team to accelerate their learning process. We did a lot of research and deliberations in planning and building up the application architecture and libraries. We leverage on existing frameworks which helps us to cope with some of the complexities involved.


Project Planning

Planning the project management component for a gaming application is very different from the planning that we have done for our previous web application projects. We had to familiarize ourselves with the game development lifecycle. It was also difficult to foresee the kinds of components that we need to develop while planning our schedule. It was also difficult to estimate the time we need to develop each component within each iteration. Again, there was very little points of reference for us to rely on.


We overcome this challenge by heavily leveraging on Jaryl's experience in the game development module that he took while he was in polytechnic. We also leverage on Clement's contact and experience in LucasFilm where he had interned at for the past two summers. These two measures helped us to formulate a better approximation to our project management components.


Project Achievements

  • Creation of network connectivity between multiple devices from scratch.
  • Develop a stable and playable version of the game.
  • An application that functions based on the concepts of data-driven, event-driven and component-based.
  • Good collaboration with design team, whom are critical external stakeholders for our project.
  • Approval from UAT users, with over 90% saying they will play the game again and 80% willing to download the game.


Project Management

Project Schedule (Plan vs Actual)

Our project schedule is planned in such a manner that we have a milestone to meet at the end of each iteration. This is to help us quantify our progress at the end of each iteration, allowing us to keep track of and benchmark it against the progress we have made during the course of our project.

Iteration Milestone Planned Date Actual Date Comments
Elaboration Iteration 1 Completion of Prototype 24 Dec 2010 24 Dec 2010
Elaboration Iteration 2 Multi-device Connectivity 14 Jan 2010 14 Jan 2010
Construction Iteration 1 Game framework 21 Jan 2010 21 Jan 2010
Construction Iteration 2 First Functional 1 Feb 2010 1 Feb 2010
Construction Iteration 3 First Playable 18 Feb 2010 28 Feb Feb 2010 Delay in the delivery of arts assets. Also due to academic commitments from other modules
Construction Iteration 4 Alpha + Start of UAT 11 Mar 2010 18 Mar 2010 Overspill effects from the delay experienced from First Playable milestone
Construction Iteration 5 Code Freeze 25 Mar 2010 31 Mar 2010
Transition Demo version 14 Apr 2010 14 Apr 2010


Besides the delay experienced, we also faced constraints in terms of resources. The two illustrations below shows the initial scope that we had defined for ourselves initially, whereas the next diagram shows the re-scoped project quantification that we had defined towards the later part of the project. We had to scale down our ambitions as we did not have enough manpower, resources, time and funding to meet our original goals. After consultations with our supervisor, we decided to focus on delivering a working, stable product. While we scaled down the scale of the project, we still adhered to the deliverables that we set upon ourselves, with the exception of AppStore submission which we decided to hold off until we are able to meet the standard that we had set within our initial scope.


Initial scope.jpg Rescope.jpg

Project Metrics

Schedule Metric

As mentioned in our mid terms section, we had set aside a buffer time of 10 days within the project schedule. This buffer time acts as a safeguard to give us some allowance in the event that we fall behind time. This buffer time can also act as the spare time for us to work on extra features that we would like to develop in the future or introduce features that we have overlooked during our preliminary planning. We designed a schedule metric that takes into account the number of buffer days left. Thus whenever we go beyond schedule, we will deduct the number of days that we have gone beyond the schedule from the buffer day bank. The remaining buffer days left at the end of the development phase (Code Freeze milestone) will be exhausted for the purpose of refining the final product meant for presentation and poster day.


We have color coded the status of the balance to reflect the gravity of the situation as follows:


Green – 8 days or more left
Yellow – 4-7 days left
Orange – 0 – 3 days left
Red – less than zero days left

We would want our schedule status to remain at least in the yellow zone. Should we ever hit the orange or red zone, we would then know that we have to take drastic measures to overcome the predicament. Optimally, we would want to leave the amount of buffer time we have untouched for rainy days. However, realistically we may experience delays throughout the project. During mid terms, we had defined that the highest risk that can our team face is the delay in schedule due to the factor of getting the game art asset production to keep pace with the speed of development. This risk had became a reality during the course of our project, specifically after the mid terms presentation. Due to work commitment, the design team was not able to churn out arts assets in accordance to our timeline, causing a bottleneck in the development process.


Schedule metric.jpg


Given that we are oriented towards meeting our milestones as our target, we have produced a graphical illustration of the schedule metric that occurred during the course of the project as shown above. We had gone into the orange status during the First Playable milestone and continued to be in the same status as we approached our Alpha milestone. During this time, we implemented the mitigation strategies as mentioned in the above Project Highlights section. We managed to push the status to yellow status for the remaining milestones that we have left in the course of the project.

Bug Metric

As covered during the mid terms, we have designed a metric that helps us to track and trace the bugs encountered. The main units of measurement for the metric are the total number of bugs raised and resolved.


The statistics we can derived from the number of bugs metric will allow us to forecast on any possible delays that we may encounter during the course of the project. However, due to our intent of completing all the required components in order to achieve a stable and playable game by Code Freeze milestone, we had been more focused on the development work initially and had worked on the show-stopper bugs in the initial stages of the bug metric documentation. We did more extensive testing from the Code Freeze milestone onwards as we seek to refine our application. During these testing phases, we documented more bugs, as shown in the diagram below.