MyWorld Meetup - 11/2/19

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.