I've not stopped working on stuff in Multiverse, but Christmas and the New Year made it a bit trickier. I'll do a technical update with some code in a few days, but in precis, here's what I've been up to.
I decided to try scripting a server-side add-in. I wanted something non-diku-ish, non-graphical, and which touched a few areas, so I decided to try adding a Sims-style, basic needs-centric AI. What Will Wright did with The Sims, basically, was to give each toon needs like sleep, hunger, cleanliness etc. Each incremented, both with time and with activities: so while the need for cleanliness would slowly increase throughout the day, it would increase faster if a Sim did strenuous exercise. Some items, like showers, satisfied these needs (and "advertised" as much), so a Sim would be attracted to them when a need was at a certain level.
So what I wanted to do was try adding a set of counters which would increment with time for npcs, which would (in this test form) be arbitrary: I called them spin, up, down and strangeness. Making given activities increase these counters was beyond the scope of what I was doing, as was my plan to later provide simple hot-spot locations to which the NPCs would move when a given need hit a trigger level. For now, I just wanted to add these new statistics to NPCs and to try incrementing them.
This would let me work on holding new variables for an existing object type (my zombie NPCs in the example world), as well as sending server messages (periodically incrementing needs) and making these values persistent (so that a given NPC could be de-instantiated when nobody was near). I was also interested to see what the effect on server resources were, both in terms of memory and CPU utilisation. AI in MMOs is traditionally rotten, because it is resource-intensive, and because it is generally better-looking to have NPCs wandering a given street where players can find them than disappearing off to the toilet, so they get given paths to follow, or basic reactions like attacked:fightback or 20% hit points:scarper.
The first thing was just to use the example code on the site to get an add-in working. In the past, I would have launched immediately into writing my own from scratch, which is certainly a good way to learn stuff in-depth. But It doesn't help when there are five things wrong with what you've done, three in implementation and two in code, and in trying to find what they are (not knowing that there are several issues) you end up repeatedly trying and discarding valid fixes. So it's quicker to crib the example code, get that working, then change one thing at a time. Ah, the caution of age.
I had wanted to write it in Java, as I mentioned before: Java I can do, Python I have little experience of. Happily, there is no example code for Java, just a note saying "we'll add this bit later". More than that, there is very little documentation at all for how to do it in Java in the developers' wiki. I say happily because I was rather hoping to learn Python, and this forced me to start doing so. Sometimes, I am a net importer of willpower. In any case, from the look of it, Python will be a quicker way to do most things after a while, even if it's slower to run. Well, tell you what: when I get 20 mill in VC funding I'll blow some of it on rewriting.
Anyway, this is getting a bit lengthy, so I'll document the next step in my next MV post: getting the add-on running. It wasn't tricky, but the documentation was a touch obtuse in places - lots of assumptions - so it might be worthwhile for others.