But First, the Game

In the last couple of articles, I might have spent too much time talking about big buzzwords – metaverse this and persistent state technology that. I get it, it can be confusing!

If I were to start throwing around even more technical stuff – like, how we drive Node.js from our highly-optimized C# server backend to implement a TypeScript-based scripting environment so gameplay code can be reloaded without a build or restart – well, plenty of people’s eyes might glaze over.

So instead, I want to talk about why our overall tech approach makes for better lives for our developers and better games for our players.

A fundamental truth

To make better games, we need to enable developers to iterate faster.

Slow iteration means fewer chances to refine gameplay. It also means higher costs, which leads to greater conservatism in game design; higher costs make devs less inclined to take risks.

When we look across the history of games, we see periods of enormous innovation come along whenever costs fall. Flash games, mobile games, the availability of Unity and Unreal: all of them led to new experiences, because cost barriers fell.

Well, MMOs have not had that happen. If anything, barriers just keep going up.

The reason why we’ve built a metaverse platform is because, by its nature, it brings barriers down.

An example

We have this philosophy that “everything about the game should be data.” That’s a fancy way of saying that even the game rules are done in “softcode” or “script” rather than hardcoded. In and of itself that’s neither new nor unusual.

But let’s look at what it means for a developer:

• There’s no need to do a compile or build to update content. Doing a build of a big game on Unreal can take hours.
• We can reload the gameplay scripts on live servers without taking them down, too. A gameplay engineer can try tweaks and changes really fast. Or launch a fix for a problem as soon as it’s solved.
• In fact, multiple people can be working on the same servers at the same time, working live against the actual game, seeing their changes happen in real time, which means better collaboration and iteration.
• This gives us higher odds of “finding the fun” in a system.
• Less obvious is the ability to A/B test. This is traditionally very hard to do with game systems in an MMO (though mobile games have done it a lot). The benefits in terms of balancing and improving a game are pretty dramatic.
•  A system like this is built out of tons of small bits of code. If one of them has a bug, only that code stops working. The rest of the game keeps running. It’s way more fault-tolerant, which means fewer crashes and fewer completely broken systems.

The point is to set designer creativity free by removing the shackles of traditional tedious, trudging iteration.

Another example

Everything you see and hear in our game comes down from the cloud on the fly only when you need it. These days, gamers are so used to giant install sizes that the benefits of this change aren’t immediately apparent:

• We don’t need to patch your install to add things to the game; we only need to do patches to update the client. Imagine patching your browser every time Amazon added an item to its store! Seems ridiculous, right? That’s where games are today.
• New art can come out constantly, not just in big lumps.
• In fact, that art might be procedural, customizable, or modifiable in ways that aren’t possible when it’s baked into your client. This can make crafting or building much cooler.
• And of course, these days install sizes are enormous. With art coming down on the fly, we can also delete it from your hard drive if you haven’t seen it in a while. That means your install won’t eat all your storage! I don’t know about you, but I am really tired of having to delete games I still play to make room for new ones.

Even all that only scratches the surface, though.

Once upon a time, we used to be able to maintain special ruleset shards easily. Now, it’s much harder. The days of having parallel worlds with different rulesets or even different appearances can come back. (Anyone remember Siege Perilous on Ultima Online?)  

We could magically replace every pine tree with a decorated tree during the holidays, and put them back after, seamlessly.

We could create “pocket” worlds for arenas, minigames, or unique experiences. Or offer much better support for player organized events like concerts, sporting tournaments or beauty pageants.

Once upon a time on text worlds, it was common to play minigames like “recall tag.” It was a sort of “last man standing” battle game. You just teleported to the arena – which looked nothing like the game it was set in – and back out when you were eliminated. In text, that was easy. With this set up, it’s easy again.

But the fact that everything is server-driven, dynamic, and streaming has one big benefit above all.

The world doesn’t have to be an unchanging cardboard stage set.

Dynamic things can change. Players can affect them. Leave their mark on the world.

Streaming down everything on the fly means the world doesn’t have to be static. It can be simulated. It can evolve on its own. It can respond to player action.

Our game is built on that idea, and it opens up huge amounts of gameplay. But I don’t want to dive too deep into that until we announce the game.

Looking towards the future

Everything I’ve talked about helps us as developers make a better game for you, the player.

• We can make more things faster, which helps us make things more fun.
• The game can change on the fly, at any time.
• This allows the most alive game world ever seen.
• This lets players affect it in real ways.
• It enables a wider array of gameplay within one online world.
• Without all the hassle of patches and lack of disk space when things change.

That’s just the stuff that this platform gives us for the game we’re making now. But there are future benefits that it could unlock as well.

• Since assets stream, we could allow assets to be uploaded by players.
• Because worlds stream and editing is live, we could allow players to edit worlds.
• The script is in a widely used language, so we could allow players to script someday.
• It is all architected as a network of worlds, which means we can segment that stuff off so it doesn’t break the main game, or cause the sorts of “TTP” issues (Google it) that so many games have seen.

Are we doing any of that right now? No. We are making a game with this tech for you, rather than asking you to make games for us.

Why? Because that’s a lot to ask! Most people aren’t expert MMO designers, or ready to start building one from scratch!

We have a very specific plan:

1. Build tech that supports the future: all the stuff we’ve outlined so far. It makes making MMOs easier, cheaper, faster; and the resulting games are more varied and can offer things that current MMOs can’t.
2. Build a game on it. Prove that it does what we think it does. 
3. Later on, once the game works and is out, we figure out what else we do. This platform would allow user modding, for example. Or outright user-created content. Or networks of multiple games, not all made by us.

But there’s no point in paying much attention to that until you make a great game. All of this only matters if players are happy. So that’s what we’re working on first. A great player experience is the point.

— crossposted from the Playable Worlds website