Hard Light Productions Forums
Hosted Projects - Standalone => Diaspora => Developer Blog => Topic started by: karajorma on May 24, 2009, 06:54:55 am
-
It's been a while since my last post but that doesn't mean the team hasn't been doing much in the intervening time. In fact we've been working very hard on the code side of things and I think it's about time we brought you up to date with all the changes that have been added to the engine recently.
As most of you know Diaspora is being built to run on the FS2_Open engine. We share this engine with several other games (Wing Commander Saga, The Babylon Project, Freespace 2 SCP, etc) so making changes is never as simple as just adding what we want. We always have to make certain that anything we add (or subtract) won't spoil things for everyone else. The advantage though is that features they add often prove useful for us too.
The FS2_Open engine is worked on by the Source Code Project Team (Simply referred to as The SCP most of the time). Most of Diaspora's coders are either already also members of the SCP or will be soon. So although Diaspora is dependant on the SCP for engine updates we do have a pretty big say in what will be in the next update.
The current official version of FS2_Open (3.6.9) is getting rather old. 3.6.10 is due out soonish but won't have all the features that Diaspora requires. For this reason it seems likely that we'll be waiting until 3.6.11 is out before release. This isn't as huge a problem as it sounds as we've made changes to the SCP internally that should result in official releases coming along much more often. Those of you watching the SCP forums may have noticed that work has already begun on 3.6.11 builds even though the official 3.6.10 one isn't out.
Not every feature that has been added will be used in R1. But most of these should be used sooner or later in Diaspora.
Changes
Support for more cutscenes - The game will now play cutscenes before/instead of briefings, debriefings, etc. It's highly unlikely we'll use this for R1 as we don't have the time to make the cutscenes. But R2 onwards will hopefully use this to some degree. Whether we'll ever be crazy enough to drop text based briefings completely and go for cutscenes only is another matter. It would be a lot more work and would require us to find extra animators to do it, but it is possible now.
AI use of glide mode - AI will now use glide (i.e. semi-Newtonian mode), both to attack you and to break out of circle fights. Until now only human players could use glide.
Subsystem sounds - Amongst other things this allows a battlestar's turrets to make the familiar whirring noise as they spin around to lock onto a new target.
Turret changes - A whole variety of changes have been added via subsystem flags to allow weapons to act more like those in the show. These include making turrets fire in salvos, return to rest positions when not in use (although we can't make them sink back down just yet), and having them prioritise enemy craft better rather than just shooting at any enemy in range,
DRADIS changes - FS2 fans may have already seen the radar icons feature. But only the team have thus far seen it used with DRADIS. We'll show this off once we've kicked a few more bugs out of it. This should replace the old square radar blips with the icons you're more familiar with from the show. Assuming we can manage to squeeze them all in without making everything look cluttered that is.
Voice code improvements - Changes to the built in messages system mean that each ship can now have multiple messages for each built in. So rather than hearing "Hostiles on DRADIS" every single time a certain pilot notices enemies the computer can now pick one of several messages. In addition AI pilots will now occasionally say something after their own kills or if you're doing very well. These changes increase the amount of voice acting we'll need for the game but it should be worth doing for R1.
Flight deck changes - Some of you will recognise these as my Team Loadout changes. This adds a simple strategy element to the game. Use up all of your battlestar's MK VII's in an engagement and they'll be gone for the rest of the campaign. Bring them in heavily damaged and they'll be down for next mission or two while the knuckledraggers pound them back into shape. If we'll use this in R1 is uncertain. It will almost certainly appear in later releases though.
Multiplayer mission design changes - Multiplayer has long been crippled by problems that didn't affect Singleplayer. Problems with both the lua and SEXP scripting systems meant that some more interesting game ideas for BtRL had to be dropped (Stealth based missions and Capture the Flag are a couple that come to mind). A large number of those issues have been resolved in the last few months and we hope to be adding missions like that to R1 or R2 now. This also makes the chance of a coop version of the SP campaign significantly higher (although there are currently no plans to do this for R1).
Lots more stuff than this was added but most of it is only going to be of interest to the devs of other FS2_Open games and they already know how to check the SCP forums and get more detailed information on those. :D
-
Very detailed post! Thanks kara!
Im particularly interested in subsystem sounds, turrent changes, flight deck changes and DRADIS changes :D
-
On the flight deck changes, will there be support for adding them at a fixed rate during the campaign (i.e a Mercury class's on board factories)
-
I liked the term 'Cye-Candy' even if it was a Typo, it was also kind of appropriate ;)
-
On the flight deck changes, will there be support for adding them at a fixed rate during the campaign (i.e a Mercury class's on board factories)
It's all done using persistent SEXP variables so the mission designer can fiddle the numbers however they see fit.
-
I am loving this. Especially the turret changes.
Speaking of which, do you have a fire-turret SEXP yet? If it's not a big priority, no worries.
-
Based on the SCP roadmap (http://www.hard-light.net/forums/index.php/topic,48559.0.html), Goober wanted to add one.
-
I know next to nothing about coding and the like, so excuse me if this is a moronic question, but is the FS2NetD2 code improvements listed in 3.6.10 going to mean less lag for multi?
-
It means more streamlined, less lag, less crashes, more players? (IIRC you and Goob were working on removing the limit)
-
... For this reason it seems likely that we'll be waiting until 3.6.11 is out before release. ...
I do feel a bit confused.. you were referring to R1 or perhaps to the full game release?.
Thanks,
-
R1. Remember, there's no full game release - it's episodic. (At least if I understand correctly.)
-
At least if I understand correctly.
Right on the money.
-
There's no full game release. As Newman says we're going to be completely episodic.
But we might occasionally refer to the full game. In this case we mean the release where we finally have enough ships to take a stab at all the missions you saw in the TV show. After that release every follow up is gravy. :)
-
That's the kind of **** I'm talking about. How's your AI coming along? AI's always hard, after all.
-
The AI is FS2 AI plus whatever changes Sushi and Wanderer can make between now and final balancing.
-
The game is going to be released in episodes, but when everything is released will you compile all the releases into ONE game?
-
Each episode will bolt onto the previous releases giving you access to everything you had before + the new stuff. You'll only ever have one Diaspora folder.
-
These updates really do have me drooling as much as the eyecandy thread ever did.
Awesome work on the SCP's part and naturally the Diaspora team's work.
-
Some more specifics on the AI (my end of it, at least) for anyone who's interested:
1. The "glide attack" behavior is pretty simple, but effective (and pretty much exactly what human players do): the AI will hit glide, turn to face a target, and blast the target while moving along its original vector. This means that occasionally a ship you're chasing will use the glide mode to spin around and shoot you while you chase it, and also provides a useful way to break out of "circle fights" or stalemates.
2. The AI actively attempts to detect a stalemate situation, and break out of it. This can be done in a few ways, including the "glide attack" behavior.
3. I'm also working on a "circle strafe" behavior. This one doesn't use glide, but does use sidethrust: the idea is that the AI will try to circle around the target in constantly-changing random directions, shooting at it the whole time. This behavior assumes a relatively slow-moving target and only (sometimes) kicks in when those conditions are met. If two fighters are trying this on each other, you get some very "descent-like" combat.
I'm still working on this one, not done with it yet but it's getting pretty close to something I'm satisfied with.
So far, all of the above has been focused on fighter vs fighter combat. Once I have that tweaked to satisfaction, I'll make sure they work well for fighter vs capship combat. Naturally, all of these behaviors are optional and off by default, so retail behavior isn't affected. At the moment, everything is controlled via AI Profiles flags.
-
Sushi, do a developer blog post of your own! This stuff is hot.
-
Alright, dangle a carrot in front of a nose and the mouth gets greedy, any chance we can see a short clip of the A.I. in action. Just a straight 1 on 1, 2 minute vid? Hopefully not asking too much, if so disregard.
It was always something that I felt was lacking from the BtRL demo (naturally I'm sure it was being worked on), the A.I.'s not using glide and even side-thrusting.
I'm just curious how brutal the A.I. is going to be on Insane.
Quite another question, and hell, might be far from relevant anymore given the strides made in the A.I. but in the BtRL demo, there was a definite problem with the A.I.'s collision detection, was/is this something easily remedied? And further can it handle something as complex as navigating the Big Potatoes interior?
-
Quite another question, and hell, might be far from relevant anymore given the strides made in the A.I. but in the BtRL demo, there was a definite problem with the A.I.'s collision detection, was/is this something easily remedied? And further can it handle something as complex as navigating the Big Potatoes interior?
Well, part of the problem is that there are a lot of hardcoded values in the AI code that are tuned to retail Freespace distances and speeds. BTRL had ships moving at speeds of 200, and the AI just didn't handle that very well. Diaspora's scale is fortunately such that this is much less of a problem. As to navigating complex capships/structures/asteroids... I at least haven't done anything in that regard. The AI just isn't designed to navigate large, complex meshes. The "best" solution I've heard so far is to give the AI some true pathfinding capabilities (such as A*), and that's definitely on the wishlist (http://www.hard-light.net/forums/index.php/topic,62602.0.html).
-
Well, part of the problem is that there are a lot of hardcoded values in the AI code that are tuned to retail Freespace distances and speeds. BTRL had ships moving at speeds of 200, and the AI just didn't handle that very well.
Ah right, I remember reading about those issues way back when over on the BtRL boards and it slipped my mind that there were collision detection issues as a result, thanks for reminding me :).
Thanks for the info regarding the A.I. navigating the complex structures, I was merely curious if there was any headway in that regard.
Cheers!
-
That new flight deck is sounding awesome. That will bring a whole new aspect to the game.
Also the turret improvements will be something to look forward to.
Thanks for all the hard work.
-
Quite another question, and hell, might be far from relevant anymore given the strides made in the A.I. but in the BtRL demo, there was a definite problem with the A.I.'s collision detection, was/is this something easily remedied? And further can it handle something as complex as navigating the Big Potatoes interior?
Well, part of the problem is that there are a lot of hardcoded values in the AI code that are tuned to retail Freespace distances and speeds. BTRL had ships moving at speeds of 200, and the AI just didn't handle that very well. Diaspora's scale is fortunately such that this is much less of a problem. As to navigating complex capships/structures/asteroids... I at least haven't done anything in that regard. The AI just isn't designed to navigate large, complex meshes. The "best" solution I've heard so far is to give the AI some true pathfinding capabilities (such as A*), and that's definitely on the wishlist (http://www.hard-light.net/forums/index.php/topic,62602.0.html).
Could you hack in something along the lines of dockpaths? E.g. plot out a bunch of splines in PCS2 telling the AI how to get through obstacles like those asteroid tunnels? They'd have defined widths the sameway dockpaths do, and only kick in when the AI needs to get from one side to the other of certain obstacles (Imagine, as an example, a very simple path through the Arcadia's hole rather than forcing the AI to go round or attempt to ram the Arcadia out of the way). They'd not be able to fight there, sure, and it's a touch hackish I guess, but, given that they're already in engine it might be easier? I dunno though, not a coder.
-
Could you hack in something along the lines of dockpaths? E.g. plot out a bunch of splines in PCS2 telling the AI how to get through obstacles like those asteroid tunnels? They'd have defined widths the sameway dockpaths do, and only kick in when the AI needs to get from one side to the other of certain obstacles (Imagine, as an example, a very simple path through the Arcadia's hole rather than forcing the AI to go round or attempt to ram the Arcadia out of the way). They'd not be able to fight there, sure, and it's a touch hackish I guess, but, given that they're already in engine it might be easier? I dunno though, not a coder.
No, it's a good idea, and one that I've thought about a bit. :) We have subsystem attack paths and dock paths, so why not transit paths for certain ways of getting around large objects? The only drawback is that depending on the object, you may need a heck of a lot of them for it to be convincing, but if we ever do it that way it will be Someone Else's (the model converter's) problem. :D
There would also need to be some way to encode how "tight" the path is, so that bombers don't try to squeeze through fighter-sized holes.
Anyhoo, yes, it's a good idea.