Reference no: EM132990424

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 A: Game Pitch and Peer Feedback

Your task for Part A of this Assignment is to:
1) Pitch a new video game concept in a short recorded video.
2) Provide constructive peer feedback to another student regarding their pitch.

Game Pitch Video
Your first task is to think of a new game idea, then pitch your game idea in a recorded video. This task is directly related to the Assignments throughout the semester. The full details of what to do for this pitch are outlined below:
• Your game pitch forms the early concepts for the game prototype you will be planning in Part B, and then developing in Part C. Therefore, read over Part B and Part C below to gain a full understanding of the game prototype you must plan through designs and then later develop into the small prototype.
o You should start your planning document for Part B early in the semester and have a good idea of what your game will be about. This will help you immensely for this Game Pitch.
• A game pitch in industry is used to try to sell your game concept to a potential investor and their market, or directly to the gaming target audience via crowdfunding; you want to them to fund your game!
o Imagine you only have 2 minutes time to describe your game concept to a game publisher! Therefore, it should be short, interesting and informative!
• Read these instructions thoroughly and think carefully about your pitch.
o Your game pitch will be a recorded video presentation. Have fun with it! It is about games.
o It must meet the criteria and be between 1:30 to 2 minutes in length.
o It can be recorded and edited any way you like, but you must be identifiable at the start of the video, and be talking throughout to explain your game concept.
o If recorded on a mobile device, it must be in landscape view ?
and must be clear in video and audio.

What to include in your video:
• Prepare a high concept statement of your game idea. Use this to introduce your game idea during your pitch.
o This is a concise but informative description of your game concept. A few sentences (~one paragraph) are used to summarise your game in an exciting manner - sometimes called an "Elevator Pitch" - a short and persuasive pitch that quickly defines the value and excitement in your product.
o Try to include as many of the most important details as possible, briefly summarised into a one paragraph high concept statement (Lecture 2 explains high concept statements, with a few examples), including:
» The Game Title, its story, aesthetics, mechanics and technology. This could include:
• Genre (see lecture 1)
• Player control such as player viewpoint, and game engine used
• General Story, Setting and major Characters (see lecture 3)
• Important game Mechanics, including the major goal (see lecture 4)

• After your initial high concept, provide some expanded details such as the most interesting features of your future game prototype.
• During your pitch, you must back up your discussion with supporting materials:
o Supporting materials can be anything that helps you to describe your game quickly:
» Examples: Sketches, images and/or videos
• Characters, objects, diagrams, ideas, game mechanics, and/or maps.
• They could be your own, or examples from similar games that inspire you.
o Supporting materials can be shown:
» In person during your pitch (record them clearly on the camera).
» Edited into the pitch using any video editing software.

*Part B: Prototype Plan and Assets

Your task for Part B of this Assignment is to
1) Document a prototype plan that outlines the overall designs and plans for your game prototype, and
2) Create three artistic assets using the specified software for your game prototype.

Prototype Plan
A game begins with an idea. At the beginning of the semester, after learning about this assessment, you should have started coming up with ideas for your game prototype that would meet the requirements.

This prototype planning document does not have a word count requirement, but
• Expect to write more than 1500 words to address all of the criteria outlined further below.
• Include lots of images to support your designs and make it easier to understand!
• Your planning document should be easy to understand, visualise, and be detailed enough that if you were to pass your plans to a completely separate Unity developer, you could expect them to develop a prototype for your game without any confusion.

The following areas should be addressed in your prototype plan document:
(these will help the marker determine if your scope is too large and therefore difficult, or simply too small, in which they can provide feedback):
1. High Concept Statement (see lecture 2)
o This is similar to the high concept statement provided in your Game Pitch, but now you have a chance to follow up on any feedback and improve it! If you have made any major changes since your pitch (or were requested to change something in your Part A feedback), make sure the high concept statement reflects this.
o Once again, try to include as many of the most important details as possible, briefly summarised into a one paragraph high concept statement, including:
» The Game Title
» The game's story, aesthetics, mechanics and technology. This could include:
• Genre (see lecture 1)
• Player control such as player viewpoint, and game engine used
• General Story/Concept and major Characters (see lecture 3)
• Important game Mechanics, including the major goal (see lecture 4)
• World/Setting (see lecture 5)
2. Mechanics (see lecture 4)
o Every student will have game mechanics to discuss that emphasises exactly how your prototype will function. With the main concepts summarised through the high concept statement, this section requires detailed explanations of your mechanics for the game prototype you will build.
o There should be thorough discussions of each of these aspects from the lecture:
» Space - This should address the space that the prototype will be played within, focusing on the dimensions, movement, and boundaries. Environment/world are to be discussed in another section.

» Time - This should address any conditions that affect the timing in the prototype. Discussion should include how time affects actions, gameplay, player control, and setting.
» Objects - This should be a comprehensive list of all objects including their usage, purpose and states that will be needed in the prototype, and can include characters/enemies (lecture 3), props, cameras, lights and other objects.
» Actions - Actions refer to the actions conducted by the player, and this section requires basic actions and possible strategic actions, as well as the input required to conduct the actions.
» Rules - Rules of the prototype. Must include rules around object interaction, rules of action usage, end condition(s) - win, loss, and/or prototype completion, as well as scoring, etc. Include any chance elements here that may create randomness and uncertainty for the player, and/or alter the rules.
o Include images/diagrams to help support your descriptions.
3. World / Setting (see lecture 5)
o A 3D game will require some sort of world, environment, or setting - even if it is abstract.
o Outline the setting for your prototype level/scene. Consider the following when documenting your designs:
» Is it indoors, outdoors, more surreal, abstract, etc.? What does it look like?
» Does it draw influences from any culture, atmosphere or setting?
» What year is it based in? Is it fictional, historical, contemporary, fantasy, etc.?
o Include images/diagrams to help support your descriptions.

4. Level Design (see lecture 5)
o It is important that you thoroughly plan the level or contained area you will develop for your Part C playable game prototype. You must include the following:
o Complete level/scene map - Draw a detailed top-down map of your proposed level/scene(s) for the game prototype, to act as a blueprint for the development stage.
» You can use software to design your map, or hand draw the map and scan it or take a CLEAR photo
» Map must be created by yourself, or you will lose marks.
» The map must indicate locations of the following:
• Player start location
• All Triggers/Events
• All Characters/Enemies
• All Props and Objects
• The Player progression through the map to win / finish the prototype
o Discussion about the triggers/events with pseudocode, relating it back to your completed map.
» Identify and summarise how each event will be triggered that was indicated on your map.
• (for more details about triggers and events, see Part C). Also Discuss:
• Are certain actions required by the player to trigger an event?
• What is/are the end condition(s)? How does the player win, lose, and/or complete the prototype?
» Provide simple pseudocode to design the process of each event.
• (Events, Triggers and Pseudocode are first introduced in Lecture 6, but you should view Part C to see the requirements of Events and Triggers in the prototype.)

Asset Creation
It is expected that you can develop your own 2D and 3D art assets that are appropriate for your game prototype. All students are required to develop at least three assets (not just primitive shapes or basic artwork) created by yourself in 2D (materials and/or interface art), and 3D (meshes). When you work on the game prototype development in Part C of this assignment, you will use your three (or more) self-created assets, as well as free downloadable Unity store assets.
The following identifies the specifications for creating your own art assets:
• GIMP Asset (see lab 1)
o Every student must create at least one 2D asset using GIMP. Appropriate types of assets include:
» Materials for surfaces of 3D objects.
» Interface elements which will be used to improve the interface visual design.
» Backgrounds and skyboxes for your prototype scene.
o Save as a .XCF file type AND export to PNG for submission
• Blender Assets (see labs 2 and 3)
o Every student must create at least two unique 3D assets using Blender. These should be:
» Static 3D models/meshes that will be used as props in your prototype scene.
• Animated 3D models will not be taught in this course, so choose static objects to model, such as props for your game prototype.
o Save as a .blend file type AND export to FBX for submission
• To show your competency in these software tools, these three assets should match or surpass the level of detail of assets created in the labs.

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

*Note: Need only Part B Documentation