Kingdoms of Amalur: Reckoning, the single collaboration between Big Huge Games and parent studio 38 Studios, became an inadvertent teachable moment for the games industry when rocky initial sales, mismanagement and no end of poor luck resulted in the complete closure of both companies in May 2012, just three months after the game's release. Financed in part by a loan from the state of Rhode Island, Reckoning is also a fairly unique case of a triple-A game built with the help of alternative funding.

In this postmortem, reprinted from the April 2012 issue of Game Developer magazine, former Big Huge Games executive producer Mike Fridley walks through what went right and what went wrong with Kingdoms of Amalur: Reckoning's production leading up to its ill-fated release.

Over five years ago, Big Huge Games set out to completely change the type of games we make. We switched from making real-time strategy games to role-playing games, and we started making games for consoles in addition to PCs. We made these changes for several reasons, and although profit was one of those reasons, it wasn't the only one. We wanted to do something crazy. We wanted to make a big open-world RPG -- pretty much the craziest project we could think of short of an MMO. But we're all big fans of the genre and thought we could find our niche in it, so we started our quest to convert the studio into an RPG ho use.

At first, our RPG project was named "Crucible" and was being published by THQ. We were making great progress on it, and THQ was happy enough with the progress that they purchased us outright; and we became an internal THQ studio. Around that time we switched some of the key features of the game and renamed the project "Ascendant." We were part of the THQ network of studios for a short period of time right up to the point that THQ started running out of money. Our big, juicy, unproven-in-the-genre studio was a prime target for them to try to sell.

With literally days left on the "close the doors" timer at the studio, THQ sold us to Curt Schilling's 38 Studios, which has R.A. Salvatore as "creator of worlds." It became clear pretty quickly that we would need to change the universe and some of the game features yet again to take advantage of Robert's genius. We changed the project name to "Mercury," which later was given the final shipping name of Kingdoms of Amalur: Reckoning.

For those keeping track at home, in five years we were bought and sold twice and changed the name and core features of the project three times. Needless to say, it's been a long, strange trip. The rest of the postmortem will be restricted to the two and a half years we spent working on Reckoning rather than the two previous false starts.

What Went Right

1. Combat: RPGs don't have to have boring fights

Shortly after we came out of preproduction, we took a long, hard look at the game we were making and tried to figure out where we were going to be better than the competition. We figured that open-world RPG designs are segmented into four basic quadrants: story, character progression, exploration, and combat. We discovered that it was easy to identify the games leading the industry in story, progression, and exploration, but there was no clear title that does combat well while still meeting the expectations of the player in the other three quadrants. So we decided to go all-in on combat and change our staffing plan to really commit to making combat fun in an open-world RPG.

The game wasn't built solely around combat, but it was definitely built with our flavor of combat in mind. Everything from the minimum size of a dungeon's hallway to the number of enemies we could handle onscreen at a time was governed by the guideline that combat had to remain awesome.

Two of the other things that went right during development were direct results of this focus on awesome combat, usability testing and functional group seating.

2. Usability testing -- early and often

We made sure that getting feedback from real players was high on our priority list from the very beginning. Since we couldn't just release work-in-progress builds to the public and take surveys, we did the next best thing and took advantage of EA's usability lab very early in the development process. The lab at EA allowed us to pull in testers from the general public and use them for highly focused testing on systems or content that we were currently developing. For example, if we had the first pass of a crafting system in the game, we could pull in a dozen or so players for a half day and get some players feedback on whether the interface was easy to navigate or whether blacksmithing felt rewarding.

Since EA's lab recorded videos of the wrap-up sessions, we were also able to show our team what the player thought of their part of the game. If the attack chain you were working on felt bad or the quest didn't make any sense to the normal player, the team that worked on those areas of the game got to hear it straight from the consumer's mouth. That kind of direct feedback from the player really helped us fine-tune the combat system, and ultimately, the entire game.

3. Functional Groups: Sitting together pays off

As part of our development philosophy, we have cross-departmental teams working closely together. A lot of studios do this, but until this project we didn't really push seating functional groups of people together at BHG.

Some of that may have been because the physical structure of the studio didn't lend itself to more than three people in an office, or it could have been just old-school thinking that never changed until it was forced to change. We did eventually break down the walls (literally) and start sitting larger functional groups together in what we called "pits" around the office. For example, the combat pit has animators and designers all sitting side by side.

This way, an animator working on an attack chain could be sitting just a few feet away from the designer implementing and fiddling with it in-game. They could easily look at each other's work and offer comments or critiques very quickly.

However, functional groups are less about speeding up the feedback process and more about forcing interaction. A lot of developers are lazy about socializing or unaware of what is going on outside their office, but when the people you are directly working with are in your face all day, you start to bond with them. A lot of our functional groups became pretty tight-knit and hung out after hours, really bonding as a group. That translated into more and better communication in their work and really increased the quality of the end product.