littlerobotblog

Little Robot

– Daniel Cobb, Jamie Ashbolt, Liam Murray and Sean Davies

Contents

Overview

Theme / Setting / Genre

Core Gameplay Mechanics

Targeted Platforms

Monetization Model

Project Scope

Influences

Story, Gameplay and Design

Story

Gameplay

Design

Assets Needed

Sound

Code

Animation

Schedule

Concept Creation

Asset Creation / Base Code with placeholders

Animation, replace placeholders/ advanced code

Testing, bug fixing

Overview

Theme / Setting / Genre

The game is a runner in the vein of temple run or vector. The player controls a ramshackle free running robot in an equally clunky and improvised city. Buildings are created from whatever is lying around in the refuse. The city is still colourful however, the game needs to feel cheerful. Our little robot character is not running from an enemy he is running for the fun of it and the city needs to reflect this.

To help the game look fun and cheerful a cartoony art style will be used. This works well for creating memorable and loveable characters.

Core Gameplay Mechanics

Movement Mechanics (gesture based)

Being a free running game movement is very important. There are obstacles the player needs to navigate past in different ways.

Variable jump – Swipe up half screen/full-screen
Sliding – Swipe down
Double Jump – Tap while in the air
Reverse Gravity – Not controlled by player. Certain areas have this effect
Slow-motion – Resource depleted as its used can be cancelled early / or press once have for several seconds has cool-down

Power ups

There are power-ups scattered across the map to help the player or increase their score. Some power ups can be bought before a run starts for a boost.

Head start – this places the player at a further start point so the player starts at a faster pace with higher score potential and power-up spawns.
Shield – This absorbs one collision with an object allowing the player to keep playing after a mistake. This does not save them from falling in holes however.
Score multiplier – these score multiplayers increase the amount of points from a successful action. They also stack.
Speed boost – Increases the speed of the player making it harder but it also gives a large point multiplier. This is a risk reward power-up for players that want a challenge.
God mode – the player is invulnerable to everything for a short time, giving them a break from the speed and time to think or recuperate.

Infinite mode

This mode creates an endless run for the player to go through. The aim is to get a far as possible and rack up as many points as you can. This will let the great players shine through.

Targeted Platforms

IOS

A huge platform and market is that of iPhone users and specifically the IOS operating system and is the second most used operating system globally only seconded by android and holds a huge percentage of the overall market shares holding 36% of the global market in 2013 but due to IOS being owned by apple and exclusively used in their devices Apple own the higher percentage market shares compared to other vendors. http://www.gartner.com/newsroom/id/2674215

Android

The most commonly used operating system for mobile devices to date is that of the android operating system that is developed by Google and as of 2014 more than a billion android based devices were sold worldwide and that same year the Google play store made an estimate of $10 billion in apps of which Google received $3 billion of and the other $7 billion was divided to other developers of the apps, with high and fair revenue even made from free to play apps, from and easy access to the system, development for this operating system is at an all-time high. http://www.nytimes.com/2015/05/28/technology/personaltech/a-murky-road-ahead-for-android-despite-market-dominance.html?_r=0

Monetisation Model

The game will be using an in App-purchases model of monetization with the core game being free, but several power ups and lives being brought with real world money, we felt that this would be the better model to fit our game because were aiming for it to be a casual and with its core game being free it allows for people to see if they like it and if they wish to carry on supporting it or not.

The model of currency that will be used in the game will either be real world currency or a premium in-game currency called bolts.

The power up costs will vary depending upon the power up with some being cheaper than others to represent they effect the game less.

Head Start – will cost the most due to it providing the player with a head start within the game (Missing several parts off the bat) the cost will be between 60 to 70p or 6 to 7 bolts.

Shield – Will cost less than head start due to it only providing the player with another chance against obstacles, the cost will be between 50 to 60p or 5 to 6 bolts.

Score multiplier and speed boost will both be of the same price due to their effect upon the game being more minimal and restricted to the score rather than gameplay, the price will be 55p or 5 bolt.

The player life will be an option when the player dies to an environmental object that will come up offering the player the ability to carry on with a purchased life, the number of times a player does this is all up to them but the price will increase with each purchase.

The starting price for a life will be 50p or 5 bolts, but will increase by a certain amount with each purchase, increasing by 10 or 1 till it reaches £1 or 10 bolts at which point it increase by five each time, till it reaches £3 or 30 bolts then it increases to ten per life purchased from then on.

Project Scope

Game Time Scale

Deadline is Friday 28^th of April 2017. We have 27 weeks to create our game.

The planning and pre-development documentation should be completed by Friday 16^th of December 2016 (8 weeks). This leaves 19 weeks for the game itself.

15 weeks for development of the game and 4 weeks contingency. Meaning we have an internal deadline of March 31^st.

Team

Dan

Animation / Concept / Character Art

Jamie

Research / Environment Art / Make Campaign levels

Sean

Team leader / Management / UI Artist

Liam

Programming / Technical Research

Licenses and Costs

Apple

Getting an App on to the Apple App Store requires a few steps. All apps have to be submitted for review and most are rejected at first. Apple will reject an app for any minor errors so it is advised to submit the app in a streamlined state with as few mistakes as possible then add updates with all the bells and whistles later.

Enrol on the Apple Developer Program
Set up an account
- Manage Agreements, Tax and Banking

Prepare and submit the App
- Guidelines for formatting/configuring code and data
App Review
- All apps are reviewed and must meet guidelines before being accepted.

Android

Android just require you to upload the app to their store through their developer console.

Other costs

Tools in use include Adobe CC (etc…) Adobe licensing (dummy marketing for now)

Influences

Vector

Vector is a free runner game with a good feeling of flow with sliding and jumping actions that we want to emulate. The perspective of the game is 2D on the landscape orientation. This style is better for the cartoon art style we are going for. Instead of being an endless runner it is split up into campaign style missions that progress in difficulty. We like this style and want to incorporate it into “Little Robot”.

Temple Run

Temple Run is possibly the most famous endless runner out there and is an obvious inspiration for any runner game. The game has many power ups that can be collected in game or bought beforehand for an early advantage. We have taken inspiration from this system and will implement it with our own power-ups.

Brawlhalla

Brawlhalla is the main artistic inspiration in terms of art style. The cartoon style of this game is perfect for what we have in mind for “Little Robot”. It has a fun light-hearted vibe from the bright colours and proportions of the characters. We think the hand drawn art style will lend itself well to the smooth flow we want in our animation actions.

Story, Gameplay and Design

Story

There is a little robot who lives on his own in a large ramshackle city built from scraps. He has a dream to become the best free runner in the city. He looks up to a well-known free runner robot called H3rmes and aims to be better than him. The little robot sets out on a journey across the city to prove he can be the best.

As he progresses through the city he finds upgrades to chassis that give him new abilities such as a double jump or the ability to reverse gravity in his local area. The journey through the city will make him the best runner ever known.

Gameplay

Our groups idea of the overall gameplay is an infinite 2D runner game similar in style as our logged inspirations. The game will involve avoiding obstacles via jumping, and sliding past and over said obstacles and surviving for as long as possible, which will earn the player currency through a point based system which will be logged every time the player dies/fails. Power ups will be present in the game which can be earned through playing the game, or buying these power ups through the earned currency in order to access them early when a new run is started. Overall the player will be avoiding obstacles and pitfalls through jumping, double jumping and sliding with the added help of power ups to achieve a higher score each time

Design

Human-Computer Interaction

HCI (Human-computer Interaction) is a set of goals and principles used to help make designs successful. For design we focus on the first goal of HCI – “designing novel computer interfaces, optimizing a design for increased learnability or efficiency of use.” HCI promotes an early focus on users, it is important to first define who the user is and how many users there are. Interface testing should start as early as possible with empirical measurement, use real users or testers to simulate real users and receive subjective feedback as well as quantitative results, such as time taken to complete tasks and number of errors made during the tasks. HCI suggests the use of iterative design; design, test, analyse results and repeat, making small but frequent changes.

Principles of User Interface Design

Following these principles should lead to a responsive design.

Structure Principle:

“Design should organize the user interface purposefully, in meaningful and useful ways based on clear, consistent models that are apparent and recognisable to users.”

The idea here is to use systems that users are already familiar with and are known to work, this lets the user learn the interface instinctively from past experience. For example Windows has the close button for all windows in the top right corner, so windows users would find it easier to use an interface that follows this design as it is consistent and recognisable.

When making an Android or iOS App, we should take into consideration the interface designs of the actual OS, as well as design of Apps on the OS that are popular/work well.

Simplicity Principle:

“Design should make simple, common tasks easy, communicating clearly and simply in the user’s own language/format, and providing good shortcuts that are meaningfully related to longer procedures.”

Anything that the user may need to do regularly needs to be easily accessible and at the forefront of the interface. The interface should follow the user’s language western culture reads left to right and top to bottom, things that should be accessed first tend to be the left most and top most items of the interface.

Longer procedures should be shortened as much as possible without impeding the ease of use for more frequent procedures.

Visibility Principle:

“Design should make all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Good designs don’t overwhelm users with alternatives or confuse with unneeded information.”

Things like ads and other distractions should be minimal or totally invisible when using the interface and all interface options should be kept to a minimum required to perform the task required.

Feedback Principle:

“Design should keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language familiar to users.”

When something happens the user should be aware it happened e.g. “game saved” messages. All outputs to the user should be in “plain English”, keep jargon to a minimum.

Tolerance Principle:

“Design should be flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and redoing, while also preventing errors wherever possible by tolerating varied inputs and sequences and by interpreting all reasonable actions.”

Take into account that different users will enter different responses for the same task, errors may arise from things like differing capitalisations of words, the interface should be tolerant of these inputs and should clearly state when it is not. e.g. passwords are often intolerant. Any input that will start a long procedure should be double checked. e.g. quitting the game.

Re-Use Principle:

“Design should reuse internal and external components and behaviours, maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink and remember.”

All systems/mechanics should be re-used within the application in order to maintain consistency. This allows the user to learn the fewest mechanics to navigate the interface and not require to learn new mechanics.