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 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.

Bug metric.jpg

Technical Complexity

The technical complexity of our project can be categorized based on the following areas:

  • Programming Language
  • Architecture
  • Graphics and game art
  • Game concept
  • Software

Programming Language

The programming language utilized for our project is Objective C, which is required to develop on iOS devices. The structure and syntax of this language is extremely new for us, even for those with C/C++ background, upon which Objective C is based on. Unlike programming language such as Java, Objective C is based on message passing and does not have a garbage collector (on iOS).

It was extremely challenging for us to pick up Objective C in the relatively short time that we have before we started our development work. While we are only aiming to get the basic proficiency needed for us to work on the project, we still learn new things about the language every day.


The usual methodology of object-oriented programming that we learn is usually based on an inheritance hierarchy. For the purposes of our game however, we adopted a component-based architecture. A component-based architecture allows us to introduce the element of reusability without committing to statically defined relationships at compile time. Using a component-based architecture, reusable components are dynamically loaded at run-time when the game is loaded.

For instance, within our game, there are multiple assets that share the same components of health. The component-based architecture allows us to create a generic health component. The health component can be shared by different entities, with each entity owning its own copy of state data.

In addition, we made sure to make our game data-driven, as component and entity data are stored in a local SQLite database, which is loaded unto the device. This makes it easy for us to make changes to the game when we are tweaking it for testing purposes as we need not change codes, or recompile them (there is however, a time factor for packaging the application that increases as the game gets larger).

To reduce memory usage (which is a scarce resource on mobile platforms), we also developed a system of storing shared data using the flyweight design pattern. For example, all enemy swordsmen share the same spritesheet (image) and thus we have a swordsman flyweight that stores a single copy of this image in memory. This allows us to generate greater numbers of enemies, each with its own state data, without bogging down the game.

To manage the complexities of the game mechanics, we developed a message queuing system that enables entities to talk with one another, but not directly. This reduces coupling between entities and allows us to define and apply business rules over message passing (pausing the game will be a matter of not processing game messages). Each entity also implements a finite state machine (FSM) that allows them to react realistically to different game messages based on their current state.

Graphics and game art

We are also exposed to the different stages of game art and assets development, courtesy of the design team that is collaborating with us for this project. The art is first drawn and sketched by our artist and is put forward for amendments and approval. Once approved, the artwork is then digitized and modified to fit to our game context. Animation is then added to induce movements and actions on the assets. The design team is also responsible for the design and production of the game UIs. We are appreciative to have been exposed to this aspect of game development, as no one within our FYP team has any prior knowledge nor experience with art and animation design.

Game Concept

The game concept is relatively new and not yet prevalent in the gaming scene. Using the iPad as a console and iPhones as game controllers as a concept is still in its infancy stage and there is very little games within the iTunes AppStore that adopts this methodology. Hoping to be a trendsetter, we have almost no points of references to model our project after, further adding to the complexity of the project. We believe that our concept can be assimilated into the work processes of the corporate world. We believe that our concept can be expanded to other types of application such as utilities and productivity applications.


We have utilized multiple software during the course of our project. Given the nature of our project, we are exposed to many new software which we had not have the opportunity to do so during the course of our education in SIS. The software that we use include:

  • XCode - IDE required for iOS development
  • Zwoptext - creation of sprite sheet for Cocos2D platforms
  • Navicat - GUI for SQLite database
  • Unfuddle - Prime tool for project management. A web application for repository, subversioning, milestone tracking and tickets/ issue tracking.

Quality of Product

Project Deliverables

Story board.

Use Case.

Raw data on ticket/issue reporting and tracking (inclusive of bugs reported).

UAT Feedback Form.

UAT Data Compiled.

Art Development Stages.




Network domain diagram.jpg

Project Architecture

Project Architecture.jpg

Event Passing Design

Event Passing design.jpg

Component based Architecture

Component based architecture.jpg


For the UAT, we conducted it in a focused group sessions comprising between 3 to 4 participants per session. Our target audience were young adults aged between the age of 20 and 35 years old. Each session lasts for about 5 minutes, where the participants were given the time to play and test out our game application. After session, each of them was told to fill in the UAT form.

We had a sample size of 45 participants. The UAT is based on a ratings and comments format. It focuses on the following four areas of the project application: graphics, storyline, gameplay and general areas. Within each area, we further broken them down into specific components so as to have a more precise feedback from the participants.


Team Reflection

  • Learn at a very fast speed
  • Learn new concepts that we would have otherwise never been exposed to
  • Improve in our abilities to resolve issues together
  • Learn the game development life cycle

Individual Reflection

Nyeow Siew Hui

In this project, I’ve learned the different phases of game development. Definitely an interesting journey not to be missed.

Jaryl Sim

In developing the game to be data-driven and component-based, I learned how to manage the complexities of a game.

Lim Hang Loon

Total exhilarating experience with different people with different skillsets. I have gained a deeper technical competency, communication, design and of course, lot's of fun!

Clement Wong

I was given the unique opportunity to contribute to game design by organizing game play to focus on technicalities, while preserving the entertainment aspects of the game experience.

Mohamad Fauzi

The management of game development provides a whole new dimensions. Its intricacies are very much different from that of normal web development projects that we are very used to. The complexity is further compounded by the management of the design component and external stakeholders whose contributions are very critical to the conceptualization and realization of the final product.