MyWorld Meetup – 4/27/19
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.
- FordLady – I’m sure having more features will help attract people to the 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Zauberin – Some tools allow you to convert traditional textures to PBR textures by stripping out the lighting information.
- 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.
- 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.
- 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.