Project

Jump to current week

Introduction

For the team project, you will build a real-time massively multiplayer online (MMO) game. You have a large amount of freedom in the design of your project as long as it meets the criteria outlined in this document.

The term "game" is used fairly loosely here. If you have an app idea that is not technically a game, you might still be able to build it as long as it satisfies all the requirements.


Team Formation


If you are forming a team, please use the following form to let us know the members of your team, your public GitHub repository link, and your team name. Teams must consist of either 4 or 5 members. If you have a team of 3, you must find a 4th member to agree to be part of your team.

Team Formation Form: https://docs.google.com/forms/d/e/1FAIpQLSfVOpVZRhIanL66FFp7ZwsjkZUIH-T21W57pvUSM_Y2OBIIUA/viewform?usp=dialog

If you prefer to be placed on a random team instead of finding your own teammates, please fill out this form. When you are notified of your random team, via email, please fill out the team formation form letting us know your chosen team name and GitHub link.

Random Team Form: https://docs.google.com/forms/d/e/1FAIpQLSeXZGfnOcWILZ50GPdtDtcKrK7LFxddgbA6H9eIt8DhqV2-3w/viewform?usp=dialog

Anyone who is not part of team and didn't fill out the random team form will be placed on a random team after the team formation deadline.


Meeting Forms and Individual Grading


You must fill out the team meeting and eval form for each week of the project. There are 4 weeks for the project so you are expected to have at least 4 submissions of this form. These are submitted on an individual basis and must be completed by each team member. You are expected to meet with your team [at least] weekly and fill out the form after each meeting, though you must still fill out the form even if there was no meeting (Where you should explain why you went a whole week without meeting).

All the AO grading described in this document determines your team score for the project. Your actual grade (number of AOs earned) may be adjusted based on your individual contributions to the project. These decisions will be made on a case-by-case basis at the discretion of the course staff. Factors used to determine these adjustments include:

  • Your team meeting and eval form submissions
    • You must fill out this form each week. Failure to do so is an easy way to earn a negative individual grade adjustment. Since there are 4 weeks for the project, you are expected to have at least 4 submissions of this form. Anything less than 4 will result in a grade reduction
    • The quality of your submissions will be taken into account as well (eg. Saying "I'll do stuff" before the next meeting is a low quality submission)
    • You may submit more meeting forms than are required even if there was no meeting (eg. If you want to adjust your evals after a deadline without waiting for the next meeting)
  • Your evaluations from the meeting form
    • If your teammates rated you poorly/excellently, your grade may be adjusted down/up respectively. This is not automatic. All cases will be reviewed by the course staff to verify each situation
  • Your commits in the team repo
    • Your commits may be checked to see if you did in fact complete the work you mentioned in the meeting form, as well as compare the amount of work you completed to that of your teammates
    • You MUST commit your own code! It is not acceptable for your teammate to commit your code for you. You should have a clear separation between your tasks and commit the code for your task. If a commit is not in your name, you effectively did not write that code. If a teammate is making this difficult, let the course staff know in the meeting form
    • If you don't have any commits on the default branch of the repo, you effectively did not work on the project and will earn a 0 after individual grade adjustments

Checkpoint Objectives


These objectives are due by the team project checkpoint. For grading purposes, we will check out your latest commit that was made before the deadline. You should continue working on your project during grading of the checkpoint.


Checkpoint Application Objective 1 - App Structure

You have the freedom to choose any web framework or language for this project. However, you are required to use a web framework (You cannot start from a TCP socket. That's what the homework was all about). Examples of web frameworks, and their language, are provided. Any web framework that is not on this list is also allowed.

  • Flask / Python
  • Express / Node.js
  • Django / Python
  • gin / go
  • Play / Java;Scala
  • Koa / Node.js
  • FastAPI / Python
  • Elysia / Node.js
  • Spring / Java

Once your team agrees on a framework, you should build out the foundation of your app using the framework. For this objective, your app must contain the following features and structure:

  • Docker Compose
    • Set up your project using Docker and docker compose. Your app must run on local port 8080 after running "docker compose up"
  • Database
    • You will need a database throughout the project. You may use whatever you'd like for your database (ie. You do not have to use MongoDB), though your database must run in a second container that is separate from your app and started using docker compose.
  • Authentication
    • There should be a clear way for users to register and login to your app. Once logged in, there should be a clear visual letting the user know that they are logged in (eg. Display their username on the home page)
    • Authenticated sessions must be persistent - If a user logs in then you restart the server, they should be able to refresh the page and still be logged in
    • Security: Stored passwords must be salted and hashed
    • Security: Only hashes of your auth tokens should be stored in your database (Do not store the tokens as plain text). Salting is not expected
    • Security: Set the HttpOnly directive on your cookie storing authentication tokens
  • Logging
    • Add the structure for logging on your server and log each request you receive. Logs must be recorded in a local file in the root directory of your project outside the docker container. For example, running the app from your root directory with "docker compose up" should result in a log file being created in that same directory and can be read even after the container stops running (You should use a volume to accomplish this)
    • For each request, log [at least] the IP address of the sender, the HTTP method and path of the request, and a timestamp for the request

Grading Note: If any one of these features are missing or non-functional, the objective is not complete.

All objectives [except deployment] will be tested by:

  1. Cloning your repo
  2. Running "docker compose up"
  3. Navigating to http://localhost:8080/ in a browser and testing all the features of your app

It is strongly recommended that you test your app by cloning a fresh copy of your repo, after the last commit for the deadline, and going through these steps. This will simulate exactly what we'll do during grading and will expose any setup issues you may have. It is common for an app to run in your working directory, but not from a fresh clone (eg. If you have dependencies installed locally in a .venv or node_modules directory). Test your app to make sure it will run during grading.


Checkpoint Application Objective 2 - The Game and Web Sockets

Build a real-time MMO. This game must support any number [within reason] of players playing together in the same instance of your game. You have much freedom in the design of your game as long as all these featured are implemented:

  • Visuals
    • There must be a visual representation of your game. You may choose how users join the game, or if every logged-in user automatically joins the game when they load the home page. When a user is in the game, they should be able to see all other users in the game
  • Web Sockets and Movement
    • Your game must have continuous movement for each player and all movement of each player must be broadcast to all other players in real-time using Web Sockets. This means all players will be able to see all other players' movements as they happen [minus network delays]. All players must be able to move simultaneously (Turn-based games are not allowed)
  • Player Names
    • The username of each player must be clearly labeled for all other players in the game
  • Game
    • Users must have a way to interact with each other that constitutes a game. To be considered a game, for the purposes of this objective, there must be a clear "winner" when the game is played. If the game has an end, all players must know who won the game. If the game does not end, all players must clearly be able to see who is currently winning (eg. By displaying everyone's score)

You have many options for the visuals of your game. You will not be graded on how visually appealing your game is so an HTML canvas with basics shapes will suffice. If you want to make something more impressive though, you should consider using a game framework like phaser.io.

If you're lacking ideas, agar.io is an example of a game that meets all these criteria.


Checkpoint Application Objective 3 - Deployment

Deploy your app on a publicly available server with a domain name and HTTPS with a valid certificate. You may use any means available to accomplish this, though it is recommended that you take advantage of the GitHub Student Developer Pack which includes offers for free domain names for 1 year. You will be provided an AWS instance to deploy your app and add a DNS record for your domain name to point to your instance.

When deployed, add a link to your app in the readme of your repository so we can find your deployment.

Note the following implications of this objective:

  • You will use the WSS protocol for your WebSocket connection. When making this change, be sure that your WS connection still works when ran locally using HTTP since this is how we'll test the other AOs. You might want to create a separate branch for the deployed version of your app
  • Your certificate must be valid. It's recommended that you use CertBot to acquire a free certificate

Security: If using MongoDB, do not map port 27017:27017 for your MongoDB in your docker-compose file. This is a major security risk that makes your database publicly available. Since you are deploying on the Internet in this objective, that means everyone on the planet would have access to your DB and attackers will steal your data. You may want ot map this port for testing purposes in your development environments, but this MUST be removed before deploying.



Deadline Objectives


These objectives are due by the team project deadline.


Deadline Application Objective 1 - Logging

Expand the logging that was set up in checkpoint AO1. Add the following features to your logging:

  • Responses
    • In addition to the request information that is logged, also log the response code sent from your server (eg. 200, 301, 404). It must be clear which code corresponds with which request
  • Registration/Login
    • Log each time a user attempts to register or log in to your app. For each attempt, record the username, if the attempt was successful, and the reason for failure if the attempt was unsuccessful (eg. "admin tried to log in with the wrong password" "pam tried to log in, but that username does not exist")
    • After a user is logged in, add their username to all their logged requests (In addition to their IP)
    • Security: Do not log any plaintext passwords
  • Errors
    • If your server ever throws an error, log the stack trace of the error. You can do this by wrapping your entire server in a try/catch and logging the stack trace in the catch block
    • This will be tested by intentionally writing an error somewhere in your code and making sure the error in logged
  • Full Requests/Responses
    • In a separate log file, log the raw HTTP requests and responses that your app receives and sends. This must be in a separate file since there will be a lot of information being logged that would spam your main lag file.
    • To reduce the size of this file, you may limit the logging to the first 2048 bytes of each request/response
    • If a request/response contains any non-text information, only log the headers of the request
    • Security: Do not log any plaintext passwords. Note that the plain text will be included in the registration and login requests. For these requests, only log the headers
    • Security: Do not log auth tokens. These tokens will appear in request and response headers and they must be removed before they are logged. You should still log the rest of the headers, and the remaining cookies. This will require some parsing to remove only the auth token

Deadline Application Objective 2 - Custom Avatars

Users can upload custom images to be used as their avatar in the game. These images must appear in the game and move with the player's character. You must support at least jpg and png images of any resolution or aspect ratio. If the uploaded image does not fit the aspect ratio expected for your game, you must choose a way to modify the image so it can be used without distorting/stretching the original image (eg. By cropping the image)


Deadline Application Objective 3 - Game Features

Of the following features, add at least 3 of them of your choice to your app:

  • Leaderboard - A global leaderboard. All your users can complete for placement on the leaderboard and the leaderboard must be accessible by all users. You may choose the metric by which users complete. All users must appear on this leaderboard even if they are not currently playing or logged in
  • Player Stats - Stats tracked per account that have some performance statistics (eg. games won). The stats must reflect the users performance in the game. Tracking only things like "games played" or "time played" will not suffice since they don't track anything related to the players skill in your game
  • Lobbies - Add support for multiple instances of your game to be played simultaneously with different subsets of your users
  • Voice Chat - Allow users to talk to each using voice chat while playing your game together
  • Teams - Add teams to your game where players compete as a team. You have freedom in how you define teams (eg. Team death match, something more like guilds, or anything else as long as sub-sets of players work together towards a shared goal)
  • Trade - Allow players to trade some in-game resource with each other
  • Achievements - Add at least 3 achievements to your game. Players should be able to see all these achievements and if they completed each achievement. You may choose what players need to do to unlock an achievements (eg. Reach level 3, score 1000 points, win 10 games, play for 24 hours)

Presentation Objectives


Sing up for a presentation time: https://calendly.com/hartloff/cse312-presentations

You will give a presentation demoing your project and opening it for the audience to test. Your project must be deployed to a live server before your presentation and the audience will use your app during your demo.

Your presentation should be 8-10 minutes. Not all team members have to talk during the presentation, but all must be present and at the front of the room. Any team members who are not present will earn 0 application objectives for the presentation (Having absent members does not affect the grade of those who are present).

Your app must be deployed and publicly available during your presentation. You must share the link and the app must be functional for anyone in the audience.

Your deployed app must be accessible via HTTPS with a valid certificate. There must not be any security warnings (ie. self-signed certificates) when a user visits your app.

If your app is not properly deployed, your team will earn 0 application objectives for the presentation.


Presentation Application Objective 1 - Demo

Demo the functionality of your app from the user perspective. Run your app and show all the functionality of the required features as well as any additional features your team implemented. For any features that are incomplete, you should still mention the feature and the status of development. You can still earn full credit for the presentation even if some features are not complete or functional.

During the demo portion of your presentation, it is recommended that you hide your URL from the audience. Leaking the URL early can entice someone in the audience to use your app during the demo. You should lock up this AO before revealing your URL and moving to AO2.


Presentation Application Objective 2 - User Tests and Logs

After your demo, reveal your URL to the audience so everyone in attendance can test your app. During this test, everyone should be able to play your game without issue. Your app should be able to handle the load of all the users playing simultaneously without crashing or suffering severe performance issues.

Logging: After the presentation, submit the logs of your app that were generated during the presentation to Autolab. These logs must at least contain the required logging from checkpoint AO1 (Requests with IP, method, path, and timestamp).


Grading

Each objective will be scored on a 0-3 scale as follows:

3 (Complete) Clearly correct
2 (Complete) Mostly correct, but with some minor issues
1 (Incomplete) Not all requirements outlined in this document are functional, but an honest attempt was made to complete the objective. This includes issues running Docker or docker-compose even if the code for the objective is correct
0.3 (Incomplete) The objective would earn a 3, but a security risk was found while testing
0.2 (Incomplete) The objective would earn a 2, but a security risk was found while testing
0.1 (Incomplete) The objective would earn a 1, but a security risk was found while testing
0 (Incomplete) No attempt to complete the objective or violation of the assignment (Ex. Using an HTTP library)

Note that for your final grade there is no difference between a 2 and 3, or a 0 and a 1. The numeric score is meant to give you more feedback on your work.

3 Objective Complete
2 Objective Complete
1 Objective Not Complete
0 Objective Not Complete

Security Essay


For each objective for which you earned a 0.3 or 0.2, you will still have an opportunity to earn credit for the objective by submitting an essay about the security issue you exposed. These essays must:

  • Be at least 1000 words in length
  • Explain the security issue from your submission with specific details about your code
  • Describe how you fixed the issue in your submission with specific details about the code you changed
  • Explain why this security issue is a concern and the damage that could be done if you exposed this issue in production code with live users

Any submission that does not meet all these criteria will be rejected and your objective will remain incomplete.

Due Date: Security essays are due 1-week after grades are released.

Security essays are individual assignments. It is important that every member of the team understands the importance of preventing security vulnerabilities even if they did not write the offending code. Multiple members of a team submitting the same, or similar, essays is an academic integrity violation.

Any essay may be subject to an interview with the course staff to verify that you understand the importance of the security issue that you exposed. If an interview is required, you will be contacted by the course staff for scheduling. Decisions of whether or not an interview is required will be made at the discretion of the course staff.