plan and create assets – Global Homework Experts

Assignments

order now

Your task this semester will be to first pitch, then plan and create assets for, and finally develop a small video game prototype. Your game must not be based on any existing artistic works or media, such as film, television, games, stories, or characters – it should be your own original creation.

This task is split into three manageable assessments and described below in more detail. After reading the specifications, and learning through lectures and labs, if you are still unsure of the complexity required for your final game prototype, ask your lecturer, and look at previous student submissions from past semesters in the “Previous Student Examples” located in the Assessments section of Moodle.

 

Assessment Task Time Due Date Weight
Part A: Game Pitch and Peer Feedback

Your Game Pitch is a video you record where you outline your game idea. You will also provide constructive feedback to a peer.

5 hours

(minimum)

Sunday 11pm,

Week 4

10%
Part B: Prototype Plan and Art Assets

Your Prototype Plan will build upon the concept, planning a small game prototype, together with creation of 3 initial game assets

20 hours

(minimum)

Wednesday11pm,

Week 6

25%
Part C: Game Prototype

Your Game Prototype will showcase your original game as one small level or area, as described in your plan

25 hours

(minimum)

Sunday 11pm,

Week 11

25%

 

The following course learning outcomes are assessed by completing this assessment:

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.

 

Plagiarism: 

Plagiarism is the presentation of the expressed thought or work of another person as though it is one’s own without properly acknowledging that person. You must not allow other students to copy your work and must take care to safeguard against this happening. More information about the plagiarism policy and procedure for the university can be found at http://federation.edu.au/students/learning-and-study/online-help-with/plagiarism.

During this semester, you will be required to create:

  1. A recorded video presenting your game concept (together with constructive feedback to a peer’s video), B. A prototype planning document, together with creation of some game art assets, and
  2. A playable game prototype.

 

Follow the rules below while completing these assignments. Your game prototype (including pitch and plan) must:

  • Be an original design.
    • You can be inspired by, and make a game similar to, but not copy an existing artistic work.
    • You cannot base your characters, story, or world on an existing artistic work, another student’s ideas, or any other forms of existing media. It must be an original creation of your own, or it may be considered plagiarism, and a breach of copyright.
    • If you are repeating this course, your game must be a new concept. You cannot use the same game idea/concept as previous attempts at this course.
  • Be designed and developed as a single player game, with a single controllable object (that will be the player character and is controlled by the player), via keyboard and/or mouse input.
    • Multiplayer/online games require much development time, so your prototype game must be single player.
    • The player must be able to control a single game object on the screen in your game via 1st or 3rd
      • It can be any object you can think of, for example: a person, an animal, a vehicle, a piece of food, a tool, etc. The choices are endless!
      • Controlling multiple characters, squads, armies, or complex interfaces often contain complicated systems and programming requirements making this too difficult a task for a single semester.
    • As markers will be marking your game prototype on a computer through the Unity editor, it must be playable using keyboard/mouse controls. Mobile, Consoles and VR/AR devices are not allowed.
  • Be designed and developed as a 3D game.
    • All of the lab work supports learning how to develop games in 3D.
    • You can still create a game in a 3D world, that reflects a 2D style game, by positioning the camera angle appropriately (side view, top down, isometric, orthographic etc). See different examples here.
  • Focus on a small one level/scene prototype that is manageable to build this semester.
    • One level/scene is required, two scenes should be the maximum to avoid too much development scope.
    • The prototype level/scene should contain player movement, triggers and events, understandable mechanics, and end condition(s) (win, loss, and/or completion of level/area) so the player can finish the prototype.
      • See Part C for more details about requirements of scene(s) and events.
    • Avoid complex mechanics and systems in your designs and development.
      • Remember this is a one semester course, with a small amount of time to produce the outcomes.
      • The labs will teach you all of the fundamentals in game development for simple 3D games, and the lectures will assist with design concepts and programming in C#.

 

 

Your task for Part A of this Assignment is to:

  • Pitch a new video game concept in a short recorded video.
  • Provide constructive peer feedback to another student regarding their pitch.

Game Pitch Video (7 marks)

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 will form 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 and then later develop into the small prototype.
    • 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!
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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)

o    Make sure it is clear (for the marker) when your high concept statement begins and ends.

  • After your initial high concept statement, provide some expanded details such as the most interesting features of your future game prototype.
  • During your pitch, in both the high concept statement and expanded details, 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.

Peer Feedback (3 marks)

The second task of Part A requires you to watch other students’ game pitches and provide some constructive feedback to one other student to help them improve their designs for Part B.

After posting your own video of your game pitch (see below on how to submit):

  • Read the titles of other students’ game concepts and view some game pitch videos that appeal to you.
    • If not many are available after you have submitted, wait a little closer to submission deadline for more to be uploaded (but don’t forget about this!)
  • When you discover an interesting game concept among your peers, reply to their forum post and provide polite and constructive feedback such as:
    • Evaluating their high concept statement and reflect on methods to improve it for Part B planning document. o Providing advice on they could better meet the overall game prototype specifications on page 2. o         Suggesting forms of media and similar games that may assist them to explain their game concepts.
    • Addressing the energy and excitement from the presentation.
  • The goal is to provide constructive feedback on how they could improve their game concept when they work on Part B and eventually Part C, while still meeting the criteria of each.

 

For all forums remember:

  • Text based communication can be misinterpreted (eg: Sarcasm and humour is not always obvious).
  • Please obey discussion forum etiquette. Do not use the Moodle forums inappropriately.

Part A Submission

When you have completed your video, go to ITECH2001 Moodle > Assessments, and enter the submission forum

 

This link contains full instructions on how to submit your video, and provide constructive feedback to a peer’s video.

Part A Feedback

You will receive marks and feedback by week 6, uploaded to Moodle.

Part A Marking Rubric

Pitch

High

Concept

Statement

(2 marks)

Excellent (2)

One spoken paragraph that gives a very clear overview of the game concept, including its title, and brief summary of genre, story/setting, characters/objects, player control/view, and important mechanics. It is very unique, interesting and persuasive!

Good (1.5) One spoken paragraph that gives an understandable overview of the game concept, including its title and most background elements

(listed in excellent). It is interesting, but could be a little more exciting.

Acceptable (1) Roughly one spoken paragraph that gives a mostly understandable overview of the game concept, and its title and a few background elements (listed in excellent), but it lacks excitement and could be improved. Poor (0.5) The high concept statement is attempted but either too short, too long, and/or has confusing game concepts which are hard to understand. Presentation is dull. Not Done (0) Nothing has been summarised into a high concept statement, instead the pitch has lots of expanded

details (as marked below).

Pitch

Expanded

Details

(2 marks)

Excellent (2) Extremely clear to understand with well thought out ideas and game concepts that expand upon the high concept statement and use the time remaining efficiently. It is very unique, interesting and persuasive! Good (1.5)

Mostly understandable with thought out ideas and game concepts that expand upon the high concept statement and use most of the time remaining well. It is interesting, but could be a little more exciting.

Acceptable (1) Ideas and game concepts are mostly understandable but not well thought through. The time remaining could be

better utilised. It lacks excitement and could be improved.

Poor (0.5)

Confusing ideas and game concepts which are hard to understand. The time remaining could be much

better utilised. It lacks excitement.

Not Done (0) No expanded details were provided OR the details provided are completely unrelated to the game concept.
Pitch

Supporting

Materials

-Images

-Sketches

-Videos

(2 marks)

Excellent (2) At least four varied supporting materials. They greatly aid in understanding the game concepts. Good (1.5)

At least three supporting materials. They aid in understanding the game concepts.

Acceptable (1)

At least two supporting materials. They somewhat aid in understanding the game concepts.

Poor (0.5)

There are additional materials, but they do not support the understanding of the pitched game concepts.

Not Done (0) No supporting materials to assist in visualising some of the pitch.
Pitch

Length

(1 mark)

Good timing (1)

Between 1 minute 25 seconds and 2 minutes 5 seconds. (Meets requirements with 5 second leeway)

OK timing (0.5)

5 to 30 seconds too short or too long (Slightly over/under requirements)

Bad timing (0)

More than 30 seconds too short or too long (Too much over/under requirements)

Feedback to Peer (3 marks) Excellent (3)

Feedback was very helpful and constructive. It addressed the high concept statement, the quality of the presentation, provided advice and suggestions, all in relation to prototype criteria. It could easily contribute towards peer making beneficial changes to their game concept for Part B and C.

Good (2)

Feedback was good but could be more constructive to help peer. It attempted to address the criteria with suggestions. Peer may consider the feedback when working on their game concept for Part B and C.

Poor (1)

Feedback could be understood, but was not constructive. It did not provide the peer with usable suggestions. It would be difficult for peer to use the feedback when working on their game concept in Part B and C.

Not Done (0) No feedback was provided, OR feedback

was totally offtopic, OR could not be understood.

 

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.

You should begin working on this assessment when the course commences, with a solid plan for your game prototype, this will help you to create your Pitch more easily.

Remember, this planning document is about making plans for just the game prototype you will develop in Part C, it is not a full game design document, but rather the design of a single level or area intended for your prototype.

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 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)
    • 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.
    • 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 dimension), 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)
  1. Mechanics (see lecture 4)
    • 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.
    • There should be thorough discussions of each of these aspects from the lecture:
      • Space – This should address the space that the prototype level/scene will be played within, focusing on the dimension, movement, and boundaries. Environment is to be discussed in another section.
      • Time – This should address any conditions that affect the timing in the prototype level/scene. 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 level/scene, and can include characters/enemies (lecture 3), props, cameras, lights and other objects.
      • Actions – This section requires basic actions and possible strategic actions conducted by the player in the prototype level/scene, as well as the keyboard/mouse input required to conduct the actions.
      • Rules – This section requires the rules of the prototype level/scene: object interaction, 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.
    • Include images/diagrams to help support your descriptions of mechanics.

 

  1. World / Setting (see lecture 5)
    • A 3D game will require some sort of world, environment, or setting – even if it is abstract.
    • 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.?
    • Include images/diagrams to help support your descriptions.

 

  1. Level Design (see lecture 5)
    • It is important that you thoroughly plan the level or contained area/scene that you will develop for your Part C playable game prototype. You must include the following: oComplete 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:

All objects (including characters, enemies, props

and other objects) from the Object list indicated in

  • All Characters/Enemies section 2 Mechanics should be shown on your map
  • All Props and Objects
  • The optimal Player progression through the map to win / finish the prototype
  • 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
  • (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 (10 marks)

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:

  • Assets created following the lab exercises do not count towards this submission.
  • GIMP Asset (see lab 1)
    • Every student must create at least one 2D asset using GIMP. Appropriate types of assets include:
      • Materials for surfaces of 3D objects. (May include a Normal Map as seen in lab 1)
      • Interface elements which will be used to improve the interface visual design.
    • Save as a .XCF file type AND export to PNG for submission
  • Blender Assets (see labs 2 and 3)
    • 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 B Submission

Electronic copies via Moodle.

Prototype Plan: Adobe PDF or Word Doc / Docx accepted.

  • Do NOT compress your document (such as ZIP, 7z, RAR, etc.). It will not be accepted.

Art Assets: Zipped folder (ZIP) containing:

  • GIMP Asset(s): GIMP XCF and exported PNG
  • Blender Assets: Blender .blend and exported FBX

 

Please refer to the Course Description for information regarding late assignments, extensions, special consideration, and plagiarism. Library Guides to writing and referencing: https://federation.edu.au/current-students#Learning_and_study

Part B Marking and Feedback

Refer to the rubric on the next page for details on how each section of the document will be marked. You will receive marks and feedback within two weeks of submission, uploaded to your Moodle submission.

 

Part B Marking Rubric

Prototype Plan (15 marks)
High Concept Statement (1 mark) Should only be a paragraph to summarise the main aspects of the game such as title, main story/concept, character(s)/object(s), mechanics, world/setting, player viewpoint, and engine.
Excellent (1)

Interesting and informative description of the game concept that concisely sums up (in one paragraph) all the following aspects of the game:

•   Game Title, Genre and Concept

•   Main Character(s)/Object(s)

•   Player Viewpoint

•   Game Engine

•   Important Mechanics

•   World/Setting

Good (0.75)

Easy to understand description of the game concept that concisely that sums up most of the suggested aspects of the game in a single paragraph.

Acceptable (0.5) Adequate description of the game concept that sums up some of the suggested aspects of the game but could be shorter, longer or more interesting to address the requirements. Poor (0.25) Confusing description of the game concept that is difficult to

follow, much too short, or much too long.

None (0) No high concept in plan.
Mechanics: Space (1 mark) Space mechanics 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.
Excellent (1)

Comprehensive discussion that is clear and easy to understand, including:

•   Dimensional Space

•   Discrete/Continuous details

•   Boundaries

Good (0.75) Substantial discussion that is mostly clear and understandable.   Acceptable (0.5) Moderate discussion that can be understood but could use more details at times. Poor (0.25)

Limited discussion and/or difficult to understand, with little supporting detail.

None (0) Space

section of Mechanics is missing.

Mechanics: Time (1 mark) Time mechanics should address any conditions that affect the timing in the prototype. Discussion should include how time affects actions, gameplay, player control, and setting.
Excellent (1)

Comprehensive discussion that is clear and easy to understand, including Time conditions for:

•   The Player and their actions

•   Discrete/Continuous details

•   The Gameplay

Good (0.75) Substantial discussion that

is mostly clear and understandable.

Acceptable (0.5) Moderate discussion

that can be understood but could use more details at times.

Poor (0.25)

Limited discussion and/or difficult to understand, with little supporting detail.

None (0) Time

section of Mechanics is missing.

Mechanics: Objects (2 marks) This should be a comprehensive list of all objects including their usage, purpose and states that will be needed in the prototype, such as characters, enemies, props, cameras, lights and other objects.
Excellent (2)

Comprehensive discussion of all objects, their usage/purpose/states that is easy to understand, including: • Characters/Enemies

•   Props and other static objects

•   Cameras and Lights

Good (1.5) Substantial discussion that is mostly clear and understandable.   Acceptable (1) Moderate discussion that can be understood but could use more details at times. Poor (0.5)

Limited discussion and/or difficult to understand, with little supporting detail.

None (0) Objects section of Mechanics is missing.
Mechanics: Actions (1 mark) 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.  
Excellent (1)

Comprehensive discussion that is clear and easy to understand, including:

•   Actions of the player

•   Keyboard/Mouse Input

Good (0.75) Substantial discussion that is mostly clear and understandable. Acceptable (0.5) Moderate discussion that can be understood but could use more details at times. Poor (0.25)

Limited discussion and/or difficult to understand, with little supporting detail.

None (0) Actions section of Mechanics is missing.
Mechanics: Rules (1 mark) Rules of the prototype. Must include rules around object interaction, rules of actions, end (win, loss, and/or completion) and scoring conditions, and chance elements that create randomness/uncertainty/alter the rules.
Excellent (1)

Comprehensive discussion that is clear and easy to understand, including:

•   Object interactions

•   Action rules

•   Win, loss, complete and/or scoring conditions

•   Chance and uncertainty

Good (0.75) Substantial discussion that is mostly clear and understandable.   Acceptable (0.5) Moderate discussion that can be understood but could use more details at times. Poor (0.25)

Limited discussion and/or difficult to understand, with little supporting detail.

None (0) Rules

section of Mechanics is missing.

 

Mechanics: Supporting Images (1 mark) The Mechanics section of the plan should be supported by images where appropriate to assist in understanding the concepts and relating them to existing games.
Excellent (1)

Supported by at least three images that assist in understanding how the mechanics function.

Acceptable (0.6)

Supported by at least two images that somewhat assists in understanding how the mechanics function.

Poor (0.3)

Supported by at least one image AND/OR images provided do not assist in the understanding of how the mechanics function.

None (0) No images supporting mechanics discussion.
World/Setting (2 marks) This section needs to outline the environment, atmosphere and appearance for the proposed prototype level/scene including any influences from history and culture.
Excellent (2)

Comprehensive discussion that is clear and understandable, that includes:

•               Setting/Environment

•               Atmosphere

•               Influences from culture or settings Supported by multiple images that assist to visualise the world/setting

Good (1.5)

Substantial discussion that is mostly clear and understandable. Supported by an image that assists to visualise the world/setting.

Acceptable (1)

Moderate discussion that can be understood but could use more details at times. Accompanying image could be better related to the details provided.

Poor (0.5) Limited discussion and/or difficult

to understand,

with little

supporting detail.

None (0)

World / Setting discussion missing.

Level Design: Map (3 marks) Student created map must indicate locations of: Player start location, All Triggers/Events, All Characters/ Enemies, All Props and Objects, the Player progression through the map to win/complete prototype.
Excellent (3)

Comprehensive map that details the prototype level/scene including:

•               Player start

•               Objects

•               Triggers/events

•               Characters/enemies

•               Player progression within the scene  It gives a solid point to begin developing the prototype in Unity.

Good (2.25)

Substantial map that outlines the prototype level/scene including most of the requirements within the scene. It gives an OK starting point to begin developing the prototype in Unity.

Acceptable (1.5)

Adequate map that outlines the prototype scene but could use more attention to required details. It will take a little effort to translate this into a prototype scene in Unity.

Poor (0.75)

Map is limited in detail, and/or is hard to make sense out of. It will take a lot of effort to translate this into a prototype scene in Unity. OR the map does assist, but was not created by the student.

None (0) Map is missing from Level Design section.
Level Design: Discussion/Pseudocode (2 marks) Discussion requires how the triggers/events occur, end (win, loss, and/or completion) conditions of the prototype, with simple pseudocode for each.
Excellent (2)

Comprehensive discussion about the triggers and events, with pseudocode that is clear and understandable. It gives a solid point to begin programming events in Unity.

Good (1.5)

Substantial discussion about the triggers and events, with acceptable pseudocode. It gives an OK starting point to begin programming events in Unity.

Acceptable (1)

Adequate discussion about the triggers and events with an attempt at pseudocode. It will take a little effort to translate these into programming events in Unity.

Poor (0.5)

Discussion is limited in detail, and/or is hard to make sense out of.

It will take a lot of effort to translate this into events in Unity.

None (0) Discussion is missing from Level Design section.

 

Rubric for the Artistic Assets continues on the next page.

Artistic Assets (10 marks)
GIMP Asset (2 marks) Creation of a 2D image in GIMP for a 3D game, using learned manipulation techniques. Assets created following the lab exercises do not count towards this submission. Therefore, Lab1: exercise 7 and 8 can be used for this assessment, as they ask you to create your own GIMP asset without instruction.
Excellent (2)

One of the following:

•  High quality 2D texture (for 3D models) at the complexity of the stone, bark, or marble textures, with seamless borders, and an additional created normal map.

•  High quality 2D interface art with effects such as gradients, transparency, and pseudo 3D appearance.

Good (1.5)

One of the following:

•  Good quality 2D texture (for 3D models) at the complexity of the stone, bark, rust or marble textures with seamless borders.

•  Good quality 2D interface art with simple effects, such as gradients.

Acceptable (1) One of the following:

•  Simple but usable 2D texture (for 3D models) that lacks quality details.

•  Simple but usable 2D interface art.

Poor (0.5)

One of the following:

•  Very plain or poor quality 2D texture (for 3D models).

•  Very plain or poor quality 2D interface art.

None (0)

GIMP

Asset not submitted.

Blender Asset #1 (4 marks) Creation of the first 3D Model in Blender using learned manipulation techniques. Models created following the lab exercises do not count towards this submission.
Excellent (4)

High quality 3D model with multiple parts at the complexity of the treasure chest from lab 3. Used many learned manipulation techniques such as extrude, loop cut, modifiers, inset faces and materials.

Good (3)

Good quality 3D model at the complexity of the gold coin or potion bottle from lab 3. Used a few learned manipulation techniques such as those listed in excellent criteria.

Acceptable (2) Acceptable quality 3D model at the complexity of the gazebo from lab 2. Used one or two learned manipulation techniques such as those listed in excellent criteria. Poor (1)

Poor quality 3D model that simply uses primitive shapes arranged into the shape of an object, with no learned manipulation techniques used.

None (0)

Blender Asset #1 not submitted.

Blender Asset #2 (4 marks) Creation of the second 3D Model in Blender using learned manipulation techniques. Models created following the lab exercises do not count towards this submission.
Excellent (4)

High quality 3D model with multiple parts at the complexity of the treasure chest from lab 3. Used many learned manipulation techniques such as extrude, loop cut, modifiers, inset faces and materials.

Good (3)

Good quality 3D model at the complexity of the gold coin or potion bottle from lab 3. Used a few learned manipulation techniques such as those listed in excellent criteria.

Acceptable (2) Acceptable quality 3D model at the complexity of the gazebo from lab 2. Used one or two learned manipulation techniques such as those listed in excellent criteria. Poor (1)

Poor quality 3D model that simply uses primitive shapes arranged into the shape of an object, with no learned manipulation techniques used.

None (0)

Blender Asset #2 not submitted.

 

 

 

After thinking of a game concept in Part A, writing a prototype plan, 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:
    • View the selection of previous student prototypes available in the Moodle Assessments section.
    • 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.
    • 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.
    • 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:
    • 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).
    • 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.
    • 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 (as shown on next page):
      • 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.
    • 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:
    • Input Events: Input supplied by the player via controls. Examples:
      • Push a keyboard key or mouse button to open a door, pick up an object, shoot a gun, or throw a grenade.

 

  • Collision Events: 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.

 

  • Collider Trigger Events: 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.

 

  • Update Events: Artificial Intelligence programmed to execute code regularly. Examples:
    • Enemy scripted to moves towards the player slowly – Enemy has a set patrol path.
    • Enemy shoots towards player location.

 

 

 

 

Remember: the core mechanics and scripted events of your game will really show proof of your game concept in the prototype assignment.

  • 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. (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:
    • 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.
    • Scenes – This folder already contains a blank scene called “MainScene”. Your main prototype scene must be built in this scene. Store additional scenes created by yourself in this folder (if any).

You cannot download and use pre-built scene assets. Your scenes must be constructed by yourself. o          Scripts – Store all C# scripts created by yourself within Unity/Visual Studio.

  • <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:
    • Unity Store Assets – To store any assets downloaded from the Unity Asset Store.
    • 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.
    • 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 2020.3.5f1 to build and edit your project. Instructions to install this version in Moodle.
  • If you do not follow these requirements, your game may not function correctly for the marker, you will lose marks and receive penalties to your score.
  • 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.
    • 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).
    • Unity Store assets sourced online MUST be placed in the “Unity Store Assets” project folder in Unity. This includes Unity’s own “Standard Assets”.
    • These assets should be used appropriately within your prototype to flesh out your scene objects. oYou 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:
    • Animators. Examples: Opening doors, moving platforms, premade animations. Keep it simple. o Rigidbody for objects requiring physics behaviour / physical collisions.
    • 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:
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.

Part C Submission

When you downloaded the project template for this assignment from Moodle, you should have renamed the project as your student number followed by the name of your game (example: 30126565-ThunderRun).

  • Locate this Unity project folder.
  • If you are not sure where you placed it:

 

 

  • ZIP the Unity game prototype project folder (the entire contents will be zipped with it)

If you do not submit your complete Unity Project folder (the source project folder/files that the marker can open within the Unity engine), many criteria of your assignment cannot be marked!

We need to be able to view everything (objects, components, scripts, etc.) in close detail!

  • Note: As Moodle has a 100mb Moodle upload limit, special instructions to upload your ZIP and your brief report are contained within the Moodle submission link. Please follow them carefully.

o    Be sure to begin uploading early, as large files may take a while to upload.

Part C Marking

The marking rubric on the next page assumes that everything in your prototype is working – except prototype features you have specified in your report as a known bug or limitation of your prototype that was too difficult to fix. For example, if a game mechanic is broken, objects collide with no event triggered, or an interface element does not update correctly, then the awarded score for that element may be lower (depending on your report and the complexity of the unfixed problem) than if it was working.

Firstly, markers will look at what you have developed by looking at all of the parts that make up your scene(s), including the arrangement of objects and their components, and the use of scripts and their interaction with objects and interface. The marks are also based on the level of complexity introduced in the lab work. For example, if you developed a prototype as complex or more complex than the Lab 9-10 example, you should score well.

Secondly, markers will actually play through and review your prototype. Creativity, unique mechanics and aesthetics will help to determine your marks. If you simply replicated a scene similar to the lab work, these criteria may score lower than a more creative and interesting prototype.

Part C Feedback

The marking rubric on the next page shows a scale from excellent to poor, and a zero for not meeting a criteria. Some criteria contain multiple conditions. You need to meet all conditions of that criteria to receive that rubric mark. For example, “Scene(s) and Objects” has four conditions per rubric score. To get Excellent, you must meet all four conditions in that criteria.

Read it carefully to aim for higher grades. You will receive marks and feedback within two weeks of submission, uploaded to your Moodle submission.      

Part C Marking Rubric

Criteria                                              Details                                                                                                                                                    
Scene(s) & Objects (6 marks max) This considers the level design, appropriate placement of objects and chosen materials, and usage of prefabs, in relation to lab complexity.
Excellent (6)

•   Scene well-constructed by the student with great placement of objects (including Part B assets) to fill out the prototype area.

•   Good use of Prefabs to create instances of objects used multiple times.

•   All objects have well-chosen materials for the style.

•   Quality surpasses labs.

Good (4.5)

•   Scene well-constructed by the student with good placement of objects

(including Part B assets) but could still be improved.

•   Good use of Prefabs in most cases to create instances of objects used multiple times.

•   All objects have at least OK materials for the style.

•   Quality matches labs.

Acceptable (3)

•  Scene constructed by student could use more attention, with more objects to fill out the prototype (including Part B assets).

•  Prefabs used in some cases to create instances of objects used multiple times.

•  Objects have at least usable placeholder materials

•  Could be improved to lab quality.

Poor (1.5)

•   Scene is constructed by student but is lacking in thought and object placement.

•   Prefabs not used.

•   Objects are missing materials.

•   Not representative of this course level.

None (0) Scene missing, empty,

OR downloaded (not created by student).

Components (2 marks max) Components should be used on objects appropriately, such as: Rigidbody (physics), Colliders (physical), Colliders (triggers), Text/Buttons (UI), Animators (object animation), etc.
Excellent (2)

•   Excellent use of many components to control physics, collisions, triggers, UI, audio, etc.

•   Objects act as expected.

Good (1.5)

•  Good use of most components to control physics, collisions, triggers, UI, audio etc.

•  Objects act as expected most of the time.

Acceptable (1)

•  Passable use of some components to control physics, collisions, triggers, UI, audio, etc.

•  Some objects may act unexpectedly.

Poor (0.5)

•   Components beyond transform and mesh renderer are used sparingly

•   Objects are not acting as the player would expect.

None (0)

•   No components on objects OR

•   Only transform and mesh renderer used.

Scripts (Controller) (2 marks max) This criteria focuses on the C# script(s) used to control the player (Player Controller). It may be created by the student (for higher marks) or a standard asset/Unity store download, but it should function well.
Excellent (2)

•   Player controller was created by the student (not a downloaded or standard asset controller).

•   Player control works as expected all of the time.

Good (1.5)

•   Player controller was created by the student (not a downloaded or standard asset controller).

•   Player control has some issues.

Acceptable (1)

•  Player controller from standard assets or Unity store was used appropriately for their prototype

•  Player control works as expected all of the time.

Poor (0.5)

•   Player controller from standard assets or Unity store was used for their prototype

•   Player control has some issues.

None (0) Player control does not function.
Scripts (End Condition(s)) (1 mark max) When player completes (or wins) the prototype, scripting should control the notification to the player. Optionally, if losing is involved, it should also output this to player when they lose.
Excellent (1)

When prototype is completed/won (or optionally lost,) the player is correctly notified.

Acceptable (0.5)

Attempts were made for completion/winning (and optionally losing) conditions, but it does not function correctly.

None (0)

No attempt at end conditions.

Scripts (Interface) (2 marks max) A basic on-screen interface is expected such as Text interface (eg. score, health, bullets, timer, dialogue) that updates appropriately via scripted events. This is separate to the end condition script(s).
Excellent (2)

Visible on-screen interface works and updates appropriately via script. Designed impressively.

Good (1.5)

Visible on-screen interface works and updates appropriately via script. Designed a bit more interesting than default UI styles.

Acceptable (1)

Visible on-screen interface works and updates appropriately via script.

Uses default UI styles.

Poor (0.5) Visible on-screen interface is implemented but is static and does not update via script. None (0) No visible on-screen interface at all.
Scripts (Triggers/Events) (3 marks max) In addition to player controller, end condition(s) and interface updates, the prototype requires three working scripted triggers and/or collisions for maximum marks in this criterion.
Excellent (3)

Use of at least 3 studentcreated triggers and/or collisions to create multiple game events that are functioning correctly.

Good (2)

Use of at least 2 studentcreated triggers and/or collisions to create multiple game events that are functioning correctly.

Acceptable (1)

At least a single use of a student-created trigger and/or collision to create a game event that is functioning correctly OR

Attempts have been made by student to create triggers and/or collisions but they have issues functioning.

None (0) No attempt at a studentcreated trigger and/or collision.
Criteria                                           Details  
Scripts (Commenting) (1 mark max) Comments should be used in student-created scripts to give concise summaries of each method/function.  Also place your name and student ID at the top of your scripts.  
Excellent (1)

English comments used appropriately to summarise methods/functions.

Acceptable (0.5)

Some English comments used to summarise methods/functions but could be improved.

None (0)

No comments or different language comments are present in student-created scripts.

 
Game Mechanics (2 marks max) Review of the actual game mechanics at a prototype level (it should reflect a playable prototype with a clear ending/win condition)  
Excellent (2)

Excellent mechanics show off great attention to gameplay and address the game concept, with a clear end to the prototype.

Good (1.5)

Good mechanics to relevantly address the game concept, with an ending to the prototype that may not be clear.

Acceptable (1)

Passable mechanics that give an indication of the game concept, with unclear end to the prototype.

Poor (0.5)

Some mechanics are present but poorly presented and

difficult to relate to the game concept.

None (0) No working mechanics.  
Aesthetics

(2 marks max)

Aesthetics should be unique and interesting to support the world/environment design of your game. Replicating labs aesthetic is worth less marks.  
Excellent (2)

Very unique and pleasing aesthetics relevant to your game world and setting.

Good (1.5)

Pleasing aesthetics relevant to your game world and setting.

Acceptable (1)

Aesthetics are relevant to your game world, but lack originality or are very similar to labs.

Poor (0.5) Aesthetics are of low quality, they represent poor design and lack originality. None (0) Scene missing or empty.  
Creativity

(2 marks max)

Creativity should reflect all unique aspects of the game. If you go beyond the labs, creativity should be awarded higher.  
Excellent (2)

Prototype went beyond expectations set out by the labs. Very creative and unique distinguishing it apart from all other prototypes.

Good (1.5)

Prototype went beyond expectations set out by the labs. Some creative and unique elements distinguished it apart from most other prototypes.

Acceptable (1)

Prototype was about as creative as the labs. It had little uniqueness to distinguish it apart from some other prototypes.

Poor (0.5)

Prototype was less creative than the labs and/or was a very generic game prototype.

None (0) Scene missing or empty.  
Brief Report (2 marks max) Report should use the template with all sections filled out correctly. All sourced assets from the Unity Asset Store require a link to the exact source webpage.  
Excellent (2)

Uses template with all sections filled out correctly.

Acceptable (1)

Uses template but criteria could be addressed more clearly.

Poor (0.5)

Does not use template and/or much of the template is missing required data.

None (0) No report submitted.  
Penalties 

(up to minus 5 marks)

If you do not use the correct version of Unity, the provided project template and/or sort assets within the organised folder structure, penalties will apply!  
No Penalty (0)

Unity version, Template project and folders were used correctly, and asset folders organised as per the instructions.

One penalty (-2)

1 of the following not correct: Unity version, Template project, and asset folders organised as per the instructions.

Two penalties (-3.5)

2 of the following not correct: Unity version, Template project, and asset folders organised as per the instructions.

Three penalties (-5)

All of the following not correct: Unity version, Template project, and asset folders organised as per the instructions.