Project 2
— GAD181 —
— GAD181 —
Table of contents
Part 2: Project Management & Mid-Project Reflection
As we have continued to work on this project, plan more microgame ideas to implement into our project and have met as a group more times to work on the project together outside of class, we have updated the game design/planning document as we've come along to record our ideas, meeting minutes for group meetings, as well as anything else that should be recorded.
Over the past few weeks, the team has been trying to expand on the ideas of each microgame in each of the three phases of the game with the microgame's story, what the player's objective of that specific microgame will be, what mechanic will be used and what controls will be presented for the player to use.
As the team is continuing to develop the project and introducing more ideas into the game, we have been keeping track of the increasing amount of tasks required for the project, whether it be for assets or for scripts.
Click on the image above to access the team's HacknPlan. Alternatively, if that doesn't work, use the button below.
This is the main Google Drive directory that the project uses, and that the entire team shares. As we have continued to work on the project, we have documented more aspects around the project, relating to both the game project itself and also the team (with things like meeting minutes, burndown charts, etc).
We also have an assets folder to store all of our external assets such as the 3D models for the cast of the game, which also serves as a backup in case we lose the asset files on any of the machines or if we need to copy any assets over to another machine.
Two things worked well for the group in week 5: Ronan's multi-button mash script, which functioned very well, and the 3D modelling done by Andrew and James. These came along really nicely and allowed us to get more work done with the microgames.
The things that could be improved are with the communication and direction within the team, and with GitKraken. I noticed that quite a portion of the team didn't really know what they were doing at times, also including me, and there was still an issue with communication and unavailability. We were also having the issue of not updating the HacknPlan more often when we completed tasks, which also factored into the communication issue.
Next week, we'll try to make our communication skills and availability better and we will also try to better learn how to use GitKraken as a group.
This time, the thing that went well for the group was the majority of the scripting. Frazer modified my PlayerMovement script to make it work better with collisions, and the rest of the scripting was up to scratch with the project.
The main thing that could be improved would be with HacknPlan. People are still not updating the HacknPlan when they work on tasks so there is still a communication issue. There also still seems to be a general communication issue in terms of people not talking to each other, and I found that I'm also doing the same thing as well. I'm also still finding it hard to figure out what to do at times, so that could use some improvement.
By next week, we will try to all come in and get a good portion of the work done because, as it turns out, not a lot of the group have computers at home that are capable of running the project. We will also try to merge the GitKraken branches into the main branch so everyone has their project updated with all the new scripts and assets.
This week, we managed to successfully merge all the branches on GitKraken into the main branch without much of an issue, which was great for the group. We will now create our own branches again and do another main merge in a few weeks time. We're also learning how to better use GitKraken, which is making our lives easier.
For what could improve, communication also seems to be getting a bit better, but there is still one or two people in the group that are having issues with their Discord notifications and aren't checking the Discord.
Next time, we need to try and make sure that all the scripts in the project are up to spec and the levels are actually playable, so that Ronan can start joining them all together using the BaseGameManager.
Throughout this project, the team has been getting together for meetings out of class to work on the project, discuss anything about the project or give an update to the group about anything, etc. After these meetings, a member of the group records the fact that we had the meeting on the day, and then records what we talked about or did.
Shown in the picture to the left is all the meetings the group had between week 5–8. These meeting minute records can be accessed from the game design/planning document.
How's it going so far?
Process: How are you planning your processes to achieve outcomes within the project timeframe? How are you managing your priorities and tasks and responding to changes or challenges? Give specific examples of your research and how it informs your project. Cite sources in APA7.
As we've continued to work on the project, we've found that the amount of load required to get the project up to the point we originally planned would be too much for us, and we simply don't have the time for it, so we decided as a group to reduce the scale of the project. One way we did this was by designating some of the microgames as unimportant, so we would be able to take them out of the game without affecting it too much.
For this part of the project, now that we were focusing more on the project itself rather than the documentation for it such as the GDD, as well as the fact that we're now using GitKraken more than ever, the whole group needs to keep in steady contact with everyone so that nothing is missed and everyone is up to date with everything. I am checking the Discord server more often and have set my notifications to "all" so that I will receive notifications for all messages sent in the server so that I don't miss any.
With feedback, I've been listening to feedback given by my teammates and have been trying to adapt my work accordingly. For example, there was one 2D asset that I made for Frazer that was not up to his specification when he saw it, and he made this clear to me, so I dealt with this feedback by making sure to ask him for more details when he asks for a 2D asset, so that there's no confusion.
I'm doing okay with the current skills that I have now, that being coding, design and drawing skills, but I think my skills could be a bit better. For one, I think that I should learn some more drawing techniques so that I don't end up making 2D assets that look like they were made for some crappy Flash game from 2001. I think a new requirement that is arising, due to the size of our project increasing and the amount of files and assets involved growing, is file management and organisation. I think the team and I need to employ some good file management techniques so that the files aren't all over the place and are nicely organised so that they can be found easily.
The first contribution I made to the project in terms of asset creation is the base PlayerMovement script. I made this script using code that was partly based off the movement script I learnt from GAD170 last trimester, most prominently the HorizontalMovement and VerticalMovement functions. This script had the ability to move on a horizontal axis, move on a vertical axis and jump, and it also had changeable speeds of the moving and jumping abilities.
Image: Snippet of the main part of the code that calculates the movement.
Image: The script's component in the inspector.
The good thing about this script is that it's relatively easy for the group to understand and easy to use and adjust. I made this script to be not only customisable, but also hot-pluggable at the request of the group, which will allow any member of the group to create a new scene, create a GameObject to serve as the player object, and then attach this script to that player object and make it work instantly (aside from the fact that they'd need to set the move speed and jump height) without the need to set anything else up first.
However, I did find an issue with the method I used in this script to calculate movement, which was using Transform.position to manipulate the position of the player object. This does the basic job of moving the player on the chosen axis (horizontal, vertical or both, chosen in the inspector) around the scene, but it does not do well with collisions. Transform.position being used in player movement, as I later found out, is like teleporting the player a smidge forward every frame instead of properly moving them forward, which makes it relatively easy for the player object to phase through walls.
Because of this, Frazer modified my original PlayerMovement script to replace the Transform.position functions in the calculation to the Rigidbody.velocity, and we found that that works a lot better with player movement rather than the original method.
While the base script is good for general use, one scene in particular that I was working on (see the "Game Levels" section at the bottom of this learning journal part for documentation on the production of that level) required more functionality through scripting. Because of the fact that the other scenes in the project also used the base PlayerMovement script, and because I believe that coding the functions for specific scenes into the base script is bad practice, I made a new script called FarmerMovement script, which inherits from the PlayerMovement script and has its own set of functions for use only in this scene, Scene 1.2.2.
Image: Snippet of the code for the TimedStartOfGameEvents UnityEvent and making sure the famer sprite is facing the right way when moving.
Image: The script's component in the inspector. This is connected to the PlayerMovement component as this script inherits from that script.
The specific functions for this level that this script provides the code for include:
Control of the prompt text and win/lose text, including the duration that it stays before disappearing;
Control over the events that occur when the microgame starts and finishes;
Ensuring that the player sprite is facing the direction that the player is currently moving in; and
The state of the horse sprite, which switches between a sick horse sprite and a healthy horse sprite.
This timer prefab was a prefab I created last trimester, for my project 1 in GAD170. I decided to reuse it in this project as the prefab in of itself has a level of polish that I believe should be present in this project. If you think it's a dirty trick to reuse old assets for new projects, many video game studios do the exact same thing—in fact, here's an example of Valve doing the same thing, presented by CrazyGiaky (2021) on r/gaming.
The timer is simple. When applied to the scene, the timer will count down starting from the value that was inputted in the inspector, and when it reaches zero, it will invoke the TimeUp UnityEvent to make something happen. The timer also uses Mathf.Ceil to return the smallest integer greater to or equal to the number, so that it only displays a whole number instead of an entire string of decimal numbers.
As an extra coat of polish, I also coded in a colour changing feature that depends on what the status of the timer is and how much time is left on the timer. In my project 1 for GAD170, I made the timer flash red and white when it hits 10 and starts counting down, to give a sense of urgency. In this project, I added some further polish by making the colour of the timer dim if the timer has stopped. I did this by creating a StopTimer boolean and having the code check to see if that boolean is equal to true, in which it will then check to see what the colour of the timer is and dim it accordingly.
GIF: The timer in action in Scene 1.2.2.
Image: The Timer component in the inspector.
The first scene I worked on, Scene 1.2.2, required custom 2D sprites to feed into the plot point of it being part of a crappy animated movie, and having created a good number of drawings of people and places in my free time in the past, as well as being part of an architecture art class in high school, I have just the right amount of knowledge and skill to be able to take on the 2D Asset Designer role.
The first sprite I made was the background sprite, shown to the right below the character sprites. This sprite depicts the farmer's ranch, with the barn positioned a fair distance behind it and a fenced path that connects the ranch to the barn and leads off into the distance. I made this background sprite using a Wacom One drawing tablet provided by the campus during class time, and I was able to make it in around an hour's time.
Image: Sprite of the farmer holding a medicine bottle.
Image: Sprite of a sick horse, with the sickness represented by the green tone.
The next sprite I made was the farmer's sprite. I decided to try and go for a more simple, cutesy animated style to both fit the background and the plot point for this microgame. I created this sprite using the Sketchbook app on my iPad, as I didn't have access to the campus' Wacom One tablet at the time. The farmer sprite consists of a farmer that has green eyes and brown hair with a bit of a plump face, and is wearing a flax sun hat and a red collared shirt with blue overalls, and holding a bottle of medicine for the horse. I was originally going to create additional sprites for the farmer moving, but I didn't have enough time in the project and in my schedule to do that.
The last sprite for this scene was the horse sprite. This is the only sprite in this scene that I didn't make from scratch, as I used a picture of a horse from PNGitem, created by Adam Duke (n.d.). Before editing the horse in Paint.NET to add the green filter and googly eyes, I erased the penis from the horse picture as it was an unnecessary detail that, frankly, didn't really belong in our game.
Image: Background sprite for the ranch that Scene 1.2.2 takes place on.
The next scene I worked on was Scene 1.2.X (named that way by Frazer because we didn't know what order it would be in). These 2D sprite assets were requested by Frazer, who was working on the scene.
The first sprite I made was a modification of the farmer sprite. This sprite consists of the farmer from Scene 1.2.2 on his knees, and even though it isn't shown here, the intent is that he is milking the cow's udder.
Image: Sprite of the farmer on his knees, milking the cow's udder.
Image: Sprite of the cow.
The next scene I made was the cow sprite. The sprite consists of a cow with brown eyes, white skin and black spots, and a happy expression on its face. I tried to go for the same kind of simple, cutesy artstyle as the farmer, and I tried to make the sprite big enough so that it could fill the entire screen without appearing pixelated or stretched.
The last sprite I made for this scene was the bucket sprite. I made two of these sprites, one to show the bucket as empty and the other to show as full of milk from the cow. I tried a new art technique that I never tried before, which I used to create the reflection on the bucket. The technique was to draw a slightly lighter colour along the bucket and then use a smudge brush to portray texture over the edges of the reflection.
Image: Sprite of the bucket, empty.
Image: Sprite of the bucket, full of milk.
The first level that I made was Scene 1.2.2, which was one of the movie microgames (designated to take place in the plot when the main character, Jimbo, is watching the movie). In this level, the farmer moves to the right on his ranch towards his sick horse to administer the medicine he has for it. The objective that is prompted to the player when they start is to "treat the horse!".
The interesting thing about this level is that, while it is presented in a 2D perspective, it's not actually 2D. Because of the fact that the PlayerMovement script is designed for Vector3 movement (which only works in 3D), I had to make the scene in 3D using 3D GameObjects for the farmer and horse sprites. I also placed an invisible wall and floor in the level so the farmer can't fall out of the level.
There is also a foreground canvas and a background canvas—foreground canvas for the prompt text and timer, and background canvas for the background sprite—and they exist in the world space, but are tied to the camera's perspective (which is set to Orthographic.
Image: Scene view of Scene 1.2.2, with the hierarchy.
Image: Game view of Scene 1.2.2, with the hierarchy.
How did it go?
I was not happy with the way things turned out for me during this time. I was dealing with burnout for a while during this project, so I wasn't able to get much of anything done during this time, and it took way too long to get out of this burnout phase. Once I did recover, though, I did manage to make some good progress on the project, and I think the group did pretty well during these few weeks. Communication was a bit of an issue, such as with updating the HacknPlan or just responding to messages in the Discord server, which was the opposite of what I was hoping this time around, but it's at least somewhat better than what it was in project 1.
As mentioned in my appraisal, the biggest obstacle for me in this project was the burnout. I managed to get around this by both taking some time to relax and get through this phase, but also take a little bit of time to continue being productive with personal projects, which might've helped reduce the duration of the burnout phase, but maybe just slightly. If I'm to learn any lessons from this, I think it would be to try and get a certain number of tasks done each week, so I can then have more time to do the things I want to do and have weekends off.
There was also the issue with the communication, but I at least managed to get around this with one or two people in the group by getting their phone numbers so I can contact them directly if they don't answer any of our messages.
For my next project, to try and not have another burnout phase, I will try not to push myself incredibly hard at times by leaving everything until the last day, and will instead try to do a certain amount of tasks a week so I have more free time to myself instead of spending all the time working on the project and making very slow progress. For the communication, I will try to have everyone's phone number by the next project so that I can contact anyone in the group if need be.
(Sorted alphabetically)
CrazyGiaky. (2021). [Valve reuses the source code for 'flickering lights' 22 years later] [Image]. Imgur. https://i.imgur.com/70ZqqG6.gifv
Duke, A. (n.d.). Transparent Horse Clipart - Horse Transparent Background, HD Png Download [Image]. PNGitem. https://www.pngitem.com/pimgs/m/384-3848164_transparent-horse-clipart-horse-transparent-background-hd-png.png
Sad Satan. (2018). The Theatre (PC) [Video Game]. Itch.io. https://satansad.itch.io/the-theater
Unity Technologies. (2021). Transform.position. Retrieved December 20, 2022 from https://docs.unity3d.com/ScriptReference/Transform-position.html