Project 1
— GAD170 —
Embedded Files
Table of contents
References are located at the bottom of this page.
Pre-Production
Pre-Production
Overview
Overview
This is the introductory project to GAD170.
In this project, I use Unity, a 2D/3D game engine, to create my first prototype game. The purpose of this brief is to learn how to use the Unity engine and understand the basic fundamentals of scripting with C#.
The prototype game consists of some very basic game mechanics, such as picking up coins and opening chests, with some extended features of these mechanics such as variation in the coins (silver and gold coins with different value between the two) and a criteria to open the chest (a level requirement to open the chest and a random chance to pick the lock successfully).
Our hero of this project is the bold, mighty and most certainly bald (don't tell him I said that) Super Blox Man, and his even mightier brother, Super Duper Blox Man! They are the player controllers that can be moved around the game world. You can see Super Blox Man in the picture to the right of this text—just look how handsome he is. Also, no, that's not a Pinocchio nose, it's a pointer.
Brief Information Document
Brief Information Document
This is the document that I use to see all of the brief's information from multiple sources such as the Axis page and unit site in one place, plus any important extra information or useful sources that I may find worthy to hang on to.
This document isn't at all necessary to the brief, but I made it for the sake of organization as the information for this project is spread out between three different locations:
The Axis page;
The week 2 page of the unit site; and
The week 9 page of the unit site.
Production
Production
The Entrée Before the Main Course: The Park Level
The Entrée Before the Main Course: The Park Level
Before the main level of the project—the City level—was even conceptualized as an idea, the main level of the project was the Park level.
Pictured to the left, the Park level was a small but overly-detailed level created for the basic player controller, Super Blox Man, as both a test level and a level designed to see how nice I could make a level look using primitives and Unity's particle system. In my last trimester, I created levels that were nowhere near this level of detail, as they were very simple levels with a few plane, a few walls, a few platforms and a tall climbable capsule, among other things.
This level is fully explorable, but because it was only a test level, no scripted events are present in this level.
My use of Unity's Post Processing Stack v2
Unity's Post Processing Stack v2 is a package that allows you to add image effects into your project, such as chromatic aberration, lens distortion, bloom, grain, ambient occlusion, etc. These kinds of effects are used in games to add more detail to the scene and, in cases like Resident Evil 7, can even add to the atmosphere and overall feel of the game. If used right, these effects can make your game look better and can simulate that of a cinematic camera; if used wrong, it can make things in the game world harder to see and just make the whole scene look like a complete mess (I'm looking at the people who increase chromatic aberration by unnecessary amounts for no good reason other than the fact that they think it'll make it look better, which it doesn't).
Park level without Post Processing Stack
Park level with Post Processing Stack
Before coming to SAE, I have used Unity's Post Processing Stack to add image effects to my personal game projects, which is how I learned how to use it and where you draw the line with the effects before it just becomes an eyesore. I created my own preset of image effects that was inspired by games like Resident Evil 7, Silent Hills P.T., Alien Isolation and Star Wars: Battlefront 2 (the 2017 release). Even though it wasn't necessary at all, I decided to incorporate the Post Processing Stack into this project to spruce up the visuals a bit, and I'm quite fond of the result, even if it's paired with a level of primitives that have developer textures on them.
The hero for this level: Super Blox Man
Super Blox Man is the first variant of the player controller that I created using the script provided to me. Super Blox Man has only the basic functions, which are moving around and turning, plus a strafing mechanic I decided to include on my own accord to make movement less clunky. Unlike Super Blox Man's mightier brother, Super Duper Blox Man, Super Blox Man doesn't have the ability to jump, pick locks, gain XP and level up.
Super Blox Man's code is pretty basic, with only 49 total lines of code, 15 of which don't even contribute to any of Super Blox Man's abilities in any way. I created a page on this learning journal where I went further into detail about Super Blox Man's code, which you can access using the button below.
The Real Meat and Potatoes of this Project: The City Level
The Real Meat and Potatoes of this Project: The City Level
This is where all the magic happens! The City level is the level I created right after the completion of the Park level, and is the level that contains all of the requirements for the brief; you could say this is the magnum opus of this project, and you'd be right.
Pictured to the left, the City level is a larger and more detailed level compared to the Park level. The original idea for this level was that the player would be able to jump on floating platforms, collecting coins, and climb their way up to the top of each build, where they could then open chests of varying difficulty and collect more coins. This idea was scrapped for the current, simpler idea due to time constraints.
The street shown on the left is fully explorable. Behind where the final platform where the chest is, the city extends sideways with a three-way junction, but only enough so the player can't immediately see outside of the city into the void. This was only done for extra detail, and to stop the player from going to this area and being able to fall into the void, an invisible wall stands in the way.
The pickups of the game: Coins
Coins—the objects in this world that make the world go 'round (metaphorically speaking), and just like real life, they're very important in this level. When you collect coins in this level, Super Duper Blox Man gains XP and can level up by gaining that XP, which increases his lockpicking skill. You must collect all of the coins in this stage and not miss one to be able to even have a chance at unlocking the chest at the end of the stage.
The models for the coins were ones I made back in trimester 1, and I just yoinked those models for use in this project. I made two versions of the coins: the silver coin (worth 1 XP) and the gold coin (pictured right, worth 5 XP). The coins not only use a script to allow the player to pick them up, but also to continuously rotate on its Z axis. You can see my breakdown of this script with the button below.
The prize at the end: The gold chest
The chest—basically the princess at the end of King Koopa's castle for this game. The chest is the one main deciding factor on whether you win or lose the game, as opening it means you win the game, while failing to open it before the timer runs out results in a game over, throwing you back to the start of the level again.
The model for this chest is also a model I created back in trimester 1, that of which I may have spent a lot of time on but am quite proud of as it is a pretty nice-looking chest model, albeit a bit basic. When you go to open the chest, you must have a high enough level to be able to try and lockpick it, which can only be achieved by obtaining all the coins in the level. When you are a high enough level, the chance of successfully unlocking it is random, and when you do open it, some coins appear outside of it and you win the game.
This chest does a lot more than just that, though, which you can see in my dive into the code with the button below.
The hero for this level: Super Duper Blox Man
Meet Super Blox Man's better, bolder, mightier and even balder (not really, they're both equally as bald) brother, Super Duper Blox Man! Super Duper Blox Man can do everything Super Blox Man can do, plus more!
Super Duper Blox Man is the more advanced player controller that I created with the script provided. He has the same functions as his weaker brother, such as moving, turning and strafing, but also has his own functions, such as sprinting (which was something I added on my own accord), jumping, picking locks, gaining XP and leveling up. He also has a bright gold pointer to reduce the visual similarities with his weaker brother, who has only the blank material. The "advanced" in "advanced player controller" becomes apparent when you see that Super Duper Blox Man has a total of 185 lines of code in total, compared to Super Blox Man's 49.
Just like with Super Blox Man, I went into further detail about Super Duper Blox Man's even longer code, which you can access with the button below.
Builds of the Game (And How to Play Them)
Builds of the Game (And How to Play Them)
How to play
As said before, this level doesn't really have an objective, and Super Blox Man (the hero for this level) only has the basic abilities for a third-person player controller. All you can really do in this level is walk around and look at the pretty basic but also overly-detailed-for-this-project's-requirements environment. The control scheme is very simple, which is shown below.
Look for the note. Don't tell anyone else.
The City Level
If you want to try out this city level for yourself, you can download the latest build for it on the right. Just like with the park level, this build is only compatible with Windows, and you still don't need a beefy PC to run this, although there might be a tiny difference in performance if you're running on an older system because of the extra content.
I recommend downloading the second build (Build 2) as that is the build that contains the latest features and has had the most amount of bug-squashing.
How to play
As is, the game loop requires the player to pick up all the coins, so that they level, which means their lock pick skill is high enough that they can lockpick the chest. If they run out of time, the game restarts. The control scheme is more advanced than it is for the park scene as you control Super Duper Blox Man in this scene who has more abilities and controls than his weaker brother, Super Blox Man, which you can see below.
Post-Production
Post-Production
Reflection for Project 1
Reflection for Project 1
How did it go?
What?
What?
To start off with, in this project, I had fun. This was a project that I had already done in trimester 1, so even though I didn't use a lot of stuff from last trimester (in terms of learning journal stuff and some in-engine assets), I was armed with the knowledge of what to do.
I went above and beyond in this project, basically doing what I had to do and more—a lot more. With some of the things like the models for the coins and chest, I had already made some good models for those in my previous trimester, so I just downloaded those from my Google Drive and imported them into my project, along with their respective scripts. I also took the scripts from my Google Drive as well instead of from the Unit Site as my versions of the scripts already had modifications that I made to them such as strafing in my Player Controller scripts. For everything else, such as the city level and the platforms used in it, I made it from scratch.
The main problem I had with getting this project in on time was my inability to balance the workload from my two modules efficiently, so once I made some good progress on the initial development stage of the city level, I shifted my focus to my CIE work and didn't shift it back until way later. Once I did shift my focus back, oh the progress I made. I went from only having the road and footpath done to having the whole city done with four different building designs, then the platforms, and then the scripts alongside everything else. I felt very proud of the work I managed to achieve when I built the game for the last time, because even with a really simple prototype game that was expected, I managed to make it look and play good, which was something I was trying to achieve.
The consequences of really putting in the effort for this project was doing too much for my time constraints. I forfeited a lot of project time for my other projects, but I don't really regret putting in that extra effort to making this project something I can be proud of, even if it was just a simple prototype game. My favourite part about the experience was designing the level using primitives. I had fun designing the buildings to add variety to the level in the City level, and making the Park scene look really nice with things like falling leaves using the particle system.
So What?
So What?
The way that this whole project turned out tells me that I'm a person that prefers quality over quantity which, while that may seem like a good thing in that I won't be trying to crap out bad games in the future, isn't a terribly good thing if we're putting time constraints and the need for proper project scoping into the equation. As I said, the main reason why I fell behind with time was because I had difficulty juggling the work for CIE152 and the work for GAD170, but I feel that some of that was also caused by the large scope I had for this project which may not have been necessary.
The main reason why I went quality over quantity on this project was because I wanted to make my prototype game as least rusty as possible. This could have possibly been done out of the fear of mediocrity, which basically means I was afraid that my work was going to be nothing special and just the bare minimum to succeed, which was something I really did not want. If I was going to work on this project, I wanted to make it mine and I wanted to be proud of it, which is exactly what happened. I probably should've just eased up on that mindset a bit and saved it for a project in a later class such as for the microgames class, but at the same time, that's basically telling me "make a game, but don't make it good and don't add your own personal touches."
Some of the positives in this project was me having fun with creating the levels and the game, getting to play around with some things like the Post Processing Stack and really making it work in this game (among other things such as features done through scripting), and making one nice big learning journal page containing my burst of creativity. One negative I had was with time management, I really did not feel good with the way I handled time and with how I balanced the projects from both of my classes.
Now What?
Now What?
I think from this point, what I should do is continue with the quality over quantity mindset, but just turned down a bit to the point where I'm not dragging myself down further into the mud by spending a lot of time on one thing. Because of the very tight time I have with project 2 and 3 as of writing this reflection, I might have to compromise a bit with those project to get those projects done and pushed out the door, and that's going to suck, but if that means I get the project out there compared to leaving it too late and missing the mark, it's just what I might have to do. With the time management, I think a good way to solve my issue is to create a planner and plan out the days where I'm going to be working on a project, so that I'm just switching between the two classes without any coordination.
Page updated
Report abuse