First question: Do you remember when you first encountered JMonkeyEngine?
What was your first impression?

Not long after that, I adopted jME for a project called “OpenWorld.”

Since I was underage my adventures there did not last long, but
I was hooked from the start.
It was like a game, but there were so many things to do and places to explore,
and the built-in creation system blew my mind.

A couple years later, I discovered OpenSimulator,
an open-source server that’s compatible with Second Life clients (viewers).
Since then, I’ve been a member of various OpenSimulator virtual worlds (or grids, as they’re called).

During my second year in OpenSimulator, I began to keenly notice
some limitations that OpenSimulator inherited from Second Life.
Compared to multi-player games, virtual worlds always felt slow and bloated,
and the architecture was fundamentally limiting.

At that point I had the idea that grew into MyWorld:
apply multiplayer game technology to social virtual worlds.
Later on, I realized that a social virtual-world platform
could also be a powerful MMO gaming platform, and
since then I’ve worked towards the dual goal of supporting
social virtual worlds and MMO games as first-class citizens on MyWorld.

1. We’re not beholden to shareholders,
   so we’re free to make decisions that bring the best experience to our users.
2. Our runway is infinitely long — we have no pressure to grow rapidly to avoid bankruptcy.
   We can grow organically and sustainably.

Unlike current-generation virtual worlds,
MyWorld was designed from Day One to satisfy
the performance requirements of multiplayer action games.
This means that exploring a virtual world can have the same fast,
fluid feel as playing a well-designed multiplayer game.

Another difference is that we support scripting on both client and server,
allowing scripted effects and latency-elimination techniques
that are impossible in current virtual worlds.

In addition, our internal systems can be extended via plugins
that can integrate into the entity system and
host or call HTTP endpoints (for custom REST APIs, for example).
Plugins can even extend the core network protocol
with jME’s fast, intuitive, and efficient RMI implementation.

In a project like MyWorld,
there are many opportunities to provide value to users,
so there are many potential revenue streams.
Initially we’re looking at a revenue model similar to Second Life:
users can rent space in the virtual world to build homes,
businesses, workshops, etcetera.
We may also introduce a subscription model that offers
extra benefits to heavy users.

We’re also investigating how we can monetize
by offering professional hosting and support services to game developers
and those interested in running MyWorld servers.

1. Issuing in-house currency is a large financial liability —
   there are many ways to destabilize an economy, virtual or otherwise,
   that are largely or completely outside the control of the currency issuer,
   which would present a risk both to us and our users.

2. Governments have begun regulating virtual currencies,
   making it expensive and difficult to issue them.

Fortunately, we’re not the only ones with this need
and there are several good virtual currency services,
some of which allow the same currency to be used across many games or virtual worlds.

So yes, we will have a virtual currency,
but we’re not planning on issuing it ourselves.

I don’t see this as a notable limitation, especially early on.
Most of our initial user base will be developers and creators,
not general users,
so I expect the overwhelming majority of interest to be coming from adults.

I want to allow minors to access at least some areas within MyWorld
as soon as it makes sense for us as an organization and community,
but for now we need to focus on the technical aspects.

The server uses jME’s network stack,
and we’re transitioning from jME’s physics to Minie, but that’s about all.
The server’s systems and heartbeat/event dispatch loop are all custom —
we don’t use jME’s application structure serverside.

Like Second Life,
MyWorld allows content creators to script anything they create.
Scripting can include physics, movement, particle/sound/animation effects,
HTTP calls, etcetera.

The problems here are security and resource use.
Since anyone with creation privileges can upload scripts to a server
(and scripts can also run client side), sandboxing is a must.

My first choice for scripting was Groovy.
It’s a powerful, well-known language with many features,
and the compiler supports AST transformations for customizing compiled code.
I spent a great deal of time pursuing this route,
but the shoe always pinched in the same spots: preemption and checkpointing.

Preemption means that the script engine can stop a running script at any time.
This is necessary to ensure that misbehaving (or resource-intensive) scripts
don’t overuse CPU resources.
Preemption is also necessary for checkpointing:
freezing a script so it can be persisted to disk or sent to another server.

Java was not designed for preemption.
Every mechanism I could think of to fit preemption support
into Java’s compiled bytecode came with substantial overhead and other nasty limitations.

I also experimented with an assembly-like language for scripting,
but it was too difficult to read to be suitable for anything more than trivial scripts.

I designed Chipmunk to fit a unique place in the language spectrum —
easy for a first-time programmer to pick up,
but powerful enough for an experienced developer to hit the ground running.
For example, classes declare state that’s shared between all instances
via the “shared” keyword,
which is semantically identical to Java’s “static” keyword,
but expresses the concept in terms that make intuitive sense
to inexperienced programmers.

In terms of features, Chipmunk supports modules, classes, polymorphism,
first-class functions, anonymous (lambda) functions, exceptions,
and dynamic typing.

The main language features are functional, but it needs more attention
on things like string manipulation, collection operations, and libraries.

What skills/tools would someone need to create and upload a 3-D model?
Do you envision people using Blender 3D?

What audio formats will MyWorld support?

Our initial creation pipeline is based around the GLTF format.
Thanks to jME’s GLTF importer, most modern GLTF files should import seamlessly.
Our primary interest in external tools is Blender 3D,
but anything that exports to GLTF should do fine.

Later on, we plan to support in-world creation via constructive solid geometry
with procedural extensions, as a supplement to the GLTF pipeline.

Any audio format supported by jME (OGG & WAV in particular)
can be opened by the client for upload.
Streaming media can be in any format supported by JavaFX’s media framework.

Our Facebook
and Twitter pages
cover major news items and announcements,
and liking/following us there helps us get the word out to more people!

For general project information, blog posts, and press releases,
the MyWorld website is the place to go.
We archive the notes from our monthly “MyWorld Meetup” sessions on the blog —
these are a great resource for finding out details about the project.

Thank you very much for your detailed answers
and all the time and care you put into them.