HeaderSIS.jpg

IS480 Team wiki: 2010T2 CrusNitor

From IS480
Jump to navigation Jump to search
IPhone4 screen1.jpg

The Trailer

Watch the trailer of our project here

The Team

CrusNitor
Slide1.jpg
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

About CrusNitor

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.

The Dream

How it all began

Angry birds wiki.001.jpg

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.

Watch Gravity Guy
Watch The Incident


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 Aim

Slide2.jpg

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.


The Concept

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.

The Design

Why iOS?

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.


Brainstorm

The Storyboard

Angry birds wiki.001.jpg

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.

Game Overview

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
  • Marketplace
  • Courtyard
  • 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.

Control

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.

Player Characteristics

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.

Character Type

There are 4 types of player characters: Warrior, Paladin, Mage and Archer.

Character Class Primary Attack Special Ability Character art
Warrior Sword slash Whirlwind sword attack Warrior.png
Archer Shoot arrow Lobs a medieval molotov cocktail Archer.png
Paladin Sword slash Shield that blocks all incoming attacks Paladin.png
Mage Magic bolts Cone that freezes enemies Mage.png


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.



Roles and Responsibilities

With regards to the project, we have ascertain the traditional roles of an IT project management as shown in the following table.

Role Name Responsibilities
Project Manager Mohd Fauzi
  • Monitor and ensure that the project is proceeding according to the project schedule
  • To spearhead contingency measures and mitigation strategies when needed
  • Updating of project schedule, documentations and administrative related matters
  • Create a methodology for development testing, including the testing phases, UATs and collation of results
  • Formulate a matrix or system of measurement and tracking of bugs
Assistant Project Manager + Liaison + UI Developer Siew Hui
  • Assist the project manager with the execution of his administrative duties
  • Liaison person between the development team and the design team
  • Conceptualize and assist in the development of the UI for the game controllers and console
  • Development of the visual design of user interface
Lead Programmer + Animation Clement Wong
  • Lead the team during designing phase
  • Educate the team in the Objective-C programming language
  • Lead the team in using Zwoptext software
  • Lead in the animation development
Lead Programmer + Architectural Jaryl Sim
  • Research and recommend architectures and frameworks for the project.
  • Educate the team in the utilization of the frameworks for the development of the project
  • Troubleshoot and resolve problems relating to programe architecture and framework
  • Periodically analyze the current framework and evaluate for ways to optimize it further
Database Manager + Animation Hang Loon
  • Design and develop the asset database
  • Assist in animation related coding and development
  • Design and develop the system database

The Game

The Technologies

The following is a summary of the hardware and software components being utilized for the duration of the project:

Component Description
Hardware 2 iPad, 5 iPhone and 5 MacBook Pro
Development Environment Xcode
Subversion Unfuddle
Programming Language Objective C
Frameworks GameKit and Cocos2D

Project Management

Milestones

S/N Milestone Date Description
1 End of Design Documentation 21 Dec 2010 Completion of the design and documentation elements including:
  • Project schedule
  • Project milestones
  • Work breakdown structure
  • Risk analysis & mitigation strategies
  • Story-board
2 Completion of Prototype 24 Dec 2010 Development of a prototype that should be able to achieve the following goals:
  • Connectivity between an iPad device and and iPhone device (one-to-one connection)
  • Basic foundational user interface
  • Able to control the movements of objects on the iPad using the iPhone as a controller
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 25 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

Project Schedule


Mid Terms Progress Wiki

Click Here.

Final Presentation Wiki

Click Here.