GameSpot may receive revenue from affiliate and advertising partnerships for sharing this content and from purchases through links.

Battle Realms Designer Diary #7

Ed Del Castillo takes us through one of the most crucial development phases of Battle Realms: the pre-test test cycle.

3 Comments

Entry #7 - 04/16/01

By Ed Del Castillo
President, Liquid Entertainment

"This is crazy! The ronin is way too powerful!"

It's not a designer who says it, but one of the artists--and it's a beautiful thing to hear. Battle Realms is finally in a playable state, and every evening we fire up a series of multiplayer games. We've still got a long way to go before the game hits the shelves, but even before all the features are in, we're going to make sure the combat dynamics are as polished as possible. And that means not just working on the game, but playing it as often as we can.

click for full size image
click for full size image

This pretest test cycle--when the only people playing the game are members of the core development team--is a crucial phase of production. It's here we'll spot the most glaring flaws, the obvious balance problems, the worst bugs, and the features that just aren't necessary. And it's here we'll finally be able to answer the question that plagues every project: Is the game fun?

From Bug Fixing to Battling

Particularly in a complex multiplayer real-time strategy game, getting things up and running early is crucial. Game balancing for an RTS is a long and difficult process. With so many factors affecting combat--height, armor, weapons, battle gear abilities, unit speed, and a host of other multipliers and bonuses--trying to balance units mathematically only took us so far. There's no substitute for putting units down and seeing them fight each other.

But before the game could be balanced, it had to work. Creating functional multiplayer and networking code in a synchronous RTS is always a challenge, and Battle Realms was no exception. We've had our share of sync bugs. Early tests on our LAN were frustrating; often we'd start up a game, only to drop three of the four players in the first ten seconds.

We pushed on. The programmer responsible for the network code implemented a system for event logging, and whenever sync bugs would occur, he would pore over the logs to see where things went wrong. Eventually, we were able to complete a two-player multiplayer game, then a three-player game, and then a four-player game.

Other bugs would often bring the early tests to a screeching halt. We had thousands of individual assets in Battle Realms, and the process of turning them into usable game data is complex. Despite our best efforts on the production side, errors crept into the process. If a single unit in any clan was missing a crucial animation state...boom, no more multiplayer game. Early tests that quickly ended in failure, though frustrating for team members who just wanted to play the game, were necessary for tracking down art or audio assets that might have slipped through the cracks.

From Battling to Balancing

The day we first completed a multiplayer game with two players was glorious. Only the Dragon clan was playable, and neither participant was fully familiar with the game's dynamics. The game was a surprisingly even match, and all-important bragging rights were at stake--whoever won would be, briefly, the best Battle Realms player in the world.

click for full size image
click for full size image

Even after the very first game, we knew we had something special. The fact that peasants were automatically generated in our game had been a source of controversy in the early phases of the project. But it worked--it felt natural and "right." The team had also worried that our unusual method for training new units would be cumbersome and require too much micromanagement. But training also turned out well; if anything, players who used our queue system spent too little time managing production.

The game was far from perfect, and flaws in our design were quickly exposed in the heat of battle. Once one player started training the Dragon clan's third-tier unit, the samurai, the game was essentially over. The samurai was way too powerful, able to hew through hordes of lower-level soldiers without even slowing down. Subsequent tests quickly degenerated into a race to see who could build four or five samurai first and attack the enemy's town.

click for full size image
click for full size image

Adding additional clans into the mix made matters worse. For several weeks, the Serpent clan just didn't feel right. Serpent against Dragon matches always resulted in a victory for the Dragon clan, even when a clearly inferior player was playing the Dragon clan.

We adjusted. We closed the gaps between units and gave the Serpent clan a little more muscle. Once in a while, we'd "fix" a unit too well; there was an odd day when the Dragon clan's chemist was the king of the battlefield. But every week brought new improvements--things were a little tighter and the game was a little more fun to play.

When we ask the team what the most powerful unit is, and everyone has the same response, we know we have a lot of work to do. It's when we start getting different answers that we'll know we're on the right track.

We're almost there. Last Friday's build of the game was the most solid yet, and everyone wanted to play "just one more." There were some excellent moments--groups of three peasants ganging up on isolated Serpent musketeers, a spearman and a swordsman going head-to-head and killing each other on the last hit, and a group of archers stopping a samurai rush in its tracks.

Is the artist right? Is the ronin too powerful? Maybe...but we've got another team member who thinks he can stop the ronin with a powder keg cannoneer.

I can't wait to see what happens.

Got a news tip or want to contact us directly? Email news@gamespot.com

Join the conversation
There are 3 comments about this story