Reference no: EM132990435

ITECH2001 Game Development Fundamentals

Learning Outcomes
K3. Outline a common games mechanics model;
K4. Relate how games can be used to enhance communications;
K5. Identify the appropriate and correct syntax and programming constructs for different game development requirements.
S1. Select and apply appropriate games development approaches to solve a real world game design; S2. Create a range of assets for a game's project;
S3. Outline the design of a game's project;
S4. Use programming constructs to respond to user input and to create object and character behaviours;
S5. Analyse, design & implement game concepts using structured & basic object orientated programming concepts; S6. Test and debug code to correctly meet game design requirements.
A1. Operate appropriate software packages to design and build games and interactive media products that align with client and project expectations;
A2. Utilise appropriate software environments to develop and integrate code implementations with game assets.

Part C: Game Prototype

After thinking of a game concept in Part A, writing a prototype plan with your designs, and creating a few assets for Part B, it is time to develop the game prototype. Using your prototype plan and assets, you must now develop a small functional and playable prototype that showcases one scene (that acts as a small area or level) with game mechanics that trigger events, and end condition(s) - win, loss, and/or completion of level/area.
How big should the prototype be?
• Your prototype should use one scene in Unity with a few triggers and events to showcase elements of your game idea, with end condition(s) - such as win, loss, and/or prototype completion. Additional scenes are allowed, however focus on perfecting one scene first.
• Here are some examples of different prototypes available in the course:
o View the selection of previous student prototypes available in the Moodle Assessments section.
o Lab 6 and 8 - this is an OK example of a prototype with a nice terrain (lab 6), and triggers and events such as teleports, death and respawn, and a troll trigger that outputs audio (lab 8), however it would require a goal for the player to accomplish, an interface, and end of prototype conditions.
o Lecture 8 and 9 example - this is an OK example of a prototype with triggers and events causing characters to respond and output dialogue on the screen interface, however it would require a goal for the player to accomplish with end of prototype conditions.
o Lab 9 and 10 - this is a great example of a prototype for this course for a 3D platform game that only moves forward. It has running, jumping, a trigger to open a door, a trigger to increase player speed, a trigger to spawn enemies, collisions to cause death, and events causing enemies to patrol a simple pattern. All it is missing is an end condition, and perhaps number of lives to enforce a lose condition.
• Examples of end conditions:
o Scores - Roll-a-Ball (lab 5) has a simple solution of counting the number of items collected, and outputting a win message when a certain score is reached. This could be used in many types of games and genres:
» Counting the number of enemies killed (using raycasting for shooting, or collisions).
» Counting items collected for a game quest (using triggers/collisions).
» Counting the checkpoints crossed in a racing game (using triggers).
o Timing - Time conditions can be used for both winning and losing conditions.
» This could also be used in many types of games and genres. If the player meets the goals within the time limit, you win and complete the level; if not, you lose.
o Triggers and Collisions - these could be used to trigger an event that indicates to the player that they have won or completed the prototype, or have died and lost, or perhaps just lost one life and then respawn. This could be used in many types of games and genres:
» Player gets hit by an enemy, and loses a life (using raycasting for shooting, or collisions).
» Player touching dangerous object/environment, or even falling off the world, and loses a life (using triggers/collisions).
» Reaching a specific point in the scene/map outputs that player has won (using triggers).
• It is important to utilise interface elements to output to the player what has occurred - such as scoring updates, life updates, and wining, completion or losing the game.

What are event and triggers?
• You will learn more about these in lectures 6 to 10, as well as some labs from 5 to 10.
o Essentially, an Event is when something happens that causes a certain piece of code to run.
» The event is said to have been triggered by something in the game.

• Examples to trigger an event in Unity:
o Input supplied by the player via controls (input functions). Examples:
» Push a keyboard key or mouse button to open a door, pick up an object, shoot a gun, or throw a grenade.

o Two (or more) objects (with collider components) collided. Examples:
» Player touches an enemy and gets hurt.
» Player stands on a switch and a door opens.
» Player picks up a coin, and their score increases.

o Player touched a triggerable collider (through a collider component).
Examples:
» Player enters an area and enemies spawn.
» Player approaches a person and dialogue appears on screen.

o Artificial Intelligence programmed to execute code regularly (update functions). Examples:
» Enemy scripted to moves towards the player slowly - Enemy has a set patrol path.
» Enemy shoots towards player location.

Beginning Part C:
• Download the "GamePrototypeProjectTemplate.zip" file from Moodle in the Part C section of Assessments.
• Unzip the file to a safe location.
• You should see a folder called "StudentID-GameName".
• Rename that folder to your actual student number followed by the name of your game. This is your Game Prototype project folder.
o (example: 30126565-ThunderRun).
• Take note of the location of your Game Prototype project folder.
o You will need it for adding the project to the Unity Hub, and
o Upon completion of your assignment you need to zip this entire project folder for submission.
• Open Unity Hub.
• Click Add.
• Browse to the folder location, and click on your named Prototype project folder, then click "Select Folder".
• It should now be in the list of Projects in the Unity Hub.
• Click on the name of your Prototype project to load it into Unity for editing.
• In the Project Tab, folders have already been created for you. Use them to keep asset files organised.
• (Depending on Unity preferences, your project tab will look like one of the screenshots to the right) ?
• If you do not use the template and/or organised folder structure, penalties will apply!

• Assets that YOU create are stored in the following folders:
o Interface - Store all interface art assets created by yourself within GIMP (including Part B interface art).
o Materials - Store all materials created by yourself within Unity, or from GIMP (including Part B textures).
o Models - Store all 3D models created by yourself within Blender (including Part B models).
o Prefabs - Store all prefabs created by yourself within Unity.
o Scenes - This folder already contains a blank scene called "MainScene". Your main prototype scene must be built in this scene. Store all additional scenes created by yourself in this folder.
o Scripts - Store all C# scripts created by yourself within Unity/Visual Studio.
o <additional folders> - you can create additional folders to store assets created by yourself if they do not fit in to any of these categories. Eg: "Animators", "Audio", "Particles", etc.
• Assets that you download from the Unity Asset Store MUST be placed in:
o Unity Store Assets - To store any assets downloaded from the Unity Asset Store.
o When sourcing additional assets, you must use the Unity Asset Store, choose free assets, and provide a link to that asset in your brief report. Do not download assets from any other source.
o You cannot download and use pre-built scene assets. Your scenes must be constructed by yourself.
• Packages - created by default for Unity. Do not remove, but you can ignore it during development.

Part C Requirements:
There are a number of requirements that you must adhere to when completing this assessment task:
• You MUST download the zipped project template from Moodle and begin your prototype on that file.
• You MUST use Unity version 2020.3.5f1 to build and edit your project. Instructions to install this version in Moodle.
• If you do not follow these requirements and use the wrong version of Unity, you game may not function correctly for the marker within their installed Unity 2020.3.5f1, and you will most likely lose many marks.
• Take note of the Overall Rules first established for the prototype on page 2 of this document.

Art Assets
• There are no requirements to develop any more 2D or 3D art assets yourself (this was completed in Part B), but you can if you want, just be aware that these newly created assets will not be marked separately and take additional development time.
o Any assets that you create yourself should be placed in the appropriate project folder in Unity.
• When sourcing additional assets, you must use the Unity Asset Store, and provide a link to the asset in your brief report. Do not download assets from any other source. Unity has a huge library of over 6000 free premade assets you can import and use, and not limited to just art assets (see Lab 6, Exercise 3 for instructions on importing free assets from the Unity Asset Store).
o Unity Store assets sourced online MUST be placed in the "Unity Store Assets" project folder in Unity. This includes Unity's own "Standard Assets".
o These assets should be used appropriately within your prototype to flesh out your scene objects.
o You cannot download and use pre-built scene assets. Your scenes must be constructed yourself.

Scene(s) & Objects
• Begin working on your prototype scene with the Prototype Unity template files (as outlined on page 14 of this document), and the scene called "MainScene". You cannot use a pre-built scene.
• Unity can be used to develop a Terrain (see Lab 6 for Unity 3D Terrain).
• Primitive objects can be placed in Unity, but may detract from the design, unless arranged into an elaborate scene. You are better off populating the scene with Unity Store Asset objects appropriate for your world/environment.
• Prefabs should be created for objects that require multiple instances in the game scene. Place in "Prefabs" folder.
• Aim for engaging use of Objects (your own three created assets, plus additional free Unity Store assets) including 3D objects such as the player, props, cameras, light sources and other game objects to create your scene.

Components
• Components should be added to your game objects where appropriate, such as:
o Animators. Examples: Opening doors, moving platforms, premade animations. Keep it simple.
o Rigidbody for objects requiring physics behaviour / physical collisions.
o Colliders for objects that can be collided with, and possibly require scripted collision events.
o Colliders with triggers for objects to set up a scripted triggerable event.
o Materials on objects to distinguish them apart from one another.
o And other components such as Audio, Particle System, Camera, and UI components as required.
o NOTE: Transform is a required component and is not considered for marking purposes.
o NOTE: Mesh Renderer is a required component of a 3D model and is not considered for marking purposes.

Scripts
• It is expected that you can develop your own C# scripts to create new events and behaviours in your prototype (see Labs 4 to 10, and Lecture Projects 8 and 10, regarding triggered events in Unity).
• You should use Scripts for:
o The Player Controller
» For higher marks and greater challenge, consider creating your own player controller. If you find that task difficult or daunting, the controllers that come in the Standard Assets package are useful and can be used in your prototype to control the player character, but will be at a slightly reduced mark.
o End Condition(s) - win, loss, and/or completion of prototype
» All prototypes require an ending condition that triggers winning (or completion) of the prototype. This should be accompanied by a message to the player that they have won (or completed) the game.
» In addition, you may (or may not) have a condition for losing, that should also output to the player that they have lost.
o Interface Updates
» In addition to the above, one Unity UI element should be scripted to update based on certain events. Try to make it visually pleasing. Examples: time limits, scoring system, ammunition left, character dialogue popups, or another interface element.
o Trigger Events and/or Collision Events (minimum of three)
» In addition to the above (player controller, end condition(s) and interface), attempt to create at least three additional trigger and/or collision events in your prototype. Triggers and Events were detailed on page 12.
» Less than three, and/or not functioning triggers/collisions may receive lower marks.
o Comments
» Scripts that you create yourself, comment your name and student ID at the top of the script. Provide English comments in your scripts, to concisely summarise the purpose of each method/function.
o All scripts you create MUST be placed in your "Scripts" project folder in Unity.

Brief Report
You should also submit a written report detailing what you have done. A template is provided on Moodle to make this easier for both you and your marker. This must briefly address:
• A list of assets that you have downloaded from the Unity Asset Store and their download link location.
• An overview of all of the scripts which YOU have created and which game object(s) each one is attached to. Do not list scripts you have NOT created.
o You can look for scripting guides from the internet, but you should not copy them exactly, they should be adapted to your game concept and prototype.
• It is easy to determine if you claim someone else's scenes, assets or scripts as your own, and this will be penalised, and may be considered for plagiarism.
• Any limitations or known bugs in the game. Unacknowledged bugs detected during marking will be taken as evidence of insufficient testing. Bugs that have been documented in this report with explanations of how you have tried to fix them will receive more leniency in marking than those that are unacknowledged.
• Any major aspects of the game which have changed since your game design document, explaining why this has occurred.
• A list of events and gameplay actions that can occur in your prototype, including the winning and losing conditions.

Attachment:- Game Development Fundamentals.rar