Tex Atomic's Big Bot Battles Q&A
We speak with three Monolith designers about the company's upcoming mech game.
We'll begin emailing you updates about %gameName%.
In the early fall, news leaked around the Web that Monolith would be publishing a mech game that, rather surprisingly, isn't a sequel to Shogo: Mobile Armor Division, the game that debuted Monolith's LithTech engine. Tex Atomic's Big Bot Battles will instead focus on arena-style one-on-one combat between customized mechs. In a novel move, Monolith has designed the game specifically for electronic distribution and so has worked hard to reduce the download file size to a manageable 15 MB. The game is scheduled for release before the end of this year, and will certainly arrive after the company's other big upcoming game, No One Lives Forever, ships next month.
GameSpot recently spoke with Jason Hall, CEO of Monolith, Matt Norton, lead designer of Big Bot Battles, and Jim Boer, lead engineer, to get more details on the game.
GameSpot: Matt, tell us a little about the concept behind Tex Atomic's Big Bot Battles. What's the story behind Tex Atomic?
Matt Norton: The idea behind Big Bot Battles is that we wanted to create a great game that we could release via the Internet. In order to do that, the game has to have, amongst other things, a very small download footprint. Our free demo is less than 5MB, and the full version of the game currently comes in at less than 20MB.
The real challenge was to create a top-rate title while keeping the file size down. By giving the game a sporting background and concentrating on head-to-head competition, we're able to keep the file size down without compromising gameplay.
Going with a sports background also gave us a chance to create a brighter, more colorful, action-packed mecha game. There have been a lot of mech combat games - some really good ones, and some not so good - but they all shared the same dark and dirty feel, which is probably the right way to go for a wargame. We've created a lighter, more action-based game - pro-wrestling personalities piloting monster trucks through American Gladiator-style events. Big guns, big noise, big fun.
Tex Atomic is the spokesperson for the game. He's part sports announcer, part used-car salesman, and part circus ringmaster. Add in a Texas twang and you've got Tex Atomic. Tex pitches in with pithy comments on the action while you and your opponent are duking it out.
GS: What are the Big Bots like? What sorts of weapons and technologies will players have at their disposal?
MN: Big Bots are divvied up amongst four different weight classes and three different types, or nationalities, of construction.
The lighter bots are very quick and agile, and they're able to jump longer distances, as well as enjoy more hang time in the air - at the cost of lighter armor and shielding. The heavier the bots get, the more armor and shields they can pack on, but the slower, overall, they move. However, bigger bots can carry the big, heavy weapons without changing their performance much, since even the larger weapons make up a smaller percentage of the mass of the larger bots.
The nationalities that we used as a basis for the bot construction are:
Japanese: Lighter and more dependent upon shields and speed for defense.
American: Medium weight with balanced shields and armor.
SovBloc: Larger, heavier bots with tons of armor.
Our bots look different from most mecha combat games because Big Bot Battles is a sporting event rather than open warfare. Therefore, the bots are sort of like dragsters or monster trucks in that they're built to perform flat-out for brief periods of time (the Big Bot Bouts) rather than standing up to weeks or months in a combat environment. You might say it's the difference between a Baja off-road racer and a Humvee - both are built to be tough, but there's a distinct difference.
There are a lot of other options that players can select from in order to make their own personal bots.
The player can choose which power plant to rig each type of bot with. Some power plants give faster speed, at the cost of weaker shields, while some have larger energy reserves, but recharge more slowly.
Different types of weapons have different effects as well. Energy beam weapons do quite a bit of damage, but they have to blast through a bot's shields before they can start to blast critical bot systems. Kinetic energy weapons (slug-throwers of various types) do somewhat less damage, but the damage that they do is split between shields and armor from their very first shot. Finally, explosives (rockets and grenades), do damage mainly to the bot's armor. One possible weapon combination that works well is equipping your bot with an energy weapon to plow through your opponent's shields and then have a Kinetic weapon to pound your opponent into shutdown once the shields are down. Another option might be to have one long-range weapon and one short-range.
We've done a lot to make sure that there are as many options as possible to allow players to customize a bot to match their style of play. One thing that we feel very strongly about is that there is no single perfect weapon and bot combination. All of the bots and their weapons are intrinsically balanced - although there are certainly some combinations that are more effective than others. The benefit is that a novice player can jump right into the game and start blasting away with the prebuilt bots we've included, but a player that wants to tinker around with the bot components can create a bot that intimately fits his or her style of play.
GS: How will the single-player game be structured? What sort of variety will there be between missions?
MN: The single-player game is structured around a series of campaign games in which each campaign is a struggle up through the ranks of other (AI driven) Big Bot pilots for a regional championship. These championships are a series of fights against progressively tougher foes in preselected arenas. We'll release several campaigns to start out with and more free add-on campaigns after the game's initial release.
GS: What sorts of multiplayer options do you expect to include in the game? Have you decided how you will handle player matching?
MN: Right now multiplayer is limited to head-to-head play. This is in keeping with the idea of a sporting event. I think the game would be a lot of fun to play with several players, but we'd have to restructure a lot of code, levels, and the interface. That's something that'll have to wait for Big Bot Battles 2. [grins]
We're exploring a number of different options for player matching. The primary consideration is that it has to be easy and transparent for the user - the simpler the better.
GS: A mech game, Shogo: Mobile Armor Division, was a key step for the success of Monolith, and it also introduced LithTech to the gaming world. What factors played a role in the decision not to make Monolith's second mech game a Shogo sequel?
Jason Hall: That's an easy question. Shogo was a very story-driven game that had strong character development and adventure elements. The arcade-like nature of the design of TABBB was not conducive to continuing to tell the Shogo story in a sequel format - so we needed to take TABBB into a different direction due to its unique gameplay type.
GS: The early push toward online distribution seems to be led by publishers just trying to make a start. Why is now the time for more established companies, like Monolith, to make the move?
JH: Now is the time because the opportunity is there. I don't think it takes a genius to figure out that sooner or later downloading software to people will be a strong distribution methodology that will generate a lot of consumer penetration and more profitable revenue scenarios.
When you see profitable net companies like RealNetworks looking at this notion and taking it very seriously, the light should go off in your head that there are new opportunities beginning to emerge and that you should pay attention to them.
Being one of the first established developers to move into the area of ESD [electronic software distribution] could prove to be a very positive step in helping Monolith become a development leader in this area. It is a calculated risk, but a good one to take.
GS: What will RealNetworks' role be in the distribution of this game? How did your partnership with Real develop?
JH: RealNetworks will market, distribute, and sell TABBB. They already have the entire infrastructure ready and available to support this kind of e-commerce activity, and they've been using it for their RealPlayer and JukeBox (as two examples) registration and purchasing for quite some time. So not only is it a proven system that works, but it's a system that millions of people are already comfortable with.
Our partnership with Real developed out of LithTech's R&D into creating a "web based" version of the LithTech. We spent a lot of time speaking to various companies about their strategic directions, and found RealNetworks through the course of our business strategy and development.
GS: If there were a boxed version of Tex Atomic's Big Bot Battles, how would you compare that to the electronic version you have planned? What are some of the design constraints involved in doing a game for online distribution?
JH: There is really only one large technical design constraint and that is the overall file size of the download. Given the current state of the average Joe user's connection to the Internet, a total file size of around 15 megabytes is about as large as you want to go if you want to land in the more mass-consumer area of download distribution. That 15 megabyte file is zipped, so the actual game when downloaded and decompressed can amount to anywhere between 30 to 40 megabytes.
Probably the largest items affected by the limited file size are the game's sound and graphics, not the gameplay. If you take a look at an average Nintendo 64 game cartridge, it stores less than 40 megabytes of data, but the gameplay still can be fantastic. The same principle applies to these ESD games.
GS: Jim, tell us a little about the engine used in TABBB. The game uses LithTech version 2.5, the same version as in No One Lives Forever. What are some of the changes you've made to LithTech between the two games?
Jim Boer: The primary difference between our version of the engine - called LithTech-Electronic Software Distribution, or ESD - and NOLF's is that we've added support for RealMedia types such as in-game RealAudio and RealVideo support, as well as some other features that I probably shouldn't mention quite yet. Some minor improvements have been made as well, such as support for detailed projected shadows, volumetric fog, and better physics.
GS: Moving forward, what are some of the key strengths of LithTech that Monolith intends to expand and develop?
JB: LithTech was designed from the ground up to be a licensable engine, which means it's easy for a developer to get up and running quickly with its project. TABBB was able to go from ground zero to a fully playable network game in about two months, and this is with engineers that had never worked with the LithTech engine before. I think it's a great testament to LithTech's ease-of-use and solid design.
LithTech is also making strides to be much more versatile than just a FPS-style engine. We've already expanded the capabilities with large outdoor terrain support, and you've seen how it can be used for top-down isometric games like Sanity. Now, LithTech-ESD will show how you can use our engine for creating downloadable games with incredibly fast turnaround times. The LithTech team is working to make the engine much more modular, so that developers can use only the features they want to use or make significant modifications to portions without affecting the general engine structure.
GS: In terms of character animation and movement, does a mech game pose different technical challenges or require different engine features than a game with human characters does?
JB: Character programming is actually simplified when dealing with robots. If the movement or animation code makes the bot look a bit robotic, it's no big deal, because, well, they are robots. Human character animation is much more difficult because everyone knows what a human is supposed to look like and how a human is supposed to move. The same is true for world environments. Our game takes place on big space platform/arena things. There's no pretense made that it's a real-world environment. NOLF, on the other hand, needs realistic looking characters in realistic looking environments. This is the main reason most games opt for nonrealism. It's simply easier to design, program, and render. We can get away with a lot of things because of the settings.
One quick example of this: Our grenades were not bouncing "correctly" for the scale of our game (the robots are about 50 feet tall). So, instead of bothering to rework the physics, we simply turned them into an "energy" grenade and threw on a visual effect. In the end it turns out to be cooler looking and more fun. It's easy to change the rules when you're inventing the game.
GS: What are some of the specific features of LithTech 2.5 that will make it possible to deliver the game in a small downloadable format?
JB: There are a couple of engine features that help with a small download size. We're using skeletal-based animations, which take far less storage space than vertex-based animation. This allows us to use one base model for all the animations in the game. We're using S3 texture compression wherever possible, which drastically cuts down on texture sizes. Our audio is using MP3 or other compression technologies whenever possible.
And of course, a lot of it comes down to using common sense. Most modern PC games are pretty extravagant when using disk space simply because they can afford to be. A typical user now has anywhere from 4 to 20GB of storage space, so requiring a couple of hundred megs of storage space for a game isn't a big deal. With TABBB we've been extremely frugal, using vector graphics and models instead of bitmap graphics in the user-interface, for instance, or reusing textures in different arenas whenever possible.
I think people are going to be very surprised when they see how much content we've actually packed into a 5MB demo.
GS: Thank you all very much.