IS480 Team wiki: 2010T2 CrusNitor
- 1 The Trailer
- 2 The Team
- 3 The Dream
- 4 The Design
- 4.1 Why iOS?
- 4.2 Brainstorm
- 4.3 Early Prototype
- 4.4 Project Management
- 5 Construction
- 6 Refinement
- 7 Project Schedule
- 8 Mid Terms Progress Wiki
- 9 Final Presentation Wiki
|Team members||Clement Wong Yik Meng|
|Jaryl Sim Mong Cho|
|Lim Hang Loon|
|Mohamad Fauzi Bin As'ad|
|Nyeow Siew Hui|
|Faculty Supervisor||Professor Wong Yue Kee|
|Project Reviewer||Professor Benjamin Gan|
|Project Reviewer||Professor Jason Woodard|
We are a bunch of final year students who have decided to embark on another final year project. Choosing to do IS481 during the final term of our SMU life, we want to end our university life with a big bang!
Why are we doing this... again
We are all MacBook, iPhone and iPad enthusiasts who had went through the Mac conversion during our IS480. The prime motivation on doing this project is that we believe in the great potential that these Apple devices possess in the way it can penetrate, enhance and improve our daily lifestyle. If you think that Apple products have reached its full potential, think again! The trend is clearly visible that with each new advent Apple product, an aspect of our lifestyle will be affected and influenced by it. iPod had changed the way we use and see portable music players. iPhone had shown that a phone is not just a communication tool but it can also be a tool for entertainment, information, networking and many more. iPad is now spearheading the change in the way we perceive traditional media and enhancing some of the features we are already enjoying on iPhones.
Each new iPhone/iPad application pushes the boundaries of how we perceive these devices and their usabilities. The key to Apple innovations lies in its assimilation with our lifestyle. Given the technologies and devices, there are multiple ways whereby these innovations can be further expanded and pushed beyond the current boundaries. Based on these premises, we are motivated to explore on how we can further maximize the utilization of the devices in concert, meaning having the different Apple devices interacting and transmitting data with one another. We hope to achieve this goal through the use of the Bluetooth technology via the establishment of a Personal Area Network (PAN) or Peer-to-Peer (P2P) connection.
How it all began
Everyone would have seen or heard about this recent phenomenon called Angry Birds. It has been a revelation in terms of mobile application, as shown by the data in the image above, and it was the top downloads for quite some time in the AppStore. While our own application has little parallelism with Angry Birds itself, the sensational response and performance of such applications was one of the prime reasons for our foray into mobile application development. Across all platforms, it has achieved more than 200 million downloads and it is the largest mobile application success up to date.
We are further inspired by two mobile applications: Gravity Guy and The Incident. The Gravity Guy is a multiplayer gaming application that can be played on the iPad in real time. The Incident is a single player game that utilizes the iPhone as a controller and the iPad as the console. A demonstration of how the following two games are played can be viewed via the two video links shown below.
Based on the 2 games, we defined two main limitations. For Gravity Guy, its weakness is that the 4 players will have crowd around a single iPad, limiting the view of the game. Having played the game ourselves, we can attest to this. Projecting the game of a bigger screen does not resolve the problem because the players will still need to be in contact with the iPad in order to play the game. For The Incident, it can only be played by one player and thus do not have the same amount of fun that we can get out of Gravity Guy while playing together.
Thus, we decided to combine the solutions to the limitations and create an game application that can allow multiple players to play it simultaneously in real time. This is to capture the fun element present in Gravity Guy. To overcome its limitations of crowding, we implemented The Incident’s concept of using connectivity. Thus, players need not gather too close to the iPad if they use their iPhones as controllers. Since not much contact interaction is needed for the iPad, players can connect the iPad to monitors or the television so as to have a bigger and more conducive play screen for their gaming sessions.
The ultimate aim of this project is to create a gaming application that makes use of the iPad as a gaming console and iPhones as its controllers.
Currently, there are very few applications that utilize both the iPad and the iPhone devices in concert. Those available in the market, like Scrabble®, are turn-based and are not fully using the capabilities of this set up to enhance the user experience. Our conjuncture is that the iPad can be used as a console and also a display unit with which users can use on the go. The idea of simultaneously using the iPad and iPhone has not yet taken off with app developers and presents a ripe opportunity with a great amount of potential.
We chose to develop a game application due to its high popularity and higher rates of adoption by both iPad and iPhone users. 41 percent of the active applications found on iTunes AppStore are game applications. While our project is limited in scope to gaming, the potential of simultaneous multi-user iPad/iPhone iOS applications can be extended to other categories of applications such as productivity and utilities. As such, we believe that there is a big potential for a multi-user application in the market.
We wanted to ride on the wave of iOS applications. Currently there are more than 7 billion downloads and over 300,000 applications on the AppStore. We also wanted to explore the feasibility and market response of a multi user application that involves simultaneous usage of both the iPad and iPhone in the manner defined in the Concept section. We also 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 applications such as utilities and productivity applications.
Hero Defense is a side-scrolling, multiplayer 2D, top down 45-degree angle perspective, hack-and-slash where each player uses an iPhone/iPod Touch as a controller for their hero on the iPad screen. The game screen will only be shown on the iPad, while the iPhones will only show the directional pad and the two buttons. Players have to battle waves of enemies using various moves and abilities with the objective of protecting the King.
Enemies will attack from the left to right generally; we will devise other means for enemies to get behind the players to make the game less predictable. Players need to fend off waves of enemies that seek to kill the object that the players are supposed to protect. The objectives can either be doors/gates or the King, depending on the area the players are at.
There is no winning condition for the game, only losing conditions. The losing condition occurs when the players fail to protect the King. While the King is still alive, the game will be ongoing with the enemy AIs coming to attack in waves. The proficiencies of the players will be based on their scores, forming the basis of their game standing.
We envisioned the game to contain five "map stages". These map stages denote the different areas of the castle that players are defending. The five map stages that we had conceptualized are as follows:
- Castle Gate
- Inner Castle
- Throne Room
Players have to protect an objective at each of the map stages. In all map stages except the Throne Room, the players have to protect a door/gate and prevent the enemies from destroying it. In the Throne Room, the players has to protect the King which signifies the final stand in the game. The king and each of the door represents non-playable characters (NPCs) that possess a health bar. Each enemy strike on them will cause their health to depreciate. Once the health of the door hit zero, it means that the players had failed to hold off the objective of a specific area and thus will be made to fall back onto another area. In the Throne Room, the final objective will be the King instead of a door. The same game rules held for the doors will also be applied to the King. The only difference is that the death of the King represents the endgame condition.
Players will start off at the outermost confines of the castle, which is the Castle gate. Each map area will have a door/gate at the end which enemy AIs will attempt to break down and destroy. These doors/gates also signify the objectives that the players are supposed to protect. If these doors are destroyed, the players are pushed deeper into the castle, into the next stage. Thus for instance, if the door to the Castle Gate is destroyed by the enemy AIs, the game will push the players to the next map stage area, which is the Marketplace.
For the game prototype itself, we may be reducing the number of map stages. This is dependent on the speed at which our artists can produce the background designs itself.
On the iPhone, players will have a directional pad or joystick, with which they can control the hero. There will also have two buttons with which to execute moves. There will be a disconnect button which will allow the player to disconnect and leave the game. This will allow the mentioned player to leave the game without interrupting the game play for the other players.
Each hero has a life bar; enemies that successfully strike the hero will reduce the life bar. When the life bar reaches zero, the screen is pushed back towards the castle and the hero is stunned for 8 seconds. When players die, they disappear temporarily but come back with the same character (after a set downtime). Thus, players cannot die indefinitely, avoiding the problem of a player getting bored after losing his character.
There are 4 types of player characters: Warrior, Paladin, Mage and Archer.
At each map stage, there will be a few different types of enemies. Ideally, we would like to have about 3 different types of enemies per map stage. However, this number again may change, depending on the speed of character production. The enemies will primarily possess basic attack capabilities of either melee or range. The enemy profile will be changed progressively to reflect the map stage. For instance:
- At Castle Gate: Enemy consist of infantry swordsmen and archers. Since this is the first map stage, the enemy profile will be of those typical frontline soldiers.
- At Marketplace: Enemy consists of knights and crossbowmen. At the second map stage, the enemy profile has been increased in terms of status elitism. This is to reflect that these more elite enemies have managed to push our players deeper to the castle.
Each enemy has a point rating, which is used for keeping score each time that particular type of enemy is killed. In addition, when generating each wave, the game will have a set of points to 'spend' on spawning enemies. The number of points the game has at its disposal increases after each wave, making the difficulty harder until the players 'lose' that stage and then the points reset to the stage's starting value. This way, we don't need to handcraft each wave of enemies for different stages; the game just progressively gets harder until players lose all stages.
We had created an early version of the game for our Acceptance presentation as a test of concept. We used free arts assets that we found online and developed an application that allows four different users to control spaceships on the iPad via the use of the iPhone as controllers. This was done as a proof of concept and viability of conducting a networked game across iPad and iPhone devices.
Roles and Responsibilities
The diagram above is the overview of the development process that we adopted for our project. At the start of every iteration, we will review the current systems against our initial project design. After coming to a consensus for the changes or the next step to take, we will move into the development component which consists of development, testing and debugging. After which, we will come out with the desired output. Stakeholders are also very important in this process. Consultations with our supervisor is also critical within this process as we take in his opinions and inputs very seriously. The design team's inputs are also given a lot of thought to and we welcome feedbacks from friends who were always supportive of our project.
Project Management Tool
The premier tool that we utilize in our project management is Unfuddle. Unfuddle is a hosted software development environment that allows us to collaborate and manage our work. It has utilities such as repository and subversioning for our codes. The milestone function allows us to plan our work around the limestones that we have established. This means that the tasks assigned to any member can be done in congruent with the milestone. by doing so, it helps us to keep track of our progress as we work towards a milestone and also gives us a big picture of the progress of the whole project itself.
From the scope shown above, we defined three main limitations that we faced for the project. They are:
- Lack of experience in game development
- Lack of exposure to iOS development
- Lack of design and animation skills
For the first two limitations, we are able to think of solutions to work around the problem. To remedy the lack of experience, we decided to leverage on Clement's network and experience from his internship at LucasFilm. Given that he had worked in the game development department, Clement is able to consult his colleagues and get their opinions and advices. For the lack of exposure in iOS development, we started reading up and familiarizing with iOS development since last term. However, we cannot find a sufficiently good solution for the last limitation.
We came to a crossroad when confronted with the last limitation. It is the main critical limitation that we face as it relates to the graphic design and animation component of the project. This is a make or break factor of the project, the ‘show stopper’ of the project and none of us possess the fundamental skills in the design lifecycle. Thus, we have to outsource our design component. This in turn presents another limitation: funding. Through personal network, we were referred to a budding designer entrepreneur Thye Chuan, who was kind enough to work and collaborate with us for free. We concluded an agreement whereby the ownership of the arts assets will belong to him and his design team, while we keep the ownership of the codes. We are to also give due credit to his team when we market the application in the future.
We tried not to put any limitations on the design artists. This is because we wanted to maximize their creativity. Partially also because we are aware of our own inadequacies in the creative and design area, whereas they are the subject matter experts. What we did was to define the parameters of the game, such as the era of the game, the way it is being played, and the kind of characters. The artists provided us their professional opinions during the process. It had been an interesting process, for the artist had pushed beyond the boundary and created female versions of swordsman and paladins, which are traditionally male defined character types.
The following is a summary of the hardware and software components being utilized for the duration of the project:
|Hardware||2 iPad, 1 iPad2, 5 iPhone and 5 MacBook Pro|
|Programming Language||Objective C|
|Frameworks||GameKit and Cocos2D|
|1||End of Design Documentation||21 Dec 2010||Completion of the design and documentation elements including:
|2||Completion of Prototype||24 Dec 2010||Development of a prototype that should be able to achieve the following goals:
|3||Project Acceptance||29 Dec 2010|
|4||Multi-device Connectivity||14 Jan 2011||Establish connection between the iPad as server and multi-clients (iPhones) using Bluetooth. Transmission and receipt of data between devices with acceptable losses/drops|
|5||Game framework||21 Jan 2011||Establish the finalized game framework so as to enable development work on assets, pathfinding and game physics.|
|6||First Functional||1 Feb 2011||Version of application that should contain the player assets and able to function with the multi- clients connections|
|7||Mid Terms Presentation||17 Feb 2011|
|8||First Playable||18 Feb 2011||Version of the application that should contain functional major gameplay elements and assets.|
|9||Alpha||11 Mar 2011||Version of application that is feature complete and assets partially finished. Also signify the start of UAT and feedback-gathering from users.|
|10||End of Feedback-gathering||25 Mar 2011||Cut-off for the gathering of feedbacks from UAT. Decisions will be made on the development and implementations or dropping of features based on user feedbacks.|
|11||Code Freeze||25 Mar 2011||No new codes to be added to the game. Correction of bugs and tidying up of application.|
|12||Beta / Demo Version||1 Apr 2011||Completed version of game.|
|13||Final Presentation||14 Apr 2011|
Fundamentally, the application Hero Defense is built upon the following foundations:
- Component-based architecture
- Cocos2D Framework
- Libraries (HeroEngine, Server, Client, Network)
Component Based Architecture
Art Development Lifecycle
Sketch with Reduced detail
Final Games Asset
Image files to Animated heroes using Zworptex