# Augmented Worlds

_The following post introduces a concept we are exploring to achieve the Geo Web's goal of creating an augmented, shared reality. For more info, check out our latest [roadmap](https://www.geoweb.network/post/post-launch-roadmap)._

---

The blog post _[Autonomous Worlds](https://0xparc.org/blog/autonomous-worlds)_ begins with the definition of a _World_:

> A World is a container for entities and a coherent-enough internal ruleset about how they behave. When a system of entities and rules comes to life, it becomes a World.

The [MUD](https://mud.dev/) framework for Ethereum takes this idea into practice by enabling the [Entity Component System (ECS) pattern](https://mud.dev/blog/ecs/) to be used in the EVM, on-chain. This framework is what was used to build [OPCraft](https://dev.optimism.io/opcraft-autonomous-world/), a fully on-chain game built on the OP Stack.

Let's take this concept even further, or perhaps more specific, into something we will call an _Augmented World_.

An Augmented World is a specific type of Autonomous World, where the ruleset is about defining how a physical space can be augmented with digital content.

## Entity Component System

The MUD framework [uses](https://mud.dev/blog/ecs/) the Entity Component System design pattern common in game development.

As a simplification, this pattern has three types of elements.


- An **entity** is just an identifier that represents some object in a world
- A **component** represents a specific type of state about an entity (i.e. position, size, color, etc)
- A **system** is where the logic and rules about a world are defined and enforced

Take a simple box as an example. This box would have some _identifier_ that is used to label it as an entity. It may also have a _position component_ that stores the x, y, and z coordinates of the box in space. Finally, there may be a _rendering system_ that is constantly looking at all entities with a position component and is drawing the shape on some 3D canvas.

This is a over simplified example. Check out the resources on ECS and MUD above for more info on this pattern and some of the reasons it has become popular for game development. This post will focus on the advantages this pattern has for implementing _Augmented Worlds_.

## Worlds of Problems

This pattern fits our model very well, as a World is really just a container of entities, components, and systems.


Existing Worlds defined using this pattern have a couple of problems when we try to create Augmented Worlds.

1. A World is often limited to a certain engine or framework
2. A system is often complex to build and requires heavy game development skills

Unity is an example of a game engine that uses the ECS pattern. Worlds can be built using Unity, but the systems can only be ran using the Unity engine and runtime. Yes, this engine is [cross-platform](https://en.wikipedia.org/wiki/Unity_(game_engine)#Supported_platforms), but that does not inherently solve problem 1 above. The real problem is **excludability**. A framework can exclude users on other platforms by only supporting one platform. But a cross-platform framework can still exclude users with licensing agreements, fees, or other business models.

Unity is also an example of problem 2 above. Developing the systems inside Unity is no easy task, as it requires heavy scripting and development skills. The reason for this is that Unity is powerful and general purpose. Developers can create practically any kind of system they imagine thanks to the powerful scripting capabilities.

Another existing platform that can be used to create Worlds focused on AR is [8th Wall](https://www.8thwall.com/). This platform is web-based and works on both Android and iOS with no app required. This is a great alternative to Unity (which requires a native app) but still suffers from both problems above. Worlds created using 8th Wall must be browsed using 8th Wall. This is a form of excludability that the creator of 8th Wall, Niantic, takes advantage of with licensing agreements and fees. Creating these Worlds must also be done using HTML and Javascript and requires development skills.

So, how can _Augmented Worlds_ be created without development and coding skills and also be as close to non-excludable as possible?

## Verifiable Worlds

Remember, entities are just identifiers and components are just state. It's pretty simple to represent state in a way that is not tied to any particular engine or framework. A simple JSON file can do the trick.

{
	"entityId": 1,
	"position": {
		"x": 1.0,
		"y": 2.0,
		"z": 1.5
	}
}

It's almost as simple as this. However, _Augmented Worlds_ have an authoritative element to them. They are suppose to be the **source of truth** for the state of a World. How do we know if the JSON file we have is the source of truth we should trust?

One way to do this is to use [content-addressable data](https://ipld.io/). [^1] If we take the hash of this JSON file, this can be used by someone else to verify they have the same content. Better yet, the hash of the file can be the entity ID. Therefore, if some says "entity A has these components", that simple statement can be verified by checking the components with the hash.


All the entities and components in a World can be represented with a single hash (or content identifier) and can be verified by anyone else without trusting a single registry or framework. Thus, not only is creating and reading components non-excludable, but verifying the components is as well. [^2]

## Open Systems

We have a way to define entities and their components, but what about systems? Recall that an engine like Unity has a powerful, relatively general-purpose way of defining systems. The tradeoff here is writing systems is complex and running systems requires a specific runtime. What if instead systems were more limited and focused only around what is needed for _Augmented Worlds_?


For example, a `RenderingSystem` can be defined to take the position, scale, rotation and 3D model and render the object into some 3D scene. How this rendering takes place is specific to the underlying platform and framework that the system is implemented in. However, any combination of platform and framework can be used to implement this system as it is defined. [^3]


A standard set of systems and components makes it easier for higher-level tooling to be built to help more people create Worlds. A mobile app, for example, can be developed to help users place a new object with a certain position, scale, and rotation in a World, with no coding required.

## Summary

With this approach, an Augmented World can be experienced using a single content identifier along with some runtime. The non-excludability of the worlds means a runtime can be built on any platform, any framework, and by anyone. The focused set of standard systems means higher-level tooling can be built to enable many more people besides developers to create Worlds. [^4]


---
[^1]: [MUD](https://mud.dev/) uses a blockchain as an alternative approach to this problem. It is out of scope here to talk about the limitations of that in regards to Augmented Worlds, but I encourage folks to check it out.
[^2]: Another advantage of content-addressable data is not just verification, but storage. If you don't need to trust any particular party to verify the data, you don't need any particular party to store the data either.
[^3]: Some systems need to make changes to components. For example, a physics system takes input from multiple entities to simulate when bodies collide, and updates the position and velocity of components over time. In order for Augmented Worlds to be shared, peers need to agree on the evolving state of components over time. Thus, some synchronization system needs to be implemented as well.
[^4]: There is explicitly no mention of the Geo Web in any of this. These "worlds" can all be separate and don't need a registry. So where does the Geo Web come in? The Geo Web is simply a registry that links many worlds together to make them appear as one.