1. Introduction

I am going to develop a Real Time Strategy game for iOS and OSX devices with the possibility of expansion to further platforms such as Android. To this end I've decided to port the PC game ‘Age of Empires: Age of Kings’. I want to justify the mobile platform for RTS games, to prove this platform I have decided to take a game that was great and prove its quality on mobile.

I intend to rewrite this game through objective-C, I intend to work in an agile fashion with sprints and MVP adding core features and expanding to additional features as the project deadline allows. I intend to reuse game assets from the original game such as graphics and sounds, the reason for this reuse is: I would like to focus on usability and developing a gesture scheme for RTS on a mobile device. Game assets are easy to swap out allowing me to market this project with a different suit of non-copyright assets at a later stage.

Real Time Strategy Computing Elements

Real Time Strategy games interest me due to the diversity of computing elements.

AI

RTS games use intelligent Algorithms for path finding, player automation and combat mechanics and teamwork; I am very interested in implementing these elements.

Swarm AI

This type of game takes elements from swarm AI with the added interaction of a human coordinator to direct the swarm towards a structured goal.

Game Theory

Game Theory is a branch of mathematics concerned with the analysis of strategies for dealing with competitive situations where the outcome of a participant's choice of action depends critically on the actions of other participants. Game theory has been applied to contexts in war, business, and biology.

Game Board

This sort of game requires a ‘world’, this can be approached in several ways such as: a tiled hex-grid board. The world or board for this game can be displayed as:

1. 3D,
2. 2.5D/Isometric
3.  2-D

I am most interested in the Isometric approach due to my interest in games like Age of Empires and Command and Conquer.

Human Computer Interaction

There is a lot of HCI in these games, well designed clear interfaces, intuitive feedback for actions, intelligent reward schemes, and immersive sounds. I believe HCI is what really sells a product and hooks a user. I want to prove the mobile platform as a good home for RTS through intelligent use of HCI.

Interface

I believe that interface has been more of a barrier on mobile platforms than processing power.

Background

Age of Empires 2 was released in 1999 for the PC; despite the age a decent port to mobile has yet to be created. The mobile platform is very powerful so far emulators exist for: PSP, PS2, Nintendo DS.

I believe a mobile platforms would be ideal for an RTS game in which gameplay is prioritized over graphics. I hope to overcome the absence of left; right and middle click operations with a combination of swipe gestures and multi touch gestures.

Gestures

Swipe selections and multi touch gestures will allow for easy unit selections; selecting a group will be as easy as circling the units, Pinching to zoom, gesture commands to choose formation or unit types…

Sliding windows

Removing clutter from the main screen will be key on small devices, using sliding windows will allow the user to view their army, resources and other non-critical information more with more detail.

Sound, Visual cues and Rewards

I believe that part of what makes games like ‘cut the rope’ and ‘Angry Birds’ successful is the depth of experience brought on by the sound effects and visuals such as visual and sound responses to success, rewards and positive reinforcement at a randomized percentage; the inconsistent rewards appeal to the gambler mind frame.

- The Psychology of the Near Miss, R. L. Reid

Psychology

A game in which the user becomes immersed and can pass hours without noticing is a good game, this is achieved by balancing task difficulties to user ability, if this balance is achieved a state coined as ‘cognitive flow’ occurs. This term was coined and explained by the psychologist Mihaly Csikszentmihalyi in the 1970s.

1. Extreme focus on a task.
2. A sense of active control.
3. Merging of action and awareness.
4. Loss of self-awareness.
5. Distortion of the experience of time.
6. The experience of the task being the only necessary justification for continuing it.

I hope to appeal to a clientele with an interest in Games, particularly RTS games. I also hope to appeal to people interested in game design strategies as I intend to blog the development and strongly rely on good design techniques.

Business Contexts: From the customers perspective

The two obvious options for distribution of this application and charging are:

1. Outright purchase.
2. Free downloads which will include in-app ads

The existence of a free option will allow potential buyers to trial the game in a limited environment, a user that purchases a game after a trial is more likely to have a good experience than a user that buys and then decides they do not like the game.

Further revenue and experience can be generated through Micro Transactions, this will allow the user to purchase in game boosts and additional features such as:

1. Expansions
2. Faster farming, better combat abilities, cheats

Business Contexts: From the business owner’s perspective

Micro transactions, this will fund future development and continue to bring in revenue after the original purchase.

The Apple App store gives an inexpensive distribution to a huge market across countless devices: phones, tablets and OSX machines.

Depending on the ad placement ads could be included in the paid version as long as it doesn’t affect gameplay. However unpaid downloads would have less subtly placed ads as there was no original purchase and the revenue needs to be recovered for the download.

Age of Empires II: Age of Kings:

My project depends on re-use of game assets such as sounds and graphics from the original game

My finished product should closely mirror the original game, though only game assets will have been reused, this allows me the freedom to exchange the game assets after the project to market my game without copyright dangers. Released September 30, 1999, Re-released April 9, 2013

1. Sprite: 2D image / animation that can be moved on-screen and manipulated as a single object.
2. AOE: Age of Empires, an RTS game developed by Ensemble Studios, released in 1999 and re-released in 2013
3. Texture: a skin or overlay for a vertex
4. Game Asset: A suite of sounds, graphics or behaviors used for a game
5. IOS: The operating system for Apples smartphone and table series
6. OSX: The operating system for Apples desktop and laptop devices
7. RTS: In an Real Time Strategy, as in other war-games, the participants position and maneuver units and structures under their control to secure areas of the map and/or destroy their opponents' assets.
8. MVP: Minimum Viable Product, this involves creating core functionality before adding high scope or additional features, it is used on tight deadline and lean startup projects.

2. General Description

Functionality:

The use of this game will follow four stages; first a game/match must be tweaked and created, then a map must be customized and created, the actual game to be played and then the victory state in which a goal state has been achieved. The user will be able to save their progress either to local storage or remote storage, based on the sprint this will different from Google game services to a remote API

Stage One:

Set up the match

• Choose Teams
• Allies
• Team Colours
• Choose Nation
• Define rules
  • Resource limits
  • Build times
• Choose Enemy
  • Number of enemies
• Alliances

Stage Two:

Generate map or Choose Map

The aim is to create dynamically generated worlds with randomly placed resources, tiles and players; this makes replaying interesting.

• Choose the size of map
  • Small, Medium, Large
  • Choose Map type
    • Islands
    • Continents
    • Random
    • Generate a hex tile grid relevant to the chosen type The Hex grid will be the frame of reference for moving the sprites and placing textures such as:
• Soil
• Water
• Trees
• Gold, Stone, Food
• Disperse players at equal intervals within range of similar resources

Stage Three: Game play

Gameplay is the truly vital element to the game, this contains the most functionality and

• Select unit
  • Circle or tap unit/s, long press to begin selection
  • Move Camera
    • Swipe or drag to move in a direction
    • Pinch to zoom
    • Move Unit
      • Tap destination to move
      • Double tap to gather/attack
      • Use Unit abilities
        • Drag ability tab from right/left
        • Gesture to use ability (Macro)
        • Create buildings
          • Create
            • Choose from ability list or Macro
            • Choose location
              • Required resources
              • Correct Tech Age
              • Accessible
      • Repair
        • Tap item to be repaired
          • Accessible
          • Resourced available
          • Gather resource
            • Stone
            • Gold
            • Food
            • Wood
            • Attack
              • Animal
              • Enemy
              • Save State
                • Google Game services
                • Remote API
                • Time out
                • Annihilation
                • Wonders

Stage Four: Victory

Audience

This application will cater to users across several groups; the original game AOE was available for users of 10 years and up but primarily marketed at a more mature audience of RTS gamers.

Play Style & Interface

My aim is to create a user input system and user interface that will be clear to younger users while not feeling over simplified for the more hardcore gamers. RTS games tend to become extremely competitive with users using key bindings and macros to maximize their efficiency; I hope to create a gesture system similar to this macro system to allow hardcore gamers to optimize their play style.

The use of Google Game Services or a remote API will lead to the ability to save state and retrieve it on another android device; this is safer than local storage and handy if the user has more than one device. This should appeal to dedicated players that move from on the go devices to tablet devices.

The following are explanations for the different interactions a user will be able to perform when running the application:

1.    Create a game 2.    Create a map

3.    Game play functions

IOS: Devices and IOS versions

Memory available per device

Project must be completed by the June 2014

Design Patterns

RESTFUL Standards compliance with API

3. Functional Requirements

I intend to develop this project using Agile Methodologies and MVP, tying down core functionality before expanding to the next stage. This will leave me with a deliverable even if unexpected roadblocks are encountered.  

Sprint 1

• Basic GUI:
  • Animated sprites
  • Basic AI:
    • Move
    • Single Player
    • Static World
    • Basic User input:
      • Tap unit
      • Basic drag-able camera
      • Basic Unit Stats
        • Health, Damage
        • Persistence: Google Game Services

 

Sprint 2

• GUI:
  • Add smoother digging and foraging, show units carrying resources, units decaying
  • AI:
    • Attack, gather
    • Add more elaborate path choices, I intend to allow units to move around terrain, pick the shortest path to a resource
    • User versus AI controlled enemy
      • Allow the user to decide if there should be a completely automated enemy sharing the world. This will allow the soldier units to be used, along with trade and diplomacy menus. It will drain resources in the world twice as fast.
      • Balanced unit stats
      • Dynamic World Generation
      • Randomly decide on the amount of wood, stone etc. to place and the location of the placements, keeping the random generation within fair a limit.
      • Persistence: NodeJS Web service
      • User input: Zoom, circle units

   

Description:

This is the interface the user will use to interact the game. This must be displayed properly on all acceptable devices. This encompasses features such as pinch zoom, drag camera, circle units and slide menus.

Criticality: Vital

This is a vital component for our system as it is the front end of the application and the users only way to interface with the app. The real goal of this project is to make RTS more accessible, this goal above all is the most important for justifying RTS on mobile.

Technical issues:

Screen size, processing power and platform can go from iPod Touch all the way to iMac Desktops, this app will need to make sure to take screen size into account when preforming actions, physical button placement also differs on devices and should be considered.

Dependencies with other requirements:

Graphics

OTHER

The performance of our application relies a great deal on whether or not the end-user’s device is suitable to run it.

Description:

This section deals with the game logic, the movement of units, combat, building this is section is very important for a good game.

Criticality: Moderate

This section is important but the game is still playable will poor AI though the experience will be less enjoyable.

Technical issues:

Porting the logic from the original game will be difficult without the original code to work off, this will be similar to black box testing in the way I will need to play the game and create and action and observe its results.

Dependencies with other requirements:

Interface and Graphics

Description:

This requirement differs from Interface in that it is directly responsible for the drawing of the tiles and sprites, this requirement details the setup of a grid of hexagons to cover the board, this allows for sprite movement in 6 directions and a good interlocking board. It is intended to draw unit sprites separate from the grid but to use the grid to store location and tile graphics.

Criticality: Vital

This element is vital and comprises the visualization of all other work, without this element no other elements can be tested.

Technical issues:

Screen size, processing power and platform can go from iPod Touch all the way to iMac Desktops, this app will need to have sprites capable of scaling. The application should not lag and needs to be well optimized in order to provide the end-user with the performance they expect; in other words if they have a low end phone it may experience lag despite our efforts, so it’s not our fault but none the less should be striven to avoid.

Dependencies with other requirements:

None    

Description:

This section details the creation of a local and remote database to store game state if the match is paused, the intention is to implement a RESTful API using a MongoDB database and NodeJS backend but that will be seen in a later sprint such as Sprint 3.

Criticality: Low

This is not a critical item but its inclusion would greatly increase player satisfaction, being able to continue games on different devices or to save a game and start a new one would be very helpful.

Technical issues:

Implementing a full API takes a significant amount of time compared to the payoff of a simple file store, using third party API’ such as the Google Game Library allows speedier development but also enforces coding to their libraries removing a lot of wriggle room.

Dependencies with other requirements:

This is dependent on all other elements since it is going to be saving their states e.g: saving unit layout and resources.

4. System Architecture

Fig 4.1 above is a diagram depicting the underlying structure of the application, there is a limited number of entries in the System Diagram due to the standalone nature of the game, outside modules are only used for persistence. The two entries seen here are the two options, implementing my own webservice with a NodeJS backend and MongoDB database or using the Google Game service to store a binary file, the beginning sprints will rely on the Google Game Service due to the ease of implementation.

5. High-Level Design

            

6. Preliminary Schedule

Description

I intend to write a game for an iOS device, this game will take advantage of HCI features to make it comfortable on a mobile device. This project will utilize a web service to store state across devices, store high scores visible by other players, and allow playing against the same AI enemy.

General area covered by the project:

This project covers:

Mobile applications Graphics HCI AI Persistence Web services Gaming Programming tools: List tools (compiler, database, web server, etc.) to be used NoSQL – MongoDB or CouchDB NodeJS – Backend service writing Typescript – Adds type and object orientation to JavaScript Express – A web framework for NodeJS to allow structured NodeJS projects ARC – Memory management in iOS Tiled – For creating tile maps in games Sprite framework – For creating graphics and animations on iOS devices Webserver – Apache, this will be used to expose my web services Debian – I will host my NodeJS and NoSQL DB on a Debian server, most likely on Rackspace or Amazons AWS. Learning Challenges: List the main new things (technologies, languages, tools, etc.) that you will have to learn: Objective-C NodeJS Express JavaScript Typescript MongoDB or CouchDB Tile and Graphic design Sprite Framework Path Finding Algorithms

Hardware / software platform:

State the hardware, software and platform for development: Debian iPad, iPhone MacBook Pro, OSX Mountain Lion   Fig 6.2 PERT Chart  

Task Name	Duration	Start	Finish
Submit Proposal	0	--	--
Submit Functional Spec	0	--	--
Research Objective C	30~	1/12/13	10/1/14
Research SpriteKit	10~	10/1/14	20/1/14
Research iOS Frameworks and tools: Mantle,Typhoon	2~	20/1/14	22/1/14
Create Map	8~	22/1/14	30/1/14
Create generic sprite	14	1/2/14	15/2/14
Create base classes: unit, building	15	15/2/14	30/2/14
Add movement AI	14	1/3/14	15/3/14
Add attack AI	15	15/3/14	30/3/14
Add Camera Movement	10	1/4/14	10/4/14
Add World generation	10	10/4/14	20/4/14
Persistence	5	20/4/14	25/4/14
Unit Stats	5	25/4/14	30/4/14
Tasks, mining, foraging	15	1/5/14	15/5/14
Review	15	15/5/14	30/5/14
Submit Project	1	3/6/14	3/6/14
Demonstration	-	5/6/14	10/6/2014