blog: developer blog #10
The Last 5%
Well, this would have been my “It’s Done” blog entry were it not for the fact that its not really done until everything is in the game. The game itself has been feature and engine complete since around early April. The IGN exclusive BETA program introduced a bunch of new comers who saw the game from a totally different angle that ourselves and our official testers. Since that 1.16.09 BETA build a lot of bug fixes and functionality tweaks have been made to the game. As of this writing, it is 100% bug free and smooth as butta.
The most critical decision I made last month was to hire someone to revamp the textures on all the aircrafts. I felt that compared to the excellent job that Ariel did on the vehicles, that the aircrafts were lacking in texturing.
Of course Jevon and Alexis did a good job when they did those awhile back; but as game dev goes, there is always room for improvement. So you call in an expert at aircraft texturing.
So Ronnie hit the ground running a couple of weeks ago. If you’re in the Beta program, then you’ve probably seen some of the new textures and they are remarkably good.
It is not a cheap endeavour and were it not for the fact that there is a possibility that we were actually going to have an XB360 publisher, I probably won’t have sanctioned the upgrade.
Anyway, these next few weeks are going to be a sit and wait excercise as the remaining assets are completed. As assets come in and get signed off on, they go straight into the game – with no code changes.
The new audio (weapons, vehicles, aircrafts etc) files from Somatone are also due this week. Can’t wait for those!! They worked with us on Echo Squad SE and they did a brilliant job with the audio, voice acting etc. Glad to be working with these world class guys again.
Last night I ran a new unit test of the 1.17.15 BETA build and took a whopping 132 shots at full 1080p 60Hz with everything turned on and 4xFSAA. The rig in question is a standard E6600 @2.4Ghz, 2GB RAM, Vista SP1, GeForce 260GTX on a 42″ 16:9 display. Not a single hiccup.
We’ve worked so hard on this game, its not even worthy of mention because the proof is in the pudding. Once again, I decided that rather than do a run-of-the-mill fps – which everyone is doing anyway – that I was going to design an fps style game with an edge.
This game – like all our games – was designed and developed for like minded gamers. I’m not out to win everyone nor cater to everyone as that would be pointless. Nor am I going to dumb down my game to suit the masses. We’ve already seen how that can backfire (see H.A.W.X) in a very big way. You want dumb-ass[isted] aerial dynamics? Look elsewhere because you won’t find it here. In our game, you better a) have a good reason for being in the cockpit and b) know what you’re doing, because the first time you hear the warning sound of an inbound missile, one thing is clear: you’re less than ten seconds from sudden death if you don’t take evasive and decisive action. And you’re not going to be firing volley after volley of missiles either. Once you find that you’re out of missiles, your only choice is to disengage and go home. Be a hero and you’ll be loading that saved game. Thats why we have save anywhere, anytime.
State Of Play
As I type this, I can’t help but look back at all the time we have spent on this game. By the time we had released our last game, Echo Squad SE, back in early 2008 we were already well on our way to either doing KnightBlade or Galactic Command Online, our MMO – and last game. What made me change direction was a combination of two things. The first being the continued drop in the popularity of traditional space games, the other being that with our end goal being GCO, we needed to ensure that we had enough financial padding to actually complete it without the help of a publisher. Of course, thinking you’re going to get a publisher – or a good deal – for a space game, is like rooting for the underdog at a three-legged horse race.
In fact, when I decided that we were going to do a pure fps game set on a deserted planet located in the far corners of our established galaxy (see if you can find LV-115), I already new that most of our technologies had to be re-written from scratch. Starting with the terrain engine, followed by our graphics and effects engine. Then dynamics, physics, GUI etc all followed suit. Before you knew it, well, we’d re-written most everything. The idea was that we wanted to use these same engines for our next two projects. So the issue was either to do it now and revise accordingly for the future, or do it all again. I opted for the path that made the most sense for a small indie developer.
As the development of AAW draws to an end, we’ve already started looking toward the future and work on KnightBlade (assuming we don’t get a publishing deal and finish the XB360 version of AAW) and beyond has already started. Our new graphics engine geared towards both DX10 and DX11 is already well on its way and on track to complete sometime in early June. With graphics advancements such as SSAO, deferred shading/lighting, a DLL interface for rendering paths etc already in and working, this is the engine that will take us well into 2011 and hopefully beyond.
The GCV-KnightBlade
The next evolution in starship command resumes (yeah, we started it awhile back but put it on hold to do AAW in the interim) full development in July 2009. Smaller (you only get to command one cap ship, not twenty-seven) than our previous space games, but better and with one thing you’ve all been waiting for. To exist in full first person mode inside a massive starship, populated with over one hundred NPC personnel you can interact with – and hurtling through space at warp speed.
Sit at the con and bark out orders to your NPC crew of officers. Run into engineering and find out what the heck is going on with the jump engines while your ship is being pounded outside and can’t make a getaway. Dash into Medibay for a medkit boost. Go to the launch pad, enter a fighter and engage in tactical space or planetary combat with your NPC fighter pilots. Do battle alongside your NPC marines as your ship gets boarded by hostiles. Drop launch on planets alongside your NPC team with vehicles and wielding weapons of mass destruction for the welcoming party. Full NLP based dialog trees for interaction with your personnel. Seek out strange new worlds. And…do stuff.
All the things you could do before in our previous space games – from a 2D interface – you will be able to do in full first person mode and in vastly superior game and graphics engines.
Of Open Worlds & Mayhem
The game.is.huge. No point in going on about that. Being an open world game, it was designed to be.
Earlier this week, during a phone conference call, an exec from a well known publisher (I can’t say who, but you probably like them, as do we) asked me a question I hadn’t heard before. And quite frankly, I was a tad surprised that I actually had an answer that wasn’t akin to techno geek speak gibberish.
Upon reflection, it occurs to me that I was probably surprised because the answer – to me the designer – was obvious. To an outsider? Not so much.
His question was something related to the massive game world and how I’d addressed the issue of “choke points” in multiplayer. A very critical issue for game developers. Of course he wasn’t talking about aerial dynamics because even for a 400 sq. km world (we don’t think in “maps”, thank you very much) you will eventually run* out of air going at Mach 2 at 10K ft AGL.
No, he was talking about the fps portion of the game. A very valid question for anyone looking at the game from the outside.
The answer is something that most gamers – with an opinion – keep knocking my games for when they talk about this vast open space, and why “there’s nothing out there”. uhm, wot? Of course there’s nothing out there. My God man, why would I want to put stuff “out there” where you’re hardly going to see – let alone interact – with it?
They’re called “Mission Zones” aka “Areas Of Interest” aka “Where you should be”.
You see, all fps games have “maps”. These maps are closed off areas and you never get to stray beyond them because a) you can’t b) you shouldn’t – if you’re actually playing the game as it was designed to be played.
Thats all well and good. But what happens when you want to develop a large open world game – with fighters capable of breaking the sound barrier, vehicles, people running around with weapons of mass destruction? Maps are out of the question.
There is a reason why in games like the Battlefield series which have fighter jets, feel cramped. Thats because they are really just fps games with fighters and vehicles thrown in. You play within those constraints because thats how the game was designed and developed to be. Nothing wrong with that.
Now you take an open world game based on a sci-fi world in which there are fast – very fast – aircrafts and “maps” – in the traditional sense – are out of the question. Back when I designed the concept of “worlds” instead of “maps”, it was already evident that you can’t build them in an editor, let alone MAX. Instead, I designed it to be done in such a manner that you’d take your world map (fine, call it that if you must), plonk it down, then use scripts to place the mission zones and scripted entities. The beauty of this is that adding something to the world and testing it, takes all of five minutes. Here is an example of what I would need to do if I wanted to place an object at a specific point in the game world.
- Run the game, warp to the location of interest, note the XYZ co-ordinates. If it is something that needs to be in the air, you need all three values.
- Open the base world script
- Add an entry using the XYZ values from above
- Compile the script
- Run the game
When you go to that location, the object (with its own internal AI) is already there either waiting or doing what it is supposed to be doing based on its default or higher level AI scripting. e.g. if you script an NPC marine and plonk him in the middle of a hostile base, he’s going to engage targets, defend himself if engaged etc. No additional scripting required. But if you want to override his default rule set (e.g. make him run and hide somewhere, attack something, stand still etc) – you just write a higher level script to do it.
If you were doing this in a level editor, you’d be sitting there forever each time you make ANY change to the map.
So, with these mzones, you can either script entities or place them in a group file that is loaded at runtime. Then again using XYZ values, put them anywhere you like on the map. This is how the mzones in the game were created. Of course for placing entire mzones, you first have to flatten the areas on the map in an image editor or you will have things like buildings being placed on inclines and such.
These mzones are where all the game’s primary actions (fps, aerial, vehicular) take place. If you wander outside of them, either on foot, in a vehicle or in an aircraft, there is nothing to see – out in the open world – until you get to the next mzone. Of course nothing is stopping you from wandering outside them – especially if you are airborne.
Similarly, given the massive size of the game world, you don’t have to fly and drive (only one step more arduous than hoofing it. You try walking 50km to the next mzone) to these mzones. You can just use Dynamic Jump Pads (DJPs) which link all of them. You can enter them either in fps mode or in a vehicle. Since aircrafts are faster, they are not allowed to use DJPs.
Well imagine if each of these mzones (which are about 20km wide in some cases) were “maps”. For one thing, you can’t do a traditional map of that size and expect any good results. Second, you would still need artificial barriers to keep the player within the confines. In our case, due to the underlying engine design, there is a “You’re gonna die, fool” warning when you get to the edge. And if you don’t turn back before the timer runs out, thats exactly what will happen.
Ah, but note the word “artificial”. Thats because it doesn’t have to be there. You see, the reason for this is that when you get to the edge, you – well – run out of map (heh). In our case, thats only because this game world was designed to be that size. Due to the fact that we’ve had worlds much – much – larger (we have the entire Earth’s surface size mapped in our Battlecruiser/Universal Combat games for crissakes), extending this world is a matter of creating new ones and adding them where the other ends. Voila! For our KnightBlade and GCO games – both of which return to our “planet sized” worlds, we’re going to do something similar, but probably using procedural generation seeded from a set of values due to storage limitations.
When the guys who built GTV-IV spent a bazillion dollars and the size of a small army on that city, they had their work cut out for them. That game imo is an engineering and technical marvel. It is amazing that the bloody thing actually runs. On a console no less! Anyway, they set out to build a city. A populated city. Now, imagine if they’d just plonked down a few buildings here and there, a few cars here and there etc. It would feel “empty” won’t it? Especially give the premise of the game taking place in a huge bustling “city”.
Well imagine if we took their city and plonked it smack in the middle of one of our mzones. Now imagine having as many (AAW has ten mzones, eight fully populated and containing starbases) as we do. Now ask yourself this. Can you run it? Forget about all the implications and intricacies of our game’s feature set.
So you see, for every game, compromises are based on design and gameplay decisions. Those design decisions may pose questions to those outside of the game development team. But trust me, game developers are very good at this because thats what we do. All day. Every day. And yet sometimes we still manage get it all wrong.
Until next time!!
*Here’s your homework for today. An aircraft flying at Mach 2 at 10K ft AGL will take how long to cover 400 km? TIP: Mach is calculated at various levels, including ASL and up to 36,089 ft AGL. Send the answer to devteam -at – 3000ad.com with “Dude, I Know The Answer!” in the subject of the email. The first ten to get it right, will get an exclusive BETA code and a download link to the game build.
developer blog #11 » « developer blog #9


Nick Walton says:
I’ve been dreaming of a fps space game where you were wandering about inside a movable ship for many years. I’ve written out so many plans and sketches, and lay awake at night dreaming of the possibilities for so long… Coupled with the fact I’ve always had an affection for the way you guys go about writing games. You seem to have the right ‘ethos’ about it for people like me. I can’t wait to have a look at Knightblade. From your description above it sounds awesome. I’ll go back to UniCom until AAW hits the shelves in the UK
Posted on May 21, 2009 @ 10:24 pm