This project consists of two main structures. The first is the Meta Multiplayer for Netcode and Photon package, which provides core reusable code for starting a new multiplayer game project with similar configurations. The second is the Decommissioned app, which builds on the Meta Multiplayer base to implement specific game logic.
We also have a package of common utility functions that accelerated our project implementation. These utilities are located in Packages/com.meta.utilities.
To extend Photon Realtime for Netcode, we copied the package to Packages/com.community.netcode.transport.photon-realtime.
This package contains project-agnostic logic reusable in any networked multiplayer project. It includes key features from our Platform Social API.
- BlockUserManager.cs implements the blocking flow API.
- GroupPresenceState.cs manages group presence API usage, enabling easy player collaboration.
- NetworkLayer.cs handles client/host connection flow, disconnection, and host migration.
The networked Avatar implementation is crucial for integrating personality into a project and demonstrates how avatars can be easily integrated (Avatars).
This section covers the game's specific implementation. Key components and systems are highlighted, but exploring the code is recommended for a comprehensive understanding.
The Application.Core and Application.Oculus.cs scripts set the app's initial state at launch. This includes initializing the Oculus Platform (user account, avatar, guardian boundary checks), group presences, and connecting to lobbies if the app starts via an invitation.
The MainMenu.cs script provides API calls to control the app's user flow, used in the MainMenu scene post-startup. It includes methods for launching a new match, joining an existing one, or exiting the application.
The Game directory contains gameplay logic for matches in the Lobby scene. Key systems and components are highlighted below.
The GameManager singleton manages the game's current state, including player limits, round count, victory conditions, and match progression.
A match progresses through four phases, each with specific objectives. The GamePhase directory manages and updates the current game phase.
During a match, each player receives a PlayerRole defining their goals. The RoleManager singleton assigns roles and adjusts player role thresholds.
Players vote to assign others to Mini Games. The Voting directory manages and stores vote states.
Decommissioned features six unique Mini Games, each with distinct tasks per round. The Minigames directory contains related scripts.
The Minigame script manages each minigame's configuration and state, found in all Minigame Prefabs.
Players move to specific GamePositions as the game progresses. The LocationManager component stores these locations and provides access methods.
The Player directory contains logic for managing players in a match. Key components are highlighted below.
The PlayerStatus component tracks a player's status, determining if they are the current Commander.
Players are linked to a specific GamePosition during matches. The PlayerSpawns component stores and accesses player locations.
The PlayerVoip component manages voice chat, allowing players to be muted or unmuted.
Upon match connection, each player receives a color-coded armband for audio settings, help menus, and quitting the game. The PlayerArmband component manages its appearance and functionality.