Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
May 29, 2020
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

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

Postmortem: Petroglyph's  Grey Goo  - getting back to the roots of RTS
March 23, 2015 | By Ted Morris

Article Start    Page 1 of 3  

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.

Article Start    Page 1 of 3  

Related Jobs

innogames — Hamburg, Germany

Java Software Developer - Core Team
Scanline VFX
Scanline VFX — Los Angeles, California, United States

Unreal Technical Director
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Experienced Game Developer
Moon Studios
Moon Studios — Remote, California, United States

Senior Character TD

Loading Comments

loader image