Submit Assignments

Complete Assignment

*Always save any open files and fully test your assignments before submission. We cannot grade what we do not receive. You will not receive credit for work that doesn't function. Your work should generate zero red errors before, during, and after playtesting all functionality of your game.

Whenever you complete an assignment, you will upload it for grading using source control. The source control solution we will use is GitHub, a widely-used industry standard service built on top of Git.

Disable Unity Collab*

*SPECIAL CIRCUMSTANCE: This step only applies if this project previously used Unity Collab, which is the old version control service that Unity has retired.

Open the Services tab via Window > General > Services. Scroll through this window and make sure Collaborate is OFF.

Disable PlasticSCM*

*SPECIAL CIRCUMSTANCE: This step only applies if this project previously used Unity PlasticSCM, which is the version control service that Unity launched to replace Unity Collab. We will not be using it in class though.

Open Window > Package Manager.

Find the Version Control entry under "Packages: In Project". Click Remove.

Confirm removal of the PlasticSCM Version Control package.

Log In to GitHub

Visit the website https://github.com/.

You will need to create an account and log in. You will be asked the usual mix of account setup questions. Once you are logged in, you will arrive at a home dashboard where you will be offered the option to create a repository. A repository is like having cloud storage where you can upload and sync your project.

Create Repository

On the Create Repository form, there are several fields we will customize to meet our project needs. Use a repository name that matches the naming format of projects for your course such as "VG1_LastnameFirstname" or "VG2_LastnameFirstname". Making your repository identifiable is very important for receiving a grade.

You should keep your repository private, otherwise anyone on the internet will be able to copy your work.

Unity projects generate a lot of temporary files that do not need to be uploaded. These may be files that are needed only for your computer specifically and aren't meant to be shared to other computers. A gitignore file is a list of files to exclude when uploading to the repository. We will use the Unity gitignore template to avoid uploading unnecessary files to GitHub.

Once you've created your repository, you will arrive at a page listing all of the files currently in your repo. Notice that it is just the single gitignore file. We are going to make a change to this gitignore file to make it more flexible for our class needs. Click the file to explore its contents.

You are able to examine the contents of any file uploaded to your repository. Text-based files can also be edited. (GitHub frequently revises their templates, so your .gitignore may differ slightly from this screenshot.

Click the edit icon to make changes to your gitignore file.

Change the lines pictured below by removing the "/" (slash) at the beginning of each line. When the slash is present, the gitignore only excludes these folders when they are at the root of the repo. We want to ignore them even if they are in subfolders. Removing the slash will configure this change.

When you make changes, you must save them to the repository. This is known as "comitting" a change. Always leave an explanation for what changes you are making. It can be very confusing in larger projects to have unlabeled entries in your project history.

With your repository created in the cloud, the next step will be setting it up on your local file system.

Install Git Client*

*If you are well-versed in Git, you are welcome to use any alternative clients and tools you prefer. We will not be able to offer support for other tools in the classroom.

Visit the website https://desktop.github.com/.

Download and install the version of GitHub Desktop appropriate for your computing platform.

Upon running GitHub Desktop, you'll be presented with the login screen.

Sign in to GitHub.com. Click "authorize desktop" to grant GitHub Desktop access to your GitHub account.

You will be asked to configure your git identity. When you modify your files, those changes to your project are tracked. In the screenshot, you can see that the history of a Git project will list who made changes along with comments on the nature of the change.

Clone Repository

In order to work with your online Git project, you will need to clone a copy of it to your local hard drive.

On the next screen, you'll be offered a few different ways of creating a Git project on your local file system. Because we already made our repository on GitHub.com, select "Clone a Repository from the Internet..."

Since we are logged into our GitHub.com account already, your project should already be listed for convenience.

An additional option for choosing a project to download is to use the URL for the project.

The URL can be found under the Code dropdown on the project's webpage. Either approach, should result in the same project being downloaded to your hard drive. The URL approach can be useful for accessing projects created by others.

Understanding Git

If you examine the folder created on your hard drive, it may appear empty. (dot files like the .gitignore are hidden by default on Unix operating systems like MacOS.)

Within the GitHub Desktop interface, you'll also notice that it lists no local changes have been made to your repository. At this point, your local copy of the git repository matches the online version.

Here is a simplified diagram of how files are handled within a Git project. (Source: https://kelvinleong.github.io/git/2017/01/20/Use-Git.html)

These are the components labeled in the diagram:

There are some common operations within the lifecycle of a Git project:

  1. Clone - Make a local copy of a remote repository.
  2. Checkout - Choose the active files for your working directory. (Often in the form of switching branches, which is an advanced technique not required in this course.)
  3. Fetch - Compare with the remote repository to see what changes can be sync'd.
  4. Pull - Download the latest changes from the remote repository into your working directory.
  5. Add - When you modify your local files (in the form of new files or changed files), we gather them in the staging area.
  6. Commit - Finalize changes that have been gathered in the staging area as part of the repository's history.
  7. Push - Upload our local changes to the remote repository.

There are many additional Git commands and features you may eventually learn. A highly-developed team process can lead to some complex project organization as can be seen in the example diagram below. My starting advice to you is KEEP IT SIMPLE. Let the tool serve you, and do not add unnecessary complexity to a short-lived starter project. Every version control solution has its own nuance, and each team will have their own organizational processes for how they manage their projects. Learning these different tools and approaches is an ongoing journey.

Overall, your process this semester will be as follows: 1) Fetch. 2) Pull. 3) Add your work. 4) Commit. 5) Push. 6) Repeat. Lets give this process a try in the following steps. We have already performed a Clone and Checkout, and we will not have to repeat those steps again unless setting up a new project.

Fetch, Pull, Add, Commit, Push

Before we move our Unity project into our repository, we need to make a couple configuration changes. Within Unity, open Edit > Project Settings. In the Editor category, set Asset Serialization Mode to "Force Text". Text-based files are easier to manage when there is a merge conflict with your repository. A merge conflict happens when two teammates edit the same file causing a desynchronization between the various repository copies. The best way to avoid a merge conflict is to communicate and take turns editing files instead of editing the same file at the same time. Because of the creative and subjective nature of video game edits, many merge conflicts cannot be resolved. The best policy is to avoid them before they even happen.

Within the Version Control category, change Mode to "Visible Meta Files". In addition to the assets you consciously add to your project, Unity will generate configuration files for each asset. Making these configuration Meta Files visible makes it easier to track them in the repository.

Next, we are going to move our Unity project into the repository.

YOU MUST CLOSE UNITY FOR THIS NEXT STEP.

With Unity closed, move all your project files into the Git project folder. You will make future edits in this new project location. Any time you move folders around, you may need to re-add the project to the Unity Hub or the GitHub Desktop interface.

Now that your Unity files are in the Git folder, these files appear as upcoming changes to the Local Repository in your Working Directory. You can change what is considered in Staging via the checkbox next to each change. You can also view detailed changes per file.

Below your Staged Files is a box where you should label the changes. ALWAYS label your Commits. It can be very difficult to understand a project's history without descriptive commits. Click Commit to apply these Staged changes to the Local Repository.

After committing your changes, you should see that there are 0 changed files remaining in the Working Directory.

When you peek at the History, you should see a timeline of all the changes to the Local Repository. Here, you can see why descriptive commit messages are helpful.

You can explore the details of each commit to see individual file changes in the project history. If you view a project file on GitHub.com, you can even see the entire history of an individual file.

So far, all of these changes have been done to our Local Repository. None of these changes have been sync'd to the Remote Repository, and our teammates will not yet see any of our work. Notice in the upper-right corner that we have changes to Push. (GitHub Desktop sometimes Fetches automatically. This is a harmless automation because the Fetch command only gathers repository status and does not actually change any files.) Click Push to upload your changes online.

Once you have Pushed your changes, you will have no other commits to Push, and the button will only say Fetch. You can try pushing the Fetch button to check for updates from the Remote Repository, but since no one else is making changes right now, there should not be any. In the next step, let's simulate working on one project from multiple computers.

*Simulated scenario: In this next screenshot, I made changes to the Remote Repository from a different computer. From the perspective of our first computer, our Local Repository has 1 Commit to Pull from the Remote Repository. These are new project changes that were made from another device that we want to sync to our first computer. You may have to Fetch in order to see the Pull option.

By clicking Pull, the remote changes will be downloaded to our Local Repository, and our local files will now be sync'd with the Remote Repository. The changes from the second device will now be present on our original computer.

This back-and-forth process of 1) Fetch, 2) Pull, 3) Add Changes, 4) Commit, and 5) Push will keep your project sync'd amongst your teammates. The smaller and more frequent your commits and sync (push/pull) operations, the less likely you will have file conflicts with your team.

Invite Members

Now that your project has been uploaded, we need to share it so that it can be graded.

Return to your project home page on GitHub.com. Click Settings.

Click Collaborators.

Click "Add people".

For your class exercises, add the grading e-mails for your course section listed on Canvas. For your group project, you will want to add your teammates instead.

Confirm adding the user to your repository.

Your invitee should receive an e-mail to confirm the collaboration, and all parties will have access to the project!

Access Project on Other Devices

OPTIONAL: This step is as-needed and is not part of the prior sequence of steps.

When you want to restore your project (such as when using a different computer), you can download the cloud copy of the project to your local hard drive by installing GitHub Desktop and accessing the project through your account or via URL.