Updated July 31st, 2001:
Rantz Hoseley, Art Director
Grendarl height: The Grendarl are the 'tallest' race in the Q1 release of MOO3 at about 3 meters.
The Trilarian diplomacy screenshot: >> Why his arm are down? Isn't he swimming? Doesn't he like to swim??? <<
Like an octopi or squid in their 'at rest' position the tentacles hang down.
>> So cool! He looks old and all. Rantz, you're a genius. <<
Thanks but equal credit goes to the art team who are doing great work on the models and textures! All I have time for is drawing and bossing them around...<G>
Most races aren't bipedal: Ok, I'll actually throw out a nugget of race info here.
The Saurian races all use their 'hands', their forelimbs for at the least, assistance in locomotion. This is true of most of the races in the game with the exception of the humanoids. In the Sakkra case, think of it as being similar to when you see a bear rear up and walk on it's hind legs. It can do it, but it isn't a natural or comfortable position.
Releasing the intro movie: The intro movie won't be seen until the first time you play the game.
Lost races in the intro movie: >> Out of interest will we see all the lost races in the intro? <<
No, you'll only see one of the lost/dead races.
Trilarians: >> 1.) Can they really look straight ahead? <<
No, the Trilarians move their head side to side in an undulating fashion to see what is in front of it.
>> 2.) Regardless the answer to question one, what does this mean to their depth perception? (No pun intended.) <<
They use other compensating factors to aid in diminished depth perception (similar to Dolphins using 'sonar')
>> 3.) Will this eye placement be reflected in their combat efficiency? <<
Not at this time.
>> 3c.) Will this be a consideration in the game? <<
As far as how they look and move, yes. Other than that, prolly not.
Dealing with criticism: >> Is there are reason you're targeting Rantz with these rather asinine comments? <<
While I appreciate the support, the bits like 'rantz pellets' doesn't bother me too awfully much. It's the death threats (joking or not) that seriously make me question why I'm doing this at times.
No matter what anyone thinks I don't make the choices on art that I do lightly. There is a lot of thought that goes into all of this, the pros and cons are weighed, and I make the choice that I feel is best for the game as a whole. I recognize that you can't make everyone happy and that all you can do is be true to the intent of the design, which is what *all* of us here at QSI are trying our level best to do.
Criticism, joking, ribbing, that's fine, and not a thing to be bothered about. It's when people start acting as if the stability f their lives and world hinge upon whether aspect 'X' (pun intended) of the game gets in their that I start to be concerned.
Good and Evil: There's no 'good' or 'evil' in MOO3, only the perception of it, based on inter civ relationships and interactions.
Dark Matter Bats: By the by 'bat' is an internal description so we know what direction it is for concept work. There won't be any anti-matter mammals or anything of that nature hopping/leaping/flying through space.
Fer the love of whatever deity give me a *little* credit...
More on the same: >> Sure it is "possible." But a Dark Matter Bat? Frankly, I thought the "monsters" in MOO2 were just plain bad. <<
Agreed. I frickin' hated them in MOO2, and yes they reek of cheese. The names of the various 'monsters' are descriptive placeholders. There was a lot of work done to try and come up with 'random space encounters' (read: Gameplay equal of MOO2 space monsters) that had at least a foothold in science. The names aren't necessarily the final ones 'bundles' fer the love of Mike?!? Please.
You can ask Alan about me ranting that there would be no space dragons in this game... it was a rant that was heard many, many times...
Current state of alien languages: Languages and recording have been established for all of the races/species with the exception of the harvesters. The 'humanoid' language is created and will be able to be deciphered by those industrious enough to do so. (what the translation tells you and what the person is *actually* saying may differ a wee bit...<G>)
Race language and ways of communication were established months ago before the race bible was complete. I'm supervising the sound and approach to each language and the stuff is turning out really cool. It was especially gratifying to see folks in the press react when the Trilarian Ambassador started talking.
As has been noted, I'm not really at liberty to discuss what they sound like or to put samples up. When we can put stuff up, we do put stuff up. Honest.
Bill Fisher, Executive Producer
Galaxy creation: There's been a fair amount of information in some of the documents which talks in colloquial terms about the equations used in our spreadsheet. We'll probably talk a lot more about the details when we do the Strategy Guide.
The short version of the story is that we've tried wherever possible to use scientifically reasonable numbers and equations wherever practical.
For example, we create stars using probabilities which match those of the Milky Way, since of course that's the one we know best. We take away the uninteresting and uninhabitable ones, figuring that they don't need to be in the game if they're not going to have planets or be otherwise adaptable to any form of life that's in the game (and there's a pretty broad spectrum there).
Planets are laid out based on the model that we have -- our own solar system. But again that's only a starting point, and the actual distributions vary quite a bit from the Sol standard. Planetary temperatures are based on the amount of energy emitted by the star, the distance from the star, and two greenhouse factors. And yes, we're using a blackbody radiation formula for the intensity.
Mineral richness and such are based partially on the age of the star. Older stars are more likely to harbor planets with heavier metals, for example.
I hope that helps give a brief glimpse of what we're up to. We had a lot of fun creating the spreadsheet, reading astronomical books and articles, and think it adds a nice touch of realism to the game.
Reasoning in the strategy guide: >> I am curious about the rationale behind giving
older stars more mineral rich planets. Will the Strategy Guide just have the equations in it, or will it also discuss the logic behind the equations? <<
Yes, we'll certainly go into more detail about the logic behind things.
As for the older stars, I got it backward it's the younger stars that have the more mineral-rich worlds, because those stars and star systems are created from the remains of other long-dead stars, inside of which the heavier elements were created as they burned out.
Mac system requirements: The game should be able to run on any iMac or later machine, though a 233 will definitely be on the slow side. I'm running now on a PowerBook G3/300, and the E3 build was reasonable but not super-fast. Remember that that build wasn't completely optimized, either. Not sure what the final "recommended" minimum machine will be, but any G3 should at least be capable of running it.
More important than processor speed on the Mac will probably be RAM. At least 64 MB will be needed, with virtual memory on, so more is better. This is a huge game with a lot of data to crunch, not to mention all of the graphics assets in the combat mode.
We'll probably set a baseline at MacOS 8.6 for the operating system. We will run under MacOS X -- we have a few machines here already -- and are working closely with Apple to look into building a Carbon version. We're not committing to Carbon yet, but we've written some code to support it and I suspect we'll be able to make it compatible with a modest amount of work.
It looks like we'll use QuickTime for the video.
Why not use Bink instead of QuickTime? QuickTime supports many more video formats and also doesn't require that we pay an up-front licensing fee. Same functionality, lower cost. Plus, we're cutting some deals with Apple that will help get the word out about the game.
Given the average machine that people will be using for this game, and the modest role played by video in MOO3, I'm not concerned about performance.
Quality Assurance: >> I hope other gaming studios out there continue the practice -- it makes it far easier to port to additional systems post-release, and also to make add-ons, I suspect. Plus, it shows you're using a full-cycle process that works -- it sounds like your testing won't be a kludge-fest of last minute hacks to make the thing work, unlike a great deal of other products (not just games) that I could name. <<
That's certainly the plan. In all of our recent releases, we started serious bug control and performance optimization efforts six or more months before release. We're doing the same here. Rob and I just talked a day ago about spending a lot of time looking for hot-spots and excessive RAM usage. I'm a big believer in thinking ahead. I want those last-minute late nights to focus on gameplay, not weird crash bugs or horrible kludges. Been there too many times before.
>> I'm especially glad to hear that you're using an existing (and cross-platform) networking module, rather than reinventing the wheel -- considering you'd have to reinvent it not once but twice if you did otherwise. <<
Networking still requires a lot of higher-level design and coding. The real trick here is to start with a solid solution like OpenPlay and then build a sophisticated game-specific framework on top of it. That's what Greg's job is, since he did this twice before. If you know how to do it, it's not hard. If you've never done it, it's incredibly challenging. You'd be surprised how easy it is to go down a blind alley for a month or more if you're not careful.
Using QuickTime: We're currently not even using QuickTime to draw to the screen. We actually generate the image in an off-screen buffer and then use our own copy routines to place it on the screen. This allows us to do a few extra things, if needed, to make the image look best on the UI screen. So, unless our code has problems on such cards, I don't see much of a concern with this.
Development of MOO3: The folks who run this company (me) hear you and share your concerns. That's why I've dedicated so many resources to making sure we get this game done right. I'm sure there will be something that gets missed, but it surely won't be for lack of trying.
I can assure you that every penny we get from Infogrames is going right into the game. I don't drive a fancy car or live an opulent lifestyle. I want this game to set a new high-water mark for the strategy game business. That's not easy when you're trying to be as ambitious as we are. There's always too much to be done and not enough time. We're spending a lot of effort right now on the details, trying to make sure we get in everything possible while at the same time making sure we don't overreach and end up with some features that are half-baked. Needless to say, that's a tough process, but I know our people are up to the challenge.
I definitely appreciate the concerns about things being "mucked up." However, I'd caution you not to compare the development process for this game with that of Starfleet Command. That was a very different project and a very different development arrangement. From the experiences we had on that project and on others over the years, we've made major changes in how we're managing MOO3. I can assure you that I understand very clearly the risks of releasing buggy products, and our entire team knows that I want this to be a clean release.
My job is to blend the "corporate bottom line" with maximum creativity in making the best possible game. That's a tall order. We _do_ need to get this game done reasonably on schedule. With this many people on the team, we can't afford to be significantly late. And "oops, we need more money" is not something our publishers like to hear. On the other hand, I'm first and foremost a gamer and it's very important to me that the game be done right, even if it means sacrificing profitability in order to do it. I wouldn't be doing this job if I didn't love the game business so much. It's incredibly difficult to run a game company (there's a reason we're one of only a handful who have been around for 17 years). But that's never stopped us before, and it won't stop us this time. Fortunately, we're not a public company and don't have to answer to hostile shareholders, so I can push the needle into the red if that's what it takes.
Post-release support: Here's the way it works, generally:
As part of every typical game development deal, we are obligated to fix bugs for a certain time period beyond the date of shipment. Usually, though, that language is focused on failures of the product, rather than play-balancing or adjustments to AI.
At the moment, I'm pushing as hard as I can and allocating every available resource to getting this game done, and done right. We've got a host of programmers and will probably be adding a new artist shortly. Making the best possible product in a timely manner is our biggest goal. That means I'm not taking away from the budget today to build up a "kitty" of extra cash to handle long-term support tomorrow. Especially with a game this large and sophisticated, there's always too much to get done, and we need every resource we can find in order to complete it.
What we've usually done following release in the past is maintain a skeleton crew of people doing maintenance on the product, in order to handle critical issues. Sometimes, we get assistance from our publishers on this, often in the form of a contract to develop another related product. As long as we're not spending huge amounts of time on bug fixes, we can often absorb the cost into the creation of an add-on pack or future product, since at least some of the issues (like engine bugs) would need to be fixed for the subsequent product anyway. For example, on Conquest of the New World we released bug fixes several times as part of the development effort to create the Deluxe Edition, which shipped 6 months after the original.
One of my key long-term plans for this company is to ensure that there's work for this team the moment we get done with MOO3. We're actively pursuing discussions with Infogrames, as well as with Sony Online and a large-Fortune-500-consumer-entertainment-company-that-wishes-to-remain-nameless about future projects. And we've recently landed two new large projects that will be keeping the rest of the company quite busy. Obviously, we've got our sights set on a few potential Infogrames franchises. Nothing's assured at the moment, but you can bet we're interested and will be trying to nail down a commitment well in advance of the completion of MOO3. One thing I really want is to have the next work lined up before the existing work is completed. That means I need to be considering a number of deals at once. Whichever potential client comes to us with the best deal the soonest will get the most attention.
So, in conclusion, I agree that we'll probably need to patch something on MOO3. With Cory, a former Q/A Lead, as our producer, you can be certain that we'll being doing a solid job of testing internally. But, being the realist that I am, I can be pretty sure that we'll need some sort of update, even if only related to game balancing. We'll do our best to get that out to everyone as soon as we can, and will try to keep some core resources free for that purpose even after the main release. I can't be sure yet how many folks I'll have for that purpose, but I'm working hard to make sure we do the right thing.
Alan following up: At the risk of sounding like a butt-kisser here, Bill has really laid the cards out on the table for you guys and given you a look into "life as it is" for a game developer. Like I said, our rep is pretty good in the patch department, so I think that should be "one less thing for you to worry about."
More on the same: We'll definitely be making fixes, if needed, and trying to get them out as promptly as possible. Sometimes that's difficult, since patches aren't always the #1 priority for the publisher's Q/A department. But we'll be watching closely, even if we're starting work on the next game at the same time.
I'm sure we'll end up doing some "rewardless" support, as you call it. In reality, even that tends to have its rewards, because it fine-tunes our understanding of how the game is being played and what people really want. Often, even if the feedback can't be addressed at that time, it ends up in a sequel. And we often find that, especially with more complex games, it's worth the time to help people get past certain challenges that perhaps weren't explained well enough in the documentation.
You'll definitely see us around after the release, if for no other reason than we love to talk about the game.
Reply to a fan's encouragement: Thanks. The prospect of providing a truly first-rate game experience is what keeps me going. And a large part of that success is ensuring that we make something that fans will want and then want to play with everyone else they know.
I'm happy because I think, based on the feedback we've received, that we've got the right concept and simply need to pull it all together now (not that that's going to be easy). The rest of this year is going to be focused on "breathing life" into the game.
Thanks for all of your support. It really does make a difference.
Mac requirements: >> Ok, well, I have an iMac with 233 MHz, and the memory is no problem, but how slow will it be? Rock slow? Freighter slow? I've-been-waiting-16-turns-to-get-my-battlecruiser-outsystem-but-its-not-halfway-there-slow? And if it is, uh, not exactly rapid, do you know of any programs to speed it up? <<
It's too early to say for sure, but I can tell you that I ran the show demo on my 300 MHz PowerBook and it worked reasonably well. This is a turn-based game with lots of detailed information display screens. All of those screens should work just fine. The movies may stutter a bit, depending on how we encode them, but they'll work.
The biggest challenge will be space combat. There's a lot going on with larger fleets, so you may find it plays a little sluggishly. But it still won't take anywhere near as long as space combat in MOO2, despite the level of activity.
Next biggest issue will be end-of-turn processing. All of the AI runs at the end of the turn, and there's a lot of thinking to be done, so turns will definitely process more slowly for you than for other folks.
In conclusion, it'll be somewhat slow in certain areas, but you probably won't be pulling your hair out about it.
Will Hive-mind races have "moneyless economies"? It would be much trickier to make a game if the playing field were that asymmetrical. Every player's position needs to have certain measurable things in common so that we can gauge and balance. An economy is one of them.
Ross Worthley, Lead Artist
Visual effects of weapons: We are making an effort to have the weapon fire effects be both varied and impressive.
Rantz following up: >> So we'll have both Star Wars and B5 beam weapons? <<
You'll have every 'standard' visual representation of weapons fire, plus some that are nifty new ideas.
[ VIEW COMPLILATION FROM JULY 3, 2001 ]