At the start of 2011, I made some predictions on what would be big in games user research over last year. 12 months on, I’d like to review these predictions, and review how games user research has changed.

Prediction 1: More user experience positions within games companies

“the demand for UX and Usability skills looks to be on the way up.”

2011 saw a large amount of jobs open up in the games user research sector. The jobs thread in the Games User Research Special Interest Group on Linkedin was busy throughout the year with many exciting opportunities across the globe.

The success and prominence of games user research has led to many studios looking to bring increased expertise in-house, which has the benefit of both reducing costs and retaining talent. I personally benefited from the increased interest in user research, starting a full time GUR position in 2011. This trend is not over, and it looks like there will be plenty of similar jobs opening up worldwide in 2012 – I’ll try and share some on twitter as I encounter them.

Prediction 2: End of eye tracking

“eye-tracking will move more into the position of one tool among many that can be used, but with caveats as to how you apply the findings”

I’ve heard of eye-tracking being used in game related usability studies over the last year, although this was in conjunction with other methods, rather than being the focus of the study. I still however have doubts over how useful this data can be. Although it can be interesting to see where people are looking, it seems to lack an applicable method of analyzing and reporting this data – unlike websites, games move around too much to draw consistent conclusions.

Instead, the use of eye tracking could be to placate viewers who are watching the sessions. It’s interesting to watch, and can help influence the client’s immediate conclusions – perhaps it’s much more useful to make user research look interesting, than to teach us results. And perhaps this means it has a future.

Prediction 3: The rise of biometrics

“the research into the wider biometrics field will really take off in 2011”

Vertical Slice have had some great successes with the application of biometrics over the last year, both for commercial application to games development, and with its popular application to finding the ‘scariest game’.

Pejman Mirza-Babaei has been working on the application of biometrics to pinpoint the exact moments in games where players react to in-game events, and then using alternate usability techniques to understand why these moments are important.

This idea has a huge amount of potential, and has been shared through Vertical Slice’s involvement in conferences during 2010 and 2011. It’ll be interesting to see how this work develops both academically and for commercial games development over 2012.

Prediction 4: Increased Organisation

“will become an increasingly organised community in 2011.”

The Games User Research group on LinkedIn has grown to over 350 members, and frequently has discussions on the hot topics in games research. In particular the group has been fantastic at sharing interesting articles and features on websites such as Gamasutra. Outside of the community, there’s been increased awareness of the field of user research, with GUR presentations (such as my one on Social Interaction) featuring in both social computing conferences (like Multi.Player) and Game-Dev conferences like Develop. This trend seems to be continuing into 2012, with games research workshops at high profile conferences like CHI and DIS.

Prediction 5: Understanding Social Interaction

“ I’ve been working heavily in the field of understanding group social interaction while playing games, and can see a lot of potential for this to evolve in 2011.”

Last of all, my personal project during the early half of 2011. I was involved in defining and measuring the forms of social interaction noted in cooperative and competitive play, and was happy with the progress of this, the work having featured at Develop, Multi.Player and in an upcoming Gamasutra article. Although I’m no longer working with Relentless, there is definitely potential for similar work to continue throughout 2012, especially with the new forms of interaction created by motion controls, or mobile gaming.

That’s it for 2011 – Whats next for 2012? Leave me a comment, or message me on twitter with your thoughts, and I’ll share them!

Related posts:

1. 5 predictions for Games UX in 2011
2. Valve’s philosophy with User Research in Games (Gabe Newell & Mike Ambinder)
3. Evaluating User Experience in Games – Book Review

Also Graham McAllister’s EDGE column this week discusses some of the potential applications of this research. Read the column in full here.

A full write up of this research will be on Gamasutra soon, so keep checking back for more!

Related posts:

1. Some great articles on games usability and player experience
2. multi.player Conference Review – Social Interaction, Bartle and Orcs!
3. Desperation & Disappointment: Social interaction in We Dare

Finally, the fun of stamp collecting on your console!

What are collectables?

Collectables in modern games are usually items hidden throughout the game world, found when the player deviates slightly from the game’s intended course. They are often thematically linked to the main story of the game, and can unlock achievements, or in game rewards when collected.

In Alan Wake, the primary collectable are coffee flasks, 100 of which are spread across the game world. They give no tangible benefit to the player in game, however collecting them all unlocks an achievement.

These are however not the only collectables in the game. Throughout the game, there are also 50 or so Manuscript pages, each of which unlocks part of a written story linked to the game’s plot. Achievements are also rewarded for finding all of the TV programmes, radio broadcasts and in-game history text scattered throughout the game world.

Seems like a lot, doesn’t it? Let’s look at the reasons why so many collectables have been implemented.

Why are collectables used?

The key reason why the design decision is usually made to implement collectables is because they can directly extend the game’s life span, by slowing the player’s pace. By hiding items throughout every level, with no indication of where they are hidden, the player is required to travel slowly and explore fully to find the collectables.

It also opens up additional replay value in the game, as completists who miss the collectables on a first run through have the additional challenge of replaying the game while getting all the additional achievements.

In Bartle’s player types, collectables seem to appeal to ‘achievers’, who are interested in visible displays of skill (such as the achievement points unlocked for completing these challenges), and ‘explorers’, who like to investigate the game world, by incentivising them to fully explore their surroundings.

What is the problem with collectables?

In the case of Alan Wake, it seems that the developers hadn’t considered the extent of the effect on player behaviour that the implementation of collectables would have. Unlike Sandbox games, which have also embraced collectables, Alan Wake is a story-led ‘survival horror’ game, where the narrative is crucial to the experience.

By implementing collectables, this disrupts the flow and timing of the narrative experience, by forcing the player to explore each area before moving on. This is exacerbated because the player cannot return to an area once they have left, forcing the players to extensively scour each room before moving onto the next.

This has a huge effect on the pacing, and ensures that the ‘experience’ isn’t received as designed.

The 100 coffee flasks suffer from having no sign-posting as to their location, making it incredibly simple for the player to miss one, which is cause endless frustration if the player was attempting to collect one, due to the aforementioned issue of not being able to return to an area. Their entire ‘run through’ of the game would be wasted, and this oversight would only be discovered at the end of a run, which can take 15+ hours.

Finally, the atmosphere and ‘illusion’ of the game world suffers from the implementation of collectables. Alan Wake can only carry 30 revolver bullets – fair enough. However he also has space for 100 flasks of coffee? Strange priorities!

As has been noted in reviews of Arkham City, in story-driven games collectables can often make little sense, negatively altering the experience. Batman only has a few hours to save Gotham – should he really be spending his time searching for trophies?

Gotta Catch 'Em All!

How should collectables be implemented?

In Batman Arkham Asylum, the Riddler had hidden a number of collectable trophies around the game world. To prevent similar issues to those identified with Alan Wake from occurring, a number of steps were taken to mitigate the effect on player experience of these trophies. The player was given a number of clues as to their location, both through a riddle, and through an indication on the map of the general area in which the trophy was hidden.

For a story-driven game, this helps immensely. By indicating to the player when they should be looking for collectables, it reduces the frustration of the player potentially missing a trophy, and only finding out when they reached the end of the game with 99/100 collected. Perhaps more importantly, it ensured that the pacing of the game during story sections was maintained, since the player would only look for trophies when indicated, and could act naturally for the rest of the game. This is in contrast to Alan Wake, where the player is continually required to search every room, for fear of missing a trophy. It’s also worth noting that in Arkham Asylum the trophies were hidden in areas the player could return to at the end of the game.

Collectables work well in Sandbox games, as the player always has the option of returning to an area. In many other game types, this isn’t possible. Caution should therefore be used when implementing collectables in non-sandbox games, as the effect on player experience will be greatly increased, at the possible detriment to the overall gameplay experience.

Related posts:

1. Get Lost! – Improving player experience through signposting and map design in games.
2. Some great articles on games usability and player experience
3. Improving the Player Experience – How to make great loading screens

Following up from my recent review of the top positive user experience elements in Driver: San Francisco, this week I’ll be looking at the top 5 usability and user experience issues that cause a negative player experience.

For each issue, I’ll also discuss potential fixes that could be implemented in order to create a more positive game playing experience.

Image by wiiloveit (Flickr)

1.  Boost Implementation

Early in the game, the player is given the ability to ‘boost’, gaining a temporary speed advantage, by pushing the left analogue stick up. However, because this shares a control with steering, a number of usability issues occur.

I encountered a large degree of accidental activation, particularly in missions which required precision driving, since I was using the stick to steer also. This accidental activation caused the car to lurch forward, and made completion of the precision driving difficult.

Although it may be a design decision, I also encountered issues with steering while boosting – because the player is required to push the stick forwards, this reduces their ability to steer to the left or right to the same extent.

Instead, the boost control should be mapped to a specific button, which it doesn’t share with any other controls, and hence accidental activation would be minimised.

2. Unclear definition of Mission Goals

Throughout Driver: SF, I found that the game was good at telling the player what their goal was, but not the steps to achieve this. For example, a very early mission finds the player driving an ambulance, and tells the player to “keep the patient’s heart rate above 20”.  The phrasing of this objective implies that the player can take action to raise or sustain the heart rate, however no indication is given to the player towards the game mechanics that can achieve this.

I encountered a similar issue when first running from the cops. The game told me to ‘escape the cops’, yet gave no indication of the techniques or skills needed to achieve this. It was not until I failed the mission where the game explained that the player should “weave through traffic to escape the cops”.

Through improvement of the hint system (detailed further below), and increased communication to the player prior to mission start (for example, on the mission acceptance screen), there is the ability to communicate the techniques required, and guide the player to the successful completion of their mission goal.

3. Hints

In Driver: San Francisco, the player can press a button to see a hint related to their current mission at any time. However my experience of the hint system was that the hints were often unhelpful, and either repeated, or paraphrased the objective. For example, an early mission said “go to the garage”, and the hint was “drive into the garage”.

Objective...

...and its hint.

A player would only be pressing ‘hint’ when they were unsure of how to complete their current objective, and would therefore find no benefit in being told the objective again. Instead, through thorough user testing, and evaluation of the nature of the problems that user’s encounter, it would be possible to anticipate the real problems players have, and provide context relevant hints.

4. The MiniMap

The expanded mini-map

Driver SF’s MiniMap suffers from a few usability issues.  Primarily, even in the expanded view, there is no key to reference what the icons represent. In the screenshot above, it’s evident that there are different mission types (a flag, a star, a padlock, lightning?), however the player has no ability to discern what each of these icons refer to.

Secondly, no indication is given on this map view of the relative differences in distance between each mission. Should the player be using this screen to decide what mission to complete next, they are not given the full information required to make an informed judgement.  This could easily be resolved by using transparency to indicate each map item’s relative distance to the player.

Finally, one of the icons on the screen is a padlock. If the player travels to this area, they will find that they cannot do anything once they arrive there. The mission is locked. As the player cannot interact with this area, there is no reason to indicate it as a place of interest on the map, since this will only potentially cause the player to travel there unnecessarily.

5. Investigation Screen

The investigation screen

Finally, I was confused by the investigation screen. This page was accessible from the main menu, and (likely) intended to sum up the plot so far. Pictured above is the investigation screen after two hours of game play.

This screen offers no interactivity, and is exactly as pictured above. The pictures aren’t selectable, and there is no additional information. This page therefore fails to communicate the story, or serve as a reminder for what the player has learned so far. To improve it, each item should be selectable, and offer increased context on what each picture represents, based on what the player has learned through the game’s story so far.

Conclusion

I really enjoyed Driver: SF, however as noted above, it did have a number of usability and user experience issues, which can cause the player experience to suffer. Through increased use of user research to understand and anticipate potential issues, these issues could have been avoided. Jason Avent, formerly of Black Rock Studios has said that user research can add 10% to a metacritic score, which would have pushed Driver SF into the coveted ‘85%+’ bracket.

Related posts:

1. Driver: San Francisco Usability Review (Part 1)
2. This week’s gaming usability roundup – Portal 2, Deus Ex, Driver San Francisco.
3. 100 Rogues – Playability Heuristics Review

Unlike last weeks post, this week I’ve looked at the real usability issues (and pluses) in Driver: San Francisco. This week I’ll be looking at all the elements that create a positive player experience. Next week, we’ll be looking at the major usability issues, and what can be done to resolve this!

Driver: San Francisco

The Top 5 Positive Features of Driver

1. Shifting for mission select

Typically in games, selecting a mission is a major drag. In sandbox style games like GTA or Driver, you are required to walk to a predetermined area of the map, whereby the mission will start. This takes time, and takes the player away from the core game experience – instead it’s recreating a commute!

Driver fixes this by introducing the shift mechanic to select missions. By pressing a button at any time, the player becomes disembodied, and floats across the game world. By taking the player out of their avatar, the player is free to traverse the world at much greater speed, and reach the next mission almost instantaneously, without being taken away from the action.

2. Rapid Shift

After the first hour, the game introduces the ‘rapid shift’ mechanic. This allows the player to instantly switch between two cars under their control concurrently (the AI controls the other car when you’re not driving it).

What this means for the player is that they are never out of the action for long. Consider alternative games – crashing your car means a long pause as you reverse, change direction, and get back into the fray. Driver: San Francisco allows the player to instantly press a button, and be fired instantly back into the action.

3. Enforced Mission Variety

The missions in Driver: San Francisco have been carefully designed to elicit and demonstrate the full range of scenarios made possible by Rapid Shift. Typical driving games include very few mission types – drive fast, drive somewhere and hit something, drive somewhere without hitting something.

Rapid Shift introduces a lot of potential variety to these initial meeting types, and the mission goals are used to elicit these custom behaviours. For example, because you control multiple cars, you can ‘shift’ into oncoming traffic and cause a head on collision with your target, in order to catch them with your primary car. Another early mission asks you to finish a race in first and second place, using shifting to control both cars simultaneously.

4. Aesthetics and Setting

Driving cars after a coma?

Although the game’s premise is very similar to a popular BBC drama, the game isn’t set in the seventies.  Despite this, the game is heavily influenced by movies and TV of the time, from the classic cars and mission types, to the car chases and the music.

Many of the missions are inspired by popular TV and films, such as Starsky and Hutch, and all these factors work together to create a ‘movie-like’ experience. By creating a complete and coherent gaming universe, Driver allows a much greater degree of player immersion.

5. Leaving drive-able zone

Just a minor usability point on this one, but I like how Driver handles leaving the edge of the world. In many rival games, the edge of the world is either a brick (or invisible) wall, or a ‘kill zone’ where the player starts to take damage after they cross a marked point.

Unlike other games, Driver has a red translucent wall depicting the edge of the game world. Driving out through this transports the player instantly to the opposite lane, coming back in to the city.  This method means that the player will not take damage from leaving the game world, as opposed to hitting a wall or entering a kill zone. Additionally, players will not have to manually slow down, turn around, and come back with this method, ensuring that they are not taken away from Driver’s core game experience.

So, that is the top five features which I feel players will react positively to in Driver San Francisco. Next week, we’ll look at the five major usability issues, and what can be done to resolve them!

Related posts:

1. Driver: San Francisco Usability Review (Part 2)
2. This week’s gaming usability roundup – Portal 2, Deus Ex, Driver San Francisco.
3. Game Usability: Advancing the Player Experience Book Review

now that's just silly

Portal 2

• Entering the evil mirror-universe is not made explicit to the player. Consider giving Chell a goatee for emphasis.
• Asimov did not have a fourth law requiring all turrets to refer to the player as ‘Your Holiness’.
• Inclusion of the companion cube as an inert but playable character in co-op leads to a poor player experience. Consider allowing cube to rock side-to-side.

Deus Ex: Human Revolution

I wanted orange, it gave me lemon-lime

• Permanent sunglasses prevent the player from navigating dark areas of the game. License and implement Specsaver’s reactions lenses.
• ‘X’ button is currently mapped to philosophise. This should be auto-activated throughout.
• Tracer Tong is unlikely to be related to Pete Tong. Remove in-game references to his love of Garage and House music.

Driver: San Francisco

• Soundtrack continually loops David Bowie’s Life on Mars. “Next Track” button just increases the volume. Replace with Ashes to Ashes.
• Cars currently talk to the player in the voice of KITT from Knightrider. Appeal to a wider audience by adding the voices of Brum and Herbie.
• Shifting near the Ghostbusters can cause permanent player death. Replace with a minigame based around Dan Aykroyd trying to convince Bill Murray to be in a 3^rd film.

Barbie’s Dream Adventure

• Ability to put injured citizens out of their misery is currently context dependent based on player’s decisions in the ‘pro-life vs pro choice’ round. Allow the player to euthanise civilians throughout.

Related posts:

1. Driver: San Francisco Usability Review (Part 2)
2. Driver: San Francisco Usability Review (Part 1)
3. [Prototype] – Some UX and Usability thoughts.

Today, I’d like to share some articles on usability and user experience in games that I’ve enjoyed recently, in case you missed them. I’d also be interested to hear recommendations of things I should be reading, feel free to leave a comment!

Personality And Play Styles: A Unified Model

@Pejman_MB  shared this one with me, a Gamasutra article summarising the different models out there for defining player motivation. This has been a pivotal aspect of the research I have been working on recently, and is a recommended read for anyone wanting to accurately target games to specific player types.  The article can be found here.

Why Are Tutorials Terrible?

Graham McAllister and Seb Long from Vertical Slice collaborated on an article last week, in Graham’s regular Edge column.  By looking at examples of good and bad tutorials, they help pinpoint what it is that successfully teaches players how to play your game. Read on here.

Some Hows And Whys Of Usability Testing

@EmeraldSong  gave a great introduction to usability testing in games, highlighting how it can be invaluable throughout the development process , can find issues missed in other forms of playtesting , and can be done on a budget. Gamasutra has more.

Resetting Accessibility in Games

Mike Ambinder from Valve software, who was featured in this blog last week, has been interviewed in more depth about Valve’s take on accessibility, as part of this article by Dennis Scimeca. Mike’s feedback is really insightful for how commercial development can balance the needs of disabled gamers, and can be found on page three of the article here.

Scary Game Findings: A Study Of Horror Games And Their Players

Finally, Gamasutra also featured an article on Vertical Slice’s novel application of biofeedback techniques to try and understand what makes a game scary. Originally appearing in Xbox magazine, this article features examples of five scary games, and works out what makes them tick! Read more on Gamasutra.

That’s all for this week!

Related posts:

1. Valve’s philosophy with User Research in Games (Gabe Newell & Mike Ambinder)
2. Improving the Player Experience – How to make great loading screens
3. Get Lost! – Improving player experience through signposting and map design in games.

Remember to be polite....

***********************************************************

Hi Gabe

I write a blog about User Research in games, and know that play-testing, and incorporating player insight, is a huge deal at Valve.

I was wondering if you could give a couple of sentences on your own opinions as to why user research is an important part of the game development process, and how you do this at Valve.

While I’m making wishes, I’d also like a motorcycle, and a picture of you in a cowboy hat. If not, just the sentences will be great!

Thanks, and all the best

Steve Bromley

***********************************************************

And great news, I got a reply! Gabe forwarded my email to Mike Ambinder, an experimental psychologist at Valve. He described Valve’s philosophy around integrating user research in games as follows:

“At Valve, we see our game designs as hypotheses and our playtests as experiments to validate these hypotheses. In addition, we always want to iterate and improve on our work, and we are constantly seeking feedback – through playtests and other means – in order to do so. By making use of a wide array of user research techniques, we will make better decisions and as a consequence, better games.“

I followed up with Mike, to get a bit more information about the practical side of implementing user research and play-testing throughout the development process:

“We start playtesting as early as we can—as soon as we have something playable. We’ll start with internal folks and then bring in external folks soon after.

In terms of research techniques, we like to use the match the right methodology to the desired form of data. If surveys and interviews are most useful, we’ll do them. If it makes more sense to look at gameplay stats or physiological data, we’ll do them instead (or in addition).  Our most common form of playtesting is direct observation followed by a brief survey and then Q&As.  We don’t use biofeedback too much in our standard playtests, but we’re running a bunch of supplemental playtests on the side that concentrate on biofeedback data, and we hope to incorporate these methods into our practices going forward.“

Thanks Valve! Mike was able to give some really interesting direct insight into how they incorporate user testing into the development process. Still waiting for my cowboy hat pic though…

Related posts:

1. Games User Research Review of 2011
2. Some great articles on games usability and player experience
3. Ian Marsh, creator of Tiny Tower, on user research, play-testing and F2P

Blammo!

It’d be fair to say Prototype is an ‘average’ game, having received 78% on metacritic (it’s sad that this counts as average, but that’s inflated review scores for you!). It does some things fantastically, and obviously has sold well enough for a sequel to be in development. So, what impressed me?

The Best of Prototype

Relatively early on in the game, the player gets the ability to glide, with subsequent upgrades increasing their potential mobility while in the air. The glide ability is successful in both appearing in-context of a superhero game, and allowing the player to navigate the game world quickly and reach destinations in an appropriate time. By giving the player great freedom of mobility, this reduces the time between the player’s missions, prevents the game feeling ‘sluggish’ and avoids issues with difficult navigation that have been found in many open-world games.

As an anti-hero, the protagonist of Prototype, Jim SomeGuy, has a habit of eating people. The ability to gain health by eating NPCs works in the context of the game, and ensures that the player is never ‘stuck’ without the ability to gain sufficient health to complete their mission, due to the prevalence of both enemies and civilians. As a method of healing the player, it is less dependent on suspension of disbelief than a shower of health packs, and more unique than the health regeneration seen in many modern games. However eating an NPC requires the player to stand still, often making it impossible to heal while being ganked by enemies – I’d query this design decision, since it significally heightens the game’s difficulty.

The Worst of Prototype

You wouldn't like him when he's angry

 As in many games, progress in missions gives you money to upgrade your abilities. However when upgrading the player’s abilities through the in-game menus, the upgrade structure is unclear, both in its UI and its execution. When abilities (such as the ‘overdrive’ ability) are dependent on other skills to be useful (i.e. it must be partnered with specific other powers), this is not indicated and allows the player to buy a potentially useless ability. When purchased, the execution of new abilities is taught through a description of what buttons to press, lacking crucial information on timing and context of successful activation.

A minor annoyance is the range of UI issues in the menu presented on start-up. Prior to loading the main menu, the game requires the player to press to continue past a pop-up dialogue – a needless delay. The menu also highlights ‘New Game’s as the first option, despite the use-case for ‘Load Game’ being a lot more common. The game knows if you have a saved game, and could highlight the appropriate option automatically. Minor annoyances like this are an easy fix, and should have been picked up during development.

Conclusion

Prototype has a huge amount of potential, and is undoubtedly fun to play. Compared to other open-world games I’ve played, it seems to have extensive variety and some unique game mechanics, such as eating people to disguise as them, which help to keep it compelling . However, a number of small issues with the UI let it down, and detract from the player experience. More extensive user testing, throughout the development process, would pick up these ‘quick-wins’, and could knock the game’s metacritic score into the 80s or above!

Related posts:

1. Usability Thoughts – Mass Effect
2. The importance of usability in Mobile Geolocation games.
3. Driver: San Francisco Usability Review (Part 1)

I spoke to Ian Marsh, one half of Nimblebit, who have had numerous iPhone hits beyond their success with Tiny Tower, including Scoops, Pocket Frogs, Textropolis and more. Ian shared his insight into how understanding player behaviour affects the development of a popular iOS game, and the idiosyncracies of testing with free-to-play mechanics.

A small tower

- Have you been keeping track on people’s reactions to your game since release?

Certainly, we keep a close watch on people’s response to the game through monitoring twitter, app store reviews, various forums, and feedback sent directly to us.

- What’s your opinion of the comment’s you’ve been receiving since Tiny Tower’s launch? Have people ‘got’ it?

It has been a very warm reception. We’ve been pretty blown away by the number of people really embracing the game, and very surprised at how little negative feedback there has been.

- Did you let anyone play your game before release? Did their actions/feedback influence your design at all?

We ran a very transformative private beta involving around 30 people. We learned a lot and made a lot of changes to refine the experience. There will always be aspects of a game that the developers are blind to for one reason or another so getting other people involved during development is essential. (NB: Ian asked players for qualitative based feedback, shared through a forum thread)

- Did you take any conscious steps to test the F2P elements with players?

An enjoyable free experience is the most important thing to us so we usually beta test the game without IAP functionality. This lets us balance the game for free players first, then layer on the IAP in a way that is entirely optional for the player.

some minature shops

- When you update the game, is it based on feedback you’ve received?

We certainly take all feedback to heart and it sometimes leads to new features, but we’re usually working on or have already considered most features that people suggest.

- How far do you think the game was (and is) lead by your own initial inspiration, and how much has been subject to changes based on player reactions to initial builds?

The game changed quite a bit during the beta period. The main goals and idea of the game remained the same but we were able to change certain systems and tweak progression to keep people more engaged, maximize the fun parts, and minimize the boring bits.

- Looking into the indie/mobile games industry as a whole how do you feel the idea of user-inspired development is being received? Is it still the culture of ‘design is law’ and superstar developers such as John Romero.

I think developers should always listen to criticism and feedback for their games but a good developer has a clear vision of what their game should be and knows whether it would actually improve the game or not. There is always the chance that someone will come up with a good idea that simply never crossed your mind.

Ian’s given some really interesting insights into the current debate over player-led vs designer-led game design, and how free-to-play mechanics should come second to a positive user experience. Their obvious success in this area implies they are on the right track, and we’re all looking forward to seeing what they come out with next!

Tiny Tower is available from the iOS App Store

Related posts:

1. Valve’s philosophy with User Research in Games (Gabe Newell & Mike Ambinder)
2. Games User Research Review of 2011
3. Erik Rothoff Andersson (Kick Ass) on testing with users & why you shouldn’t listen to what users say!