EECS 494 – Game Design and Implementation – Tutorials

Tutorial Assignments

  1. IGDPD Chapter 29

    This is worth 4% of your final grade and is due whenever Canvas says it is due. (This is most likely Wednesday, January 11.)

    Chapter 29 – Prototype 2: Mission Demolition

    Whichever option you choose (singular – no extra credit will be granted for doing both), you must strictly follow both the course setup and submission procedures..

    There is no additional writing component associated with this tutorial, so the Documents subdirectory can be omitted.

  2. IGDPD Chapter 30

    This is worth 6% of your final grade and is due whenever Canvas says it is due. (This is most likely Wednesday, January 11.)

    Chapter 30 – Prototype 3: Space SHMUP

    Again, you must strictly follow both the course setup and submission procedures..

    There is no additional writing component associated with this tutorial, so the Documents subdirectory can be omitted.

Errata

Be aware that updates to Unity have changed the way some of this code must be written since the publication of Introduction to Game Design, Prototyping, and Development. Please see the IGDPD website for some errata. And here's some more:

  1. Application.LoadLevel(...)

    Unity has deprecated Application.LoadLevel(...). In any files where the function is required by the book, instead:

    1. Ensure that a using UnityEngine.SceneManagement; directive is present near the top of the file.
    2. Replace Application.LoadLevel(...) with SceneManager.LoadScene(...).

  2. Directional Lights

    It seems like Unity automatically generates a Directional Light for each scene, so when the book tells you to create a new one, edit the existing one instead.

  3. GUIText

    Unity has made some major changes to their GUI (Graphical User Interface). A redesign of the Create menu now makes it more challenging to create the old GUI elements. Anywhere that the text asks you to choose GameObject -> Create Other -> GUIText from the menu bar, instead:

    1. From the menu bar, choose GameObject -> Create Empty.
    2. With that empty GameObject selected, from the menu bar, choose Component -> Rendering -> GUIText.

  4. Making Enemies Drop Power-Ups (Page 541)

    With powerUpDropChance = 1f, once your ship is fully upgraded it becomes very likely that an enemy will be hit by multiple projectiles in the frame of its destruction. You don't want an enemy to ever drop more than one power-up, so add a bit of code:

    GameObject other = coll.gameObject;

// Prevent additional projectiles from causing a destroyed ship to fire additional on-destruction triggers
if (health <= 0)
{
    Destroy(other); //< Otherwise, extra shots that strike are never destroyed and float in space indefinitely
    return;
}

switch(other.tag)

  5. Enemy_4 (Page 550)

    The settings for the Capsule Collider for Wing_L seem to be incorrect. Try:

    Center:    [0,0,0]
Radius:    0.5
Height:    1
Direction: X-Axis

  6. prefabEnemies

    Be sure to add one of each enemy to prefabEnemies before you turn in your projects to make it easier for us to see that you've implemented all of the enemies in Space SHMUP.

  7. Power-Up Drop Rate

    Likewise, set power-up drop rates high enough to make power-ups common.

Additional Thoughts

Here are some additional thoughts that might help you while going through the tutorials.

  1. Mirrored Editor

    In Unity, you need to view things from the back to have positive x pointing to the right.

  2. Everything is darker after SceneManager.LoadScene(...) is called.

    This is only an issue in the editor. It will not affect your final builds. It's a bug in continuous baking.

  3. return ...

    Jeremy routinely treats return ... as if it were a function, return(...). Since it is not a function, I suggest omitting the parentheses.

  4. ... as GameObject

    Jeremy routinely casts return values for some functions to GameObject even though this appears to be unnecessary. Perhaps it was in a prior version of Unity, but you can generally omit the casts as you go through the tutorials.

  5. Comments

    There are three kinds of comments in the tutorial code:

    1. Great explanatory comments, like you should write in your code:

      // This function will iteratively climb up the transform.parent tree
//   until it either find a parent with a tag != "Untagged" or no parent
public static GameObject FindTaggedParent(GameObject go) {...}

      See how it explains in more detail what FindTaggedParent(...) should actually do? Do this.

    2. Great tutorial comments, which you don't need to write yourselves:

      // Check to make sure that the key exists in the Dictionary
// Attempting to retrieve a key that didn't exist, would throw an error,
//   so the following if statement is important.
if (W_DEFS.ContainsKey(wt))
    return W_DEFS[wt];

      See how it informs you that it's written this way to avoid throwing an exception. This also allows you to realize you could write it try/catch style.

    3. Superfluous comments, which needn't be written:

      if (u>=1) {  // if u >=1...

      These provide no information. Please don't write them in your code. They're distracting at best.

  6. Singletons and Pseudosingletons

    The singleton pattern should ensure several things:

    1. It is impossible to have more than one instance of the class.
    2. The class will be instantiated automatically.
    3. It's impossible to manually instantiate or destroy the class.
    4. It's impossible to interfere with access to the instance of the class.

    What Jeremy calls a singleton is actually just a global variable. For real C# singleton implementations, I recommend reading C# in Depth: Implementing the Singleton Pattern in C#

    They're unfortunately not legal for anything derived from MonoBehaviour. On the plus side, MonoBehaviour provides guarantees #2 and #3 for you on its own. Presumably multiple instances of the same script being attached to different objects will cause you problems. (i.e. #1 appears to be unsolvable.)

    #4 is solveable however. Jeremy's version leaves the static instance variable unprotected. That is fixable without refactoring global data into classes that can be made into actual Singletons:

    static private ThisType instance; // Singleton

static public ThisType S
{
    get
    {
        return instance;
    }
}

void Awake()
{
    instance = this; // Set the Singleton
}

    If you need multiple instances of such a script across the lifetime of your game, I haven't investigated what will happen using this pseudosingleton. I suggest using actual Singleton implementations to provide access to global data where possible.

  7. Delegates and Events

    When you get to Jeremy's introduction to delegates, I suggest additionally reading C# in Depth: Delegates and Events to see how to avoid exposing public delegates. I want you to care more about encapsulation. It'll help you avoid a lot of pitfalls.

  8. Aspect Ratios

    The aspect ratios expected by these tutorials (particularly by Space SHMUP) are a little strange. Most computers will not support them. If you want to enforce the correct aspect ratios, you have permission to use the code snippet from Controlling Aspect Ratio in Unity for this assignment and for future assignments.

Final Deliverables

Unity Project Setup

There are some steps you should take care of before getting deep into your project:

  1. Verify your ability to build Unity projects for both Mac and Windows.
  2. Make sure that git (Git) is accessible from the commandline.
  3. Install Keka on Mac or 7-Zip (64-bit x64) on Windows.

    Note: If you choose to use Brew to install Keka, make sure you use brew install Caskroom/cask/keka.

  4. After creating your Unity project, initialize a new Git repository in its directory. (i.e. A .git/ directory should exist in the root of your Unity project.)
  5. Add our .gitignore file and both eecs-494-unity-canvas-manual.sh and eecs-494-unity-canvas-manual.bat to the root of your new Git repo before your first commit.
  6. Create a Documents/ subdirectory within your Git repo and plan to store any written deliverables of the assignment there. (Keep anything we haven't explicitly requested out of there.)

From time to time, you should additionally

  1. Make sure that you've added all necessary scenes to File -> Build Settings... and that the checkboxes for them are checked.
  2. Test an actual build for your platform.

Submission to Canvas

Be aware of the naming convention for the given assignment:

Please do as follows:

  1. Ensure that you've met all of the project requirements. Seriously. Reread them.
  2. Ensure that you've committed everything that you're supposed to have committed and nothing else.
  3. Build the .app bundle for Mac OS X and the .exe for Windows following the above naming convention.
  4. Run either eecs-494-unity-canvas-manual.sh or eecs-494-unity-canvas-manual.bat on the commandline (bash or cmd.exe respectively) from your Git repo / project directory.
    • For project 1, something resembling eecs-494-f16-p1_uniqname_uniqnamf-private.7z should be built in your repository. It should contain eecs-494-f16-p1_uniqname_uniqnamf.app/, eecs-494-f16-p1_uniqname_uniqnamf_Data/, eecs-494-f16-p1_uniqname_uniqnamf_Repo/, and eecs-494-f16-p1_uniqname_uniqnamf.exe.
  5. Upload the .7z file built by the script directly to Canvas or, if absolutely necessary, provide a link and the SHA256 sum generated at the end of the script as part of your submission.
  6. Finally, whether you submitted or one of your partners submitted, download and check the submission to make sure everything is in order.
    • Submissions must be prepared using our scripts. If we can tell that they were not prepared using our scripts, they will not be graded. You will get a 0.
    • Submissions provided as links without corresponding checksums will not be graded. You will get a 0.
    • Submissions that are missing required Documents/ or which include only links (such as .gdoc redirects) instead of required exports will not get credit for those deliverables. You will get a 0 for them.
    • Submissions with either broken builds or missing sources will entail grading delays at best and getting a 0 at worst.

Late Policy as Stated in the Syllabus

Late assignments will be assessed a penalty of 2.5% for each 6 hours it is late (10% per day) up until the cutoff. We will not grant extensions except for extended sicknesses.

Questions

The class forum is available through the Canvas Piazza and is by far the best place to ask questions.