Postmortem: Petroglyph's Grey Goo - getting back to the roots of RTS

Ted Morris is the Executive Producer at Petroglyph working on Grey Goo.

Grey Goo is a sci-fi, real-time strategy, (or RTS for short) game from veterans of Westwood Studios – creators of the Command & Conquer franchise.  

Our goal from the beginning with Grey Goo, was to encapsulate the gameplay that made RTS games of old so great and to update it with the modern trimmings that today’s gamers expect.  

As we like to say internally, we wanted to go back to the roots of the RTS genre and we did that by focusing on immersive base building, intuitive resource management, and intensely rewarding combat that you’ll want to tell your friends about.  

Today, I wanted to take the opportunity to share our experiences, both positive and negative, tackling the beast that is making a classic RTS game for the modern marketplace.

What Went Right

1. Very Early Prototyping

Before there was a GDD or even a playable game, the design team tried some very early playable prototyping and gameplay. We started with a board game version of the major game systems to work out a lot of stuff before we overcommitted to our designs. 

We wanted to make sure we got it right. Being able to play the basic game before the GDD was even completed caught problems and issues very early and allowed us to have a lot more polish time instead of scrambling to “find the fun” halfway through the project.

2. A Fundamental Shift in the Work Environment

To assemble the Grey Goo team required us to break up a couple previous teams, and reconfigure them back into a highly efficient group. There was a fairly good debate going on whether we should go to a more open office environment. 

Previously, everyone had been crammed two or three to an office and there were long hallways throughout the building. It didn’t allow for the kind of open communication that we felt was key to making great games. For our new building, we decided to go for a more open environment with workstations built in pods of four and walls high enough that you could stand up and see everyone in your group. 

We also created more meeting rooms so that if someone wanted some privacy or a discussion got noisy it could be taken someplace more private.  

We saw a lot of benefits from this change; impromptu meetings sprang up to solve problems on the spot, everyone was on the same page about the components they were working on, windows were now a more widely available commodity and there seemed to be less of a reliance on email to get things done. There were, of course, a few transitional issues as well (like noise), but after everyone got used to their new environment, that regulated itself fairly well – or people started wearing headphones.

3. Utilizing Our Production Assistant Team

We have a strike force of about 15 people we call Production Assistants (PAs). They do testing for us, but they are not QA. They have been called upon to handle FX and animation work, produce gameplay and tutorial videos, write documentation, help with V/O work, build maps, and handle localization, amongst other responsibilities.  

They’re art school graduates, beginning coders, and aspiring game and sound designers and they’ve been able to develop their experience in these capacities. We’ve promoted people out of this department into Design, Art, UI, Engineering, and Production based on ability, drive, and our needs at the time.

Our PAs are serious players as well, and they very often provided insightful and in-depth feedback on the balance and fun of the game. We treated and listened very carefully to them as if they were the customer.  Very often this put our PAs and Designers in conflict with one another, but the Design team appreciates a good debate and is open to making changes where necessary.

One of the other great benefits was the ability to quickly test new features.  With a few rare exceptions, the game was always playable, always rock-solid. Assigning PAs to test the functionality of specific systems allowed our engineers to do shallower testing of their own work and move on to other important tasks.

4. We Took Risks

We took more risks than we have in the past, and they mostly paid off. We aimed high with the art quality and that required very high min-spec hardware. We completely ditched our old UI system that we were very comfortable with and went with Scaleform. We replaced the entire movement and navigation system -- which is always a huge headache for RTS games.  

We used CLIPS for an AI system that actually reasons about the game and does not cheat. Instead of canned animations for the Goo, we went the procedural metaball route which was a very punishing but rewarding process. Without a doubt these decisions were second-guessed throughout development and we could have always back-pedaled or punted if we had to, though it would have been painful. But if you take no risks and end up with an uninspiring title, you’re screwed-toast-road-kill-dead-meat.

One of the biggest risks was with the design of the Goo itself. The original idea of creating the Goo -- a race of nanite amoebas -- is cool. It’s relatable. It’s an idea good enough to hang a game on. This kind of “high concept” thematic vision was risky because it introduced the idea of a self-replicating, highly mobile faction that could ignore the rules of where armies could and couldn’t go on a map. In the end, we had to rework the core design about three times before we felt we got it right -- and it seemed we were always flirting with a deadline we might not make.

5. Focus Testing

We were aggressive on getting volunteers outside the company to play the game. We beat the bushes to find people. We blocked out half-days for in-house play. We advertised on Facebook and Craigslist, brought in relatives, neighbors and friends. If you got a job with us, the first thing you were assigned to do was play Grey Goo and give us your review. We conducted surveys, both written and digital, but the most valuable information was from watching each person play the game for the first time. We had a team member with a notepad sitting behind every player we brought in.

One of the best partnerships we made was with a local high school to supply us with aspiring game developers on Saturdays. In exchange for four hours of time, pizza and soda, we received feedback that was both invaluable and brutally honest. Things that seemed so obvious to us were completely invisible to them (and sometimes vice versa!) The students felt privileged to feel a part of the process and we received the feedback we needed. Everyone won.

What Went Wrong

1. Campaign Redirect

The initial plan for the campaign was a series of completely unscripted missions tied together by cut scenes. We wanted a showcase for our slick new AI system. About a year before launch, things didn’t feel right. The “missions” felt more like an AI skirmish match repeated 15 times -- it was tedious to play through. There was a rebellion in the design department, but deciding what to do about it was difficult. It took two long and valuable months of deliberation before we finally decided to start over.

We essentially doubled the amount of work it would take to complete the campaign. Two more designers had to be repurposed to create the character dialogue, mission objectives, triggers, and other scripted content. We had to resurrect our scripting engine and tools, which added a delay before the designers could even begin their work. 

We also had to build in a cinematic system to move the camera around the scene before each mission so we could intro the story to the player instead of just dropping them in cold. This was extra code work that had not been planned for. Some of the map designs got a reboot -- which caused more unplanned work for the artists.

In the end, we absolutely made the right call.  Had we been more objective, we could have seen the redirect needed to be done sooner and allowed for even more iteration.

2. Our Campaign Was Too Challenging

The Grey Goo campaign game has three difficulty levels. We refer to them as Easy, Normal, and Hard, but our players like to think of them as Hard, Brutal, and Nearly Impossible.

With our focus testing, there wasn’t time to allow players to go through the entire campaign from beginning to end, so we received much more feedback on the first few missions of the campaign and less on the rest. Internally, we played it from front to back hundreds of times and we took several passes through the campaign to make it easier, but we couldn’t objectively gauge the difficulty level for our first-time players. We were just too close to it. The difficulty level was just too punishing, especially given our new AI system and we were too good because we were already seasoned veterans of the game.

It took a couple weeks, but we installed knobs so we could slow down the AI on Normal and Easy.

3. No Beta Phase (No, not the faction)

At launch we received great review scores and kudos from most players regarding the general stability for a game that didn’t have a Beta Test. 

However, it was incredibly painful to hear about a handful of bugs or strange behaviors that some players were getting -- all of which could have been found and fixed before launch. Especially bad were multiplayer connectivity issues that could only be replicated with a large number of players.

4. Too Few Multiplayer Maps

While we achieved the goal of creating a very rich game environment, the cost of map development in terms of time and manpower felt very expensive. Each campaign map took roughly four months from paper to final polish. We didn’t want to sacrifice quality, so in the end we had to build less multiplayer maps.

Not wanting to compromise quality as well, Grey Box welcomed the opportunity to share map creation tools with our players and develop a public version of our Grey Goo Terrain Editor to be distributed with the game at launch. At last count there were plenty of maps available for download through Steam Workshop and more coming online every day. We are also continuing to add new features to the terrain editor over the next couple months which will allow players to import their own assets into the game if they wish.

5 Piracy / DRM / Anti-Virus Concerns

We began signing and DRM-wrapping our files three months before launch. It didn’t take long before we received reports that virus scanners were flagging the game as malware. They would refuse to run the game or delete the files outright as they were being downloaded. We knew it was the addition of DRM that caused it. The support forums suggested we just remove DRM to get around the problem, a risky move.

It took months of phone calls, emails, and FTP uploads before we were able to work through the various anti-virus vendors to whitelist the game. It took the pirates a day to undo all that work and post it on the web.

As if that wasn’t disappointing, the message boards were full of people complaining about weird graphics issues or crashes -- all stuff we KNEW was fixed in the build we released just before launch. 

As it turned out, they were complaining about bugs in the incomplete, pirated version of the game. A random sampling of our metrics server data indicated that 35 percent of our players were using a pirated version, but they were causing 77 percent of the crashes. This was going on while we were trying to fix bugs for the loyal, paying customers.

Outside of going free-to-play or requiring the game to connect to a server to play it, we’re still looking for a better solution.

Conclusion

I’m really proud of what we’ve been able to create in conjunction with our stellar partners at Grey Box, Axis Animation, and Weta. It was a bold move to build a classic, yet also evolved RTS game when the market has been shifting so heavily to the MOBA and F2P titles. 

We’re excited for the future of Grey Goo as we continue to improve on the core game and release new features and improvements to the fans over the coming months.