Home

Awesome

Unity Multiplayer Playground 2D

Featuring 2D via Unity's Netcode For Game Objects (NGO).

<table> <tr> <th>YouTube Video Overview</th> </tr> <tr> <td> <a href="https://www.youtube.com/watch?v=G-AliHieYz4"><img width="500" src="https://img.youtube.com/vi/G-AliHieYz4/maxresdefault.jpg" /></a> </td> </tr> </table>

TLDR;

Table Of Contents

  1. Getting Started
  2. Overview
  3. Details
  4. Resources

Getting Started

  1. Download this repo (*.zip or *.git)
  2. Download the Unity Editor (See Unity Version below)
  3. Open this repo in the Unity Editor
  4. Choose one of the Scenes...

Overview

Features

Starting Point

This repo started as a fork of my own Github.com/SamuelAsherRivello/unity-project-template project. It contains "Unity Best Practices for Project Structure and C# Coding Standards". It is a recommended starting point for new projects.

Ending Point

This repo includes various versions of similar gameplay. There is a playable character and a crate in a playful environment. Use the arrow keys to move.

The demos required 8-10 hours total, from initial planning through completion of development.

Notes

The client-authoritative approach represents a quick and dirty way to get started and prototype, while the server-authoritative approach represents the real-world solution path for a commercial multiplayer game. But I like the academic challenge of exploring both at the same time, adding features, and keeping feature parity. For future prototypes, I'll likely use only server-authoritative.

Apparently, the "com.unity.netcode" package creates a "DefaultNetworkPrefabs" asset. No problem. However, its created at the root of the Assets folder, and it cannot be safely moved to a subfolder. I don't like that.

Challenges

I enjoyed iterating on the game versions from single-player to server-authoritative multiplayer, but there were some challenges along the way.

  1. Choosing to create multiple versions at once introduced some organizational and structural challenges. I first tried to keep each version's assets completely distinct. But that proved to be too much of a redundancy (e.g., copies of Sprites). So, I chose the Game folder vs Shared folder approach. Works well.

  2. Between the multiplayer versions, it would be intuitive to have my custom classes extend each other (e.g. PlayerCA.cs and PlayerSA.cs extend some non-existent BasePlayer.cs), but I chose to keep the custom class structure flatter and simply duplicate logic via copy/paste. This way, each game version is (more) self-contained.

  3. The QuickLobby is purposefully lean. It has some bugs when (very rapidly) joining/quitting with many app instances.

  4. The QuickLobby is purposefully limited. It supports multiple app instances running on only one PC. A more robust version would allow each player to be on a unique PC. Using Unity's optional services (e.g. Matchmaking, Lobby, Relay) would help.

  5. I notice bugs if I spawn an app instance and leave it open, then continue to do more development and play the newer Unity Editor vs. the older app instances. I think the NetworkObject IDs of the crate, for example, fall out of sync. Rebuilding all app instances solves the issue. I'd like to know more about workarounds to understand exactly when rebuilding a new app instance is really needed and when it's not.

Possible Improvements

With infinite time, some additional improvements can be made. Some would be especially fun.

  1. I'd like to have a unique character appearance per app instance. Solution path, likely: Don't automatically spawn a player prefab. Instead capture the player connecting and spawn a unique prefab per player. Using a base player prefab and per-character player prefab variants could help the workflow.
  2. I'd like to show all player's scores onscreen for all app instances. Solution path, likely: Have the host listen to a NetworkVariable change for the score for all clients, and then concatenate the results for display onscreen.
  3. I'd like to make a build tool that when I hit Control-B to build, it automatically puts the currently active Scene as the FIRST index in the build settings. This would facilitate multiplayer testing so the active Scene in the Unity Editor matches the active Scene in the built app.

Bonus Content

The supporting material (video & slides) required additional creation time beyond the timeline for the content above.

Details

Documentation

Configuration

Structure

Dependencies

Resources

Links

Best Practices

Unity Web3

Unity Courses

Created By

Contact

License

Provided as-is under <a href="./LICENSE">MIT License</a> | Copyright ™ & © 2006 - 2024 Rivello Multimedia Consulting, LLC