• Adapt the screen for different resolutions
• Try to see if it looks good on different devices
• Adapt the camera

As discussed here #44 (comment), we should have a proper logger.

• Must be able to handle crashes
• Must log errors, warnings and info depending on the setting specified
• Logs should be dated and written in a file on the device
• The logs should be sent to our AWS server

This is not a priority right now, but it must be done before we start to have real testers.

• Make the wheel collider a bit larger than the wheel itself specially for the small one
  The percentage of offset could be proportional to the wheel size.

• Character
• Wheels

When the player finishes a level, we present this menu,

• The player should be able to go back to the main menu
• The player should be able to continue to the next level
• That menu should be designed for an ad bar at the bottom
  Eventually we will add metrics (high score, best time) here too

• Collider should be growing over time
• If the hero touches it, restart the level

• Must be able to set one or multiple arc(s) as "not sticky"
• The "not sticky" parts must a have a different sprite (set automatically if possible)

I suggest we divide the wheel in four arcs with each one an arc collider.
I found that MIT library (meaning we can use it in our closed-source software if we write somewhere that we used it) that could be used for the colliders:
https://github.com/GuyQuad/Custom-2D-Colliders

Compilation error:
[Unity] Assets/Scripts/Hero/States/State.cs(31,9): error CS0103: The name `InGameMenuDisplay' does not exist in the current context
It seems that Monobehaviour doesn't like static functions. Plus it is useless to have this inheritance.
The class should also be marked as static.

• Find base resolution
• Create camera

• Need to replace the InputManager to be more flexible
• When the player presses a wheel it slows down and speeds back up when its released
• The player should jump on button pressed instead of release (otherwise its confusing for the player)

Since I plan to publish the game in open alpha in maximum one month, it would be nice to chose a final name.
Current candidates:

• Wheels of Redemption
• Wheely

• Must be able to receive a JSON from Unity Cloud Build
• Must be able to fetch the apk from Unity and upload it to the play store
• Should be hosted on an AWS machine (free tier is perfect for us)

If the player temporary quit the application (phone closed for example) or home button hit.

• The game should enter a pause state
• The game should resume only when the play touches the screen once
• There should be a visual indication of the pause (gray screen and a big Pause for example)

• The hero should bounce on specified quarter of the wheel
• Create necessary prefab with different texture

• Create basic assets (rectangles)
  • Hero
  • Platform
  • Wheels
  • Background
  • Lava
  • Walls
• Assign them to the sprite
• Create prefabs

• Nuclear Waste
• Metal BackGround

• Should follow the player
• Must have boundaries

• On collide, the player wins
• For now, restart the level (fade on black)

• Detach hero from the wheel
• Calculate and apply initial force to player

• Should have a different color
• Should only reverse the x speed

• Levels should use a locking mechanism (using the progression save, see issue #27)

We the player dies, we present that menu.

• The player should be able to go back to the main menu
• The player should be able to replay the level
• The menu should be designed for an ad bar at the bottom
  We will eventually also add metrics in this menu.

The title says it all.

• Must be able to navigate the menus
• Must make the player jump when clicking on screen

• Must be able to jump when pressing the touchscreen
• Force applied must be related to the time the player pressed the screen (need a maximum too)
• Space bar emulation for PC tests

• Levels should be divided in sub-menus (we need to determine how we want to separate them)

• Rotating wheels
• Can change dimension easily
• Can change speed easily

We must discuss about the level loading

• It should be flexible for the level designer
• It must be easy to upgrade/change a lot of levels easily
• It must small in size (cause we will have a lot of them)
  I see two solutions: Each level is a scene OR We load a file and replace the objects (always in the same scene)

• When the player go on the quarter once, its destroyed (the player can't stick anymore)
• Create the necessary prefab and apply a different texture to it

• Hero drop on a platform
• Must move automatically from left to right and back

• We should have a permanent file where we save the player progression
• It must be flexible enough so we can add more information later (for example stars on the level for the performance, best time, coins accumulated, etc)

As I was thinking about level design I thought it would be nice to add various shape walls inside the levels to make the levels more difficult in the later levels.

• Walls should be able to have various rectangular sizes (and still look good)
• Suggestion: Maybe we could have types of walls, some with bounciness, others without, etc.

• Should have a Play button
• Should have a Settings button
• Optional buttons: High Score/Achievement, Share the game
• Should be planned for an ad banner at the bottom

• Must have the various sizes required by Unity
• Must represent well the game

• Hero must stick to the wheels when he hits it
• On collision, replace the hero to be ready for another jump

• Use the quriousdev google account to publish the game
• Make sure its private and only accessible when you have the link
• Pay the one time fee to be a google dev

When the hero jumps, he must jump straight. He must not jump in the direction it is moving.

Since we update to unity 5.5 and the compiler was updated to C# 4, it no longer supports the method I was using to dispatch generic events.
I will rewrite it using delegates or an event aggregator.

We the play hit play, we present this menu

• Should be have to choose a sub-menu of levels (we need to determine how we want to separate them) Moved to #41
• Each sub-menu should have multiple levels using a locking mechanism (using the progression save, see issue #27) Moved to #40
• Should dynamically display all the available levels of the game
• Should load the right level when clicked
• Should have a button to return to the main menu

When the core game features will be done, we should consider how we want to create the levels.
If we decide to create them all ourselves we will need some guide lines for the difficulty of each level as well as for the difficulty progression.
Maybe a bit of exterior help would be nice to have here.