« News
Mar
21
Hi, I've been too busy to write a Newspost.
Just a little quick info about what we've been doing.
The last few weeks have been somewhat frustrating for us, as we've been debugging the whole server-side Border Skirmish performance issues. We found the original "trigger" problem relatively quickly, but after fixing that we still saw sub-par performance, and analysis indicated that there were.. a lot of different issues to look into.
Some avenues, like LuaJIT, ended up not working out for us for the time being (LuaJIT is very cool, but we make extensive use of coroutines, which are suboptimal in the released 1.x version). Other work just didn't really produce the results we were hoping for, and after two weeks of screwing around with sector code, we've been really wanting to get back to things like.. oh.. adding gameplay.
So anyway, this week we attacked this issue anew, to try and really nail it down, and we've been working pretty intently.. hence the lack of news updates on my part. I've been more directly involved than in past weeks, as I'm the only person equipped to do stuff like model new collision hulls (more on that later).
After some use of FreeBSD's very cool PMC Tools (basically the FreeBSD equivalent of Linux's oprofile), we discovered some issues in our spatial partitioning code. We use an Octree to subdivide space and give us certain regions where certain objects should be checked for collisions (but others should not), and the like. In situations like capital ship battles, so many shots are being fired from capship turrets that the octree code was becoming sub-optimal. We're now experimenting with a Sweep and Prune implementation that seems to yield much better performance in the specific "giant space battle" case, but may be less optimal for other, more generalized situations. We have constructed several benchmarks and are continuing to experiment.
Aside from this, I've also been producing more efficient collision hulls, for use only on the server-side. Games use separate models for "visual" detail versus "collision" and "physics" usage. The visual model includes all the pretty and intricate detail that makes an object visually interesting. The collision hull only needs to have the parts that are important to actually.. colliding with other objects (such as enemy shots, rockets, big rocks, or that docking bay that you swear moved). On small ships, there's a lot of leeway.. collision models can lose a lot of surface detail without actually causing any noticeable or combat-relevant change to object collisions.
Large ships, on the other hand, are much more challenging cases for "optimized" collision hulls. Think of a stack of ten equally-sized legos: if you remove one lego, the overall size of the object is not that dramatically different. However, to a creature the size of an ant, it might be significant; by the same token if you scaled the lego object up to the size of a skyscraper, that "one" lego you removed might be hundreds of feet in difference. The same issue holds true when creating collision hulls for physically "large" objects in games: if you remove some detail that looks irrelevant when zoomed out, all of a sudden someone's torpedo is now missing its target, flying "through" some visual geometry; or perhaps striking geometry that isn't visually apparent.
There is a desire, on the part of the game developer, to have the minimum number of polygons necessary to provide an accurate collision surface. Collisions can be computationally intensive, especially between complex objects. This is particularly the case on the server-side, where a single machine may be simulating collisions for a vast number of NPCs in a particular sector battle. To date, we have used the same collision hulls on the client as we did on the server. The client-side objects have relatively high polygon counts, as the large "detail" is really necessary. However, now we're experimenting with server-specific hulls, which will only really be apparently in NPC-to-NPC collisions. These very-low-poly hulls should drastically improve certain worst-case-scenarios, where ships are in close proximity and are firing vast numbers of turret shots back and forth. At the same time, evidence of the reduced collision hull detail won't be very obvious to the player, as the client will still use the high-detail hulls. On a sidenote, I have also done some tweaking to the client hulls, so some of them may yield better performance on people's computers, but I'm not sure that this will be noticeable.
Turrets have also been optimized, specifically the collision of their shots to objects, a very common case in these large battles. We could simply reduce the number of shots, of course (or the number of capships, or force the capships only to sit far away from one another), but that would detract from the type of "crazy-ass space battle" that we're trying to generate.
Results from the above tweaking have been optimistic, so far, at least in our benchmarks. We've also run into some weird bugs, so this BS-optimization work will be continuing into next week; but we expect we'll be able to wrap things up within the coming week, and get back to "new gameplay development". Some of the recent improvements seem to indicate a possible ~50% general performance increase; while other "extremely bad" cases may be improved much, much more. Still, we'll have to see how it goes.
Tonight we're (hopefully) going to release the optimized collision hulls, but still using the octree code path. The sweep and prune code may debut next week, we need to do some more testing, and perhaps optimization of certain areas.
I'm afraid I've been too busy to make anything particularly cool to release into the game tonight. Hopefully "improved BS performance" is worth something. There has been a lot of great Suggestions Forum activity lately, I've been following it but not responding as of yet. Please keep this up. Also, I'd like more feedback about Friendly Fire in grayspace, which we enabled last week; I've created a special forum thread for related feedback.
That's all for now, we'll be aiming to have some more significant and interesting releases next week, and be getting back on track for further Friendly Fire / Faction system changes, as well as expansions and improvements to Dynamic Warfare and the Economy. Thanks for your patience during this unplanned and highly undesired debugging period.. hopefully this work will give us a better foundation on which we can build crazy new gameplay.
-Incarnate
The last few weeks have been somewhat frustrating for us, as we've been debugging the whole server-side Border Skirmish performance issues. We found the original "trigger" problem relatively quickly, but after fixing that we still saw sub-par performance, and analysis indicated that there were.. a lot of different issues to look into.
Some avenues, like LuaJIT, ended up not working out for us for the time being (LuaJIT is very cool, but we make extensive use of coroutines, which are suboptimal in the released 1.x version). Other work just didn't really produce the results we were hoping for, and after two weeks of screwing around with sector code, we've been really wanting to get back to things like.. oh.. adding gameplay.
So anyway, this week we attacked this issue anew, to try and really nail it down, and we've been working pretty intently.. hence the lack of news updates on my part. I've been more directly involved than in past weeks, as I'm the only person equipped to do stuff like model new collision hulls (more on that later).
After some use of FreeBSD's very cool PMC Tools (basically the FreeBSD equivalent of Linux's oprofile), we discovered some issues in our spatial partitioning code. We use an Octree to subdivide space and give us certain regions where certain objects should be checked for collisions (but others should not), and the like. In situations like capital ship battles, so many shots are being fired from capship turrets that the octree code was becoming sub-optimal. We're now experimenting with a Sweep and Prune implementation that seems to yield much better performance in the specific "giant space battle" case, but may be less optimal for other, more generalized situations. We have constructed several benchmarks and are continuing to experiment.
Aside from this, I've also been producing more efficient collision hulls, for use only on the server-side. Games use separate models for "visual" detail versus "collision" and "physics" usage. The visual model includes all the pretty and intricate detail that makes an object visually interesting. The collision hull only needs to have the parts that are important to actually.. colliding with other objects (such as enemy shots, rockets, big rocks, or that docking bay that you swear moved). On small ships, there's a lot of leeway.. collision models can lose a lot of surface detail without actually causing any noticeable or combat-relevant change to object collisions.
Large ships, on the other hand, are much more challenging cases for "optimized" collision hulls. Think of a stack of ten equally-sized legos: if you remove one lego, the overall size of the object is not that dramatically different. However, to a creature the size of an ant, it might be significant; by the same token if you scaled the lego object up to the size of a skyscraper, that "one" lego you removed might be hundreds of feet in difference. The same issue holds true when creating collision hulls for physically "large" objects in games: if you remove some detail that looks irrelevant when zoomed out, all of a sudden someone's torpedo is now missing its target, flying "through" some visual geometry; or perhaps striking geometry that isn't visually apparent.
There is a desire, on the part of the game developer, to have the minimum number of polygons necessary to provide an accurate collision surface. Collisions can be computationally intensive, especially between complex objects. This is particularly the case on the server-side, where a single machine may be simulating collisions for a vast number of NPCs in a particular sector battle. To date, we have used the same collision hulls on the client as we did on the server. The client-side objects have relatively high polygon counts, as the large "detail" is really necessary. However, now we're experimenting with server-specific hulls, which will only really be apparently in NPC-to-NPC collisions. These very-low-poly hulls should drastically improve certain worst-case-scenarios, where ships are in close proximity and are firing vast numbers of turret shots back and forth. At the same time, evidence of the reduced collision hull detail won't be very obvious to the player, as the client will still use the high-detail hulls. On a sidenote, I have also done some tweaking to the client hulls, so some of them may yield better performance on people's computers, but I'm not sure that this will be noticeable.
Turrets have also been optimized, specifically the collision of their shots to objects, a very common case in these large battles. We could simply reduce the number of shots, of course (or the number of capships, or force the capships only to sit far away from one another), but that would detract from the type of "crazy-ass space battle" that we're trying to generate.
Results from the above tweaking have been optimistic, so far, at least in our benchmarks. We've also run into some weird bugs, so this BS-optimization work will be continuing into next week; but we expect we'll be able to wrap things up within the coming week, and get back to "new gameplay development". Some of the recent improvements seem to indicate a possible ~50% general performance increase; while other "extremely bad" cases may be improved much, much more. Still, we'll have to see how it goes.
Tonight we're (hopefully) going to release the optimized collision hulls, but still using the octree code path. The sweep and prune code may debut next week, we need to do some more testing, and perhaps optimization of certain areas.
I'm afraid I've been too busy to make anything particularly cool to release into the game tonight. Hopefully "improved BS performance" is worth something. There has been a lot of great Suggestions Forum activity lately, I've been following it but not responding as of yet. Please keep this up. Also, I'd like more feedback about Friendly Fire in grayspace, which we enabled last week; I've created a special forum thread for related feedback.
That's all for now, we'll be aiming to have some more significant and interesting releases next week, and be getting back on track for further Friendly Fire / Faction system changes, as well as expansions and improvements to Dynamic Warfare and the Economy. Thanks for your patience during this unplanned and highly undesired debugging period.. hopefully this work will give us a better foundation on which we can build crazy new gameplay.
-Incarnate