August 25, 2019

MyWorld Meetup - 8/10/19

Updates:

  • Alpha date: unfortunately we won’t be able to release by September 1st. We’re setting the new goal date at the end of September/beginning of October and will keep you all posted as we get closer.
  • The scripting language is very close to being feature complete.
    • Lots of time recently has gone into the script engine. This is a very time consuming piece of code to work on, and once done we’ll be able to spend much more time on the main MyWorld codebase.
    • After we’ve finished the core language features, we need to integrate the script engine with the server (a much faster task than developing language features).
  • Over the summer Meetups, we talked about research I was doing on practical GOAP AI solver algorithms for my day job.
    • Recap: GOAP (Goal Oriented Action Planning) is an effective and intuitive way to implement AI in NPCs. Traditional GOAP solvers, however, can only work effectively on very small planning problems, limiting the abilities of the AI.
    • My research has been successful – I’ve developed a new type of solver (Wavefront Search) that’s able to solve very large planning problems extremely quickly. The licensing situation with the algorithm is such that we will be able to do a clean-room implementation for MyWorld’s AI system.

Discussion:

  • Q (Zauberin) – Can the server operator configure the size of the zones?
    • Zone size is currently fixed at 2 kilometers on a side. The current zone sizes are the largest that they can be (to minimize network crossings between zones & servers) while still maintaining the ability to position objects in the world to within 1 millimeter of precision.
    • Zone size could easily be made a configurable parameter. However, all servers in a cluster must use the same zone size.
      • Rather than supporting resizable zones, we’re looking into load balancing a single zone across multiple machines by allowing servers to mark “subzones” and transition them onto other servers, partially alleviating the load on the main server. This gives all the benefits that configurable zone sizes could without the downside of increased frequency in network crossings.
  • Q (Zauberin) – Will MyWorld support vehicles?
    • Absolutely. The physics engine we’re using (Bullet) has great vehicle support, and the scripting engine design has features to reduce control latency below what’s possible in current virtual worlds.
    • The only issues I see with MyWorld’s design are related to extremely fast vehicles crossing zones at a very high speed: the network needs to be able to keep up with transitioning the connection between servers, and flying that fast could easily overload the world generator (i.e., you might cross a zone before it’s generated if there’s nothing previously there).
    • One feature we’ve designed is “transient” zones – if you cross into empty space where nobody has built yet, the server will automatically create a new zone. That zone will promptly be discarded when you leave if you cross through without making any modifications to it. These are very fast for the server to create, but the world generator still needs to run (unless you’re flying high above ground level).
  • Q (Zauberin) – Could something like Morton encoding (Z-order curves) be used to reduce the load of zone coordinates on the network?
    • Zone coordinates don’t come up frequently at all in the network protocol, so I don’t anticipate the need to compress them beyond their canonical (X,Y,Z) form. Should the need arise, however, we’ll consider this along with any other options.
  • Q (Zauberin) – Are there any places where MyWorld code is using quadtrees?
    • Not right now, although the client-side scene graph will likely be optimized into an octree or similar structure for efficient culling.
  • Q (Zauberin) – Going back to the question of zone sizes, for people running a server at home with less compute power than typical, could having smaller zone sizes be beneficial?
    • I’d actually expect the opposite – each zone has some (small) overhead associated with it. One server can only handle a certain amount of network traffic, entities, and scripts. Reducing zone size won’t have an effect on how much a single server can handle, and while zones are extremely lightweight each zone does have some (small) overhead. While the overhead is negligibly small, your best bet for getting the most out of your server is actually to lower the number of zones running on it. For these reasons, servers actually benefit from a zone being as large as possible, provided that a single zone doesn’t overload the server on its own (from too much traffic or too many scripts running at once).