HeaderSIS.jpg

IS480 Team wiki: 2010T2 CrusNitor Final

From IS480
Jump to navigation Jump to search
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 the progress made and benchmarking it against the

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