The last development version I sent to my $50 backers contained a serious bug, so I'll be sending out another soon. As I mentioned in a recent post, I had to quickly and unexpectedly convert the database from using a ODBMS to using serialization. The relationship of object references was such that attempting to serialize a database with more than 1000 sectors resulted in a stack overflow. I've fixed this by making the database structure into a tree.
Weapon M ran its first scripts back in June, and its first useful scripts a couple weeks ago. This weekend, I wrote the first script that interacts with the database in a meaningful way. It's a non-interactive ZTM script that uses a very simple and naïve algorithm, plotting courses in the CIM from 1 > 2, 2 > 3 . . . n > 1. I wrote it not only to see if the script system and database were working properly, but to get a first estimate of what kind of speed Weapon M is capable of.
The results were encouraging. On one server, it consistently plotted 5000 routes in about 325 seconds, which is a little slow. But on another, it plotted 5000 routes in 215 seconds, which is on par with the fastest ZTM speeds I ever achieved using SWATH or TWX. The run times of repeated ZTMs of the same universe were consistent to within 1%. With a good buffering strategy, the practical limiting factor seems to be the speed of the server, not the speed of the client. Of course, the ultimate benchmark will be credits-per-hour in unlimited turn games. I'm confident that with its transparent access to the database and the power and flexibility of Java, Weapon M will be able to meet or exceed the performance of the best existing cashing scripts.
I was planning to set up a host and bug tracker this week, but now Amazon Payments is telling me that it may take 5-7 business days to transfer funds to my checking account, which currently contains about $8. So that may have to wait one more week. Meanwhile, I'll be sending out more alpha builds via email.