Dun dun… DAAAAAAAAH! This is it, folks. The last and final assignment for this course. The big burrito, with a side of all the chips – your very own game. This one is worth a little over 25% of your grade for the course, so make sure to read the directions carefully. You don’t want to get caught on a technicality!
As discussed in class, the final assignment is for you to make your own, complete game. There are two paths that you can choose for this – continue to develop the Platform Game , or create your own Original Game. Your project will be due by Friday 12/9 @ 1:00pm. Instead of a Final Class, we will have a Final Showcase where students are encouraged to show their designs.
In this option, you continue to work on your Platform Game to make it a fuller experience and build on the work that has already been accomplished. If you are nervous about your Unity skills, this is definitely the safer option of the two.
For this option, you will design and create your own Original Game. This is the riskier option; you have to propose a game – and then actually make it. There are less constraints to this, as you get to define what the game “is”, but it should still be a complete game. Only choose this option if you are feeling comfortable with Unity and know that you can dedicate extra effort to your work.
Project Grading Criteria
The grading for this project will be more subjective than in previous assignments, meaning that projects will be evaluated more upon the quality of their performance across a number of categories (outlined below) as opposed to whether individual requirements were technically met. That said, there are still requirements and failure to complete them will negatively impact your grade. Whichever option you choose, please note that there are some requirements that apply to both. Make sure you read all of the items carefully!
Art / Aesthetics
Does your game have a cohesive aesthetic? Do the parts “fit” with one another? Do they support the story or experience that you are trying to deliver? This category covers the appearance of your game – how well it is designed, and how well it is executed. Choose fonts that fit your game (make sure that you are not using default fonts such as Arial).
Attribution is important. Make sure to include attribution credit for assets that you did not create. This should include the name of the asset (or something to identify it by), the creator, and a link to where you found it.
Your game should have a cohesive sound design, appropriate to the style of game that you are seeking to create. Sound is important to set the mood, inform the player, and make the world come alive. Your sounds should be balanced, meaning that volume levels should be set so that sounds fit with one another, and important sounds are not lost behind ambient or background clips.
Your game should be fun and interesting, with a simple and strong core loop. Gameplay should be well-balanced and tuned towards an experience that most players can enjoy. You’re looking for the “Goldilocks” approach here – not to hard, and not too soft. Challenge your player, but don’t make them quit in frustration. Your game should be user-friendly, meaning a player should understand what they are supposed to do, and how well they are doing it. User Interface is clear, informative, and easy to comprehend.
As this course has been all about getting things to work, what you create should reflect that mastery of the tools. This means that your code should be bug-free (or as close as you can get it), without obvious errors or missing components. Your game be the product of strong, iterative development, and should feel like time was taken to test and improve the quality. It should not feel rushed, or feel like it was thrown together at the last minute.
FOR ALL PROJECTS (both options):
ITEM 1: Complete Game
Your game must be a COMPLETE game. That means it should have a beginning, middle, and end states. This is not a prototype, so polish definitely counts. The user should have the opportunity to start the game, and should understand what is happening during the game, and know when it is over (and why). You should be able to return to the title menu after a win or loss.
ITEM 2: User Interface Menus
Your game must have the following working menu screens or function buttons:
- Title Menu
- Credits (with attributions!)
- Tutorial or How-to-Play
ITEM 3: Project and Working Build
Your assignment must be submitted in two ways – a zipped version of your project folder, and a zipped version of your build.
- These must be separate zip files. Do not package your build inside of your project folder.
- The build must work on the intended platform. Please make sure you test your build before you submit.
ITEM 4: Gameplay Video
One new deliverable, a screen capture video of at least 60 seconds of gameplay for your game. This capture should be of the final (or very near final) asset, and should show at least one successful completion of your game loop.
This file must be saved either as a mp4 or mkv format file, and submitted in your Assignment Folder alongside the project zip and build zip.
ITEM 5: Attribution of Assets
You must include attributions for any assets that you did not create yourself. Include this in your “credits” page, as well as in a readme.txt (or .docx) file that you include in your assignment folder. Attribution should include the name of the asset, its creator, and a link to where you got it.
Platform Game Requirements
The Platform Game will be required to have the following:
- 5-8 minutes of gameplay to complete
- Three (3) levels of regular play + a Boss Level/Fight. (Each level must be its own separate scene)
Original Game Requirements
The Original Game will be required to have the following:
- 3-5 minutes of gameplay to complete
- Game Pitch Proposal (due 11/12)
Game Pitch Proposal
If you do want to create your own game, you must first get approval for that game. This step is to ensure that your creation is within a reasonable scope for this class, so that you have an appropriate amount of time to complete your game. You must submit a Proposal Document to Canvas by 11/12, and this document will be reviewed and either approved, conditionally approved with feedback, or denied. The earlier you can submit your document, the better.
The Proposal Document must include:
- Game Concept – what are you creating? Outline the game, mechanics, and core loop.
- Reference Images – images or sketches that illustrate your game concept
- Expected Technologies – how are you going to make this? Outline the expected features, methods, or tools you anticipate using to accomplish this.
Your Final Project is due by Friday (12/9) at 1:00pm EST. Create a folder labeled Final Assignment in your Box directory and submit the following deliverables:
- a compressed (zipped) version of your project directory
- a compressed (zipped) version of your application or executable (with support files)
- a readme.txt file containing attributions for your assets
- a gameplay video (.mp4 or .mkv)
If you are choosing to work on the Original Game, a Game Pitch Proposal document is due via Canvas by Thursday, 11/10.