Just posting a quick update about what's going on with us. As of my last post (below), we were ramping up on the process of debugging server-side performance issues in Border Skirmish. We also had some unplanned excitement a little later in the week, with a webserver outage, which further sapped some time from the debugging-and-fixing process.

Back on track, we're now much more informed about the issues specific to dense capship/fighter battles on the server, and are making significant headway.. both in resolving some major bugs (which caused the interpenetrating-capship issue that recently appeared and helped spawn this effort), as well as generally improving server-side performance. The better performance we can get, the more and larger battles we can have, which is critical to our upcoming "Dynamic Warfare" gameplay enhancements.

We're playing with using LuaJIT to speed up some of the server's Lua code. LuaJIT is a very fast "Just In Time" compiler, which compiles Lua down to x86 assembly code. However, it still isn't clear if it is optimal for our particular code usage, as there are other tradeoffs (memory usage, etc).

We're also trying to enhance collision-detection performance. A lot of our collision code is pretty fast already (this is all compiled C++), but there are a few cases that could be improved. For historical usage, it has always been more than fast enough, but for expanding on the "Skirmish" type gameplay, every extra server-CPU cycle counts.

This all stems, fundamentally, from our having large quantities of complex, heavily-armed capital ships flying around and attacking one another, along with clouds of NPCs fighters. Videogame developers are inherently adept at "faking" a lot of situations in the interest of gameplay performance, a certain amount of puppetshow-theater is par for the course. It's necessary to maintain an immersive illusion, while also making the desired gameplay feasible on the target platform. In this case, however, the situation we're simulating actually is the gameplay, and we have little option but to create it all for real if we want to provide the desired experience. Thus, we really do have a lot of different individual ships making individual decisions based on a variety of input criteria, and actually shooting and harming one another, no differently than players. As a result, a lot of CPU time is used, sometimes more than is strictly "available". Even with infinite finances, we would still put effort into making such code as scalable and optimized as possible; but because we're a smaller shop, we have the added financial motivation to wring as much performance from our server-cluster as possible.

New Stuff for This Week

I had planned to drop more content last week, due to the rest of the company being bogged down in debugging-land. However, the webserver issue also used up a lot of my time as well, and I wasn't able to finish anything in time (thankfully, our Player Contribution Corps had six new missions ready).

This week, we have a bit more in the works. Among other things, you can expect to see friendly-fire restrictions dropped from the entire system of Odia. We'll see how this goes, and hopefully learn a bit more about how prepared we are for FF-removal. I also can't promise anything, but I will make an effort to drop in some new content, in the form of enhancing grayspace trade routes, and potentially adding something from the New Addon/Ship Suggestion Thread.

That's all for now. Thanks for your continued patience. Hopefully we'll have some awesome Dynamic Warfare / Border Battle stuff to show off, once we optimize some of these issues.