Posted on Leave a comment

Blog: The running joke behind my un-streamlined controls

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.



Press “O” to open: the running joke behind my un-streamlined controls

This weekend I traveled to Clujotronic — an arts and entertainment event — in Cluj, Romania, where I demoed my new game: Ebony Spire: Heresy. The audience of the event had very little in common with my target audience for the game but I learned a whole lot of from the people who tried the demo. Let’s take a look what people who never tried a old school RPG with un-conventional button mappings had to say.

Showing the game to a fellow designer who did not understand how to open doors.

The audience at Clujotronic was mostly young people in their 20’s. Most of them electronic fans with a taste for artsy stuff. A few of them were actual gamers of the mainstream kind (think AAA games). Most games featured at the venue (like Black the Fall, Second Hand: Frankie’s Revenge, Raiders of the Lost Island) were Indie games and it was great seeing people interacting with them for the first time. They all featured controller support and most players had little problems figuring out what to do. In my case there was only a screen and a keyboard and, for a few hours after setting up my “booth”, a mouse.

Arrow keys and Mouse are the first thing players look for in a game they know nothing about.

My target audience are technical, slightly older gamers who enjoyed dungeon crawling classics like Eye of the Beholder or Dungeon Master or fans of the roguelike genre that are looking for a more graphical game in the vein of the previously mentioned titles. The game relies heavily on the keyboard and breaks the conventional streamlined controls. I promised myself I won’t intervene and describe the game’s control to players until they all but gave up on trying. A good way to get data and see how much time they are willing to sacrifice before giving up.

What I noticed is that in the absence of a controller, when faced with a unfamiliar games, the first thing people gravitate towards is the mouse and arrow keys. If the game does not respond to those two types of inputs well… let’s just say that 70% of the people who tried the game gave up, assumed it froze/crashed and just left it at that. The remaining 30% are split between randomly pressing keys until something happens, checking out the monitor to see if it’s touch enabled (it wasn’t) or, those more interested in experiencing it, asking people around them for information. Touch screen-ers were more common than those willing to ask for information

First batch of players pre-key update

So after a few hours of me staring at people’s fingers gravitating towards the arrow keys I was faced with two decisions:

  • The easy way out: Print the controls on paper and stick it to the side of the screen
  • The slightly less harder way: Add support for the Arrow Keys and the Enter button.

I wanted as much data as I could get from the players and I didn’t feel like cheating and sticking a piece of paper in their face so I added support for the aformentioned keys in the Menu’s and the retention rate grew. I also hid the mouse from view.

 

Now that the “standard” way of navigating through the in-game menus was solved I almost had a full 100% retention rate until gameplay started (A few gave up once they entered the help menu and saw a wall of text). The first big hitch was met when the game started and arrow keys were once again useless. Here things took a weird turn.

Most players (a bit over 50%) went straight for W,A,S and D controls once the arrow keys were deemed useless. Twelve people asked if the mouse is missing. Around 25% of them moved on without wanting to hear any explanation about the controls. Slightly less than that asked for help immediately after the arrow keys failed to do anything.

The “O”gh moment when it all clicked

Once they figured out you can move around with WASD and turn the camera with Q+E they started exploring the first level. After experiencing the grid-based movement a few of them asked if the game was turn based. Spotting the first NPC made them want to grab a mouse out of instinct to shoot. This was a big amount of players (sadly I did not record this data). Others moved next to him and asked how to engage and attack. But the controls did not click with them until two more buttons were revealed: “I” to access the Inventory and “T” to throw items at the enemies. Quite a few of them questioned the decision to interact with the environment (here doors) by using the “O” key. They expected to press E or F. But as soon as they found their first items on the floor, and thinking about the previous keybindings it all clicked. More than once I heard: “How do I pick up an item.. Wait? Is IT P? Oh it is P! I GET IT NOW”. And then, suddenly, O to open doors, I to open the inventory, T to throw, P to pickup, L to access the log suddenly made sense for them. And after playing the game and noticing other people trying to figure it out they chimed in and helped excitedly. It even became a running gag around the venue. When people would ask if the bathroom is occupied some would answer: “Press O to open and see for yourself” or the now classic at the bar: “Should I press B for beer?”.


Let’s look at the facts for a minute

People figuring out the controls and being excited for the discovery was a great thing to witness however there’s a problem here hiding in plain sight: out of all progress data I recorded while the game was demoed the following things stand out:

  • Less than 3% of the total players reached the final (3rd) level of the demo
  • Only 15% explored the first level and its two portals
  • A whooping 40% of all people that tried the game gave up at the main menu

I cannot stress the last part enough: Because the default input method WAS NOT the norm almost half of the people who tried the game never even got to the game part. Imagine this data wasn’t picked up during the demo and I would have only found out about it after doing the steam release. A 40% refund rate would have killed me, my game and my business. Now I can argue that the drop rate would have been lower because of my target audience and their experience, because people that invest money in the game would stick around more and learn how to play it but it would still have dented my income and review scores.

The amount of polish before I launch next month is huge. I need to get a tutorial system in the game. Or a better way to present the controls. I am sticking to them but I learned that learning them through pure discovery, even if rewarding, can potentially put people off. People who are to be my customers and supporters.

I also learned that players who expect a mouse and do not find it will touch, press and even shake a regular monitor. Even when there is someone nearby to explain the game to them.

 

Ebony Spire: Heresy was demoed at Clujotronic. It’s a first person, dungeon crawling, turn based rpg inspired by roguelikes. The main mechanic revolves around picking up items and using them against your enemies. And the enemies can do the same things you can do. And you need to press “O” to open doors. It will release on steam in November. You can pick-up and play the Clujotronic 3 level demo for Linux and Windows from itch.io. And even buy the game at half-the-release price if you want to throw mean words about the controls at me. 

Posted on Leave a comment

Getting the message right in Another Lost Phone

Accidental Queens is a game company you might not be familiar with because they’ve only been releasing games this year. Earlier in 2017, they released the game A Normal Lost Phone in which plays found a smart phone, unlocked it, and began to piece together the life of the person who owned it.

There’s a degree of voyeuristic delight the propels the player forward. There are puzzles, mostly consisting of investing your time and attention into the assorted texts, emails, and other information on the device. It doesn’t feel like puzzles because it doesn’t feel like a game. There isn’t even a suggestion that the game has natural start or end points, much less a story, until one begins to emerge within the context of what you put together yourself. It’s a small game with a big message, and it has sold 100k units, and is won numerous accolades. 

Another Lost Phone: Laura’s Story is the pseudo-sequel just released by Accidental Queens, is available on Steam and on Android phones. This time, you explore a phone owned by a young professional woman named Laura. Again, there’s some very complicated messages and themes at play here. Miryam Houali and Diane Landais from Accidental Queens explain how you do a message game but make sure to get the message right.

In Another Lost Phone: Laura’s Story, players are tasked to find out what happened to Laura, a young woman who has apparently vanished without a trace. Stumbling on her lost phone, they need to discover what happened to her by uncovering crucial pieces of information and hidden passwords scattered among texts, apps, photo gallery and social networks.

This builds upon the basic system that Accidental Queens developed originally during a game jam. At this point, it’s a fully realized phone operating system, complete with music playing in the background via the iTunes comparative app and even requiring you to toggle various in phone systems like Wi-Fi and GPS. 

Or you can just delete all the data on the phone right from the start. I did to see if I could. And you can. 

Asked about transitioning the original title to this more elaborate version, art director Houali said that the impact the first game made upon players seemed to be something they could easily build upon because there were so many other subjects the team wanted to tackle. Diane Landais shared that the team through this would be easy to accomplish by simply adding a few new apps. Then Landais laughs because, of course, nothing is that simple. 

“The first game was mostly finding a password or guessing it,” Landais says. “This is more about piecing things together and deducing a password or how to advance the game. This design shift meant from a design and technical standpoint we had to redesign. One that was hard to do right was the recovery app which unlocks content within the messages and notes apps. In the original, each app had one bit of content. Now we have apps talking to each other.”

Miryam Houali points out that there were mistakes me in the first game, from a design perspective, that needed to be corrected — especially after getting some negative feedback. And that’s where Accidental Queens moved into territory that they knew required outside help.

“We know what we want to talk about, but it takes asking people how they felt after playing and why.”

In the original game, there is a puzzle in which you must forward a photo from the phone to someone else. There are numerous photos to choose from, but there are also images of the phone’s owner presenting as male instead of female in a game that doesn’t give you any heads-up that it is entering into trans-issues territory.

This puzzle solution resulted in Accidental Queens getting criticism for not fully thinking through their issue. While they wanted to make people feel uncomfortable in certain privacy violation ways, there were unforeseen issues that made a percentage of their audience too uncomfortable to continue. 

“We tried not to do that again on this one,” Landais says. “Any potential problem, we asked ourselves if it was useful to have it make people uncomfortable. What are the bigger complications of that?”

So for the sequel, which takes on a number of emotionally and politically complicated issues, the team decided it was best to ask someone else to answer these questions. In a game about complicated emotional and psychological abuse, the team didn’t want to risk hammering anyone over the head with their message but also wanted to make sure they presented a human, realistic portrayal of these events. So they turned to the professionals.

Houali says, “We had domestic abuse survivor groups play to point out any abuse mistakes we didn’t spot. There was four different organizations, all French based, helping us with the subjects and we sent them prototypes. We sent them beta versions. They pointed out mistakes in dialogues or how the message was conveyed. Our production time was very short, but at each big milestone we had a playtest station.”

As very small scale developers on a short production timeline, using so much of their resources and time to make sure that every detail about their message is conveyed accurately, seems sort of breathtaking. Especially when there are groups out there willing to help with work like this, why aren’t more larger-scale studios putting this much care into their product?

There was also considerable playtesting with individuals. “As developers we know what we want to talk about and how we imagine it being an entertaining game to play,” Landais says, “but it takes asking people how they felt after playing and why. That’s the only way to get this right. 

There’s a sort of trigger warning device at the beginning of Another Lost Phone: Laura’s Story which gives you different depths of plot and theme analysis, depending on how much you’re willing to have spoiled.

This is a delicate balancing act that both Accidental Queens games have had to straddle: if people know The Message of a game, it changes how you play and what you’re looking for. How do you put that out into the world without changing how others approach what you’ve made?

Landais says, “We wanted to spoil as little as we can, and going in there was a vague idea of those subjects. We don’t want to say those messages up front because they are more efficient way to play. For example, we wanted to share that psychological manipulation was coming from multiple sources. And if you know that at the start of the game that was still too much.”

But how do you let people know what your game is about? For Landais, the best route for games right now seems to be keeping that a kind of open secret. There are enough people in games-space right now complaining about too much politics in their games.

“I understand where they’re coming from,” Landais says. “We could’ve marketed this as “Oh look at these good LGBTQ people” and look — first of all, if you’re going to market a game like that you’d better deliver. But second, if you announce like that you’re going to drive away the people the need to hear your message. Some people who had “problematic” visions wound up empathizing with characters in our game before they realized what they were reading. You are trying to change someone’s perspective, and telling that in the sale of the idea is not going to let them understand your point better.

Miryam Houali agrees. “Some people say that the game was still too preachy. We wanted players to have their own opinions. We don’t think that people disagreeing with us makes them bad people, we just want to give them the tools to reflect on their beliefs. We can try to touch a lot more people with this approach instead of making overly political games.”

And that’s how Accidental Queens are using a subtle marketing push that leaves all the themes in the background, mixed with spending a majority of their time making sure those same themes are done beyond reproach, to turn out something truly special in Another Lost Phone: Laura’s Story.

Posted on Leave a comment

Midweek Madness – Dying Light, up to 60% Off

Raw Data is Now Available on Steam and is 25% off!*

Built from the ground up for VR, Raw Data’s action gameplay, intuitive controls, challenging enemies, and sci-fi atmosphere will completely immerse you within the surreal world of Eden Corp. Go solo or team up and become the adrenaline-charged heroes of your own futuristic technothriller.

*Offer ends October 12 at 10AM Pacific Time

Posted on Leave a comment

Blog: What is UX, and how does it help your game?

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Nearly every major game development studio is pivoting toward a more player-centric development process and culture. New internal teams and staff embodying the ‘voice of the player’ are commonplace, including Community Management, Analytics, UX Design and Games User Research.

For decades, ‘UX’ (or ‘user experience’) staff have been helping gamedev teams improve their development processes and craft better gameplay experiences for their players by leveraging psychology and human sciences. UX has proven to be an instrumental voice in crafting seminal video games – The Last of Us, Portal, Destiny, Monument Valley, Clash Royale, to name but a few – yet much of this games UX knowledge is siloed inside larger studios and publishers, and inaccessible to the wider gamedev community.

UX’s diversity of phrases, processes and perspectives can be confusing – What does it do? Who is it for? So, for developers unfamiliar with UX or wanting an easy overview: What is Games UX? What does it do for you and your team? How can I know if my game needs UX attention? What is the difference between UX and UI?

 

About the Author
Sebastian Long is a Games UX Researcher at multi-award-winning UX research and analytics consultancy Player Research. Seb has led UX research projects for ~200 games, including best-loved franchises like FIFA, Little Big Planet, Harry Potter, LEGO, Sonic, Talking Tom and many more titles, from indie through to AAA.

What is UX?

User Experience (UX) is a particular discipline of design, centred around the psychology of the end-user – or in gamedev’s case, the player – and their behaviours, thinking processes and capabilities. UX is part of a large toolkit used to ensure the experience that you’ve designed is truly reflected in the mind of your player. It applies a true knowledge of players’ behaviours and thinking processes, and couples it with data-collection, an iterative design process, and many types of testing with real players.

UX is where the science of the player meets the art of game design.

Everyone on your gamedev team is a designer, not just those with ‘design’ in their job title. Seemingly small choices made by every one of the team will impact how the game experience manifests in players. A programmer choosing a UI grid layout over a list, or a legal department demanding that players absolutely must scroll to the bottom of the EULA to proceed, or a voiceover artist choosing which words to emphasise in a spoken tutorial prompt. Each small choice could have minimal or monstrous implications on the players’ holistic experience. But we can be detached from the true impact of our choices; there are just so many to make.

Resultantly, every gamedev discipline could benefit from being shown the actuality of their choices on how players truly think and behave. With this knowledge teams can collectively change their minds, iterate their designs, justify changes, and gain confidence that their final choice is the right one.

This is the remit of UX: focusing on the true impact of design choices on players – and helping teams collaborate to make those choices. Hiring staff to “do UX” and become a player-centric voice in the studio is therefore an investment in directing the team’s attention, reality-checking design choices, informing the team’s judgement, and facilitating communication.

UX provides constant guidance, going back-and-forth between aiding design and then testing it on real players. As a whole, this process reduces key risks inherent to making things for people to use, such as ‘complexity-creep’, games being difficult-to-understand, or having to re-do work over and over if players “don’t get it”.

UX helps make better games.

Why is UX needed? Can’t we just be more thorough?

It is extremely difficult to remain objective about things we’ve crafted ourselves, or things we’re extremely familiar with. We can easily become oblivious to causes of disparities between the design of our game and real player’s’ actual experience of our game. This can damage our games; the fun that we know exists might not be resolved in our players.

How does UX help the team?

The problem of not knowing if players are experiencing the game as intended can result in  unnecessary confusion during the already challenging process of development:

Will players understand the game rules? Will they ‘get it’?
Do we need more features? Are the ones we have enough?
Is the friction in the game where we intend it to be, and balanced?
Is the game experience correct-enough for us to release yet?
Which parts of the game needs our focus during iteration?

Leaving these questions unanswered or – worse –  guessing incorrectly, leads to games being undesirably different from their intended experience – players don’t ‘find the fun’ – leading to lost development time, lost revenue and lost fans.

Why might players not ‘find the fun’ in our game?

In crafting a game you’re having to constantly guess how players might think, perceive, learn and react, in order to inform the design of the game and how it communicates itself to players: “I think a player would see that ‘enemy nearby’ feedback and head in the opposite direction”. There are many innocent reasons for these guesses to be wrong, and for the players’ thoughts and actions to undesirably differ to your intent.

These disparities are fundamentally human in nature, not technical; they’re about predicting thoughts, behaviours and perceptions of other people. Being incorrect isn’t a symptom of naivety or inexperience, but is inherent to designing artefacts for other people to use.

Below are some of the most impactful player-centric challenges teams face during development; perhaps you’ll recognise your own gamedev experience in some of them:

There are barriers to seeing disparities as creators:

  • Teams inevitably become ‘too close’ to their project; they cannot play nor perceive the game as a real player would. This skewed perspective can lead to needless iteration, or simply never recognising where experiential disparities exist.
  • Designing instructions, prompts and ‘onboarding’ non-expert players to your mechanics is difficult because you’re an expert in the game. There is a risk that players ‘don’t get it’, or tutorials becoming heavy-handed.
  • Designing games suitable for players who aren’t like you (such as children, novice or casual players) risks incorrect assumptions about that audience unduly influencing your design discussions. There is a risk you’re making a game for no one.

…and barriers to recognising these disparities in others…

  • If we try to playtest or observe real players interact with our games, it is very difficult to assess a player’s emotion as they play. This is both in assessing their moment-to-moment feelings, and in considering their engagement over days, weeks, months. Such data is vital to iteration, but is hard-to-obtain without bias, is difficult to analyse, and can be demoralising to the team if it isn’t handled well.
  • Because players are unskilled at rationalising and explaining their emotions, and they won’t appreciate the experiential intent for the game, their verbatim reactions risk diluting or misguiding the project’s intent. Focus groups, or asking people “is this fun, would you buy this?” is not the answer.

…and barriers can exist in company culture or processes …

  • It never feels like the right time to ‘check’ the player experience: “it is too early to playtest right now!”. This reluctance often results in teams putting off essential feedback-gathering processes until far too late in development. This risks late-flowering flaws being too complex, too expensive, or too far-reaching to address.
  • It is hard to appreciate the bigger picture of a game build once the individual features and components start to come together. Justifying saying NO to features or ideas is incredibly difficult without this big picture view, risking feature-creep.
  • Studios can find it hard to balance attention between what the development team consider interesting to make versus what matters most to players, if they lack a confident, player-centric voice in studio leadership.

These challenges are a hurdles for game developers all over the world, large and small. Each challenge can result in games having ‘cognitive friction’ in unintended places, such as UI, controls and communicating game rules. They can result in games being mechanically unsuited to the audience they were intended for. These factors are hugely influential on fun, on game reviews, and ultimately on commercial success.

But despite the significance of these challenges, the responsibility and ‘player science’ know-how needed to address them falls outside the remit of all traditional game development roles. Teams often think about these problems, but often aren’t empowered to take necessary action to overcome them.

Furthermore, the looming presence of these difficult-to-answer questions can have an impact on day-to-day team morale and company culture. They contribute to anxiety about one’s individual creative outputs. They cause conflict and power struggles as the team’s interpretations differ and clash; without knowing what is right, conflict can devolve into who is right.

How can we overcome these issues?

To mitigate these risks we need a someone in the team that:

  • …can maintain creative impartiality and objectivity
  • …truly understands how different player audiences perceive, think, and learn
  • …knows means of engaging real players to gather specific, trustworthy feedback
  • …can assess player’s experience with game mechanics both piece-by-piece, and as a holistic whole
  • …can take responsibility for the player-centric process right from the beginning of development

These are the responsibilities of ‘user experience’ professionals – or ‘UX’ for short.

UX, as a wider discipline outside of gamedev, has been built upon decades of actionable knowledge on designing for busy, everyday people. User Experience professionals embody ‘user-centricity’ across all sorts of design domains, from jetfighter cockpit design, to admin software, to the design of medical instruments, to apps, phones and physical products. Designers of all kinds of everyday things have the same human-centric challenges listed above in common with gamedev, yet gamedev is among the slowest adopters of UX thinking and processes in response to them. But we are catching up; in the last 5 years UX groups have been built inside nearly every major game publisher and developer globally, hiring individuals who’re passionate about helping gamedev teams realise their creative vision using player science.

Responsibilities are typically broken into 4 key job roles:

  • User Experience Designer, tasked with visual design, applying player psychology knowhow to support game design
  • Games User Researcher, charged with running playtests and research sessions with real players
  • Data Scientist, who captures player behaviour through game analytics and evaluates for insight
  • UX Leadership, a Director-level voice for player-centrism in process and studio culture

Together, these four professional roles empower studios to follow an evidence-driven and structured development process, leveraging ‘player sciences’.

What does UX do, exactly?

UX is both a body of knowledge and a series of formal processes. Each team uses these differently, depending on the core competencies of the studio, the game genre, the development stage, the challenges that define the project, and so on. We’ll go through each development phase in turn to outline the UX tasks, and how they overcome the risks above. No matter what genre, scale or business model – even on live games – the same UX processes apply.

UX feedback changes over the course of development. Each item above is a formalised UX approach, with specific objectives, tasks, sample sizes and deliverables. Each is designed to overcome common design missteps made during that phase.

At a game project’s conception, ideas are unstructured, wild, and exciting. To help inspire and focus creative teams, UX conducts ideation and concept research: “Who is our player? What do we want to make?” and identify the best-in-class experiences: “What little details do competitors integrate to ensure great experiences?”.

Game design teams can learn from their audiences’ play habits and traits, so UX teams conduct ‘exploratory research’ through interviews to discover players’ expectations of concept art and prototypes; examine competitor titles for experiential weaknesses and opportunities; interview genre-fans to understand their fascinations and frustrations, and so on. These data are typically provided to teams in the form of presentations, written reports, and as part of collaborative workshops.

In this way, teams can be helped to discover their game in themselves and in their players.

OK, we have an idea!

As a game design pillars crystallize around specific ideas and prototypes, teams need increasingly focused feedback and contributions to the specifics of the project: iteratively informing design choices and then assessing them using playtests and research methods. A focus on up-front iteration and informing prototypes avoids having to double-back later in development.

UX Designers help teams make informed choices about UI – List or grid? – interaction design – Button or gesture? – feedback design, prompting, icon design, mental models, colour language, terminology…

Without UX, each of these choices is made by developers imagining how players feel or interact with that thing: “I think a player would use this power-up and then they’d understand what it does”. But developers aren’t like players, and they’re often ‘too close’ to a project to make valid assumptions. Consequently, this imaginary player will too closely reflect the developer’s own knowledge, experience and perspective on the world, leading to flawed decision-making.

Your player-base is diverse, dynamic, and dissimilar to you.

UX tries to make choices right-the-first-time by raising questions and contextualising their impact as the choice is being made, not in hindsight. A User Experience Designer could assert that “Players might have difficulty seeing that feedback because it will have insufficient contrast against the light-coloured backgrounds” based on their knowledge of human visual perception. So too they might flag creeping visual complexity based on an understanding of human attention; and so on. A UX Designer’s output might be documentation like wireframes or mockups, but also full-fidelity art, reports, or simply in collaborating with existing UI Design and Game Design peers.

Where does player feedback fit in?

Games are complex, and some flaws will slip through into code. The team will likely be too close to the project to see them, so instead we’ll need to leverage real players’ perspective.

Week by week, Games User Researchers take a recent build, reflecting the most up-to-date design choices, and test it using specifically-designed experiments with real players. They’ll take research questions: “Can we prove this tutorial is effective at teaching? Do players reliably recognise the enemy weakspot?” and devise means of testing players for answers, followed by presenting their insights back to the team. Using different players for every single playtest means never being caught out by assumed knowledge in players, and constantly revisiting the learnability of your game mechanics. UX Research is traditionally delivered as a written report or presentation, or using internal issue-tracking tools like JIRA.

With a Data Scientist involved, player behaviour can be visualised and better understood, even allowing metrics to be tracked over time for a ‘bigger picture’ of development progress. For live games or titles in early access, Community Managers with research training can also leverage access to their fanbases for insight into their experiences and frustrations.

By trying to break potential UX issues into layers we can start to explore them in isolation.

The frequency and focus of playtests depends greatly on the challenges of the particular project, but every-few-weeks is not uncommon. Playtests start early in development, with small studies using prototypes and on-paper designs to check usability, accessibility and learnability. Later they’ll move to larger and longer playtests covering the player’s emotions, subjective impressions, and difficulty balancing; each aims to bring the game closer to excellence.

But what about emotions? Can we measure those too?

Once smaller pieces of the project come together, teams move onto the bigger questions: is our game fun?

UX’s foundations in the sciences – Cognitive and Experimental Psychology – do provide some means to explore player’s motivation, emotion and satisfaction, however, such ethereal data is harder to obtain and analyse than the black-and-white, observable outcomes of good usability and learnability. There is greater need for experimental control, carefully written questions, more playtesters, standardised methods, and taking measures over time.

Asking loaded, leading or mal-timed questions can lead to ‘bad data’

UX teams exploring fun rely on iterative full-game playthroughs with tens or hundreds of real players, each providing carefully-gathered subjective feedback and analytics data, toward a more concrete understanding of their holistic experience. Conducted correctly, a game’s experience can be benchmarked, checked and compared against itself over time, forming the ‘bigger picture’ that teams need to make big decisions.

Many studios without a UX voice wait until this point to begin getting player feedback, in doing so they have bypassed the majority of opportunities to save time and money avoiding the redesigns they’ll discover are necessary at this stage. Without having eked out the usability and learnability flaws in the preceding months and years, teams can struggle to handle a sudden barrage of fundamental flaws.

These full-game playthroughs need careful analysis. Because players lack the introspection and language to explain their emotions and explain their actions, it is common for usability and understandability frustrations conflate their feedback on fun. Because players cannot appreciate the experiential intent of the game, their verbatim reactions can be misleading. All the UX disciplines – Design, Research, Data Science – lean heavily on academic backgrounds to ensure data is soundly collected, analysed and presented to mitigate bias.

Players can lack the language, introspection and experience we take for granted in ourselves; teams shouldn’t rely only on players’ verbatim responses to inform design

Techniques for observing and measuring emotion, advanced data visualisation, biometrics and eyetracking are areas of active research – some of many developments in player science that this article doesn’t have room to cover.

A Culture of Informed Iteration

Together, UX Designers, Games User Researchers and Data Scientists work with teams round-and-round the production loop. Each has a particular voice, harmonising to refine implementation of the design intent; they’ll prevent and diagnose flaws, using quantitative and qualitative approaches, bringing together fine detail and big data. Each of their perspectives is required; omitting any one may lead to an uninformed conclusion.

Note the lack of emphasis on player’s opinion. UX doesn’t bend a game to the whims of a focus group, nor against the will of the creative team. Success isn’t necessarily marked by players saying “I like this”  or “I’d buy this”, but pragmatically by metrics set by the team themselves: “Are players able to demonstrate understanding of the game, and behaving as we intend them to?” “Does the difficulty, measured by completion time and deaths, align with our intent?”.

Players’ actions often speak louder than words. Any Developer that has attended a proper playtest will share stories of playtesters frustrating for minutes over some small flaw, only to suggest “yeah, it was fine”. Every task and process is designed to value contextualised behaviour and structured interview data over players raw opinion.

What happens if we don’t bother with UX feedback?

Without actively steering a studio toward this kind of knowledge-seeking and feedback-gathering culture, teams aren’t empowered to seek it themselves. Without a leadership voice calling for these check-ins, they’re eschewed in favour of just getting on with it. This is understandable: the prospect of re-doing hard work, or teams learning that their best work isn’t being experienced-as-intended, isn’t pleasant.

But blindly moving forward is false progress. By not addressing the player-centric challenges, they’re tainting the work being produced. At best this means re-doing hard work, at worst teams iterate themselves into bankruptcy, or release to lukewarm reception. Better to invest in getting it right early; better to redo days of work than months or years of work.

Teams feeling they’re “not ready yet” or “in too much flux” are suffering the very uncertainty that UX processes are designed to overcome.

Finding examples to highlight how the development challenges listed above lead to failure isn’t difficult. Games with ‘poor UX’ are every game you’ve never heard of, every game that never passed into the zeitgeist. Failed games and failed development studios don’t blame ‘poor UX’ for bad reviews, layoffs or bankruptcy; gamedev has its own well-developed lexicon for poor experiences: inaccessible, cluttered, clunky, too easy, unbalanced, shallow, clone, money-grubbing, greedy, deceptive, unoriginal…  All are interpretations of unrealised intent – of poor UX. I’m sure you’ve played your own fair share of ‘bad games’, perhaps even sensing that they’re a diamond in the rough. “If only they’d changed X”. It can seem so obvious in hindsight.

Successful products have releases with now-infamous usability or learnability issues in one form or another too: the widely-bemoaned Pip-Boy and settlement UI in Fallout 4, and the UI overhauls undergone by Gran Turismo 5 were both the result of failure to address ease-of-use issues. Luckily neither were core to gameplay. Pokemon Go suffered severe learnability issues at launch, leading to a raft of ‘how to play’ articles, but ultimately delivered experientially, through novelty and brand. No Man’s Sky failed to capture the experience players anticipated, despite generally good usability and learnability. Sometimes marketing dollars or branding can overcome UX frustrations, but not always, as Mario Run’s “disappointing” commercial performance attests.

The challenges listed the start of this article don’t always manifest as a single UX issue clanger, but find any poor game review on Metacritic or app stores and there will be criticisms that fall under UX’s remit: difficulty-in-use, low understandability or inconsiderate design. These topics do matter to players, and so they should matter to you.

Whom should we make responsible for ‘good UX’?

The short answer is: everyone. Every individual contributor to a project leaves some mark on the experience of the player, be that aurally, visually, mechanically or otherwise. All Developers are creators, and all are responsible for the impact of their work on the players’ experience.

Some parts of UX can be adopted without hiring UX staff, such as running playtests, surveys and collecting analytics data. But there is no substitute for expertise in research, psychology and interaction design, bringing those decades of human/machine study. Player data is hugely powerful in altering the course of a project, so ensuring you’re investing in capable staff avoids inexpertly-gathered data, biased analysis, unscientific research. Each can do more harm than good.

Understanding your studio-specific challenges and competencies is a great place to begin. Some UX might already be part of your processes: playtesting, analytics, maybe some existing-player surveys or formalised competitor analysis. How could they have been employed earlier, and more predictively? Is the staffer getting the academic and moral support they need? Gamedev post-mortem articles very often cite regret for not beginning with player-centric tasks earlier and more actively.

Perhaps rally the team and discuss your experiential risks in the project; does the team recognise any of the challenges listed above impacting their work? How does the team currently combat each of the challenges listed at the start of this article?

It never feels like the right time to ‘test’ the game, until it is too late…

The principle that “good design starts from day one” always hold true. Don’t fall into the trap of ‘checking it tomorrow’, because it never feels like the right time. Investing in UX ‘pays out’ in time saved or reallocated later in the project. Delays only serve to devalue UX’s potential contribution. One cannot reclaim development time already spent.

Try parsing your studio’s previous journalistic reviews and storefront comments; could their criticisms be rooted in not understanding the game, or the impact of tutorials? Do comments reveal players having unintended ease-of-use frustrations, or issues with feedback, balance or navigation? Do analytics reveal metrics below our projections for retention or other player behaviour? If so, you’ve evidence for the return-on-investment for investment in player science on your next project.

Time is the biggest challenge, pacing earlier stages of development to greatly speed up the later stages. Setting aside monthly budget and time for playtesting and research is a challenge for teams who’ve never experienced player-centric development. Know that these roles specifically exist and continues to thrive in all creative domains because their processes pay out in quality and time over the lifetime of production.

Player-centric processes are more than hiring new people and setting aside budget; the company culture may need to change also. Hiring UX staff isn’t enough if the studio is unwilling to steer the company toward this empathetic design process, and empower those staff to instigate change.

There is much to learn from studios who’ve already embedded player science professionals. EA’s Veronica Zammitto shared years of experience at GDC in 2017; Ubisoft, Riot and Epic have all shared their experiences in transitioning to a player-centric culture and process. Celia Hodent’s just-published book considers the applicability of UX and neuroscience to game development. There is a wealth of information about specific UX methods, processes and case studies available, particularly via the IGDA GURSIG community, and the UX Summit. Let’s learn and share together, toward better experiences for our players.

In Summary

Games User Experience is a discipline of science and design for overcoming the difficulties in making games that deliver on their experiential intent. It uses formalised processes and job roles to discover flaws in a game’s design and its means of communicating itself to the player. UX leverages a body of academic knowledge on designing for humans than spans decades of study, across many domains.

Without UX approaches, games fall victim to difficulties that are inherent to creativity, including a lack of objectivity, and challenges in teaching and accommodating players that are dissimilar to ourselves. These factors ultimately affect the perceived quality of the game, critical reception and enjoyment.

When game teams embrace the 4 key roles (Design, Research, Data Science and Leadership), a more empathetic and confident studio culture can form around the core development loop (design, implement, measure, assess), which leads to better games, happier staff and a more productive studio.

Applying these practices to game development delivers successful games, faster, cheaper and closer to the design team’s creative vision. The combined power and efficacy of these player sciences will ensure their continued path to toward becoming a core game development discipline.

Illustrated by the author. With thanks to Lanie Dixon, Aaron Walker, Jozef Kulik, Masse Moughal, Alistair Greo, Morgan Kennedy, Kitty Crawford and other proofreaders or your valuable comments and guidance.

Posted on Leave a comment

PlayStation boss Andrew House is departing Sony after 27 years

Sony Interactive Entertainment (SIE) president and global CEO, Andrew House, is stepping down and leaving Sony after 27 years with the PlayStation maker. 

John Kodera, deputy president of SIE, will take over the role, although House will stay on as chairman until the end of the year to ensure a smooth transition. 

House, who has become the public face of the PlayStation brand in recent years, began his career at Sony way back in 1990. 

Back then, he served in corporate communication at Sony HQ, before moving to the marketing and communications division at Sony Computer Entertainment in 1995. 

From there, he contributed to the launch of the first PlayStation, and after moving through a number of key roles at the company, was eventually made president and CEO of Sony Computer Entertainment in 2011. 

Since then, House has led the charge from the front, driving the launch of the PlayStation 4 — which has sold over 60 million units to date — and overseeing the development and release of Sony’s PlayStation VR virtual reality headset. 

Looking back on his many years with Sony, the exec said he’s “tremendously proud” of everything he’s achieved, but explained it’s time to “pursue new challenges.” 

“I’m tremendously proud of what we’ve built with PlayStation and Sony Interactive Entertainment: entertaining millions globally with the best in games and creating a fully fledged digital entertainment company,” he said.

“PlayStation has been a huge part of my life for more than 20 years but with the business having achieved record-breaking success, now seemed to be the right time for me to pursue new challenges.

“I shall always treasure the friendships and people that have made SIE such a wonderful place to work. I’m also grateful to PlayStation fans and gamers around the world for their loyalty and support. John and the team at SIE are world-class and I know the future of PlayStation is very bright.”

Posted on Leave a comment

Game Design Deep Dive: Randomization and frustration in Everspace

Deep Dive is an ongoing Gamasutra series with the goal of shedding light on specific design, art, or technical features within a video game, in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.

Check out earlier installments, including maintaining player tension levels in Nex Machinaachieving seamless branching in Watch Dogs 2’s Invasion of Privacy missionsand creating the intricate level design of Dishonored 2‘s Clockwork Mansion.

My name is Hans-Christian Kühl, and I am a senior game designer and programmer at Rockfish Games in Hamburg, Germany. Together with about a dozen talented colleagues, I have been working on Everspace for over two and half years. It’s the studio’s debut title and was released on PC as Early Access and on Xbox One as a Game Preview in September 2016, followed by the full release on May 26, 2017.

I’ve been developing games for 13 years now. It all started at Fishlabs Entertainment (now Deep Silver Fishlabs) with 3D mobile games on Sony Ericsson and Nokia feature phones, where I was mainly responsible for Galaxy on Fire I and II, as well as Deep 3D: Submarine Odyssey. I then ported the Galaxy on Fire series to iOS, worked on the two add-ons, and helped with porting the games to MacOS and Windows.

In 2014, Michael Schade and Christian Lohr, the former founders and managing partners of Fishlabs Entertainment, started Rockfish Games as a new indie studio to create high-quality PC and console games with a premium business model. Some co-workers and I took the opportunity to join them and work on a space game which has now become Everspace.

Because of our love of space and sci-fi, and our previous personal track record with the Galaxy on Fire series, it soon became clear that we wanted to create another space game. We knew we couldn‘t afford to create the epic sandbox space opera like Freelancer that everyone dreams of (we still do), so we had to come up with something new. Something smaller and more focused.

Because challenging, rather unforgiving games have recently enjoyed a renaissance, we came up with the idea of creating an action-focused space game where the player dies a lot, set in a randomly created environment to offer a different experience each time they start anew.

We play a lot of games, and some of them offered inspiration for aspects of the game design, most prominently:

  • Freelancer: Every one of us loved the easy mouse and keyboard controls and absolutely wanted Everspace to have similar controls.
  • FTL: This game’s basic framework was something we wanted to have as well.  Press start, choose a ship, upgrade during the run, and reach the last sector.
  • Rogue Legacy: Collect money, die, then spend the money on permanent upgrades that will make all following runs easier. This is a brilliant way to make up for the disappointment of dying during a run.

We combined these features with fast-paced 6-DOF (6 degrees of freedom) combat mechanics and a personal sci-fi story which slowly unfolds as the player advances through the sectors. Finding and crafting new equipment and resources is done on-the-fly, so the further the player gets in a run, the more powerful they will become.  At least until they die and lose everything except found blueprints and credits. The main loop is: Select a ship – Try to reach sector 7 – Die or succeed – Upgrade and unlock new ships and perks – Start again.

When designing Everspace, we had to be careful not to get carried away with trying to add too many features and instead focused on just a few aspects and then put more depth into them. I picked two aspects that I think are worth mentioning because we put a lot of thought into them. So this is not an overview of everything that makes up Everspace, but a couple of its key game design elements and how we implemented them.

On dampening frustration: Looking at the Game Over screen is a frustrating part of playing any game, especially if the game is so hard that you die a lot. We added several things that work against that feeling of frustration so players will say “Bad luck, my mistake. Let’s try this again!” instead of “This is unfair, and I’ve lost everything. I’ve wasted an hour of my life for nothing!”

Reward for dying: The moment the player dies, they see a screen listing the gains of the last run, including credits and permanent unlocks like colors, enhancements, or blueprints.  Then they can spend the collected credits on upgrades that make them stronger by improving their stats and unlocking new gameplay possibilities.

This is the most important feature to reduce frustration, and in the best case leads immediately to the next run. During production, the title said “Congratulations, you are dead!”  We shortened it to “KIA” for release, but we really do mean the former.

Don’t take your time: The longer you play, the more frustrated you’ll be if you die, so we wanted to keep the runs short. We initially targeted one hour for a completed run, which we overshot by 30 minutes for an average run, but it still feels pretty good (and experienced late-game players can finish a run in under ten minutes). 

The most visible method of minimizing a run’s duration is the arrival of alien forces to drive the player out of the location if they linger for too long. If the player continues to dawdle, a colossal warship will eventually arrive as the final bit of persuasion. Some players have complained because they want to explore everything, rather than being hunted. But we really have done it for their own good. Also, players can now earn in-game ways to delay or even prevent the arrival of reinforcements.

We also wanted to ensure that players don’t have to spend too much time in menus. That’s why Everspace does not have a traditional inventory. Equipment items must be placed in a slot, salvaged, or used immediately. When players find equipment, it takes only a few seconds to swap, use, or salvage it, and then continue their flight.

Play fair: When watching streamers playing the game, we often see that there is a certain degree of understanding when their ship gets destroyed. Sometimes they’ve pressed the wrong button and turbo-boosted into an asteroid, or forgotten to repair their ship or regenerate energy before engaging in a fight, and often they’ve just risked too much. So no one really complains about the game being unfair, and that’s a good thing! Though there can be times when the RNG (random number generator) will give you a very hard time by spawning the hardest enemies and situations all in one location. In almost all cases, however, the problem can be overcome with skill, strategy, and patience.

On randomization: Like any classic rogue-like game, players will start a new run numerous times, so we had to make sure they do not get bored by presenting something fresh every time. I want to note that “fresh” does not necessarily mean “new,” but rather “different.” We are a small team and can only create so many new assets and features before players start to encounter the same things again. We had to come up with a plan to utilize our assets in the best way possible to achieve the best effect.

Creating the sectors: Everspace enables players to progress a little further on each run because both their skill and their ship’s stats improve every time they play. This correlates directly with how we designed the sectors, and with how we generate each new run. The higher the sector number, the more the difficulty increases in several ways:

  • Locations (the actual gameplay areas) have a risk rating.  The higher the sector number, the more locations or jump points it has and the greater the chance that a location will be more difficult and yield more credits and resources.  Variations in the number and position of locations results in different intersecting paths, some potentially longer or more difficult than others.
  • The player will encounter more diverse and more difficult enemies as they move forward, requiring the player to become stronger both between runs and during the run itself by finding or crafting better equipment.
  • Natural hazards occur more often in later sectors, with increasingly challenging hazard types possible.
  • With each new sector reached, the list of structures that can be encountered (Outlaw outposts, derelict stations, wrecks, asteroids, etc.) grows.

Creating the locations: A location is an area where the actual gameplay takes place. Though it’s a 3D space, it’s not a perfect sphere, but rather a cylinder with a diameter of 10 kilometers and height of about 3 kilometers.  So it’s basically a flat plane with some room for objects to spawn slightly above and below it. Because we do not have a mini-map, this helps tremendously in finding one’s way.

Each location has a certain number of points it can spend on the POIs (Points of Interest) it can spawn, depending on the selected difficulty level and the current sector number. A POI can be an alien patrol, a freighter wreck, an Outlaw station, a huge hollow asteroid, a mining outpost, etc. Each POI has a score that represents its difficulty and its probability of appearing in a given sector, so many location scenarios are possible: a balanced location with a little bit of everything, or maybe just a few large Outlaw outposts, or perhaps a relatively quiet mining facility with resource freighters and some surprise attacks. Combine that with the randomized appearance and placement of planets, stars, asteroids, plasma fields, black holes, mini-missions, and loot containers, and you get a fresh location each time you play.

This all sounds like a good way to create a virtually unlimited number of exciting playgrounds, and it is, but there are also downsides:

  • If you don’t work with a lot of restrictions, strange things will happen. We had asteroids blocking doorways or stationary warships spawning inside of jump gates, making it impossible to get away. We had two of the same type of Outlaw station spawn right next to each other. We had black holes spawn right next to a mining outpost, dragging all NPCs into it immediately. We also had (and sometimes still have) missile turrets that pose no threat because they will always hit an asteroid which spawned directly in front of them. 
  • If you work with a lot of restrictions, strange things won’t happen.  With all the restrictions in place, we still have a lot of variance between locations, but we rarely see any real surprises. There are no locations with just two freighters in it, no locations which are full of asteroids and nothing else, and no locations with a dozen black holes or a battle between fifty NPCs.

The price of control is uniformity here. Apply more restrictions, and you will get more reliable, but also less interesting outcomes. Custom scenarios with special rules that come up now and then would have been a nice addition, but this idea did not make it into the game.

Creating the NPCs: We intentionally excluded all non-player characters from any randomization except for the loot they drop and the length of freighters. So you can be sure that Outlaw Scouts will spot you at a 2.8km range, shoot at you with Gatling guns, and have more hull than shield hit points. This is important because it allows memorization of each unit’s behavior. The first encounter may be surprisingly hard, but the more players observe their enemies, develop their skills, and learn how to best use their equipment, the more seasoned and capable they will become. Randomized enemies would only dilute this “Git Gud” experience.

Everspace is a game that combines old-school skill-based dogfighting with modern rogue-like (or more fittingly “rogue-lite”) elements. Not going for the all-embracing epic space opera and being limited to a small team helped us focus on the most important features: Live-Die-Repeat game loop, easy controls, and impressive graphics (because I heard they were pretty good).

Exploring the power of randomization has taught me a lot, and I can see its usefulness for multiple upcoming projects. Also, keeping players happy after the Game Over screen and motivating them to try again worked surprisingly well. I’m curious to see how other games will handle this and which combinations of established game design aspects we will see in the future.

Posted on Leave a comment

New Developer Interview: Learn the secret origin of Yoshi!

New Developer Interview: Learn the secret origin of Yoshi!

Yoshi—Mario’s adorable, flutter-jumping companion—made his debut back in Super Mario World™, the smash hit game that launched with the original Super NES™ system back in 1991. Now you can learn about the lil’ green hero’s creation in this in-depth interview with members of the original development team here.

To play Super Mario World and many more classic titles, check out the Super NES Classic Edition system, available on Sept. 29, 2017 for a suggested retail price of just $79.99. This miniaturized version of the original system lets you plug-and-play 21 classic Super NES games.

Learn more on the official site at http://www.nintendo.com/super-nes-classic.

Posted on Leave a comment

Crafting the visuals of 20XX for maximum comprehensibility

20XX is a fast-paced sidescrolling roguelike that’s found an appreciative audience on Steam since it launched last month. It mixes a decidedly Mega Man X-esque play style with generated levels to constantly test players’ twitchy jumping and shooting reactions. That’s meant that the art and animation has been a very, very important part of the game.

20XX has always worn its inspirations on its sleeve, but there’s plenty beyond that that’s informed the game’s aesthetic. says Chris King, programmer and designer at Batterystaple Games, developers of 20XX.

While a Mega Man X aesthetic appeared due to its inspirations, 20XX looks like it does not just because of where the game came from, but because its ever-shifting level structure and enemy layouts require players be able to react quickly and decisively, reading information on-screen without having to focus on it.

More than just for visual appeal, 20XX looks like it does to help players succeed at its challenging roguelike play.

“The skills gained by implementing a given asset made us much more capable of fixing up older assets, which is a good bit of why we’ve iterated on the visuals so much.”

None of that is to say that the visual style doesn’t have an aesthetic appeal to its developer. 20XX’s art style isn’t just designed for readability, but also for that same reason any developer would choose a certain art style: because it looks good and suits the game they’re striving to create. Having sprung from a Mega Man X inspiration, this meant a futuristic, mechanical sci-fi appearance, but it’s one that has continually evolved over the game’s development.

“We’ve learned a tremendous amount over the past four years while making 20XX, and ‘How to make it look better.’ has been a pretty consistent part of that,” says King. “We were new enough on the scene at first that the skills gained by implementing a given asset made us much more capable of fixing up older assets, which is a good bit of why we’ve iterated on the visuals so much.”

Part of that design process meant shifting art styles here and there, gradually changing the exact appearance of the game over time as they experimented with variations on the look they began with. They also simply learned more as they worked at the game over a four year span, growing in skill over that period.

“Somewhere in the game’s second visual iteration it took on a very colorful, Saturday-morning-cartoon kind of vibe, which ended up working really well with the game’s quick pace and need for instant player reactions.”

This is part of what would lead them to the look 20XX has now – a growing skill and a slow honing of what art style felt right to the developers at Batterystaple Games. 

“Somewhere in the game’s second visual iteration it took on a very colorful, Saturday-morning-cartoon kind of vibe, which ended up working really well with the game’s quick pace and need for instant player reactions,” says King. “Zach Urte’s style leans into the game’s rounded edges and smooth curves, and he definitely took a good bit of inspiration from Chris Sanders’ (Lilo & Stitch) work.”

“I guess what I strive for most is consistency and fidelity,” says Urtes. “I want the game to be the best version of itself, and finding what that means has been an ever-present part of the learning process. Sometimes less is more; learning where to snipe quality and when to pull back’s been a big deal for us. On a personal note, I’ve just always wanted to make a game that feels like a colorful, exciting action cartoon. I think we’ve done that here.”

That ‘action cartoon’ style was not just the result of the developers feeling their way toward the art style that felt right for 20XX, but also a way they could work on the important features of readability and reaction.

“The game’s foes and projectiles have to be clear enough that a player immediately knows what’s come on screen without having to fully shift focus to it, which turned out to be a serious challenge”

That vibrant, rounded Saturday morning cartoon style was the final step in the constant struggle toward clarity the developers had been working at. 20XX would require that same twitchy reaction time that the games that inspired it required, but the randomization aspects meant that players couldn’t just memorize enemy layouts and shot patterns. They would have to react to them with no previous experience (in that exact, repeated situation) to train them.

20XX has undergone more than one facelift since we started making it four years ago. We’ve learned a lot while making and remaking it, and one of the key lessons is that the game’s pace prefers instant readability to painstaking detail when it comes to asset and environment design.” says King. “In order to avoid getting in the way, the game’s foes and projectiles have to be clear enough that a player immediately knows what’s come on screen without having to fully shift focus to it, which turned out to be a serious challenge.”

King and the development team would need to make enemies and their projectiles crisp and visible without requiring the player take their attention away from what they were doing, requiring their visuals be recognizable at a glance. If it required any more attention than a moment’s peek, or drew even slightly more focus to identify them, the game would fall apart.

“Spine (our animation software) lets us layer animations on top of one another, so we don’t have to be too concerned about what movement state a player is in on attack-press – we can always snap to action instantly when required.”

They made that less of a problem by focusing on the animations of the characters and enemies. “Crisp gameplay is key,”  says King. “In a game like 20XX, it’s super important that every button press results in an action instantly, and that dictates how most of the player animations need to play out. If it takes Nina three frames to raise her buster before firing, or if Ace’s base sword slash takes three frames to get in front of him and deal damage, the game’s immediately much worse.”

Players needed to be able to react to surprising situations they hadn’t seen before in 20XX, or to enemy attacks that might not immediately jump out at them. They had worked to make these attack visuals stand out, but if the player couldn’t react to them quickly enough, their work would have been wasted.

“Spine (our animation software) lets us layer animations on top of one another, so we don’t have to be too concerned about what movement state a player is in on attack-press – we can always snap to action instantly when required,” says King. “To make up for that a little, we add more weight to the non-player-action animations – things like landing, stopping, lowering your weapon, etc all get a little more detailed since they’re not instant-player-input sorts of actions, and them taking a little time doesn’t cost us anything.”

“Games like 20XX are all about pattern recognition when it comes to dodging bad guys, so super conspicuous tells before enemies take action are really important.”

The player’s attacks in 20XX are all instantaneous, allowing players to switch it an attack animation the moment they sense they need it. This deliberate decision to animate in this was would be key to allowing players to deal with new threats or changes in the environment quickly, rather than force them through a few frames that may result in their death. Readability was important with the art style, but being able to react to what is read with a quick attack animation was the other half of the equation.

And that’s not to say that there aren’t some elements of memorization at play, either. “For enemies, it’s the exact opposite,” says King. “No enemy should attack without warning – games like 20XX are all about pattern recognition when it comes to dodging bad guys, so super conspicuous tells before enemies take action are really important.”

Enemy animations would have long tells that the player could learn to recognize, as while stages were generated, enemies would still have known actions and behaviors players could pick up over time. Even for a brand new player, these kinds of animated tells would indicate that an attack was imminent, getting the player ready to use their tools to react and dodge or fight back.

These three items – focusing on readability in visuals, quick player attack animations, and enemy attack tells – form a means of keeping the action at a fast pace while still giving the player tools to instantly know what is happening and how to react to it appropriately. Through these animation details, a player is given multiple levels on which to deal with a threat that they see clearly before it’s coming, see clearly when it’s on its way, and be able to drop everything and deal with it.

“First and foremost, the game’s visuals serve to abet its rock-solid gameplay — after that, we hope it’s nice to look at,” says King.

Posted on Leave a comment

Video Game Deep Cuts: The Creative Loot Box Observer

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


[Video Game Deep Cuts is a weekly newsletter from curator/video game industry veteran Simon Carless, rounding up the best longread & standout articles & videos about games, every weekend.

Some of the highlights include the history of Creative Assembly, a disassembly of the loot box phenomenon, and analysis of the cyberpunk standout Observer.

While not a long-read, I wanted to point out something you might have missed – Amazon’s move into Echo buttons, which will be used specifically for family games.

Though the concept that you might play audio-only games seems a bit weird to start with, we’ve been playing the Jeopardy game on Alexa fairly regularly in our house, and it’s lots of fun. (Particularly because it tells you your ranking against other teams.)

There are others thinking about visual party game solutions using cellphones, too, from Jackbox Games to Sony’s relatively slept-on PlayLink series. It’s all an interesting crossover that brings to mind the late and sadly lamented 1 vs. 100 Xbox Avatars game. There’s some fertile ground here, folks!

Until next time…
– Simon, curator.]

——————

What Other Games Can Learn From the Bullet Hell Genre (Amr Al-Aaser / Paste Magazine)
“When you hear “bullet hell” what do you think of? It’s not a new term, but it’s gained increasing prominence in the mainstream games discussion over the last decade, and is often associated with any game with overwhelming numbers of enemy projectiles.”

World Record Progression: Half Life 2 (Summoning Salt / YouTube)
“[SIMON’S NOTE: this mini-documentary explains how the speed run for Half-Life 2 was gradually improved, and is, naturally, mindbending in several different places – all his videos on speedrun progression are super-interesting btw.]

Postmortem: Greater accessibility through audio in Killer Instinct (Zachary Quarles / Gamasutra)
“One of the main audio goals for our fighting game reboot Killer Instinct (KI) was player feedback.  We wanted to make sure that someone knew exactly what was going on at any given time using audio alone.”

Pilotwings’ Lost Open World Reboot (DidYouKnowGaming? / Unseen64 / YouTube)
“Factor 5’s Pilotwings reboot was an open world game developed exclusively for the Nintendo Wii. The project originated on the Nintendo GameCube, but was eventually pushed onto the Wii. Factor 5 experimented with with a kind of head tracking glasses that affected what was displayed in relation to the player’s position. [SIMON’S NOTE: with lots of unseen footage from the creators!]”

From shareware superstars to the Steam gold rush: How indie conquered the PC (Richard Cobbett / PC Gamer)
“Indeed, the world of indie development is now so important that it’s hard to remember that it’s only really a decade or so old. That’s not to say that there weren’t indie games before then, as we’ll see, but it was only really with the launch of Steam on PC and services like Xbox Live Arcade that the systems were in place to both get games in front of a mainstream audience.”

Video Games: Access To The Computer Age (Jorge Reina Schement / Los Angeles Times via Simon’s Twitter)
“[SIMON’S NOTE: a 1982 editorial about courts banning game arcades, pushing back & suggesting there’s long-term ‘academic value’ in having kids grow up with games. Which there was! Found via a separate article in an arcade trade mag, original discovered by the Video Game History Foundation Discord I hang out on.]

Gaming’s Toxicity Problem Can’t Be Solved With DMCAs or Valve Charts (Katherine Cross / Glixel)
“What is equally clear is that if you’re a developer, despite profiting from your work, Valve will not protect you when their platform is used to organize abuse against you or your colleagues. This abstentionism, of course, only nurtures the worst of gaming culture.”

Applying 3D Level Design Skills to the 2D World of Hyper Light Drifter (Lisa Brown / GDC / YouTube)
“In this 2017 GDC talk, independent level designer Lisa Brown explores how level design skills transfer between different formats, comparing her work on 3D titles Insomniac Games to her work on the 2D game Hyper Light Drifter.”

The Company That Wants To Replace Textbooks With Video Games (Chloe Spencer / Kotaku)
“On any given day, CEO André Thomas arrives at his company Triseum’s office in Bryan, Texas at nine in the morning. While this is when Thomas gets in, his work day usually starts hours before by checking sales on the company’s educational video games.”

The doors close on The Chinese Room – for now (Wesley Yin-Poole / Eurogamer)
“Just under a year after the launch of Everybody’s Gone to the Rapture, a “walking simulator” about dealing with loss in Shropshire in 1984, it won three BAFTAs. For its developer The Chinese Room, it seemed things couldn’t get any better. Fans anxiously awaited the studio’s next big project. They’re still waiting. [SIMON’S NOTE: one of the most honest dev interviews I’ve ever seen.]”

Retronauts Micro 70, plus the inside story of Oregon Trail (David L Craddock & Jeremy Parish / Retronauts)
“The following excerpt comes from Break Out: How the Apple II Launched the PC Gaming Revolution by David L. Craddock… In this chapter, roommates and student-teachers Don Rawitsch, Bill Heinemann, and Paul Dillenberger work around their teaching schedules and brainstorm game design for the first version of The Oregon Trail. [SIMON’S NOTE: there’s also a podcast about the book in here.]”

Games Industry Lobbyists Praised Trump, and No One Should Be Surprised (Patrick Klepek / Waypoint)
“More than a few people winced yesterday when the Entertainment Software Association, the Washington, D.C.-based trade organization representing the video games industry, issued a press release in which they praised President Trump for “bold leadership in computer science education.””

The New Flesh | Observer (Zach Budgor / Heterotopias)
“Observer is the rare cyberpunk story that refuses to fetishize its milieu, even today, 30 years after the genre’s inception. William Gibson’s early work, despite its incalculable influence, still throbs with the low-level hum of awestruck Japanophilia subsumed into equally stylish noir tropes.”

The story behind the design of Dishonored: Death of the Outsider (Gamasutra staff / Gamasutra)
“Gamasutra staffers recently had the pleasure of talking to Harvey Smith of Arkane Studios while livestreaming Dishonored: Death of the Outsider, the well-received standalone followup to Dishonored 2. Smith’s comments about the design of various features in the new game, and in the franchise more generally, were fascinating. So fascinating that we decided to transcribe portions of the stream.”

Games on the Mersey, Part 4: The All-Importance of Graphics (Jimmy Maher / Digital Antiquarian)
“Psygnosis’s first games had been created entirely in-house, with much of the design and coding done by Lawson and Hetherington themselves. In the wake of Barbarian‘s success, however, that approach was changed to prioritize what was really important in them.”

The untold origin story of Creative Assembly (Robert Purchese / Eurogamer)
“”The aim was earning a living,” says Tim Ansell. There were no dreams of strategy epics and no dreams of blockbusters. In those days people wanted PC ports of Spectrum and Mega Drive games, and they wanted 23-year-old Ansell, apparently the only person in the country capable, to make them.”

Loot boxes have reached a new low with Forza 7’s “pay to earn” option (Sam Machkovech / Ars Technica)
“At this point, it would take something monumentally stupid to reverse the “loot box” trend in video games. The practice, which combines real money, virtual items, and random chance, has been found in various free-to-play games for years (and has been showing up more in fully priced retail games recently). [SIMON’S NOTE: detailed & vital rant against something which may be important for devs to fund games, but can go wrong pretty quickly.]”

One Man’s Journey From Welfare to World’s Hottest Video Game (Yuji Nakamura & Sam Kim / Bloomberg)
“Three years ago, Brendan Greene was on welfare in his hometown of Kildare, Ireland, getting an earful from social workers about how he should stop wasting time developing free computer games. “They were telling me to look for jobs or I’ll be cut off,’’ says Greene. “I kind of ignored them.””

The Dungeons & Dragons-loving geeks who became the godfathers of gaming (Sam Leith / The Spectator)
“‘I have a slight bone to pick with you,’ I tell Ian Livingstone as he makes me a cup of coffee in his airy open-plan kitchen. ‘This is a bone I have been waiting to pick for, oh, 35 years. That bloody maze!’”

Flash games and the importance of disposable media (Phil Salvador / The Obscuritory)
“When Adobe announced plans to discontinue Flash earlier this year, people rightly mourned that we’d soon lose the ability to easily play over two decades of amateur games and animation. Gigantic collections, like nearly the entire library of the game platform Kongregate, will rapidly become obsolete.”

Jaedong fights the end of his career with reckless abandon (Young Jae Jeon / ESPN)
“”I’ve been playing for 15 years now. My body is wearing out.” His eyes are bloodshot, his face pained. His tone is subdued, his voice a half-whisper. It feels nothing like a victorious postmatch interview. He almost looks ready to cry. [SIMON’S NOTE: potentially aging out of eSports at… 27?! It’s a young person’s game out there.]”

——————

[REMINDER: you can sign up to receive this newsletter every weekend at tinyletter.com/vgdeepcuts – we crosspost to Gamasutra later on Sunday, but get it first via newsletter! Story tips and comments can be emailed to vgdeepcuts@simoncarless.com. MINI-DISCLOSURE: Simon is one of the organizers of GDC and Gamasutra & an advisor to indie publisher No More Robots, so you may sometimes see links from those entities in his picks. Or not!]