HeaderSIS.jpg

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

From IS480
Jump to navigation Jump to search
 
(26 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
=Project Progress Summary=
 
=Project Progress Summary=
  
The following are the chronicles of our IS481 journey up till the mid terms.
+
The following chronicles our IS481 journey up till the mid terms.
  
 
==Project Highlights==
 
==Project Highlights==
Line 7: Line 7:
 
===Steep Learning Curve===
 
===Steep Learning Curve===
  
We had underestimated the initial time we needed to learn and get fully accustomed with the programming language of Objective C. Initially we had estimated that we will need about 2 weeks to master the language. However, we took about 5 weeks to grasp the basics and concepts of Objective C. The difficulty arises from stark difference between the syntax of Objective C and Java, the language we are most familiar with. Further complicating the learning process was due to the fact that we also had to learn the frameworks of OpenGL and later on Cocos2D.
+
We underestimated the initial time we needed to learn and get fully accustomed with the programming language of Objective C. Initially we had estimated that we will need about 2 weeks to be proficient the language. However, we took about a month to grasp the basics and concepts of Objective C. The difficulty arises from stark difference between the syntax of Objective C and Java, the language we are most familiar with.
 +
 
 +
Initially, we sought to do the game in OpenGL, but later decided that it was too difficult for us to create a game engine on top of. We thus chose to use the Cocos2D graphic engine, which has allowed us to work on other aspects of the game.
  
  
 
===Freelance Designers for Game Art===
 
===Freelance Designers for Game Art===
  
One of the most major concerns of our project was the apparent problem of not having any graphic designers in the team. This is a critical area as besides the game play, the aesthetics of the game also forms a major component and attractiveness of any games. We are fortunate enough to link up with a group of freelance designers. They were kind enough to design and develop the animation for our game characters for free, on the condition that they are entitled to the ownership of the game assets.  Thus we developed an agreement where we will own the codes of the games and will feature a credit page within the game to give the designing team the due recognition for the game art.
+
One of the most major concerns of our project was not having any graphic designers in the team. This was a critical because the aesthetics are an important aspect of successful games. We have been fortunate to find group of freelance artists and animators, who would design and develop the animation for our game characters for free, on the condition that they are credited. All game art assets will belong to the artists/animators.
  
  
 
===Increased risk in terms of schedule and project control===
 
===Increased risk in terms of schedule and project control===
  
While the collaboration with the freelance design team was a boon for us, it also presented us with increased risks. We have to re-factor our timeline and produce a more agile development schedule. This is because the game art and asset production takes time. This means that we have to possess the flexibility of working on other aspects of the game while waiting for the assets to be produced. Subletting the asset development out to the design team also means that we have increased the risk of not having full control over one of the main aspects of game development. As such, we will have to take this new risk into account and come out with mitigation strategies.
+
While the collaboration with the freelance design team was a boon for us, it also presented us with increased risks. We had to re-factor our timeline and produce a more agile development schedule. This is because the game art and asset production would take longer and we would have no control over it. This risk meant that we could expect some downtime waiting for the assets to be produced. Subletting the asset development out to the design team also means that we have increased the risk of not having full control over one of the main aspects of game development. As such, we will have to take this new risk into account and come out with mitigation strategies.
  
  
Line 25: Line 27:
 
===Project Status===
 
===Project Status===
  
We have restructured our scheduling and development plans to induce more flexibility. This is so as to allow us to continue developing the game concurrently while the designers are developing the game arts assets. We aim to work on other aspects of the game whenever we experience waiting time from the asset development. This is to ensure that the project will keep on progressing. This also allows us to periodically analyze our game system and conceptualize development areas that we have overlooked during our preliminary planning sessions in the Inception and Elaboration phases.
+
We have restructured our scheduling and development plans to increase flexibility so as to allow us to continue developing the game concurrently while the designers are developing the game arts assets. With our rescheduled tasking, we can work on other aspects of the game when art asset production falls behind, ensuring continuos progress. Being more agile allows us to analyze our game system and conceptualize development areas that we have overlooked during our preliminary planning sessions in the Inception and Elaboration phases.
 +
 
 +
Values in below table are qualitative.
  
 
{| class="wikitable" cellpadding="15"  
 
{| class="wikitable" cellpadding="15"  
Line 37: Line 41:
 
|| Fully deployed and tested
 
|| Fully deployed and tested
 
|| 1
 
|| 1
|| May install a heartbeat mechanism to enhance it.
+
|| May develop heartbeat mechanism to check for dropped connections
 
|-
 
|-
 
|| Directional-Pad
 
|| Directional-Pad
Line 45: Line 49:
 
|-
 
|-
 
|| Primary attack
 
|| Primary attack
|| In progress 10%
+
|| In progress 30%
 
|| 0.9
 
|| 0.9
||  
+
|| Attack data should be data-driven
 
|-
 
|-
 
|| Special ability
 
|| Special ability
 
|| In progress 5%
 
|| In progress 5%
|| 0.8
+
|| 0
||  
+
|| Will be cut as the art team are not confident of delivering
 
|-
 
|-
 
|| Artificial Intelligence
 
|| Artificial Intelligence
|| In progress 15%
+
|| In progress 25%
|| 0.8
+
|| 0.7
||  
+
|| Implemented using finite state machines
 
|-
 
|-
 
|| Game score
 
|| Game score
Line 64: Line 68:
 
||  
 
||  
 
|-
 
|-
|| Health
+
|| Combat system
|| Started 5%
+
|| Started 15%
|| 0.2
+
|| 0.4
||  
+
|| Difficulty in designing a fun combat system
 
|-
 
|-
|| Basic UI Server-side
+
|| User interface (client & server)
 
|| In progress 10%
 
|| In progress 10%
 
|| 0.8
 
|| 0.8
||  
+
|| Waiting on art for more defined specs
 
|}
 
|}
  
 
===Project Schedule (Planned Vs Actual)===
 
===Project Schedule (Planned Vs Actual)===
  
Among the main realizations that we have made is that the development of the game artificial intelligence (AI) and game physics will have to be developed incrementally as the project progresses. This is very different from our initial conceptualization where we figured that we can develop these two components in a one-time off basis. These components will be continually build upon and revisited at the start of other iterations so as to ensure that the development is in line with our vision for the final game product.
+
We realized that developing the game's artificial intelligence (AI) and combat system will have to be done incrementally throughout project duration. This was very different from our initial expectation where we could develop these two components as a single deliverable. These components will be continually built upon and revisited at the start of other iterations so as to ensure that the development is in line with our vision for the final game product.
  
The 14 March deadline takes into account of our Alpha game version milestone and gives us some time allowance to factor in feedbacks from our UATs before we freeze our development work before the code freeze milestone is induced.  
+
The 14 March deadline takes into account of our Alpha game version milestone and gives us some time allowance to factor in feedbacks from our UAT before the code freeze.  
  
 
{| class="wikitable" cellpadding="15"   
 
{| class="wikitable" cellpadding="15"   
Line 104: Line 108:
  
 
|| Construction Iteration 2
 
|| Construction Iteration 2
|| Game Physics Development
+
|| Game Combat/Physics Development
 
|| 8 Feb 2011
 
|| 8 Feb 2011
 
|| 14 Mar 2011
 
|| 14 Mar 2011
 
|| Development will be ongoing instead of one-time off task. Will be revisited at the start of each iteration.
 
|| Development will be ongoing instead of one-time off task. Will be revisited at the start of each iteration.
 
|}
 
|}
 
  
 
===Project Metrics===
 
===Project Metrics===
Line 115: Line 118:
 
====Schedule Metric====
 
====Schedule Metric====
  
We had set aside a buffer time of about 10 days within the project schedule. This buffer time acts as a safeguard to give us time allowance in the event that we go 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.
+
We had set aside a buffer time of about 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.
  
  
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. The highest risk of this situation occurring is getting the game arts asset production to keep pace with the speed of development.  
+
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. The highest risk of this situation occurring is getting the game art asset production to keep pace with the speed of development.  
  
  
Line 131: Line 134:
  
 
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. This portion will be covered within the risk assessment and mitigation strategies section.
 
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. This portion will be covered within the risk assessment and mitigation strategies section.
 
  
 
====Bug Metric====
 
====Bug Metric====
Line 252: Line 254:
 
====Programming Language====
 
====Programming Language====
  
The programming language utilized for our project is Objective C. The structure and syntax of this language is extremely new for us. Unlike most other programming language, Objective C is based on message passing to object instances. Furthermore, it requires to have the interface and implementation components of its classes to be declared separately, by placing the interface in a header file and the implementation in a code file. The instantiation of the objects are done by allocating the memory first and then initializing it. It has a very different syntax as compared to most other programming language. Unlike in Java, we have to handle the garbage collection by ourselves in Objective C. These new learning points (and many more) made it extremely challenging for us to pick up Objective C in the relatively short time that we have before we started our development work. Even till today, we are still learning and familiarizing with the 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.
  
 
====Architecture====
 
====Architecture====
  
The usual methodology of coding in Objective C is usually based on the inheritance hierarchy. For the purpose of our game application however, we had adopted a component-based architecture. A component-based architecture allows us to introduce the element of reusability and allows us to develop programs quickly. 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 all the assets, where adjustments can be made to the health properties of each individual asset.
+
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.
  
We also adopted the Cocos2D framework for our game development purposes. Cocos2D is a framework for developing 2D games and graphical applications. This open source framework allows us to maximize the flexibility it induces and optimized data structures. It also has an active community, allowing us to have sources of references for our development. Many game development elements are present within this framework, allowing us to have a relatively easier and faster time developing the game application.
+
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====
 
====Graphics and game art====
Line 275: Line 282:
 
====Software====  
 
====Software====  
  
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. Among the software that we had utilized are:
+
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:
  
 
<ul style="line-height: 140%;">
 
<ul style="line-height: 140%;">
<li> XCode - IDE for Objective C</li>
+
<li> XCode - IDE required for iOS development</li>
<li> Tower - a tool we utilize for subversioning our codes and collaborative work </li>
+
<li> Tower/Git - a tool we use for versioning and sharing our codes</li>
<li> Zwoptext - creation of sprite sheet </li>
+
<li> Zwoptext - creation of sprite sheet for Cocos2D platforms</li>
<li>Photoshop/ Illustrator - Editing of graphics </li>
+
<li> Navicat - GUI for SQLite database</li>
<li> Navicat - for database purposes</li></ul>
+
<li> Unfuddle - web application for bug tracking (also hosts our git repository)</li></ul>
 
 
  
 
==Quality of Product==
 
==Quality of Product==
Line 289: Line 295:
 
===Use Case===
 
===Use Case===
  
 
+
[[Image:Use Case CN.jpg|400px]]
  
 
===Game Framework===
 
===Game Framework===
  
 
[[Image:Game Framework.png|300px]]
 
[[Image:Game Framework.png|300px]]
 +
 +
 +
===Component Architecture===
 +
 +
[[Image:Component Architecture.png|500px]]
 +
 +
 +
===Game art Sketches===
 +
 +
====Archer Character====
 +
 +
[[Image:Archer.jpg|500px]]
 +
 +
 +
====Mage Character====
 +
[[Image:Mage.jpg|200px]]
 +
 +
====Warrior Character====
 +
[[Image:Swordswoman.jpg|300px]]
 +
 +
===Digitized Assets===
 +
 +
[[Image:All char.png|500px]]
 +
 +
 +
==Reflection==
 +
 +
===Jaryl Sim===
 +
Learning iOS development was something that I wanted to do but was put off until now. IS481 has been a great opportunity for me to pick up what I think is a valuable skillset. Having been a C/C++developer, it was a surprise to me how different Objective C was but thankfully we found Cocos2D which helped remove some of the project's complexity, especially when dealing with graphics.
 +
 +
I was in charge of the game's component-based architecture, and am glad to find that our early efforts are now paying off since the team is able make changes to the game easily once they understand how the architecture works. It was a fairly easy task of developing additional functionality into the game by encapsulating them as an additional component.
 +
 +
Also, working with the artists and animators has provided us with first-hand insight into how art teams work and also made us some new friends.
 +
 +
===Clement Wong===
 +
My passion was to develop games as a career and thus, IS481 helped spearhead my first game development project on the iOS platform. Though I may have knowledge in C/C++, Objective C is a different level of programming that I have ever done. Therefore, the learning curve was steep, and is still steep, but the technical skills obtained is priceless.
 +
 +
I was in-charged of getting the graphics into the game and making the animations work well with player controls and AI behaviors. I had to use Zwoptex to create sprite sheets of animations with each individual sprite's coordinates optimized for use with the cocos2d framework. It was hard learning the technicalities, but I picked it up fast, and end up having lots of fun implementing the game art into the game and bringing the game to life.
 +
 +
Lastly, I had the privilege to work with concept artist, designers and animators. Seeing them create amazing art work for the game, gives me drive and excitement to work on the game. It also grants me a great opportunity to work with other professionals from another industry.
 +
 +
===Siew Hui===
 +
Seeing the increasing trend of iPhone users, I have been wanting to pick up iOS development. IS481 is the best avenue for me to test the waters and until now, it has been a fun and enjoyable learning experience.
 +
 +
I am being put in charge of the physics and UI component. These tasks gave me a good overview of the whole project as the physics component is applicable throughout the game. Also, I have to pick up both Objective C and coco2d concepts after realizing that cocos2d framework is easier for game development.
 +
 +
I am looking forward to the upcoming development work and I foresee it will be as exciting.
 +
 +
===Hang Loon===
 +
 +
The past few weeks of working on the project has been difficult yet fulfilling. Not only I get to learn one of the most popular programming language from scratch but also able to work with a group of enthusiastic peers. Game designing and programming have also gave me a different exposure.
 +
 +
I was in charge of programming some component modules and to implement database connectivity into all modules, ensuring that we can add/remove/update values and configuration easily.
 +
 +
It's halfway down the road and this product is going to be an exciting one.
 +
 +
===Fauzi===
 +
 +
Working as a project manager for a iPhone game application has been a very eye-opening experience for me. It is drastically different from the other SIS projects that I have done and managed. The mechanics in game development is very dynamic and requires a lot more foresight and considerations during the planning process. It has a lot more components (connectivity, game design, assets management, sprites etc), so much so that every step of managing this project has been a new learning experience. The learning experience is so enriching that I do not feel the frustration of having to revise the project schedule multiple times. Having to work with the design team also opens up a new dimension in project management, for now I have to coordinate two timelines and ensure that the progression of both the asset production and application development keeps pace with one another and complement each other in the process.

Latest revision as of 10:23, 17 February 2011

Project Progress Summary

The following chronicles our IS481 journey up till the mid terms.

Project Highlights

Steep Learning Curve

We underestimated the initial time we needed to learn and get fully accustomed with the programming language of Objective C. Initially we had estimated that we will need about 2 weeks to be proficient the language. However, we took about a month to grasp the basics and concepts of Objective C. The difficulty arises from stark difference between the syntax of Objective C and Java, the language we are most familiar with.

Initially, we sought to do the game in OpenGL, but later decided that it was too difficult for us to create a game engine on top of. We thus chose to use the Cocos2D graphic engine, which has allowed us to work on other aspects of the game.


Freelance Designers for Game Art

One of the most major concerns of our project was not having any graphic designers in the team. This was a critical because the aesthetics are an important aspect of successful games. We have been fortunate to find group of freelance artists and animators, who would design and develop the animation for our game characters for free, on the condition that they are credited. All game art assets will belong to the artists/animators.


Increased risk in terms of schedule and project control

While the collaboration with the freelance design team was a boon for us, it also presented us with increased risks. We had to re-factor our timeline and produce a more agile development schedule. This is because the game art and asset production would take longer and we would have no control over it. This risk meant that we could expect some downtime waiting for the assets to be produced. Subletting the asset development out to the design team also means that we have increased the risk of not having full control over one of the main aspects of game development. As such, we will have to take this new risk into account and come out with mitigation strategies.


Project Management

Project Status

We have restructured our scheduling and development plans to increase flexibility so as to allow us to continue developing the game concurrently while the designers are developing the game arts assets. With our rescheduled tasking, we can work on other aspects of the game when art asset production falls behind, ensuring continuos progress. Being more agile allows us to analyze our game system and conceptualize development areas that we have overlooked during our preliminary planning sessions in the Inception and Elaboration phases.

Values in below table are qualitative.

Features Status Confidence Level Comment
Wireless connectivity Fully deployed and tested 1 May develop heartbeat mechanism to check for dropped connections
Directional-Pad Fully deployed and tested 1
Primary attack In progress 30% 0.9 Attack data should be data-driven
Special ability In progress 5% 0 Will be cut as the art team are not confident of delivering
Artificial Intelligence In progress 25% 0.7 Implemented using finite state machines
Game score Not yet started 0
Combat system Started 15% 0.4 Difficulty in designing a fun combat system
User interface (client & server) In progress 10% 0.8 Waiting on art for more defined specs

Project Schedule (Planned Vs Actual)

We realized that developing the game's artificial intelligence (AI) and combat system will have to be done incrementally throughout project duration. This was very different from our initial expectation where we could develop these two components as a single deliverable. These components will be continually built upon and revisited at the start of other iterations so as to ensure that the development is in line with our vision for the final game product.

The 14 March deadline takes into account of our Alpha game version milestone and gives us some time allowance to factor in feedbacks from our UAT before the code freeze.

Iteration Feature Planned Date Actual Date Comments
Construction Iteration 2 Milestone First Playable Version 11 Feb 2011 25 Feb 2011 Delays in game asset production
Construction Iteration 2 Game AI Development 28 Jan 2011 14 Mar 2011 Development will be ongoing instead of one-time off task. Will be revisited at the start of each iteration.
Construction Iteration 2 Game Combat/Physics Development 8 Feb 2011 14 Mar 2011 Development will be ongoing instead of one-time off task. Will be revisited at the start of each iteration.

Project Metrics

Schedule Metric

We had set aside a buffer time of about 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.


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. The highest risk of this situation occurring is getting the game art asset production to keep pace with the speed of development.


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. 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. This portion will be covered within the risk assessment and mitigation strategies section.

Bug Metric

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, resolved and closed.


  • Bugs raised – Refers to the bugs that are found by the tester and referred to the developer team for resolution.
  • Bugs resolved – Refers to the bugs that have been solved by the developer team.
  • Bugs closed – Refers to the authentication that the resolved bugs have ceased to produce the failed test case outcome and the bug report closed. This acts as a 2nd layer of check.


Bugs found will be prioritized by the tester in the test case documentation. Bugs that have higher priority will be put in front of the queue so that it can be resolved first. The priority level are assigned by the following guideline:

  • Priority 1 bug - Bugs that affects core functionalities of the application critically and in need of urgent resolution
  • Priority 2 bug - Bugs that affect the game play of the application but not in a critical way.
  • Priority 3 bug - Bugs that are minor in nature and does not cause major disruption to the game play


The statistics we can derived from the number of bugs raised, resolved and closed will allow us to forecast on any possible delays that we may encounter during the course of the project. For instance, having numerous unresolved Priority 1 or 2 bugs would signify possible bottlenecks in the development work, as these bugs would not allow nor facilitate the later development works to function properly.


Project Risks

Risk Assessment

The following are the revised risk assessments we have made since our Inception Phase.

Risk ID Risk Likelihood Risk Impact Comments
1 Slow progress due to steep learning curve of Objective C Medium High Likelihood raised to 'medium' from previously 'low'. We had underestimated the complexity of learning the language and relevant frameworks needed for the game development. Even at this stage, we are still learning many new things with regards to the Objective C language.
2 Lack of experience in game development Medium High Likelihood lowered to 'medium' from 'high'. We have coped well with the development work. Our main developers Jaryl and Clement had been spearheading the direction and coached the team with the mechanisms of game development. Referring to books and online forums has helped to mediate this risk.
3 Fall behind schedule High Medium This risk came about as the game art assets production will take time and not keep pace with the development work.
4 Lack of control over game art asset production Low Medium This risk comes about as we have let out the design portion of the project to the design team.


Risk Mitigation Strategy

Risk ID Mitigation Strategy Mitigation Type Risk Impact after Mitigation
1
  • Initiate a familiarization and training period during Inception Phase.
  • Conduct peer tutoring
  • Pair programming by pairing stronger coder with a weaker one
  • Walk the team through the codes of newly developed features
Reduction Medium
2
  • Leverage on Jaryl's past experiences in game development.
  • Leverage on Clement's past experiences interning for LucasFilm.
  • Research and read up on game development with specific to iOS games and Cocos2D framework
Reduction Medium
3
  • Work overtime to meet deadlines and milestones.
  • Rescope parts of the project, focusing on the essentials and leaving the additional parts for later development.
  • Reuse available assets to facilitate development and replace these assets when the actual assets are ready
  • Work closely with the design team and always do a followup on their progress so as to be able to preemptive possible unforeseen circumstances
Reduction Medium
4
  • Be involved in the planning and conceptualization process.
  • Maintain clear and open channels with the design team so that we are always on the same page.
  • Share the ownership of the project with the design team
Retention Low

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.

Architecture

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.


Software

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
  • Tower/Git - a tool we use for versioning and sharing our codes
  • Zwoptext - creation of sprite sheet for Cocos2D platforms
  • Navicat - GUI for SQLite database
  • Unfuddle - web application for bug tracking (also hosts our git repository)

Quality of Product

Use Case

Use Case CN.jpg

Game Framework

Game Framework.png


Component Architecture

Component Architecture.png


Game art Sketches

Archer Character

Archer.jpg


Mage Character

Mage.jpg

Warrior Character

Swordswoman.jpg

Digitized Assets

All char.png


Reflection

Jaryl Sim

Learning iOS development was something that I wanted to do but was put off until now. IS481 has been a great opportunity for me to pick up what I think is a valuable skillset. Having been a C/C++developer, it was a surprise to me how different Objective C was but thankfully we found Cocos2D which helped remove some of the project's complexity, especially when dealing with graphics.

I was in charge of the game's component-based architecture, and am glad to find that our early efforts are now paying off since the team is able make changes to the game easily once they understand how the architecture works. It was a fairly easy task of developing additional functionality into the game by encapsulating them as an additional component.

Also, working with the artists and animators has provided us with first-hand insight into how art teams work and also made us some new friends.

Clement Wong

My passion was to develop games as a career and thus, IS481 helped spearhead my first game development project on the iOS platform. Though I may have knowledge in C/C++, Objective C is a different level of programming that I have ever done. Therefore, the learning curve was steep, and is still steep, but the technical skills obtained is priceless.

I was in-charged of getting the graphics into the game and making the animations work well with player controls and AI behaviors. I had to use Zwoptex to create sprite sheets of animations with each individual sprite's coordinates optimized for use with the cocos2d framework. It was hard learning the technicalities, but I picked it up fast, and end up having lots of fun implementing the game art into the game and bringing the game to life.

Lastly, I had the privilege to work with concept artist, designers and animators. Seeing them create amazing art work for the game, gives me drive and excitement to work on the game. It also grants me a great opportunity to work with other professionals from another industry.

Siew Hui

Seeing the increasing trend of iPhone users, I have been wanting to pick up iOS development. IS481 is the best avenue for me to test the waters and until now, it has been a fun and enjoyable learning experience.

I am being put in charge of the physics and UI component. These tasks gave me a good overview of the whole project as the physics component is applicable throughout the game. Also, I have to pick up both Objective C and coco2d concepts after realizing that cocos2d framework is easier for game development.

I am looking forward to the upcoming development work and I foresee it will be as exciting.

Hang Loon

The past few weeks of working on the project has been difficult yet fulfilling. Not only I get to learn one of the most popular programming language from scratch but also able to work with a group of enthusiastic peers. Game designing and programming have also gave me a different exposure.

I was in charge of programming some component modules and to implement database connectivity into all modules, ensuring that we can add/remove/update values and configuration easily.

It's halfway down the road and this product is going to be an exciting one.

Fauzi

Working as a project manager for a iPhone game application has been a very eye-opening experience for me. It is drastically different from the other SIS projects that I have done and managed. The mechanics in game development is very dynamic and requires a lot more foresight and considerations during the planning process. It has a lot more components (connectivity, game design, assets management, sprites etc), so much so that every step of managing this project has been a new learning experience. The learning experience is so enriching that I do not feel the frustration of having to revise the project schedule multiple times. Having to work with the design team also opens up a new dimension in project management, for now I have to coordinate two timelines and ensure that the progression of both the asset production and application development keeps pace with one another and complement each other in the process.