MySQL is the engine that drives the machine. The reason for it is twofold:
1. Speeeeeed. When an Actor evaluates it's surroundings, it does four (sometimes five) things: find the nearest enemy (by sight or failing that by sound), find the nearest ally, find the center of enemy concentration, find the center of allied concentration.
Can you imagine the time it would take Python to cycle through distance calculations between each and every Actor in the sim, at each frame? SQL systems are designed to query and sort lists of results. It's pretty much all they do. For each Actor, I ask it for the first result in a list of opponents/allies, ordered by Distance, and it spits it out. It's also great about returning lists that meet discrete criteria, like everyone trained to a specific Commander, or everyone below a certain level of health, or a certain distance from an object, etc.
I'm also thinking about scalability. If you have 40,000 Actors, this might slow things down. If a professional organization might use this some day (or an enterprising individual), they could run MySQL on a clustered system without any modification. Zoom! It's as fast as you need it to be.
Task splitting. Once again, when you get into high numbers or very detailed terrains, things will most likely slow to a crawl even on the snappiest single system. You can have one machine running MySQL at full speed, and the sim running on another box, full speed there too. If you really need the speed, put Gigabit Ethernet between them.
What it boils down to is that upon thinking about the various things this kind of program would have to do, a whole lot of them were problems that good database software had licked a long time ago, and I felt no need to reinvent the wheel when others had done it MUCH better than I could.
2. Portability. If you want to run things over and over with similar settings, or run the sim for a while then put it away and return later, you need some way to save your state. I could have written exporters/importers and created a file format, but using MySQL, I didn't need to. If you want to take a break from running your sim, you just stop. Your state is waiting for you in the DB. You can examine it with any DB tool you care to. If you want to pull up and take the sim to work, you just grab the dbActors folder from the MySQL folder tree and drop it in place at work. Voila! As I mentioned above, you don't even need to do this - you can run the sim with a connection to the db over the Internet. In fact, this is what I did when I was first working on this.
But what's the justification for making people jump through hoops to use this? Wouldn't it be easier to have it run all with just plain Python out-of-the-box? Yes. But it would have been significantly slower. Also, to get good results out of BlenderPeople, you have to do some work. The odds are that if you (and that's a general "you", not "you" personally S68!) can't follow the install instructions, or are disinclined to because of the effort, that you wouldn't be happy with the results you get from the scripts anyway. It takes some tweaking and playing with stats to get cool looking battle configurations.
Will that cut down on appeal for the casual user? Yes. Do I care? Not so much. If someone needs the tool, I suspect they'll use it regardless. This is one of those "I'm glad people enjoy it" kinds of things, but I'm really doing this just because I find it an interesting problem and fun to do.
I am a long-winded cuss.