A new wiki is coming!

This wiki will be locked for editing on Friday, March 13, 2020, while we upgrade to a new wiki. Here is more information about our migration process.

This box searches only this space. The box at the upper right searches the entire iPlant wiki.

Skip to end of metadata
Go to start of metadata

1. Write programs for people, not computers.

Miss Naomi was able to send the team her project as well as the coding necessary to complete said project. The code for the game was broken down into multiple files, each with multiple functions. However, each file was named specific to the “actions” that were to be taken when executed in the game. For example, files were named based on the functions the creators wanted the users to execute while playing their game, such as naming a file Grab1 or Grab2 and EmulateHeadRotation. Because of this, readers definitely do not have to memorize huge chunks of code at the same time to understand the program. Instead, they can read a file for this project and understand what is going on based on the name of the file and know instantly that the code written is for that portion of the program solely. 

Speaking of naming files, every function, class, and file had a specific name to it which makes each process of building this game, indeed, very meaningful. Each file had a meaning to the project and each played its own part in finishing this project. 

As for the style and formatting, everything seemed very consistent when writing the program. Each function or class used comments that would help a reader understand what the goal of the code was or what was being executed with that line of code. It is to be noted that because writing programs require specific and careful syntax, it would seem that this could be a bigger reason as to why the actual code looked consistent in the first place. I am still new to programming, but I was able to comprehend most of the code while browsing through each file. These files had a pattern where they would import other files, create a class, explain the class in comments, and then add onto the file in order to enact specific actions inside the game. Examples of the code would look like this:

public class Grab1 : MonoBehaviour


    private bool isGrabbing = false;     //A variable to hold if the user is grabbing a grabbable object

    private Transform grabbedTransform;  //A variable to hold the transform of the grabbed object

    public float zSpeed = 4.5f;          //A variable to hold the speed of bringing an object near the user in z-axis (adjustable)

    private Transform hitTransform;      //A variable to hold the hit object's transform for color change & outlining

As you can see, the programmers are very detailed in their code and want the users/readers to understand their thought process.

Overall, the team who worked on this project did a great job in making sure the programs were written for people and not computers. Everything, at least from a beginner programmer’s eye, seemed thought out and consistent.

2. Let the computer do the work

In unity, code can be run every frame. Taking advantage of this, the team checked every frame for a condition or make sure a certain variable remains constant by adding a single line of code and running it every frame. 

public class BlobShadowRotation : MonoBehaviour {

          void Update (){

        //Updating the forward (blue axis) of the blob shadow projector

        //as down, so that even when the game object is rotated, the 

        //shadow is projected on the correct plane (downwards)

        transform.rotation = Quaternion.LookRotation(Vector3.down);



Many parts of the final project were parts used in earlier homework assignments. The scripts for ray casting objects were used several times. For example, IsHit_S.cs was used on all grabbable objects and the same texture was used on multiple game objects. 

public class IsHit_S : MonoBehaviour {

    public Color originalColorVar;

              void Start () {

            //We are storing the original color of the gameobject to which this script is attached

            originalColorVar = transform.GetComponent<Renderer>().material.color;



However no build tool to automate workflows was used. Since the team lacked a github workflow due to unity’s issues with keeping track of assets, some team members would have to code on their own computer, send the files via email to the person working on the main project, then switch over to the project computer to recreate the steps--which typically consisted of creating new objects and attaching the scripts on them. Finding a better system that would lessen the amount of repetitive tasks such as storing certain files in a cloud and letting one person add work on the GUI, rendering objects and attaching the newly created scripts. 

3. Make incremental changes.

The team had feedback from testing periods that led to changes in monster movement and this in turn led to more advanced features later on. One problem occurred when players with no VR experience were trying to figure out the movement controls. The monster was too fast! Other more experienced players found the game to be too easy. The feedback led to a complete change in the way the enemy movement worked. As the player found the object needed to win the game, the monster’s movement would increase. 

Before the final version of the project was completed, another testing phase during the iShowcase allowed for more valuable feedback. Only then were the nicer features added such as score tracking and sound effects. 

The version control system consisted of naming conventions such as TermProject_2.0. The team could have taken the time to get unity and github working and this would make keeping track of changes a lot easier. 

4. Don't repeat yourself (or others).
 The team effectively modularized their code. They split up code by its functionality that could easily be identified and later reused or repurposed. For example, they separated the GUI code from game-play code. This allows all team members to easily access and work on specific sections of the project without causing some inadvertent error in other pieces of code. As a consequence, this modularization allowed for streamlined workflow and efficient collaboration in the project. Below is a picture of their modules:

They reused code when possible. The team used code from previous course assignments that tackled similar tasks as the ones in their project. This greatly sped up the development of the project and reduced errors by using their code that they knew worked.

5. Plan for mistakes. 

The team did not include assertions in their code, but they seemed to check operation frequently to make sure individual blocks worked and worked when combined with existing code (unit/integration tests). 

The team used Unity, which could be considered an IDE - it has built-in means of manually unit-testing and a built-in debugging console, though the team did most of their debugging manually. Mainly, they commented out chunks of code and utilized print statements as a means of debugging. 

6. Optimize software only after it works correctly. 

The team generally followed the practice of focusing on improving code only after it worked on a foundational level. For example, after the code for the movement of the games’ monster was implemented a lot of time was spent trying to get it to behave ideally - and after the code for the player’s grabbing was implemented the team spent a good deal of time trying to spruce it up with advanced features. Both of these efforts had to be abandoned after consuming too much time in favor of other endeavors, and this could be considered an identified bottle-neck, albeit not found via a profiler.

They used a profiler tool known as poly count (which is included in Unity) as a means of identifying resource-hogging assets, which made sure their program could run smoothly with a stable framerate which is important in games. 

The team wrote code for the game in C#, a high level programming language. 

7. Document design and purpose, not mechanics. 

 Most of the scripts for the Unity project is well documented. A detailed description is included at the beginning of the scripts (see an example below this section). Also, as it is mentioned in Section 1 by Jennen, code was divided into multiple files based on the game actions and each of these files were named based on the same. It is pretty understandable from files names, what each script does. Embedded documentation and code refactoring was not used for this project. 

Example code for document interfaces and reasons:

using System.Collections;

using System.Collections.Generic;

using UnityEngine;





   //Press C while the Game View is active, rotate the Oculus Go controller with the left mouse button

  //Grab objects by hovering and clicking down the left mouse button

  //Scroll up and down the mouse wheel to move the grabbed object in z-axis

  //Move in the virtual world with the WASD keys

public class EmulateGrabMove : MonoBehaviour

{   ……...



8. Collaborate.

The team did not do any pre-merged code reviews, i.e. reviewing code before committing to the master node, and no version control system was used for the project. The team tried to manage without a version control system by creating backups before importing new assets/incorporating new code to the main computer. But no code was reviewed before merging to the master node. As the code reviews are the fastest way to find bugs in the code, it should have been used to improve the overall quality of the code and get the job done faster.

The team did not use any issue tracking tool for the project. Instead of using an issue tracking tool, the team spent a lot of time looking at the same screen, testing and face to face interaction to stay on track. Once the team is working remotely or grows beyond a certain size, the project will be not manageable without everyone reporting/tracking issues. In larger teams, it becomes necessary to reduce the communication gap and get the right person to fix the issue.

Pair programming was done a lot as the Unity project team worked most of the time in the lab together. After getting stuck on a problem, two students worked together on it to resolve it faster.

Overall project grade:


Post-mortem analysis

Good: Everyone worked on their assigned section and completed it on time. Communication was good on Slack.

Bad: Maybe meeting in person a bit more could have helped everyone understand the project and why certain methods were chosen. 

Ugly: N/A

Change: Slack notifications can be finicky. Team members should make sure they are being notified about new messages on group channel.


Team members: 

Reetu Tuteja

Naomi Yescas

Jennen Maryniak

Hayden Dunn

Emmanuel Gonzalez

  • No labels

1 Comment