<aside>
💡 Building an XR multiplayer platform doesn’t necessarily need to be complicated. The key is to ensure that the world is organized in a way for players to understand easily. A simple information architecture can help a player to kick off the experience instantly while at the same time providing a solid foundation for iteration in the long-term development and operation process.
</aside>
To read this documentation in dark mode, press ctrl+shift+L [Win] or cmd+shift+L [Mac]
如需在中文环境下阅读这份文档, 请点击此处.
The “Basics”
If we reduce a multiplayer platform down to the most basic level, there will be only three elements remain:
- Player: The human being from the real world who plays inside the container called space.
- Object: Every non-human substance that appears in the container called space.
- Space: The most basic container of everything. A platform is made up of numerous spaces.
Space
In the definition of Project Touch, the space is a basic unit that the system offers to a player to display and exhibit all sorts of objects. A well-designed space should have the following features:
Macro
- Every space should have an owner. The owner can be an individual player or an organization.
- As the “basic unit” container, any space should have the same feature set consistently, regardless it belongs to an individual or an organization. This will help maintain the information architecture light-weighted and hence will help a player to understand how the world works in a short time.
- For example, the typical “tutorial mode” can also be a space. After the tutorial, a player can be teleported to their personal space.
- We don’t recommend adding nested space (e.g., a space within a space) to the world in the early adopting stage. The idea of nesting usually causes confusion among new players. It would be better to introduce it later when the platform already has a solid player base and most players are well-familiar with the world mechanism.
Privacy
- From the perspective of an owner of a space: each space should have at least two states - public and private. An analogy to understand these two states is: we can think of the door of an apartment in the real world. When the door is open (public), the owner welcomes other visitors; when the door is closed (private), the owner of the space is still editing the contents of their apartment.
- From a visitor's perspective, all the visible spaces should be accessible since we already hide all the private spaces from being surfaced to them.
Commute
- Spaces should be connected using portals. For information on designing the interaction of placing portals at a micro level, see the 'grabbing' guide in chapterKnob
- Portals can help a player quickly establish the concept of information architecture on a macro level. This is another reason we do not recommend adding nested spaces too early - nested spaces might require a different design for the entrance rather than a portal (since you're not commuting on the same level). And the design of the entrance will have a direct impact on how a player comprehends what’s inside and outside of the “door”.
Interior Design