RPG Developers Should Implement Experience Assurance Testing

Over the years, I have played many role-playing games. I also experienced many bugs that influenced my opinion of those games. Every time I found a bug in the game, I thought: the developers could have fixed this if they had played the game.

I'm looking forward to future games in the franchises that I love. And I know they'll flop if the developers won't test them wholly. In this article, I'll share what players like myself enjoy the most. I also offer an introduction to Experience Assurance testers (not the same as UX). Let's dive in.

We're Here For The Story

RPG Developers, please don't make your game multiplayer-focused. The rich, diverse world-building and character stories draw players to your RPG universe. Make the lore behind your world extensive and your NPCs a conduit to immersion.

But focusing the game on Multiplayer is not the way to win a gamer's heart. At least not gamers who play pure shooters. I'm here for the story. Multiplayer can wait until I've satisfied my need to immerse in this universe.

Mass Effect 2 is the perfect example of a story done right. That game's storyline was a frame story to tell teammates stories to help with a galactic threat. Each of these characters felt like a real person to me. They had their backstories and missions to feel invested in Sheperd's mission. You needed to solve their own problems to help them solve yours.

Mass Effect 2 is not about the Collectors. It's about these companions and their micro-stories within the frame story of the game. It's about their interactions with one another and their interactions with Sheperd. Mass Effect 2 took our decisions and how our teammates reacted and shaped the ending based on that.

If your teammate doesn't commit to your mission, they have a higher risk of dying during the final quests. The ending of the game would reflect such a death.

All this is to say that we, as players, felt our choices mattered. The story was robust, and our decisions affected the characters around us.

The story is remarkable, but what about the ending to the story we've experienced?

The Ending Should Blow Us Away

As a writer, I know how hard it is to create a satisfactory ending.

I played hundreds of hours on Mass Effect 3, doing every quest to raise Galactic Readiness. And when the time came, all my hard work poured into a single choice: Red, Blue, or Green.

What about all the missions I did? All the allies I gathered? My teammates? The DLC released after the game's initial launch to amend the ending is a testament to its importance.

The ending should reflect the choices we made during the game. The conclusion and the main storyline cannot feel disconnected from one another.

One reason such disconnections happen in video games is the presence of bugs.

Squash The Bugs

There is one video games company I applaud for squashing their bugs better than anyone else. If you've heard of Cyberpunk 2077, you know I'm talking about CD Projekt Red. They refused to announce a release date because they wanted their game to be bug-free. They did this with Witcher 3: Wild Hunt, too. They advanced the release date of the much-anticipated game by six months to work on bugs alone.

Inspiring, no?

I love RPG games, and many gamers will agree when I say I'm willing to wait for a perfected game instead of a rushed one. The buggy user experience repeats itself in many triple-a games even today. The irony is these developers have more money to perfect the game. They also have corporate goals. The answer to said goals is the Day One patch. The developer abides by the corporate need to release the game by a specific date. Instead of releasing the game with those fixes, they release them as patches.

Day One patch is not the solution.

There will always be bugs, but they shouldn't affect the players' game experience.

As a Software Engineer, I can estimate the QA process for such a game is enormous. And still, someone should approach management and say, "Listen, there are these issues. Can we get some more time to perfect them?" You may receive a no, which will cause a crunch. That's what we do when we want to release a quality product in a short amount of time. You may receive a yes, which will make things easier.

I'm sure employees had done that within some developer companies releasing terrible games. A game is usually not bad, but you don't have a second chance in first impressions. I hope their message is better received next time.

Microtransactions Break Immersion

I only expect to see microtransactions in multiplayer mode. That's the only place where it doesn't feel weird to me to engage with them. The negative effect of entering my PayPal credentials on immersion is irrevocable. I immediately lost interest.

Their placement is not the only problem. It's deeper than that. We frown on Microtransactions in paid games. I mean, I already paid. Why should my experience differ from someone who bought something extra through microtransactions? Multiplayer is a different story. The main single-player game should remain free of microtransactions.

'The Witcher 3: Wild Hunt', 'Pillars of Eternity', and 'Divinity: Original Sin' are only a few examples. They prove the game will pay for itself if the story is compelling.

RPG Developers should limit Microtransactions to multiplayer if they must include them. Players love and thank developers who invest in their immersion.

Experience Assurance or XA Testing

I don't fancy myself as someone who coins new terms, but I am a writer and haven't seen XA Testing anywhere else. Let's not confuse XA with UX, which deals with the experience users have with the game's UI systems. XA testers deal with the story, the feel, the immersion, and the whole package. Experience Assurance is so much more than the UI and interactiveness.

All game developers should hire XA testers. Experience Assurance testers would have identified all the points I mentioned above.

In my ideal vision, XA testers come to the office daily and play the games they're testing as regular players. The emphasis is on playing the game as a whole experience instead of checking specifics. These testers have little to do during the development stage, as there is no game to experience. They shouldn't have any technical experience with the game. That can affect their judgment of it.

XA testers can be regular players who sign an NDA before the game releases. Many game developers allow players to play a beta version, which does not reveal the story, only a piece of the game.

Instead, XA testers should be able to play a full release-candidate or two. Based on their experience, they will write a thorough review of what is off-putting in the game. Some will focus on the story. Others on graphics, interactiveness, characters, mechanics, et cetera. They will have fresh, varied perspectives from which the developer can learn much.

A better approach to using XA testers' feedback is implementing it and allowing new XA testers to test the next RC. This way, the players do not focus on past issues and find new problems.

A game developer does not need more than two to three rounds of XA testing. All outrage players would have raised will happen in-house instead of Social Media.

Players will always find something to complain about. Fixing issues that XA testers will find will raise the game's reception. 20-30 people playing a game can be a good indicator of how the public will receive it.

XA Testers Are An Essential Expense

Many developers will deny the idea of XA testers. Aside from playing the game and writing a review, they do not assist in the dev stage or writing the story. XA Testers aren't even doing pure QA. They are an expense not all developers would be willing to pay.

But before I go, here's a question for you. What's worse? Spending on XA testers and releasing a better product, or a bad first impression of the game?

You decide.