GOAP is one of many ways to create a good AI, and it's commonly used and well known. It's an intuitive way for programmers to create an AI - the solver takes a logical representation of the world (the world state), and a description of what actions the NPC can perform, what preconditions must be met for each action to be useable, and what effects each action produces. The solver is given a goal state, and if the NPC is able to reach that goal state the solver will produce the sequence of actions required to get the NPC from the starting state to the goal state. Going back to the capture the flag example, the starting state might be that the enemy flag is guarded by two players and the NPC is thirty yards away. The plan might be to rush into close quarters, fight through the two defenders, pick up the flag, and escape to reach the goal state of capturing the enemy flag.

GOAP does not specifically require that any particular solving algorithm be used to produce the solution, and there are several types of solvers in common use. The first type explores all possible solutions and chooses the "best" one. This is an extremely limited solver, however, as it can only plan for very small problems (5 or 6 actions at most) in realtime - the amount of time it takes to produce a solution increases factorially with the number of actions! In order to get around this, many advanced GOAP systems solve with the A* pathfinding algorithm, but this also poses difficulties as A* is formulated as an algorithm in 2 or 3 dimensional Euclidean space, and the assumptions that it relies on to efficiently produce good solutions may not hold in the general state spaces that GOAP works on.

A couple of years ago Daniel developed a new solver for GOAP problems called WaveFront. Unlike A*, WaveFront is defined on general state graphs, not Euclidean space, but like A* it's typically able to converge very rapidly on an optimal or near-optimal solution. Source code for the reference implementation is not available, but the algorithm is not patented and an open source reimplementation is planned for MyWorld's AI system. Detailed notes from a recent presentation Daniel gave on WaveFront's design and implementation are available here: WaveFront Presentation.

We're as busy as ever with the alpha test and new development, but since we've stopped posting our monthly Meetup notes things have been quiet here on the blog! After some discussion among the MyWorld staff, we've decided to start posting occasional development blog updates so that those of you who aren't on our Discord yet can keep up with our progress.

The last few months have been a whirlwind as we've opened MyWorld for alpha testing, open sourced Chipmunk, our in-house scripting language, and continued new development. Today we'd like to share our newest development with you - windowing support in the UI!

Previously, the UI design was what we called "flow based" - as users clicked around to interact with the world and perform tasks (such as creating new objects in the world), UI elements relevant to their activity would appear and disappear. There were two problems with this: it wasn't customizable, and it required us to spend a lot of time and energy designing UI flows that would fit most users and wouldn't irritate the rest! As feedback from the alpha testers showed a lot of interest in having a window-based UI and as the limitations of the flow-based UI became apparent, we decided that we would keep the best features of the flow-based UI and add support for windows. This gives us the best of all worlds: users can customize both their view and their workflow, the UI still retains its fluid, responsive feel, and it frees up a lot of our time and energy to focus on other features.

Here's what it looks like now:

If you'd like to hear about new developments as soon as they're announced, come join us on Discord. It's our primary means of contact with our community, and we have many fun conversations there too - so if you haven't joined yet, please do! Facebook and Twitter are also a great way to receive our updates, and following us on social media helps us get the word out too.

Updates:

• The design for the permissions system is finalized and partially implemented.
  
  • We had originally planned on using a role-based permissions system. However, as we prepared to implement it we saw a number of ways that this type of system didn’t fit virtual worlds and games well. As a result, we’ve switched to using a permission system based on custom filters. The filters can use any criteria to decide whether or not an operation is allowed, and plugins can easily and cleanly add criteria that aren’t supported by MyWorld core.
    
• The design for the trading system is well under way, nearly finalized, and partially implemented.
  
• For several reasons we’re likely going to be using the Gloebit virtual currency rather than producing our own.
  
  • Virtual currencies fall under heavy regulatory scrutiny to ensure that they aren’t exploited by criminals. As a result, almost all U.S. banks do not do business with any company that produces its own virtual currency. A number of well-established businesses have lost their bank accounts, and it is very difficult for newer businesses to open accounts at all.
    
  • When somebody announces a new virtual currency, there is often a degree of skepticism that goes along with it. Gloebits are well established and well regarded, and they travel with the user – so any Gloebits bought for use in MyWorld can be used in other places also (and users can bring their already-purchased Gloebits to MyWorld!).
    
  • Using Gloebits allows us to avoid the long, time-consuming step of establishing a new virtual currency and release MyWorld faster. It benefits our users by allowing them to use the same currency in MyWorld and in a number of other virtual worlds, meaning that our economy will integrate well with other virtual economies – users will not be locked-in by currency.

Discussion:

• Daniel – Note about custom currencies and the trading system. The new trading system will allow two parties (users, or users and NPCs/scripted vendors) to trade any number of various currencies, items, or even land in a single trade. One powerful feature about this design is that it integrates with plugins very easily – our Gloebit support will be provided by a plugin, and any items that MyWorld core doesn’t support trading can easily be supported by a plugin. If other virtual world operators building with MyWorld don’t wish to use Gloebit as their currency, it will be easy for them to support a different virtual currency.
  
• Zauberin – When will there be a beta release?
  
  • We’ve unfortunately been somewhat delayed in October, in part by the widespread power outages in California. With two months left in 2019, we’re still hoping for a release around the end of the year – but it’s possible we may need to delay until early 2020. We’re moving as fast as possible towards release, and carefully selecting only critical features for development before alpha release.
    
• Zauberin – How will the trading interface work? Will you be able to trade more than one item at once?
  
  • Yes, absolutely. Both parties in the trade will put up a list of items that they’re offering in the trade. Once both parties accept the trade, all currency/items/land/etc will be transferred.
    
• Zauberin – Will there be protection to prevent people from doing things like deleting items during a trade, or cheating in other ways?
  
  • Yes, absolutely. These sorts of issues are all things we’ll address as we finalize and implement the trading system.
    
• Daniel – One thing we want to do is reduce “inventory bloat” caused by items being duplicated all the time. For example, in Second Life every time you drop a copyable item in the world, you get an item copy that eventually tends to make its way back to your inventory.
  
  • Zauberin – I never really liked items being sold as no copy – there are many circumstances where you’d really want to be able to copy items, but there should be ways to do this while also avoiding redundancy in the inventory.
    
  • Daniel – Yes, there are two ways I’ve thought of reducing unnecessary object duplication – first, by defaulting to no-copy items, and second, by not copying copyable items when they’re dropped in the world. If a user wanted to drop a copy, they’d need to explicitly duplicate it when they place it in-world.
    
  • Zauberin – It’s best to use the “principle of least surprise” on things like this – the system should default to doing what users would expect. One thing you could do is drop instances (objects that reference the same data as the original item) rather than copies, and only do a full deep-copy when the underlying data changes (like the item’s material properties are edited).
    
  • Daniel – We’ll explore this further – one difficulty with instances is that some attributes (position, orientation, velocity, etc) will always change by necessity with each instance, while other things (like material properties, as you mentioned) will only change with explicit edits.
    
• Zauberin – Will there be support for attribute inheritance? The way this would work is entities would specify a “template” and borrow all attribute values from the template by default, but could override them on a per-attribute basis. This could be one way to implement instancing, and it could help with being able to trade stacks of identical items at a time.
  
  • Daniel – We’ve been considering templates in some form for the last several years – particularly as a “blueprint” to make new items (as part of the effort to reduce unneeded duplicates). I can see the value in using templates/attribute inheritance to allow game developers to easily update art/item attributes after a game has released, however – we’ll investigate this closely.
    
• Zauberin – I was reading the other day that Godot engine claims to have developed the first practical implementation of voxel-cone traced GI (Global Illumination), and they’re planning to release in version 4.0.
  
  • That’s a great resource – we’ll likely look to their implementation as we further enhance our own graphics pipeline. Our plan now is to stick largely to the graphics features currently offered by our game engine, jME, for the alpha and beta releases. This means the foundational features that we’ve talked about will all be in place – PBR shaders, shadows, AO, and a number of other effects. Once we have a release out, we’ll be able to devote more time to improving and enhancing the graphics functionality.

Announcements:

• The Plugin SDK is ready for release!
  
  • MyWorld has a powerful plugin mechanism on both the server and the client. The SDK provides plugin developers with a toolkit for using industry standard languages, IDEs, and the Gradle build system for plugin development. The Groovy and Java languages are supported out of the box, but other JVM languages are trivial to integrate with the SDK’s Gradle build system.
    
• A note about networking – until fairly recently, MyWorld used a message-oriented networking protocol. This was quite rigid and fairly fragile, as all messages must be pre-registered in the same order on both server and client. This meant that the network protocol was static, with no way for plugins to add network-level features or exchange network-level messages between plugins that coordinated between server and client. We recently switched to a lightweight RMI system (Remote Method Invocation) that allows both core code and plugins to “share” objects with a network connection. The other side of the connection can then remotely invoke methods on these shared objects, replacing the brittle and verbose messaging pattern with a powerful and flexible way to extend the network layer at runtime. This also allows graceful degradation of behavior when one side of a connection supports a feature that the other does not, since a missing shared object appears to the other side of the connection as a null value rather than as a missing message type (which will cause a serializer error). The new RMI system is highly efficient and imposes virtually no overhead over raw messaging, so adopting it required making no performance compromises.
  

Discussion:

• Zauberin – Will the SDK allow world operators to add script functions via plugins?
  
  • Absolutely – MyWorld’s script engine, Chipmunk, uses a typical module system. Once the scripting is fully integrated, it will be trivially easy to add importable modules to the scripting engine.
    
• Zauberin – Will it be possible to flag a module as being restricted? For example, some developers might want to add script functions for server or zone administration.
  
  • Yes, there will be a security model for scripts. We have two options for doing that: preventing a script from loading a restricted module (as you’ve suggested), or requiring individual functions to do security checks as they are run. The latter option is much more flexible, and we’re leaning in that direction although we may do a combination of both (only allow a module to be imported by certain scripts, and then allow the functions in that module to impose additional security checks at runtime).
    
• Zauberin – Would it be possible to use C-like #ifdef statements for permissions at compile time?
  
  • No – Chipmunk does not have a preprocessor so there is no mechanism for using #ifdef or other macro techniques. In addition, #ifdefs get out of hand very quickly if they’re not used sparingly, and the issues manifest themselves as confusing compiler errors. Permissions are complicated, which would make such a system highly prone to ifdef-related compilation errors.
    
• Zauberin – Does Chipmunk support assertions?
  
  • There is currently no built in assert keyword like Java and other languages have, no. Assertions are easy to create with functions, but this has the downside that they can’t be disabled at runtime unless kept in test-only code. Early on, we’ll likely take the approach of assertion functions as part of a test framework, but if there’s demand for it we may add an assert keyword to the language and bytecode support to the VM.
    
• Zauberin – Will it be possible to attach scripts to parcels, zones, avatars, etc. and not just objects? There are a few reasons that could be very handy.
  
  • Yes, that’s the direction we’re looking into going. Note that on avatars, you already get to attach scripts “for free” since MyWorld has no special rules or treatment of avatars – avatars are entities just like every other object in the world, with the only exception that they are loaded and associated with a user when the user logs in. We do see a case for attaching scripts to things like zones and parcels, and we will probably take this route.
    
• Zauberin – Will the renderer support edge maps (textures that preserve sharp edges on objects with low-resolution normal maps)?
  
  • Currently no – we will investigate this option, however. As long as it works well with PBR, it could be a powerful feature.
    
• Zauberin – Will there be support for JSON in scripts? What about JSON Patch (a format for defining patches that override sections of an existing JSON object)?
  
  • Yes, we will have a JSON library for serializing/deserializing script data. We will look into JSON Patch and consider support if we see a usecase in MyWorld.

Announcements:

• We’re postponing alpha – time estimates are difficult to make, and we’re not going to be able to make a release by the end of September. We do not have a specific date chosen at this time, but we’re tentatively aiming for the end of the year. We will keep the community posted as we progress.
  
  • MyWorld is about making virtual worlds the best they can be. We’ve never compromised quality to rush things out the door, and we’re not going to now. We are working to get an alpha release out to the community as soon as possible, and we are pushing non-critical features to a future release, but we aren’t compromising on design or code quality. The last thing we want is to rush a feature out only to discover later that it’s flawed and needs to be completely reworked, breaking existing content. MyWorld, as a software package and as an organization is people-first, and we believe it’s worth waiting for when the wait means delivering on the quality and stability our users deserve. We thank all of you for your patience and understanding.
    

Discussion:

• X – Is everything in MyWorld mesh based?
  
  • Yes – At the moment, MyWorld only supports mesh. In a future release, we’re planning support for CSG (Constructive Solid Geometry) building. CSG is a bit like building with prims in SL/OS but much more powerful – for example, you can make complex cutout shapes by using one geometry to cut a piece out of another. We are also working on a displacement mapping extension to standard CSG – displacement mapping is where you use a greyscale texture on an object to add features, similar to how terrain heightmaps work. For example, to make the shaped of an ornate vase you could start with a plain cylinder and use a displacement map to create the curves on its body.
    
• X – One consequence of mesh-only building is that there is no secondary market for textures like SL has.
  
  • Yes, this is true. CSG building should make that market viable again, however, as creators will be building with analytic geometry – just like prims.
    
• X – I prefer mesh, and having used Blender I think many people would want to but don’t think they can. Being able to combine mesh with CSG objects will be very powerful for people who don’t use Blender.
  
• Zauberin – Could we use curves to define the displacements for objects that have the same feature spun around an axis (like balustrades and vases)?
  
  • So far we’ve only looked into using displacement maps, but there’s no reason we couldn’t support using curves or splines for this as well. We will investigate this further.
    
    
• Zauberin – will there be support for triplanar texture mapping?
  
  • On terrain, yes. I don’t see a usecase for non-terrain triplanar mapping, and it is more expensive than simple texturing. If a usecase arises after release we’ll investigate supporting it on non-terrain objects.
    
• X – I’m a texture artist in Second Life and I pay extremely high attention to making things as realistic as possible. This is hard to do in Second Life’s material system. Will MyWorld’s graphics allow realistic texturing?
  
  • Absolutely – MyWorld’s graphics system is a PBR system – the industry state-of-the-art for realistic realtime graphics. PBR allows artists to create near-photorealistic content in a straightforward way that is interchangeable between PBR engines.
    
  • Zauberin – PBR is based on the physics and energy conservation of real light, and it uses the surface properties of the object to simulate light interaction. For example, one PBR parameter is metalness, which makes the surface reflect light according to whether it’s a metallic or non-metallic surface.
    
• X – So for example, would a shiny object look different depending on whether it’s outside in the sunlight or inside?
  
  • Yes – PBR accounts for the environment and is highly realistic under all lighting conditions. Note that environmental factors (like simulating reflected light striking another object) are difficult to simulate in real-time unless most objects remain in one place and you can aggressively pre-bake light information. As a result, MyWorld may not support full environmental rendering effects at alpha, but it will support full, standard PBR texturing. As we go on, we’re exploring methods for adding support for full environmental rendering support.
    
• X – How will MyWorld prevent content theft?
  
  • We have multiple ways to combat different aspects of content theft. For one, unlike SL & OS, obtaining the UUID of a texture or audio asset will not be enough to apply it to your own creations.
    
  • Zauberin – Could the permission system be used for this?
    
    • Yes, to a degree – this is how we’ll prevent UUID leaks from being used to steal textures. The permission system places everybody in “roles” and then allows certain roles to do certain things – for example, permissions for a texture might put the creator in the “creator” role, and the creator’s associates in the “allowed users” role, and then restrict adding the texture to an object to people in the “creator” or “allowed users” roles. However, this doesn’t prevent someone from ripping and re-uploading a texture.
      
  • X – Could you add support for texture licensing?
    
    • Yes, although licensing is difficult to enforce as it’s somewhat on the honor system until a violator gets caught. The rules in licenses are too varied and complex to put to code, in general. We’re definitely open (and have considered previously) allowing creators to license assets they upload so that a copy of the license goes along with the asset. It’s a good start and it gives us a clear legal ground to respond to DMCA requests, but it doesn’t fully prevent content theft since there is nothing stopping thieves from taking the content and re-uploading it without the license.
      
  • X – Would it be possible to hide something in an asset that always goes with it so that stolen content can be identified?
    
    • Yes, that’s possible anywhere with a technique called stenography. You can hide information in things like textures by making tiny variations to pixel colors to encode binary 1s and 0s. If you encode a cryptographic identifier in the texture, you can easily find cases where it was stolen. However, the problem is that a thief can alter or remove the stenography if they know it’s there.
      
    • One thing that’s an area of research for us is statistically identifying uploads of duplicate items. That way, if someone uploads something that is stolen and its “fingerprint” matches something that already exists, we can flag it as a potential theft. However, reliably identifying stolen content is very difficult (many metrics can be thrown off by subtle changes to an asset), and it’s possible (and likely) that there will be sufficient practical barriers to prevent this.
      
    • The takeaway here is that content theft is difficult to fully prevent through technological means, but we will pursue whatever we can. In addition, as an organization, we fully oppose theft and copyright violation of any variety and will do the best we can to support creators and protect their intellectual property.

Updates:

• Alpha date: unfortunately we won’t be able to release by September 1^st. 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).

Updates:

• The scripting engine is almost done!
  
• Almost all language features for v1.0 are complete.
  
• Virtual machine is much faster than most existing LSL implementations

Discussion:

• Q (Zauberin) – Will the scripting language have compile time type error checks?
  
  • Initially, no – the language is fully dynamic (like Python, JavaScript, and most traditional scripting languages).
    
  • The language grammar can easily accommodate static type declarations later, and we’re open to adding optional static typing in the future. Also, it’s much easier to add static typing to a dynamic language than it is to add dynamic typing to a static language – since dynamic languages don’t care about types, it’s no big deal to force an exact type at a particular point in the code – it’s much harder to cleanly broaden types in static code where an exact type is expected.
    
  • We’ve started with a dynamic language for two reasons.
    
    • Most people expect a scripting language to be dynamic, not static. We really want to avoid surprises as much as possible with the scripting language and make it fast, intuitive, and easy to work with. Static typing doesn’t necessarily interfere with that (a good type system should clarify code and stay out of the way), but since scripting languages are traditionally dynamically typed it’s a good starting point.
      
    • A good type system is time consuming to implement, and time is at a premium right now. Compilers for dynamically typed languages are much faster and easier to implement, and the dynamic runtime is powerful enough to easily accommodate a statically typed language later.
      
• Q (Zauberin) – Since static typing is determined per variable, would the static extensions be determined per-variable with something like an if-def or a pragma?
  
  • No – If/when we implement static typing, it will work by adding types to variable/parameter declarations… for example a statically typed string declaration would change from “var myVariable” to “String myVariable.”
    
  • There are some fascinating options for integrating dynamically typed code into statically typed code…
    
    • You can treat the dynamic object as having a “wildcard” type and automatically allow all calls to that type (this is essentially what TypeScript does).
      
    • You can disallow dynamic objects in partially-static expressions and require a cast or type coercion to make the expression fully static.
      
    • Different programmers may desire either warnings that they can ignore or a full error if the compiler encounters a dynamic type in an otherwise static expression.
      
    • We may take the approach Groovy does – all code is dynamic by default, but annotating methods or classes as static enables and enforces static typing rules only on those sections. This tends to give clean ways to mix static and dynamically typed code.
      
• Q (Zauberin) – What string encoding will MyWorld’s script engine use?
  
  • Internally, it piggybacks off of Java’s strings, which are UTF-16 encoded in memory. However, it’s advisable to use explicit string encoding during I/O to avoid ambiguity. MyWorld uses UTF-8 in virtually all I/O operations.
    
  • In general, Java supports Unicode very well so this isn’t a huge concern for us as long as we have feature-parity with Java (which we essentially get for free with our implementation).
    
• Q (FordLady) – What’s the timeline for release looking like? Are you on track for the planned release date (September 1, 2019)?
  
  • We’re not sure – I (Daniel) have unfortunately had to take more time off of the project in July than I hoped to. We’ll see how things go in August. At this point, I think it’s likely that we’ll postpone the September 1^st date for alpha, but we may still be able to release before the end of September. We’ll see how things go and plan an official date update in early August.
    
• Q (Zauberin) – Will the GOAP AI system be for short or long term NPC planning?
  
  • Both – GOAP planners can be as short or long term as you like. You model world states and a set of actions that the AI agent can take, and the solver finds a (hopefully) ideal sequence of actions to accomplish the goal state. Time is irrelevant to the planning, but if something else (a player, another AI agent, etc.) changes world state in between actions running, it may be necessary to re-plan subsequent actions to fit the new world state. GOAP itself doesn’t care about time, but interference in the world state by other agents may make it necessary to re-plan.
    
• Q (Zauberin) – Would it be possible to give NPCs an intelligence stat such that they could be made more likely to make bad decisions?
  
  • That’s difficult in that characterizing a decision as “good” or “bad” is difficult in AI. GOAP planners typically rely on heuristics for “cost” and seek to minimize the cost of a plan. It would certainly be possible to introduce randomness or some other means of fuzzing the heuristic to make an NPC make “poor” (suboptimal) choices, but it’s difficult to predict how unintelligent your NPCs will really appear to be in general. Heuristics that introduce foresight into how the agent’s actions will influence the future could be limited to utilizing less foresight to simulate a low intelligence stat, although this could also be tricky for making the NPC seem less intelligent to a human observer. Without a characterization of how humans perceive the intelligence of an AI, it’s difficult to come up with a reliable way to make certain NPCs seem more or less intelligent.
    
• Q (Zauberin) – Would it be possible to simulate insanity by modifying the behavioral traits of an NPC?
  
  • Yes – one advantage of simulating attitude/emotion and using that as a means to choose behavior (part of MyWorld’s planned AI system) is that you can alter the perception process so that an NPC overreacts to minor incidents.
    
  • We’ve planned a system for passing down traits generationally, with the possibility to modify each trait a small amount (stable but drifting slowly) or a large amount (unstable, one generation may be very different from the last). If each trait has its own stability parameter it’s possible to make some traits more likely to be volatile from one generation to the next. This allows the “culture” of NPCs to respond to events and change slowly over time, just as human cultures (and animal populations) do.
    
• Q (Zauberin) – Will players be able to chat with NPCs?
  
  • There are a lot of different chat systems out there (predetermined responses, language processing tied to a knowledge base, etc.) and many games have very specific requirements. It’s possible that we won’t build one in, or that we’ll build in several alternatives. This is an area we haven’t expanded much on yet, but it’s also an area that’s well established and (relatively) easy for an end developer to add as part of a specific game. Once we have time to flesh out the AI we’ll see what folks are interested in for chat systems.
    
• Q (Zauberin) – Will NPCs be able to pass on memories from one generation to the next?
  
  • Yes, we’re planning ways to have NPCs pass on memories across generations, with the possibility for some accuracy to be lost with each successive generation.
    
• Q (Zauberin) – Will there be a system to simulate genetics for things like appearance?
  
  • We’re planning on ways to pass on intelligence traits but not necessarily physical ones – tying traits to appearance is likely to be very game specific. We’ll probably leave that to specific games’ scripting, but if we come up with a way to meaningfully do this in a game-agnostic way we’ll definitely look into it further.

Discussion:

• No updates right now, but wanted to talk a bit about AI in MyWorld (Note: This is still highly tentative and mostly in planning/design stages right now. Any features discussed may change in the released version. In addition, most of the AI system is intended for MyWorld’s support for games, not the MyWorld Virtual World.)
  

• GOAP (Goal Oriented Action Planning) is a common and very powerful way to give NPCs behavior – the solver is given the current world state, desired state, and a set of actions that it can use, and it makes a plan for how to reach the goal state.
  
  • Traditional GOAP solvers used in game development are pretty limited and exhibit poor scalability, practically limiting them to working with a small (< 10) number of actions.
    
  • On a project outside of MyWorld, we’re experimenting with a more powerful type of solver. If successful, we may be able to use a clean-room implementation in MyWorld.
    
• Q (Zauberin) – Will the AI be able to be “package” behaviors for specific NPCs?
  
  • Yes, our plans for the AI involve a high degree of customizability for individuals and for groups.
    
  • Our goal is to support “personalities” of sorts, allowing NPCs to grow and adapt over time. These would model attitudes, personality traits, and the flow of information from one NPC to another.
    
  • If successful and given complex enough logical models, the AI could possibly allow NPCs to exhibit emergent behaviors and develop distinctive personalities according to the conditions they live in.
    
• Q (Zauberin) – With NPCs adapting over time, would it be possible to model NPCs going insane?
  
  • Yes, it would be possible. From early on, we’ve planned heritable traits and “volatility” scores, allowing traits to change both subtly and dramatically according to time and the events the NPC encounters. This could be either spontaneous (which would be quite rare) or could be influenced with script bindings to “tip” the NPCs mentality over time.
    
    • Even without direct intervention, given enough time such a system has the potential to produce everything from extreme pacifism to terrorism in an NPC population (assuming limiting factors are not put into place).
      
• Q (Zauberin) – Would the AI support giving specific traits or volatility scores to specific in-game character races?
  
  • Yes, tribal/racial/species differences are critical. The traits/mood/personality system won’t need to know anything about the race/species it’s simulating – all it would need is the individual’s (or group’s) traits and it can go from there, and different race/species/individual NPCs will be able to have distinctive traits/moods/memories, etc.
    
  • For example, with sufficient model complexity, NPCs could engage in political behaviors (war, peace, etc).
    
• Q (Zauberin) – Will there be a system for interaction between an NPCs and regular players?
  
  • Yes, NPCs will likely be modeled with moods and emotions that can influence their behaviors. A critical part of this is the ability to respond to events in the world around them, both from other NPCs and from players, as well as to form memories and impressions.
    
    • To prevent an explosive growth to the AI dataset, NPCs need to be able to meaningfully forget – memories need to either be incorporated into fuzzy statistical generalities, or insignificant memories need to be forgotten in favor of memories of major events.
      
      • Q (Zauberin) – Could NPC memory (good memory or forgetfullness) be tuned?
        
        • Yes, that’s something that would definitely make sense to expose as part of the AI trait system.
          
• Q (Zauberin) – Some games have disguise systems where players can disguise themselves to get away with unsavory behaviors that would normally lower their reputation with NPCs. For example, say the player is in a village and is playing as a thief, would the AI be able to handle the players disguising themselves?
  
  • This would require overriding how the AI translates events in the area into perceptions. It would be possible to support this, probably through scripting support for the AI, but probably would not be a directly supported core feature as it’s quite specific to individual games. We’ll investigate this as we integrate scripting into the AI system.
    
    

Discussion:

• Work is progressing on initial world generator design
  
  • There are many aspects that need to be addressed – generating an interesting world, handling modifications made by users, updating/improving algorithms later, etc.
    
  • Many procedural world generators work by layering noise & fractal functions – we’re investigating applying/saving user modifications to terrain as functions that are applied as patches over the generator’s output. The alternative is storing the world as soon as it’s generated, but this takes a great deal of space.
    
• FordLady – It seems easier to store the world as it’s generated – would this take up too much storage space?
  
  • The issue with storage space only comes up when people travel across vast areas and don’t come back to them. If the world is stored as soon as it’s generated, this means storing large amounts of data that may never be used again or may only be used very rarely.
    
  • Another issue with storing the world as soon as it’s generated is changing the generation algorithms or parameters later. You may want to re-generate some wilderness areas, but user-customized areas should probably not be changed. Storing the world results after generation make it harder to re-generate as algorithms are improved. Re-generating and storing only user modifications makes this much more straightforward.
    
• FordLady – Would re-generation happen automatically or would it have to be manually applied?
  
  • This is still an open question – probably the best solution is to allow either to be used at the world operator’s choice.
    
• FordLady – Will the world-generator be fairly complete by alpha?
  
  • Simple world generation is easy – during alpha we’ll have some simple feature generation, but we’ll likely delay further enhancements to beta or later until higher priority tasks are completed. Eventually we may pursue placing animal populations as part of the generated world.
    
• Advanced features will wait until higher priority tasks like porting the scripting engine to Graal/Truffle are completed, but basic world generation will be in place by alpha.

Announcements:

• MyWorld has switched from the Cassandra database to CockroachDB.
  
  • In the last few months, we’ve been moving from a more traditional world model to a “regionless” world, where the world is visible to users as one enormous space instead of being divided into many separate regions. With that change, naming areas of the world and cutting it into parcels has also grown to allow nesting named areas and parcels, very much like how real world areas are divided into countries, states, cities, neighborhoods, and lots. While Cassandra fit our older zone-oriented model quite well, the new world model relies on nested hierarchies in the world data – a data model which fits Cassandra very poorly.

• Rather than spend precious development time force-fitting the new world model to Cassandra, we’ve switched to CockroachDB. CockroachDB is a cloud-scale SQL database – it scales very similarly to Cassandra for handling very large data sets and heavy workloads without downtime, but uses a traditional SQL data model that provides far more flexibility than Cassandra’s more limited model does. This allows us efficient and natural support for the new world model, and also provides flexible indexing for much more of the data in MyWorld’s database – which means much more flexibility and power as we design new features.
  
• In short, the switch provides much more power for MyWorld’s next-gen design, without compromising on the scalability and reliability that led us to choose Cassandra initially.
  

• CockroachDB is also significantly easier to setup and run on a personal computer than Cassandra is. This makes it much easier for us to support people who want to run a MyWorld server on their own computer.
  
• We’ve already completed the switch – MyWorld is currently running on a CockroachDB server, and we’re quite satisfied with the results we’ve seen so far.

Discussion:

• Zauberin – Does CockroachDB support JSON?
  
  • Yes – it has first-class support for JSON as a column data type, including indexing JSON data for fast querying.
    
• Zauberin – Does the index support arbitrary JSON documents, such as deeply nested fields in a free-form structure?
  
  • This lies outside of our current usage of CockroachDB, but it’s my understanding that the indexes do support that well. Right now entity data is serialized to a custom binary format, but we’re investigating making use of JSON columns & indexing to allow querying on entity attributes. It’s not clear if we’ll go this route or not yet – the current format does have some advantages over JSON, despite being opaque to queries.
    
• Zauberin – One of the projects at InWorldz was switching internal data storage to Protocol Buffers. Have you investigated using that format?
  
  • In the early days of MyWorld, we investigated Protocol Buffers but stayed away for several reasons. For one, Protocol Buffers have some awkward aspects to the format, and the tools significantly complicate compiling your code. For another thing, Protocol Buffers work best when the data you’re serializing is of a previously known type – when you don’t know the type of the data ahead of time, you have to manually add type information to the Protocol Buffer data. As a result, it’s not effectively different from what our current format does, and it has the downside of complicating MyWorld further and adding dependencies on a format and a set of tools that have proven to be somewhat quirky in the past. This is why we haven’t gone that route.
    
• Zauberin – In Minecraft, large caves are common but pose some difficult issues for culling at render time. Are there plans for generating large caves in MyWorld?
  
  • No, especially in the short term. The alpha release will use traditional heightmapped terrain, but in the future we’ll be adding support for voxel terrains. While small caves and terrain with overhangs add a lot of depth to a world, I don’t see virtual world users having a high demand for large underground cave networks. Even after we add support for voxel terrains and implement the world generator, I would lean in favor of biasing the generator towards generating smaller caves, not large underground networks.
    
  • Zauberin – Minecraft also had a challenge with cave culling because they store chunks that are small horizontally but extend upwards in tall columns. This makes culling underground features harder.
    
    • Most of the people I (Daniel) personally know work with small cubic chunks as a standard practice – probably for this very reason. It definitely makes culling much easier to handle. We’ll cross that bridge when we come to it with MyWorld, but I expect that we’ll handle voxel terrains in the same way (small cubic chunks).
      
• FordLady – You’re talking a lot about Minecraft – in Minecraft everything you build is very blocky. Will MyWorld be like that, or will you be able to build in different styles, such as building a Victorian house?
  
  • MyWorld and Minecraft are totally different – in Minecraft, everything (terrain, houses, machines, etc) is made of voxels. In MyWorld, voxels will only be used to support terrain with features like canyons, overhangs, and caves (which aren’t possible with the traditional heightmapped terrain that current virtual worlds use), and MyWorld’s voxel engine will produce smooth, natural looking terrain – not blocks. Technologically, Minecraft’s voxel engine is relevant to MyWorld for terrain, but buildings in MyWorld will always be made of either mesh or our CSG “SuperPrims.” So no, your creations won’t look like Minecraft’s block style – unless you explicitly make them to be that way.

Discussion:

• Virtual – what viewers will MyWorld be compatible with?
  
  • MyWorld is completely separate technology from OpenSimulator and the Second Life ecosystem. As such, it has its own client – Second Life viewers will not work with MyWorld.
    
  • One advantage that MyWorld’s client has for users is a powerful plugin system – instead of having to install different viewers to get certain features, users just install the one MyWorld client. Anyone who wants to add features writes a “plugin” – code that extends the client and adds features. Users who want these features just install the plugin, and without even needing to restart the client (usually – it would be possible to write a plugin that needs the client to restart, but this is a limitation of the individual plugin, not the client), they can access that feature. This means that users won’t need to install separate viewers and log in/out between different viewers to access the features they want.
    
• Zauberin – Will the viewer have plugin “profiles?” Minecraft and some other things like it have profiles that let you specify a specific set of custom modifications. Especially for some kinds of worlds, users will need to have some specific plugins installed.
  
  • MyWorld currently does not have support for profiles that specify certain sets of plugins – but there’s nothing stopping anyone from writing a plugin to provide that feature! We will, however, support some mechanism for the server to indicate to the client that it should have certain plugins installed and activated in order to experience certain add-on features in the world. We’re still working on that.
    
• Zauberin – Could the client auto-download and install plugins that the server indicates?
  
  • No, that would be a pretty severe security flaw. Plugins run as part of the client, so they aren’t sandboxed at all – if they were auto-downloaded, there’s a potential to install malware on unsuspecting visitors. Installing plugins will always require a user to make the decision to install, and we’re investigating additional security measures to prevent plugins from being a way to distribute malware.
    
  • Once a user decides to install a plugin, however, it will happen very automatically and with minimal (or no) user intervention. In general, plugins will immediately be loaded without even requiring a client restart.
    
• Zauberin – Will people have to log out frequently as a “fix” to certain issues? One issue that OS/SL based virtual worlds often have now is that people clear the viewer cache as a “fix” to lots of issues, even when not needed at all – clearing the cache is rarely needed and often just worsens the issues they are experiencing because of additional network load.
  
  • We’re building the MyWorld client to be as restart-free as possible. User experience is critical to us, and requiring a client restart is generally a poor experience. There are some circumstances where it could be necessary, but our goal is for those to be as rare as possible. Also, clearing the cache is something that should rarely (or never) happen.
    
• Virtual – Any idea when the MyWorld beta will be open to the public?
  
  • Our goal is for alpha to be out around September of this year (2019). Alpha will be on an invitational basis – everyone in our community is welcome and will have access, and they will be able to invite friends. I anticipate a 2-3 month alpha period until beta, which will be open to the public – so that puts us at beta around November or December.
    
  • We’re moving towards alpha as fast as possible, but there is still a lot to do. With all software development (especially projects as large as this one), predicting development time is notoriously hard to do – there’s so much that can go wrong and cause delays. We’re working our hardest to get MyWorld out as soon as possible, but if we’re delayed (or ready sooner than planned), we’ll always be open to the community and keep you informed of what is happening.
    
• FordLady – Do you have any announcements or updates?
  
  • Yes! The last couple weeks have been quite productive and I’ve made significant headway on a major issue. This is a little sooner than I typically announce major changes, but I believe at this point it’s safe to say that this is the direction we’ll go so I’ll announce it now.
    
  • User interfaces are notoriously time consuming and difficult to do well for things like MyWorld. Traditional desktop user interfaces (like Qt, GTK, and others) are notoriously difficult to get working well with hardware-accelerated applications like MyWorld (and the SL/OS viewers), which is why things like this usually have a completely custom UI system built just for them. For over a year, I’ve been working on such a custom UI system for MyWorld. However, UI systems are notoriously complex to write from scratch – individual features usually aren’t that hard to implement, but there are so many of them that building a complete UI that meets user expectations is very difficult and time consuming.
    
  • There’s a very well known user interface library called JavaFX that was developed by Sun/Oracle and released as part of Java. It’s incredibly powerful, and from the beginning of MyWorld’s development I’ve wanted to use it for MyWorld’s UI. When I started the UI development, it would have been possible to use JavaFX, but integration of JavaFX with things like MyWorld was in a state that had me concerned about its long term viability, so I opted for a fully custom UI system. Now, over a year later, the situation with JavaFX has changed substantially – to the point that it’s a very viable long-term option for us.
    
  • With a great deal more to do before our custom UI could be used, and with time until alpha being very tight, I’ve been investigating closing down development on our custom UI and using JavaFX for MyWorld’s UI. Initial results have been very promising – I’ve re-implemented some of the existing user interface in JavaFX, and I was able to complete it about 10x (or more) faster than the first time I did it. In other words, JavaFX is going to be a huge time saver if this works out. At this point I believe that it’s safe to say that we’ll go with JavaFX as the final UI solution.
    
  • JavaFX will also likely provide an easier and faster solution for allowing server-side scripts to interact with the client’s UI far more directly than they can now. Currently, creators must build a “prim UI” and script it to imitate a UI. Our goal is to allow scripts to define a “real” UI that the client displays, and JavaFX may very well make that easier to do than a custom UI would.
    
  • JavaFX also means that we’ll probably be able to support web media far sooner than initially planned.
    
• Zauberin – Web media got my attention! Does this mean we’ll get media-on-a-prim type functionality?
  
  • Yes – that’s what we’re aiming for. JavaFX has a WebKit-based embedded browser engine – essentially the same thing that Safari and other Apple products use. I’m hoping we’ll eventually be able to allow MyWorld script code to interact with JavaScript in the embedded browser, but there’s a lot that needs to happen before something like that would be possible. Even if that doesn’t happen, we’re aiming for at least feature-parity with Second Life’s media-on-a-prim functionality.
    
• Virtual – Are you planning to have MyWorld be free to join and then have paid membership options, or will this information only be presented when beta comes out?
  
  • MyWorld will always be free to join! We’ll likely offer paid premium memberships with some extra perks, but MyWorld will always be free to join in. Any premium memberships will always be just for extra perks, very much like Second Life and some OpenSimulator-based grids do it today.
    
  • Similarly, just like other virtual worlds, you’ll be able to own your own land. There will be usage fees for that (we have to pay for servers, after all!), but while we have some unique improvements that we’re working on, you can expect the monetary aspects of the virtual world to work very similarly to what you’re used to today.
    
• Virtual – Will MyWorld be on the hypergrid?
  
  • In the sense of tying into the OpenSimulator hypergrid, no. MyWorld is a completely different technology, and it isn’t compatible with OpenSimulator at all – even the network protocols are different, so there’s no way to make them talk to each other.
    
  • However, MyWorld’s core technology allows running multiple separate worlds on the same server cluster, and we’re exploring even more “hypergrid”-like functionality. At the end of the day, we’re aiming for something similar to OpenSimulator’s hypergrid – you’ll be able to have one login account and visit many different virtual worlds without having multiple accounts or having to log out and back in.
    
• Zauberin – In earlier Meetups, we’ve talked about MyWorld generating the world and users being able to find a nice scenic piece of land and claim it as their own. Suppose someone finds a nice woodland area and builds a cottage. What’s to stop someone from moving in right next door to them and ruining their woodland view? Could they put in a request to mark an area around their property as uninhabitable?
  
  • I like to call this the “nasty neighbor problem” – users want a nice place to build, but there’s nothing stopping a neighbor from moving in next door and building something ugly. This is a problem in current virtual worlds too, and we’re working on a couple different solutions.
    
    • (a) There will be a way to mark an area around your property so that nobody can claim something immediately next to your home. In current virtual worlds, to do this you need to either use only a small area near the middle of your region to build, or you need to purchase scenic regions to place around yours. Neither of these options are very economical for users, so we’re investigating ways to mark an area around your land that gives you some space and is economical for you too.
      
    • (b) We’re also looking into “HOA” (Home Owners’ Association) type solutions for large areas. We’re looking at letting a group claim a large undeveloped area at an economical price, and then only paying regular use fees for the much smaller areas where people actually build. This allows groups to form large “protected areas” where group members can build according to the group’s theming/building rules without worrying about the “nasty neighbor problem.” For example, a group could claim a large mountainous area and build an alpine village and cottages without anyone being able to build right next to their area and spoil the effect. (Similar to what themed regions do now in current virtual worlds, but on a larger scale.)
      
• Virtual – Will you be offering MyWorld how-to training classes or making videos?
  
  • In some way, yes, absolutely. We’re not just going to “toss it in your lap” so to speak and then walk away – as soon as we reach alpha we’ll do everything we can to document features and help users get settled, learn MyWorld, and adjust. Exactly what form that takes is still up in the air – we’ll definitely have written documentation and tutorials, but we’ll also likely conduct in-person workshops and other similar activities. I generally prefer written documentation over videos because you can quickly scan and get the information you want without watching a whole video – but if there’s significant interest in how-to videos, we’re open to doing that also. We’re building MyWorld to be easy, fun, and straightforward to use and create in, but there will always be a need for assistance too. We’ll support and assist the community however we can. MyWorld is about people first!
    
• Virtual – Will your viewer have built-in help tips for using the functions?
  
  • Yes – the client is designed to be clean, easy, and straightforward to use, and that includes built-in hover tooltips. We’re also working on designing the user interface to be straightforward and natural to use – you shouldn’t have to hunt all over the place to find that one button that you need. As you perform a task (like texturing), everything you need should be right there and quickly accessed from one place. Usability is incredibly important to us, and while I expect that users will find it easier to use than SL/OS, it will take some transitioning to get used to.
    
• FordLady – I appreciate Virtual’s questions because I’ll probably need a lot of assistance myself – I come from a gaming background, not a virtual world background.
  
  • We want MyWorld to be simple, straightforward, and people-friendly in both a community and technical sense. We won’t just toss it out there and leave users to sort it out – we’ll be there to assist.
    
• Virtual – Are you using a version of your viewer to develop and create MyWorld?
  
  • Mesh content will be created in Blender, Wings 3D, Google Sketchup, Maya, or whatever your tool of choice is. Regarding in-world content, such as our CSG “super prims,” terraforming, or the assembly of meshes into in-world objects, yes, we’ll be using the exact same client tools that you will be using.

Update (Daniel):

• We’re continuing to progress towards alpha as fast as possible. This week saw some new experiments aimed at accelerating UI development, with initial results looking very promising.
  
• MyWorld now has database support in place for script key/value storage. This is a feature that’s highly beneficial to scripters, but has had only limited support in existing virtual worlds. Key/value storage gives scripters a safe, permanent way to store data in a way that won’t be affected by script resets or errors. There’s more to be done before this will be ready for scripters to use, but the foundation is in place.
  

Discussion:

• FordLady – Great news about the progress towards alpha!
  
  
  • Daniel – One thing I should note is that these types of shifts happen frequently on the project as we move from design phases to building-for-production phases. Things like this (especially this particular shift) mean that once I’m able to focus on this full-time work will progress very quickly. This also means more time to dedicate to adding features to the alpha that wouldn’t otherwise have made it in.
    
    • FordLady – I’m sure having more features will help attract people to the alpha.
      
• Daniel – A couple of notes about alpha:
  
  
  • Alpha releases almost always (a) lack some features, and (b) have some bugs. As a result, MyWorld’s alpha will not be fully publicly open. This is for two reasons: (a) to manage load, and (b) to give us a chance to iron out bugs with the folks who are interested enough to stick around and help us find them. Some users don’t have the patience to deal with alpha-quality software, and that’s fine – but we want to keep the alpha to people with realistic expectations initially and then wait until beta to start offering services with a quality that we can guarantee.
    
    
    • We’ll do our best to avoid breaking content created during alpha – but service level features like land ownership and currency may not be operational during the alpha phase.
      
• Q (Zauberin): One major concern I have about MyWorld as a game engine is that its clustered server design creates a problem for creating single player games by running the server locally on the user’s machine.
  
  • Daniel – This is a topic that’s come up during our Meetups before, and I’ve been putting some thought into it. MyWorld has always been about virtual worlds and multiplayer games, and that’s what we’ll keep our primary focus on – there are many great tool sets for single player games, but very few for multiplayer games. Having said that, MyWorld’s major systems – entities, physics, and scripting – all run on both the client and the server. Our powerful plugin system means that some very powerful customizations can be made to the client with minimal effort. I believe that it would not be difficult at all to adapt the MyWorld client to single-player games with a small set of plugins.
    
    • MyWorld will be released in two phases: Phase 1 will be focused on virtual worlds, and Phase 2 will be focused on game development. Once we’re at Phase 2 we’ll definitely support community development of single-player focused plugins, and if demand for these is significant enough we may create and support these ourselves.
      
• Q (Zauberin) – Will the key/value store be able to store lists, and if so will it support in-place appends?
  
  • Daniel – Yes, the key/value store will be able to store lists. At the most basic level, the value stored is just a binary blob. The script API will tie into this low-level functionality with a serialization layer – so when you store a value from a script, you just store any object and the key/value store serializes it to binary and persists it. Lists will be supported in this fashion, so in-place appends at the data store level won’t be supported. However, I don’t believe that this is going to be an issue for many people.
    
• Q (Zauberin) – If in-place appends aren’t supported, how will scripts store data that’s larger than the script memory limits allow?
  
  • Daniel – The key/value store is intended to allow safe storage of values that should survive script resets and other events that could cause a script’s memory to be lost. It’s not oriented towards being a script database or mass data store. For cases where scripters want a full database and/or mass data storage, we do have embedded HTTP(S) server (scripts serving data across HTTP) and client (scripts making HTTP requests/calls to out-world servers) functionality, so out-world web services and databases can be dealt with that way. We want to support as much data storage/processing as possible in-world without making scripters deal with the complexity of this, but that will still be an option for those who need more specialized functionality than the built-in data store supports.
    
• Q (Zauberin) – Even though MyWorld uses PBR rendering, will people still be able to use content with traditional diffuse/specular/normal textures?
  
  • Daniel – Technically yes, because the PBR shaders can use any texture. However, due to the nature of PBR, any traditional (non-PBR) content will always look out of place. The reason for this is that PBR requires that the textures on an object contain no lighting information directly baked into them, but traditional texturing methods do exactly that (which is why it’s difficult to make traditionally textured content look good across a range of lighting conditions). So while it’s possible in that the system won’t break or prevent the upload or anything like that, they will never look correct – and that’s true for any PBR system in the industry, not just MyWorld.
    
    • Zauberin – Some tools allow you to convert traditional textures to PBR textures by stripping out the lighting information.
      
    • Daniel – Yes, there are tools to process plain photographs into PBR textures, and anyone can always use them to convert a traditional texture into a PBR one.
      
• Q (FordLady) – Will people be able to start making things during alpha?
  
  • Daniel – Yes, absolutely. That’s one of the main goals for alpha – to get people in and creating. We won’t offer full services (land, currency exchange, etc.) during alpha so that we have a chance to get any major issues ironed out, but we definitely want people in and creating – and we’ll do our best to make sure that creations made during alpha aren’t broken by any changes later.
    
  • FordLady – So the goal is to have everything in place by beta?
    
    • Daniel – Yes, to a certain extent. During beta we’ll open up land ownership and other services, and by then we should have at least a minimal world generator running. However, that component in particular needs to respect all existing land – it can only generate new areas, and they must tie to existing land seamlessly. That will leave it open to future improvements. Even after MyWorld reaches a full release all of these systems will continue to grow – but by beta, we will at very least have the basics in place and working.

Update (Daniel):

• MyWorld’s world model is already quite different from Second Life/Open Simulator – zones are much larger than 250×250 meters, and stack vertically as well as horizontally.
  
• We’re taking it another step forward – extending to a full “regionless” model where the server instantly generates the world on-demand without an administrator setting up regions. MyWorld’s zones will be quite invisible to users – users will see a continuous, large virtual world.
  
• We expect this to be fully functional by alpha release.
  
• As we move forward, we’re investigating full procedural world generators – this means the server will auto-generate oceans, mountains, plains, lakes, canyons, etc. automatically. Instead of users placing orders for full regions, they’ll find areas they like, claim as much land as they want, and customize the terrain/plants and build as they wish. This is not likely to be fully functional by alpha/beta release, but we will have some simple form of terrain generation in place.
  
• This also gives users much more flexibility with land amounts – if they don’t want full “region” sized pieces of land, they don’t have to rent more than they want and then rent out pieces to other users.
  
  • Zauberin – In OpenSimulator there was a push for larger regions via Mega and then VAR regions. However, at the same time there was also a non-trivial demand for smaller regions. People who only wanted a smaller piece of land didn’t want a full 256×256 meter region if most of it was going to go unused.
    

Discussion:

• Q (Zauberin): How will private islands work in MyWorld?
  
  • Answer: The final world generator will generate sections of land in a common style – for example, large oceans and mountain ranges. For islands specifically, users can just go to a vacant area in the middle of the ocean and choose a piece of land for themselves. This could mean either starting with an island that was auto-generated, or just choosing an area and terraforming their own island. This has the advantage that users can make their islands exactly the size they want them to be.
    
• Q (Zauberin): Will we be able to script auto-generators for specific areas? This would allow users to set specific parameters and auto-generate islands to their specifications, for example. This could even allow the user to supply a noise texture for the generator to use or specify heightfield textures to generate things like craters.
  
  • Answer: This isn’t a feature we had planned on, but it does pose many exciting possibilities. There are no technical reasons we couldn’t expose the generator to scripts, so this is something we’ll look into. Regarding noise and heightfield textures specifically, one of the planned client-side tools is letting users load heightfields and “stamp” terrain into shape with them. This would be easy to integrate into the script engine (even apart from script access to the world generator).
    
• Q (FordLady): Are you planning on doing all the terrain yourself (or automated), or will users be able to customize it?
  
  • Answer: Users will always be able to customize the terrain (or other world features) of their own land. The world generator will pre-generate terrain, vegetation, and other features, and then users can customize (or even completely override/replace) the auto-generated terrain with their own. The generator allows people to explore an infinitely large world and choose where they want to claim and develop land.
    
• Q (FordLady): How much of this will be done by alpha, and will people need it to be complete to start building their own homes?
  
  • Answer: The new regionless model (infinite world) will be done before alpha release as it’s a central, critical aspect of MyWorld’s long-term operation. We’ll likely have some early, simple world generation in place, but advanced world generation (like generating extensive biomes and placing vegetation) is likely to be highly time consuming and will likely have to wait until after release. There are entire companies that do nothing but advanced world generators like this, so we do need to carefully prioritize so that we get an alpha out quickly. That being said, a simple fractal generator should be pretty fast and easy to do, so we can probably get something more advanced than, say, a flat plain 10 meters below sea level.
    
  • The generator will be set up to not overwrite areas that people have customized – if a user has built a home and then we make changes to the generator, those changes will only affect land that hasn’t already been settled.
    
• Q (FordLady): How much of the things people create during alpha will be kept? Will everything be erased?
  
  • Answer: The entity and asset systems are mature as they are and are highly unlikely to see any breaking changes when we get to release. As such, creations that people make will not be deleted during the transition from alpha to beta. Other systems, such as land and currency, will likely operate on a temporary basis during alpha. For example, during alpha, test currency will be freely available and will be erased at the beta launch. Land will not be assigned to users as their own during alpha, so it will probably be erased at the beta launch as well. At the beta launch, land ownership will become available, and after that point once it’s yours it’s not going to be deleted.
    
  • Once we reach alpha, what’s permanent and what will be deleted will be clearly listed for users so that everyone knows what’s going to be deleted before they spend time on it.
    
• Q (Zauberin): In Second Life, if a user wants to make a home in a vehicle they have to either leave the vehicle parked in one place or link their belongings to the vehicle. How will MyWorld support creating homes in vehicles.
  
  • Answer: Creating homes in movable vehicles has long been a primary support goal of ours. MyWorld’s entity system features a full hierarchical scene graph – this means that objects can be attached as children to other objects and move with them. For “house vehicle” entities, we’ll make this process automatic and invisible to the user – any object dropped inside the vehicle will automatically move with it.
    
• Q (Zauberin): Will MyWorld support fluid dynamics? For example, could you have a flowing river?
  
  • Answer: Yes, this has been a goal of ours for quite some time. There’s a question of how detailed this will be – highly detailed water simulation is very computationally expensive, so we’ll have to set some limits. Our current thinking is to do some physical analysis and pre-bake vector fields describing fluid flow. Those vector fields can then be used to animate flowing water and physically influence objects that are in the water.
    
• Q (FordLady): Does MyWorld have weather, like storms and rain?
  
  • Answer: At the moment, no, although this is something that we’re working on. We want to get fairly realistic with this, but there are limits to how realistic we can go. Weather is a chaotic system and as such is notoriously hard to simulate – small changes in one area can lead to massive disturbances in another. Depending on how realistic we get, our weather system may need to put limits into place to protect against, say, the entire world turning into one hurricane after another. It’s likely that we’ll go for a very simplified weather system with a high degree of user control. This will give a sense of realism while still allowing users to control the weather to a reasonable extent.
    
  • FordLady: Weather control could be kept within a small area.
    
    • Yes, although weather in one area does highly influence neighboring areas. This would be a problem with any reasonably realistic weather simulation.
      
  • FordLady: Will there be seasons?
    
    • Probably not, although we can definitely look into that. Seasons may be too realistic for some folks’ tastes – if you’re snowed in, you’d probably rather go online to a tropical beach than another snowy area. We’ll investigate this further once we get closer to release. That being said, there’s no technical reason we couldn’t support seasons – and if we opt not to go that route, users can always create a plugin to add seasons.
      
• Zauberin: With plugins, people could tie the weather in the virtual world to real-world weather conditions. There are web APIs where you can provide a zip code or airport code and download real-time weather data for that area. Plugins could use that to set the virtual weather parameters, and they could also use it to set the sun height/angle so that it corresponds with the real world at a certain point on earth.
  
  • This is a great idea! We hope somebody will try this out with a MyWorld plugin! Regarding sun angles, the atmospheric system we’re using does allow exactly that already. You can set your virtual place to correspond to a real-world location, and it will align stars and planets according to how they would appear at that position on earth.
    
• FordLady: The sun could even be up in one area and down in others.
  
  • Yes, absolutely – although trying to make that correspond to real-world locations does present some challenges since planets are spherical and MyWorld is an infinitely large plane. That said, there are ways to mimic realistic sun movements, however.
    
• Q (Zauberin): For recreating real-world areas in MyWorld, people could download satellite terrain data. What are the minimum and maximum height of terrain features in MyWorld?
  
  • MyWorld is not constrained to a 2-D world grid like other virtual worlds – you can go infinitely far in any direction, including up and down. This makes it suitable for space simulations as well as traditional virtual worlds.
    
• Q (Zauberin): Would the deep sea block out light, and will there be lava if you tunnel towards the planetary core?
  
  • Yes, the water filters will block out light, but we’ll allow users to set ambient light parameters so they can still see deep underwater if they wish. MyWorld itself won’t simulate the earth’s core, but of course there’s no reason you can’t add lava deep underground if you want to.
    
• Q (Zauberin): If you made an underwater base, would it render with the water on the outside?
  
  • Yes, this is something we’ve had planned for quite some time. There are some rendering tricks that need to be done to make this happen, but we’re working on it. For example, if you’re in a submarine you should be able to look out the window and see underwater without the interior of the submarine being shaded as if filled with water.
    
• Q (Zauberin): For outer space, could you generate the world as an asteroid field?
  
  • Yes, absolutely. MyWorld doesn’t assume that the world is even on a planet’s surface. Things like oceans and terrains are optional “extras” as far as the core of MyWorld is concerned.
    
• Q (Zauberin): I had a friend in Second Life who joined, did very little, and then left because the user interface was too complicated. What will MyWorld’s user interface be like?
  
  • We’re taking a very different direction with MyWorld’s user interface than Second Life did in their viewers. Everything will be extremely streamlined, and while creating, very task-focused. Every tool or feature that you commonly use should be only one click or shortcut key away. Creating an easy, fast, and fun user interface is an extremely high priority for us, and one we’ve spent a lot of time on. As with any user interface work, we won’t know how well we did until people start using it and giving us feedback – but even now we’re highly focused on making it straightforward and easy to use. We always develop from the standpoint that simplicity is powerful, and we’re excited to see what we can do with the user interface.

Discussion:

• Q (FordLady): As you are working on MyWorld how do you know what to work on next?
  
  • Answer: That’s a question I (Daniel) have to answer each week as I work on the code, and it can be a difficult question on when working on something the size of MyWorld. There are many different systems within MyWorld, many of which are interconnected and have to cooperate. These often have to be developed side-by-side.
    
    • You can also consider systems like MyWorld to be built in “layers” – a data storage layer, a server simulation layer, a network layer, etc. Layers will depend on other layers, but they build on top of them and (if designed well) aren’t as tightly coupled. This gives a natural separation point and priority to different parts.
      
    • This last week I’ve done a lot of major work in the data storage layer that will accelerate development moving forward.
      
    • Similarly, MyWorld’s custom UI system (which has been very time consuming to build) is oriented towards fast and clean development. Tradeoffs often have to be made between spending more up front time to build something that will be very fast and powerful later and keeping initial development time shorter to stay on track for alpha release.
      
• Q (FordLady) How long have you been working on MyWorld? Has the design changed much in that time?
  
  • Answer: I’ve been working on MyWorld for around 6 years. The design has improved substantially over the years – it’s very different from what I started out on, and far more powerful. I set out to make virtual worlds better, but that improvement was initially very much at the code level – writing code that was cleaner, less bug-prone, and more efficient than current virtual worlds. As I worked on it, I became increasingly aware of some pretty severe design flaws and limitations in current virtual worlds, and began making design changes to address those. One thing led to another, and today the design is substantially more flexible and powerful than anything out there right now.
    
    • One thing that’s different is the data model – older virtual worlds defined a set of database columns to describe a specific thing (a region, an object, a user, etc.) and if you ever want to add more data about something (or change something) you have to make many changes to both the database schema and the codebase. MyWorld is far more flexible about data storage. I’ve developed a theoretical model that starts with some basic “building blocks” and lets many different systems within the server flexibly handle very different tasks on the same common platform.
      
    • The theoretical model is very similar to how mathematicians and physicists build logical models to describe physical or mathematical phenomena. This model (MWOS – MyWorld Object System) treats everything from entities to physical sections of the virtual world as generic “objects” and defines a common data storage and set of operations for all “objects.” This means we can quickly add or change the data we’re interested in storing or the operations we want to perform without touching the data storage layer.

• Q (FordLady): Can you work on multiple different things at the same, or do you have to completely finish one thing before starting another?
  
  • Answer: Yes, I often work on multiple very different aspects of MyWorld at the same time. For example, for quite some time I was building the server and scripting engine at the same time. These are two very different codebases, and to this day have not yet “touched” each other. (Integrating scripting is one of the things left to do before alpha – they were developed separately to keep the scripting language generic and not tied just to MyWorld.)
    
• (Daniel): This brings me to another big change to the scripting engine that we’re exploring before release. Scripts run in a “virtual machine” – a special program that runs the programs written in the scripting language. There are three ways to write these virtual machines: (1) AST interpreters (easy and fast to write, run scripts slowly), (2) bytecode interpreters (significantly harder and slower to write, but run scripts much faster than AST interpreters), and (3) JIT/optimizing interpreters (bytecode interpreters + some extras – very hard and slow to write, but often run code much faster than the others).
  
  • MyWorld’s scripting language is currently built on a completely custom bytecode interpreter custom designed just for MyWorld. As bytecode interpreters go, it’s quite fast and efficient and fairly well optimized. We’ve done some informal benchmarks against common LSL virtual machines such as Xengine, Phlox, and Second Life’s Mono-based VM, and MyWorld’s engine is consistently 3x faster (and in some cases up to 16x faster) than any of them.
    
  • However, compared to industrial-grade language runtimes, it’s still a bit slow. We can do better.
    
  • Up until recently, small teams could really only take on AST or bytecode interpreters. JIT/optimizing interpreters were out of reach to smaller teams because of their extreme complexity. However, over the last decade Oracle (the company behind Java) has been working on an exciting research project called Graal that’s finally coming to fruition.
    
  • To cut a long story short, Graal gives scripting language developers the best of both worlds – we get to write AST interpreters (which are fairly simple and easy to write), but Graal automatically converts the (slow) AST interpreter into an optimizing JIT interpreter! Even better, Graal watches the scripts as they run, and as runtime conditions change it constantly adjusts and re-optimizes the running code into the most efficient form possible. This means that for the first time in computer history, single developers or small teams can, over a matter of months, take large, industrial languages and develop interpreters that are competitive with (and in many cases, much faster than) the fastest interpreters in existence now.
    
  • We’ve done experimental work with Graal in MyWorld before, but kept our current design due to some specific requirements that are difficult to handle in Graal. Now that we’re closer to release, we’re revisiting Graal again to see if we can work out the complexities in a reasonable timeframe.
    
  • In addition to making MyWorld’s scripting language faster than it is today, Graal also presents some very exciting opportunities for using existing professional grade debugging and optimization tools for MyWorld scripts, saving us a great deal of time and giving scripters a professional toolset from day one.
    
  • Note/disclaimer: This is still tentative, and we may have to stick to what we have now for the time being. Graal is definitely worth exploring, and we’re hopeful that we’ll be able to use it, but there’s still a lot that needs to be done before we can definitively settle on basing MyWorld’s script engine on Graal.

Announcement: Changes to the Meetups

• We’re not setting a weekly theme anymore.
  
  
  • MyWorld is a lot to take in – we announced themes to give the community a gradual and detailed introduction. We feel that the themes served their purpose well, and now that the community is familiar with MyWorld it would be better to focus on what the community wants to discuss.
    
  • What we talk about at Meetups will be up to the community – just come with your questions and ideas and we’ll talk about whatever you want to talk about!
    
    
    • If you don’t have questions, come anyway! We’ll bring a list of things to talk about, and let the Meetup attendees choose.
      
      
• Meetups will now be available to those who can’t make our Saturday time! After each Meetup, we’ll publish the notes to the blog. We’re creating a new text channel on our Discord server just for Meetups, so if you can’t join us on Saturdays, look over the notes and join in as we continue the conversation throughout the week!

Discussion:

• (Raven) – How long until the alpha release?
  
  
  • (Daniel) – At the moment, development is slow (but steadily progressing) due to a 50+ hour/week day job. However, we’re making some large adjustments that will allow me to work on the project full time. We’re targeting for an alpha release in September.
    
    
    • Note: Software development is notoriously difficult to put in a time frame – it’s possible that we won’t be able to release in September, but it’s also possible that we’ll be able to release before September. In any case, we’re working towards alpha release as fast as possible.
      
      
• (Daniel) – Right now, development is focused on the client’s user interface (UI).
  • MyWorld will have its own custom UI system.
    
    
    • Thoroughly investigated other UI systems, but existing systems didn’t quite fit our needs. As a developer, MyWorld’s UI design is looking very promising – it’s fast and intuitive to work with.
      
      
  • A notable change for SL/OS users – MyWorld’s UI will not have the floating chat/inventory/building windows that the SL/OS viewer does.
    
    
    • Floating windows tend to pile up in messy ways while you work, creating a distraction and slowing down workflow. MyWorld’s UI will be highly focused towards the task the user is doing – most tools/functions will be only one click (or a keyboard shortcut) away, helping maintain focus. The UI should never set itself up to be a hindrance to the task at hand.
      
      
• (Raven) – Will MyWorld have an advanced rigging system similar to Second Life’s Bento?
  
  
  • No – instead, MyWorld allows you (the creator) to use (or create) any skeleton you like. It does not assume that the avatar is even human shaped – for example, creating an avatar like a centaur (half human, half horse) would be no different than creating a human avatar.
    
    
  • MyWorld is a fusion of game technology with virtual worlds – we’re providing the same tools game developers expect to virtual world creators, and likewise, we’re providing the power of massively scalable virtual worlds to game developers.
    
    
  • MyWorld is a very powerful tool for game developers.
    
    
    • Making a new MMO typically costs millions of dollars and years of time.
      
      
    • As a result, MMO games are typically out of the question for small studios and indy game developers. MyWorld changes this by providing a complete platform with “batteries included” – all that’s left for a studio to publish a game is creating game content, and possibly some server/client plugins for highly specific functionality that isn’t provided out of the box.
      
      
• (Zauberin) – I’m designing a game. Will I be able to customize the MyWorld UI for my game?
  • Yes – most systems in MyWorld (including the UI) are extremely flexible and are designed to be customized through plugins (or even in-world scripting). Game developers will be able to create fully custom user interfaces if they wish.
    
    
• (Daniel) – A note about MyWorld for game developers
  
  
  • We provide a complete client & server, but both are designed to be quick and easy to extend and customize with plugins.
    
    
  • We want to avoid MyWorld having multiple forked clients like SL/OS – users will be able to heavily customize their own client through plugins, so developers can just release a plugin for a new feature instead of forking the client and making the user maintain a whole separate install.
    
    
  • Some internal systems (physics, database, etc) are not intended to be replaced, although in many cases it will still be possible. The idea here is to provide a stable core on which to build extensions without the issues caused by providing several different implementations of internal systems.
    
    
• (Zauberin) – Which physics engine does MyWorld use?
  
  
  • MyWorld uses Bullet
    
    
  • Z – Bullet’s GPU compute could be very powerful for MyWorld
    
    
    • Unfortunately, the Bullet developers are not maintaining or pursuing further development of the OpenCL GPU compute features right now.
      
      
    • It’s possible that at some future date we’ll pursue either supporting Bullet’s OpenCL pipeline or building our own physics engine that’s specialized for multicore/GPU compute.
      
      
• (Zauberin) – Will MyWorld support single player games in addition to multiplayer?
  
  
  • MyWorld is designed and oriented towards exclusively multiplayer/online games/virtual worlds.
    
    
  • However, many systems (entities, physics, scripts, etc.) are designed to run on both the server and client. With some plugins and a little work, single player should be reasonably attainable if a developer wanted to go that route.
    
    
• (Zauberin) – Will MyWorld support running a server on your local machine, either for hosting your own games or for running a standalone virtual world? (Like Minecraft?)
  
  
  • There’s nothing stopping someone from doing this (a small MyWorld cluster runs on one machine for development work), but MyWorld’s server is designed to be run in a cluster.
    
    
    • MyWorld uses Cassandra for its database, which is designed for multi-node clusters.
      
      
    • MyWorld’s server is designed to be used with an asset server cluster.
      
      
    • Unlike Minecraft and similar games, MyWorld is designed to scale to massive worlds with many thousands of players online at once. This requires the server to be designed in a very different way from the Minecraft server. The advantage is that MyWorld is linearly scalable (the world can grow indefinitely large in users, content, and size without performance loss), but this means that it’s not as simple to run on your local computer.
      
      
• (Zauberin) – InWorldz used an early version of Cassandra for its inventory database and had some scalability and upgrade issues. In particular, servers needed to be added in powers of two. Will this be an issue with MyWorld?
  
  
  • No – Cassandra has come a long way over the years and is used successfully in massive production clusters by several large companies (Apple, Netflix, and others). It’s come a long way since the early versions, and we don’t foresee scale or upgrade issues moving forward.
    
    
    • The number of nodes in a cluster should be odd (for distributed consensus reasons), but do not need to be added in powers of two.
      
      
    • Not familiar with InWorldz’ upgrade issues, but modern Cassandra releases have well defined upgrade paths.
      
      
  • Z – Cassandra deletes cause tombstones to be written, which was also an issue for InWorldz.
    
    
    • We avoid delete-heavy patterns in MyWorld for this reason, although modern Cassandra does better with handling tombstones than it used to.
      
      
• (Raven) – Do users get regions in MyWorld like in SL?
  
  
  • Users will absolutely get their own space/land in MyWorld, but it’s more powerful and flexible than in SL.
    
    
    • MyWorld divides the world into “zones” – very similar to SL regions, but larger.
      
      
    • Unlike SL parcels, which mark a 2D ground footprint, MyWorld’s “parcels” are marked by 3D boxes. This allows stacking owned areas (for example, an apartment building) while maintaining the right permissions.
      
      
  • Right now, MyWorld zones act a lot like regions – an admin has to set them up, and they stick around forever. We’re moving towards a “regionless” model that presents the virtual world to users as an infinitely large world with no edges/boundaries. The server(s) will create zones as needed when users travel around the world. In addition, we’re exploring procedural world generation so that users can explore a truly infinitely large world with interesting features everywhere. We’re looking into allowing users to areas of land that they like as their own when they find them, allowing the world to grow organically and letting users get pre-generated scenic areas and customize them as they like.
    
    
    • Note: World generation is a time consuming feature. We likely won’t be doing this until after alpha, and probably not until after the first full release.
      
      
• (Zauberin) – What would stop someone from claiming huge sections of land as their own?
  
  
  • Users will be billed for the land they claim, so they will only claim as much as they’re willing to pay for.
    
    
• (Raven) – If you claim a piece of land and make it beautiful, what prevents someone from griefing by putting something ugly next to it?
  
  
  • This is a difficult problem and definitely needs a solution. We’re still in very early planning stages on this and we don’t have all the answers ourselves yet. There are a few ways to solve this problem:
    
    
    • The server can make a buffer area around your property to prevent this. While this will add some space between you and your neighbors, it doesn’t completely eliminate the problem. (A giant pink tower is just as ugly 100 meters away as it is 30 meters away.)
      
      
    • (FordLady) – Can you deal with this through Terms of Service?
      
      
      • To a degree, but this has limits too – hard to prove that someone’s motivation for building something ugly is to harass neighbors. Content that breaks ToS is an issue regardless of the “bad neighbor” problem.
        
        
    • Another solution would be marking large sections of land and placing “homeowners’ association” rules on them. This would provide clear limits on what’s allowed where and would allow dealing with ugly/out of place content.
      
      
      • (FordLady) – These could be marked out as first-come-first-served.
        
        
      • (Raven) – Large sections could be marked with themes – alpine, apocalyptic, naturist areas, etc. Then people with specific interests would have a place to go, and there could be areas for just about anything.
        
        
• (Zauberin) – Will there be a free tier of land?
  
  
  • Probably not, but this is something we still need to think over and decide on. One issue with free tiers is dealing with land that people claim and then disappear for long periods of time, leaving the land claimed but unused.
    
    
    • (Raven) – Could give a free trial period or reclaim land if it’s not used for a certain period of time.
      
      
• We’re more likely to provide land as a premium account feature.
  
  
  • Very similar to what SL does now and what InWorldz did for a while.
    
    
  • Premium accounts would require a small fee, and would reward the users with a comparably valued piece of land, and/or possibly some MyWorld virtual currency.
    
    
    • Note: These are still preliminary plans and are not yet finalized.
      
      
  • (Raven) – You could also group these Premium areas together, giving neighborhoods for Premium account holders and reserving areas for expansion.
    
    
• (Zauberin) – When someone claims land, will they be able to grant use (or rent) land to other users while still maintaining ownership?
  
  
  • Yes – MyWorld has a powerful role-based permission system that makes it easy to allow whoever you want to do certain things. Restricting what someone could do on your land is as simple as granting specific permissions to specific roles, and then adding people/groups to those roles however you like.
    
    
• (Zauberin) – Will MyWorld allow groups to split the bill for group-owned land between group members?
  
  
  • Probably not, although we will consider this. There are a few issues here – how the payment processor (PayPal, credit card, etc.) handles things, and what happens if one individual refuses/forgets to pay their share.
    
    
  • Likely that we won’t go this route, and will leave individuals to sort out the payment details themselves.
    
    
• (Zauberin) – Will we be able to pay land fees with in-world currency?
  
  
  • No – for legal and liability reasons, in-world currencies (and other virtual currencies like GloeBits) are typically classified and handled as valueless “tokens.” They have value to users because they can be cashed out for real currency, but they are not a real currency. Land rentals & membership fees will need to be paid to MyWorld in real currency.
    
    
• (Zauberin) – Will MyWorld support GloeBits?
  
  
  • Probably not – our current plans are to keep currency fully in-house. This will allow us to track & integrate exchanges like object sales much better and provide much better guarantees and safety around sales & financial exchanges between users.
    
    
• (Zauberin) – How will partnering work with avatars?
  
  
  • This is a feature we haven’t gotten to yet, but it will be fast and easy to complete. There’s a high demand for it, and something we will almost certainly support.
    
    
  • (Zauberin) – One option is to allow adding multiple relationship fields (spouse, parent, sibling, etc) that users could fill in (subject to the other party’s approval).
    
    
    • Good idea, will consider and investigate.
      
      
• (Zauberin) – How many avatar profile fields will we be able to fill in?
  
  
  • We want profiles to be flexible – we’ll probably have several system-defined ones (name, description, date of joining, etc), but we may allow users to add their own custom fields to profiles. We’ll experiment with this as we go through alpha & beta release/testing.