Assignment 4: Multiplayer Extension

---

Project Description

In this assignment you will take the single player game platform you produced in Assignment 2 and 3 and extend it into a multiplayer game platform that connects players on at least two machines by a local network. You will continue to work in the same teams as Assignment 2 and 3 unless special arrangements have been made.

The basic requirement of this assignment is to make a game playable between multiple players connected by a network. By the end of this assignment, you will have a game that has both single player and multiplayer modes. In multiplayer, each player will have their own machine, controls, display, etc, but the game will be played in a shared environment. The actual game design is up to you, but make something that's sensible for both modes of play.

The "game technology" extension is to add in some advanced networking feature to handle one of the situations discussed in class (e.g. grid/aura systems, massively multiplayer handling, low-level socket programming, security concerns, etc).

Basic Requirements

• Multiple game states

  Since you will have a single-player and multiplayer mode, you will also need a menu system to help players start or join games. Consider what you need to have in terms of code architecture and GUI systems to handle this. The GUI can be done in C#, but you should consider strongly putting any underlying complexity into GDExtension for flexibility/efficiency.

• Lobby system

  You will implement a lobby system for your multiplayer mode. The lobby system will allow a player to set up a server which at least one other client can connect to. Players will join during this lobby phase, and they will provide the server with their preferred player name and any other character info the game requires. When the game is ready to start, all players who have joined will be transported into the game automatically. You can decide how/when the game should start. This should be set up in GDScript initially to prototype your working game, but depending on your advanced system, you may need to push this into GDExtension for the second phase of the project.

• Player changes

  You will gracefully handle players joining and disconnecting during a game. This means a player should be able to connect to the game after the lobby is closed (assuming the game has not reached its player cap). When a player joins an in-progress game, they will still provide their player name and any other character info required, but then they will be immediately dropped into the current game. You can decide how/where a new player should enter the game. You will also need to ensure that the game does not crash/break if a player is abruptly disconnected from the game/lobby.

• Game end condition

  Define rules of when a game has ended. In singleplayer, this will return the player to the main screen. In multiplayer, this will either return everyone to the lobby or ask if players want to rematch. You can choose the behavior -- just make sure it is consistent and robust.

• Engine extension

  Create a networking-centric extension for your game in GDExtension. This feature should address any one (or number) of issues we discussed in class. You will be evaluated based on the complexity of your problem and the quality of your implementation. So simpler problems require more elegant solutions.

Extra Credit

• Replicated Animations (2 points)

  If you have a 3D character with animations, replicate those animations across the network for client players to see. Animations should not be consider critical information, so you should send these unreliably.

• 3-4 Player Support (1 point)

  Support more than two players in a multiplayer game. You will still recieve extra credit for more than 4 players, but I wouldn't recommend trying it on your first pass...

• Even More Particle Effects (2 points)

  Just keep adding these in! But now with network replication!

Milestone 1

The milestone will be a substantial part of your grade, as this class is about planning and organization. Thus you will want to put in a significant amount of effort on the milestone documentation. I'd recommend starting as soon as possible to come up with a plan and a division of labor then flesh out your documentation as you realize you are encountering unexpected issues/situations.

1. Documentation: You will turn in a document with the following information:
   • Overall design of your network. How are you thinking about the client-server system? What information will be reliable/unreliable, and when will you send it? What is the user flow for joining/leaving a game? Consider these and other questions that arise while planning your networked player experience.
   • Software architecture and plan. How does you structuring of scenes/classes help you implement networking? How are you keeping track of game state, and how will the client machine know when that state changes? Estimate how much work it'll take to incorporate each of the required capabilities. If it looks like you won't be able to meet your deadline, how can you scale back during the second week?
   • Engine extension. Describe the problem you'll be solving and the engine extension you'll be incorporating in your base game to solve it. Include a plan for what code structures are necessary and how you will create a tool for solving this problem in a scalable, flexible way.
   • Division of labor. In terms of the delivered capabilities, who is responsible for which parts of the code, and what is your plan for meeting up? My experience is that teams who meet up and code together on a regular basis create a more cohesive, functional project than teams where everyone works autonomously and tries to come together at the end. Keep this in mind during your planning stage.

     Note that you should also specify who has done what at this point in the project. Since the milestone is now a substantial percentage of the project's grade, your milestone grade will be adjusted based on your contributions to the code base during this phase of the project.

2. Project Demo: You will also link an initial demo of your proposed game for Milestone 1.

   This demo can be simple, but we should see a working prototype in GDScript so we can gauge whether or not you're on track.

   Please include some video footage showing your game in both client and server modes. You may want to include some subtitles explaining what's happening in the footage you are showing.

Final Submission

You should turn in a link to your git repo as you did in the previous assignment. Make sure you have your file structure and SCons files set up correctly to minimize build pains. Please also make sure you included all relevant files, including those related to the Godot project, the C++ bindings, and your own source/library files. Also include:

• A README giving full build instructions and version info
• A user manual explaining how to play your game, game objectives, and any extra-credit worthy features
• A final project report that details and explains how you implemented your system with relevant screenshots of the corresponding code, and places where you've managed to do better or worse than you had planned and why.
• Individual Evaluations which each member of your team will turn in separately (not as part of the team's game package) an evaluation of the performance of your team on this project, your strengths, weaknesses, what you'd do differently if you were starting again, the main things you've learned. The evaluation must include a specific evaluation of your own performance and that of each of your team members (again both strengths and weaknesses). This will be kept confidential and will be taken into consideration in grading.

Getting Started

You are allowed to prototype with GDScript to get things working, but for more advanced features, you may want to extend/use Godot's ENet wrapper, ENetMultiplayerPeer, which will handle much of the lower level details for you.

It will not be necessary for your code to manage more complex networking issues like connecting through firewalls or across NAT routers, but keep in mind those things may be issues depending on your teammates' home situation (if you have issues, you may want to test on a local network/hotspot). I would start by working with server and client on the same machine and testing functionality locally before trying it across a network.

This networking development will focus on player experience, so you should take time to consider:

• Number of players your game will support
• How and what you will communicate between server and client
• What the server should verify when considering a client's request
• How you will handle players with faulty connections, who may need to disconnect/reconnect during the game

In terms of the nextworked game mode, once connections are established, each instance of your code will manage the game on behalf of its local player. You must be careful to maintain a consistent view of the shared game environment across all players. There are several ways you can do this:

• One is to designate one machine as the server and all others as clients. The server machine will receive command inputs from the players via the clients, and it will then update the game state and transmit the results back to the clients. This is a simple way to be sure that the game state is consistent for all player at all times. It has particular advantages when using a physics simulator, since objects whose motion is determined by physics simulation tend to diverge when run on different machines within their individual rendering loops. This is the model I'm expecting you to work under, but you are welcome to consider the others.

• Another way is to have different game objects be managed by different peers, who then communicate with the other peers to update the state of the game objects they are managing. So, for instance, each peer could manage the player object for its local player. Shared objects like balls, scoring targets, etc. can be apportioned, but in this scenario each is managed by only one of the peers and state is communicated to the others. This also will avoid inconsistencies with multiple instances of a physics simulation producing different results for game objects these instances are updating in parallel.

• Another possibility is to run simulations in parallel on the peers, limiting communication of state information as much as possible. A design like this will require extra care to make sure simulation results don't diverge for various players and is therefore not recommended.

In terms of software architecture, making networking tractable will require a bit more consideration of the overall architecture of your code than the previous assignment did. If you haven't already, you should strongly consider abstracting your game objects and control interfaces to allow event-based messaging at a level that treats local mouse/keyboard command inputs and remote network-sourced command inputs the same way. Likewise, other message events conveying information between game objects should treat the network transparently. That is to say -- the underlying code should not change for single versus multiplayer modes.

Likewise, you should consider a systematic approach to separating your code's behaviors according to the global game state or mode. For instance, if you are interacting with the user via UI screens, that's a different mode than if you're in the middle of "combat". User inputs are directed to different parts of your software in each mode, and the rendering loop is putting different stuff on the screen in each case. Since you'll be in at least two UI screen modes at the beginning of the game when choosing game mode, establishing connections (and possibly setting up other game parameters), you will have at least three modes on interaction (include game UI and controls) in your project.

You may be tempted to make general upgrades to your game in addition to the basic networking requirements outlined above. Perhaps you didn't finish some things last time. Perhaps you finally figured out what you want to do, or how to do it. Such upgrades are cautiously encouraged, provided you make your first priority getting the basic requirements done. Any additional upgrades will be considered for extra credit to mitigate points lost on Assignment 2 and 3.

Turning it in

We'll use Canvas as with previous assignments. Only one teammate needs to turn in the assignment (and milestone) linking to your git repository's code-freeze branch. Please make sure you README on the git repository includes (or links to) the final report (including screenshots, code details etc), as well as a link to video footage of the final project. Be sure to add both me and the TA to the repo. If you have concerns about your team mates' contributions, please contact me directly and I will try to address them.

Grading

Grading will be handled the same as Assignment 2 and 3: C quality work is implementing the features in a way that is mostly working, but may be buggy or not scalable. B quality work is implementing the features in a way that works but may have scaling issues, or lacks consideration for tuning and iterating. A quality work is implementing the features in robust, polished way that demonstrates consideration for tuning and scaling.

Make sure you meet the requirements before doing additional enhancements. And when considering enhancements, realize that improving the UI/networking robustness/gameplay/etc is generally a better place to spend your time than adding bells and whistles. If you end up showing this off to people later, you'd much rather they get involved in playing it than for you to have to look over their shoulder to show off your special effects while apologizing that you never actually got it to a playable state.

---

Last modified: 10/22/23 by Sarah Abraham theshark@cs.utexas.edu