An icy move – iOS game ideas from a day of hauling boxes in the snow

Something of a shorter post than normal this week for #idevblogaday: we’ve been moving house. Much gratitude to those in the 36peas team who happen to reside in the same country as both our old and new house, and have spent the last 14 hours hauling boxes and furniture back and forth in the snow and ice.

The day’s events prompted a number a thoughts for game development ideas, most of which are quite well suited to iOS. Instead of staying up several hours longer than I’d like and writing up one of the general game design posts we’ve been working on, or finishing the 2010 gaming retrospective we’ll likely post next week, I thought I’d spend a smaller amount of time expanding on the ideas below.

Balance: removing the normal visual cues

Park a truck on slope sideways, with an exit on to a level path. Then get inside said truck and bend to pick something up – all of a sudden you realize that a lot of what you rely for balance and stability has gone and it’s actually quite disconcerting.

Taking this idea, it’s pretty easy to extend it to an accelerometer-based game that involved some abstracted form of “balance” in the game world. Progress the game by making the player dependent upon visual cues and then – bit by bit – removing them.

Logistics: right resource, right place

Take 4 people, 4 vehicles, 2 primary locations and several secondary locations and then try getting things in the right place at the right time. When the respective skills and properties of those people, vehicles and locations are varied (and in some cases absolute) things get mighty tricky.

This is an idea needing a context / world design – but anyone who’s ever considered game design has plenty of those. Apply one to the other for puzzling or real-time management fun.

Environment cycle: the massive effects of night and day

Doing things in the dark has its problems, doing them in the dark when the temperature drops another ten degrees below zero between day and night is another thing entirely. The knock-on consequences of several cycles are interesting too – a snowy hill is drivable one day, but unusable the next because it that snow was compacted and is now sheet ice.

Degrading performance: hampering expected ability causes frequent re-planning

Locomotive movement, respiratory function and agility are generally predictable for any human being. But when the environment they’re operating in affects those things significantly they’re forced to frequently re-assess their ability and re-plan their actions.

The obvious game mechanic here is in gradually degrading the abilities of the player, forcing them to perform faultlessly or otherwise find alternative methods.

Displacement and misplacement: confusion and exploration

When you’re familiar with how your objects are connected to your environment (physically and functionally) it becomes very difficult to answer normally-trivial internal queries (where is this, what do I need to do that).

This is likely best applied as a specific element of a wider game – one in which the player becomes familiar with their tools and their abstracted connection to the game world. Changing that environment around them (i.e. not giving them a new environment, but one that provides the same function in a one-home-for-another like way) presents them with challenges they wouldn’t have expected and likely aren’t well prepared for.

Space is premium: confinement drives perfection

The main criteria for selecting our new home were all about space – specifically the size and space within each room. Already (and we’ve not fully lived here yet) we can see the massive (beneficial) change there is in doing very simple things – like moving in and out of rooms.

Have a player perfect something, then make them do it again with less “space” – two examples spring to mind here: PacMan and the usefulness of many entry/exit tunnels and what happens if you take them away, and; Osmos and the affects of a more confined (or densely packed) play area.