Project 1
— GAD181 —
Embedded Files
Header image: L'Odéon, by Alexandre Chassignon (2008)
Table of contents
Part 2: Concept & Mid-Project Reflection
Part 1: Project Overview
Part 1: Project Overview
Overview
Overview
Making games is hard. There are many aspects and processes, workflows, skill sets, people, timelines. For a project and product to be successful, all these elements (and more) need to smoothly align and integrate. This is rarely simple or straightforward. Time is limited. Scope and requirements tend to evolve as more is known about the project, via iteration driven by testing and feedback. This is project management: a delicate balancing act of trade-offs and compromises. It’s aim, to deliver the best outcome for a given limited set of resources and time.
In this project, the client seeks a spiritual successor to an existing title. The client sets broad requirements and I work in a team to pitch and deliver a prototype of a single element or mechanic based on those client requirements and in accordance with their feedback.
Image: The main protagonist's (Jimbo) concept design.
Brief Information Document
Brief Information Document
As the name implies, this is the document that allows me to just dump all the information I find on my chosen person so that I can use it during the production of the main content of this brief.
I have created documents like this in the past as it helps me to keep track of everything such as the information for the brief itself, like the project deliveries and general overview of the brief, as well as the sources of information that I find on the chosen topic, and preparation for the main part of the brief such as, in this case, planning what sections will be in the video script.
This document is not expected for and is therefore not essential to the completion of the brief, but I prefer to utilize it nonetheless.
Part 2: Concept & Mid-Project Reflection
Part 2: Concept & Mid-Project Reflection
Game Design / Planning Document
Game Design / Planning Document
My team and I created a document for our project that serves as both a game design document and planning document. We did this as we found that it’s easier to keep track of things with just one document instead of two, and the document is sectioned into two parts for the game design document aspect and the planning documentation aspect.
In the game design document section, we are expanding on the game idea and going into further detail with what microgames will be presented and what mechanics will be in them, as well as the story of the game and the descriptions of the cast. In the planning documentation, we determine and go into further detail about who has what role, the meeting minutes (a record of each time the group has met to work on the project), the project schedule that we expect and other important information.
Concept Pitch
Concept Pitch
To show our idea for a microgame project to the class, we constructed a concept pitch deck that covered all the point we could think of. These points included the story (more specifically the main character's motivation to kill), the cast (so far), key game hooks in quick points, how the game's progression worked, some visual examples of the style we wanted to go for, and the development roadmap that we were expecting.
Concept Pitch Feedback
Concept Pitch Feedback
When my team presented our pitch deck to the class, it didn't go exactly to plan because of factors like rarely to occasionally stumbling on our words and losing our talking points, but we were able to quickly pick up from these mistakes. We did, however, get some pretty valuable feedback on our concept.
The first point that was made was in regards to the game's plot and intended art style, which could come out as one of those poorly-made Flash games found on the internet from the 2000s–2010s, which is definitely not something that we should do. Another point made was in regards to the fact that the game followed a linear gameplay loop with a story instead of a gameplay loop more similar to WarioWare, with random microgames chosen. The main argument was that this would make it harder for us to downscale our scope if the team ever needed to do so, as it's more complicated than just taking out a few microgames from the microgame pool.
There were two points made that stood out as the most significant. The first point that was made was in regards to the motivation to kill in the game's story—with our original idea, that being an intro cutscene that sets the plot up and shows the player the main character's motivation to kill the victim, it came to our realisation that there could be a difference between the main character's portrayed motivation to kill the victim and the player's motivation to kill the victim. We found that, unlike the main character, the player wouldn't really have much of a reason or really care enough to go through with killing the victim. The second big point was in regards to the game's plot, and its potential. The original idea for the game was to have the first two phases be about setting up for and then committing the murder, and the last phase was to try and hide the body and get away with the murder. The main argument was that the plot could be changed from a very drawn out murder to something more dark but interesting; something in the vein of psychological horror, similar to games like OMORI (OMOCAT, LLC, 2020).
Image: OMORI cover, by OMOCAT (2020).
To address these concerns, we sat down and considered the plot and art style, and how we could change it to improve our product, and we came up with some ideas. Firstly, with the feedback of the game being compared to a poorly-made Flash game, we decided to expand on the plot of the story and think about how we could improve it to not make a poorly-made Flash game. This point combines perfectly with the point about the potential to change the plot into something that focuses more on psychological horror, as we came up with a great alternative plot idea. The idea was that, instead of the entire game being all happy and comedic/silly, we could have the game be just that at the start, and then after the murder takes place, the game would delve into themes of psychological horror as the main character descends into madness due to the psychological torment of the burden of murder.
With the point about the motivation to kill, we came up with the idea of making the player more involved. Instead of an intro cutscene, we decided to make that scene of the game part of phase 1. One of the challenges the player will face will be to complete a button mashing microgame between every movie microgame to remain calm while the victim is on their phone, and being a general nuisance. As the difficulty ramps up each time, it will make the player more annoyed at the victim until they eventually lose, which will give them more motivation to kill the victim. With the last point about the linear gameplay loop making it difficult for us to downscale our scope, we came up with a good idea to get around this. We're planning to make a handful of microgames for each phase, but we have designated a few of the planned microgames in each phase as either important (ties into the story and cannot be removed without breaking the plot) and non-important (isn't crucial to the plot and can be removed).
Phase Progression Diagram
Phase Progression Diagram
Before we presented our concept pitch to the class, we came up with a phase progression diagram that would demonstrate how and when each phase would progress and where each point of the plot would sit within the three phases.
Originally, the plot was laid out so that the murder takes place at the end of phase 2, after the big build-up presented in all of phase 1 and just before the murder stage in phase 2, and then phase 3 would consist of hiding the body and try to get away with committing murder, before getting to the ticket buying stage again which would make the plot come full circle by starting a loop. After we presented this idea to the class and received our feedback, we found that the plot leading up to the murder felt very dragged out, with plot points that feel like they're there to just add more microgames to the game.
Instead of having a game where you spent the majority of it doing things leading up to the murder and then trying to get away with the murder in a shorter amount of time than what it should be, we decided to change up the plot to solve this issue. As shown in the phase 1 diagram in the two images, the plot was changed so that the murder takes place at the end of phase 1, which eliminates a good amount of the unnecessary build up and gives us a lot more room to incorporate the feedback we were given on the potential of turning the game into a psychological horror game.
As shown at the end of the murder scene in the left-most picture (titled "Hold his head under the water"), the microgames that come afterwards seem to be relatively normal objectives, such as "get
Image: Revised progression diagram of phase 1, with the changed plot
out of bed". The idea, even though it isn't represented here in this diagram, is that the game's protagonist, Jimbo, will try to continue on with their life as if nothing actually happened, completing normal objectives such as getting out of bed and eating breakfast, but things will start to become stranger and more horrific as the plot progresses, which represents a deterioration in Jimbo's sanity as he struggles to continue on with normal life after murdering someone.
At this point in time, the entire revised plot is not yet finished, which is why the left-most progression diagram only shows phase 1, but as we continue with the project, we will come up with ideas for the later phases, and hope to have a completed plot throughout the three phases by the end.
Image: Old progression diagram of all three phases, before the plot changed
Mid-Project Reflection for Project 1
Mid-Project Reflection for Project 1
How's it going so far?
Process
Process
My team is currently keeping track and planning our processes and tasks via three ways: through the Discord server Ronan made dedicated to this project specifically, the HacknPlan (that Ronan also made) and the Game Design/Planning Document (also made by Ronan. Do you see a pattern here?). We believe that by doing this, we will be able to keep better track of what tasks we need to do without just storing it in our memory or individual notes, where it could either be easily forgotten or not updated (with the status of current tasks or the addition of new tasks).
We are also trying to sort each member of the team into roles to make things a bit easier to deal with; for example, my roles are the 2D asset designer, level designer and programmer. I read the "Small Company Organization Overview" section in chapter 2 of Seth Spaulding's Team Leadership in the Game Industry (2009, pp. 24–30), where he lays out the model of what the structure of a small video game studio would typically look like. While Seth does explain some of the flaws that this kind of model would have, those flaws only really apply when the company is upscaling their size, and aside from that, it also applies more to a team that consists of more than five people, which is unlike the case with my team. I found that the model that Seth provides here could help us figure out roles for our team, mainly through our own structure that has been inspired by the provided structure—for example, while the whole team have the programmer role, Ronan is the lead programmer of the project.
Person
Person
While I have worked on a project with a team in the past, whether it be for a project as part of my studies at SAE, an assignment in high school or even a personal group project in my free time, but this is the first time that I have worked on a project with a group bigger than two or three people, let alone a group that requires a good level of communication for something like this game project. This will be a test of my communication skills, but I have an idea of how I can maintain good communication with my group.
For one, we have a Discord server set up by Ronan where we talk to each other and post updates about how our tasks are going, and my Discord is set up so that I receive push notifications on my devices when someone sends a message, which will allow me to quickly respond to anything that is directed at me. I will also bookmark the HacknPlan dashboard so I can quickly go back, check for anything new/updated and update anything that I have worked on. We are also meeting in every class to touch base and discuss what to do from that point forward, as well as hosting some out-of-class meetings via Discord voice chat to work on the project.
Proficiency
Proficiency
This project will require me to apply my knowledge on the usage of Unity and coding with C#. I believe I have an intermediate understanding of coding with C# due to not only my studies at SAE, but also the time spent in my free time (before SAE) working on prototype projects in Unity, starting from 2017. I don't believe I will need to apply coding techniques for serious code optimisation as there won't be a whole lot of things slowing down the framerate/response time in the game, but I will need to organise my code so that it is at least readable.
I know that what I have learnt in GAD170 last trimester, such as the player movement code, will assist me in developing this project, and I will also refer to the Unity Documentation and answers found on Google to aid me. I will most likely have to look into better methods of the code I have learnt however, as I have been told that the code from GAD170 was not very good, and I didn't learn how to code player movement while working on any of the prototype projects before SAE.
Part 3: Research & Project Management
Part 3: Research & Project Management
Genre Investigation
Genre Investigation
What is a "microgame"?
What is a "microgame"?
Originally, a microgame was associated with physical board games. Mark Johnson (1996) defines microgames as "any inexpensive--no more than $15--wargame or conflict simulation which is generally also small in size and quick-playing." An example of a microgame in this style is Seiji Kanai's 2012 card game Love Letter. Microgames were most popular in the 1980s according to the claim of Mark Johnson (1996), in which he says "it's no coincidence that these are the circumstances under which many of us microgame fans originally found them--in the early 80s while still in school."
Since then, the concept of microgames have moved into the video game industry. The term "microgame" in the context of video games is used by some as an alternative term for minigames, which according to IGI Global (n.d.) are "short, 3-5 minute game that can be used inside the context of another, larger game." A good example of these minigames can be found in the "Minigames" section of Nintendo's New Super Mario Bros. for the Nintendo DS. Another good example is with Konami's Bishi Bashi Channel arcade game, which revolves entirely around its minigames instead of having them as one extra part of the game, such as in New Super Mario Bros' case.
Others have a definition for the term "microgame" in the context of video games, such as Comp Form (n.d.), which describes microgames as "tiny games, stripped to their essential elements, often playable in a few seconds." An example of this definition in practice is with Nintendo's WarioWare series, which consists of many microgames that contain unique mechanics.
Image: WarioWare, Inc. front cover, from RHG1951 (2021).
What is psychological horror?
What is psychological horror?
Psychological horror is a subgenre of horror that, according to Ivy Lofberg (2016), "focuses on the darker side of the human psyche that’s often repressed. It also explores emotional and psychological vulnerabilities over primal survival fears." Before the subgenre made its way into the video game industry, it was first popular in the movie industry, with movies such as Robin Hardy's The Wicker Man (1976) and Nicolas Roeg's Don't Look Now (1973) being one of the early psychological horror movies that graced the movie industry.
Horror is a genre that has been in the video game industry quite early on, with games like The Texas Chainsaw Massacre (1983) for Atari 2600 being some of the first video games to take on the horror genre. Despite this, the psychological horror subgenre wasn't really popular in the video game industry at all until the 90s, when games like Silent Hill (1999) for the original PlayStation hit the scene. Silent Hill's gameplay consisted of combat, exploration and puzzle-solving in a third-person perspective, throughout a dark/low-visibility monster-filled city, where the threat of attack is extremely prevalent. According to Silent Hill Wiki (n.d.), Silent Hill received generally positive reviews, gaining an 86/100 and 84.99% aggregate at rating websites Metacritic and GameRankings, respectively.
Silent Hill also sparked the beginning of the psychological horror subgenre's rise in popularity within the video game industry, as it showed what psychological horror games could be capable of. It gave way to well-known and well-received psychological horror games such as Team Psykskallar's Cry of Fear (2012), Tecmo's Fatal Frame (2001), Monolith Productions' Condemned: Criminal Origins (2005), and the list goes on.
Image: SH1Boxart, from Alex Shepard (n.d.).
The Team's HacknPlan
The Team's HacknPlan
Image: Screenshot of the team's HacknPlan board.
As well as the Discord server that Ronan made for the team, we use HacknPlan to keep track of what tasks need to be done for each phase, who is doing it and what stage of each of those tasks are at, whether it’s started, testing or completed.
Click on the image above to access the team's HacknPlan. Alternatively, if that doesn't work, use the button below.
Project Google Drive
Project Google Drive
This is the main Google Drive directory that the project uses, and that the entire team shares. It will contain custom project files such as 2D and 3D assets, audio, etc., and will be handy if we ever need to access the custom assets on a different machine that doesn’t already have them, or if the custom assets are lost or broken and a backup is needed. It also contains the documentation for our project such as the game design / planning document, the concept pitch deck, etc.
Part 4: Final Reflection & References
Part 4: Final Reflection & References
Final Reflection for Project 1
Final Reflection for Project 1
How did it go?
Appraisal
Appraisal
I think the start of the project went okay. We managed to start on a lot of the documentation and get our idea up to a solid enough point where we can begin to work on implementing it into the game engine and work our way up from there. The pitch deck we created to present was done quite well, in my opinion, and the feedback we received from presenting was especially helpful in reshaping our idea to something that would work better.
To highlight one thing that could have worked better for me, the way we set up the game design/planning document was a bit confusing at first because I was expecting it to be two different documents, so that required a bit of getting used to, and I personally believe that having the two separate documents would've worked better in terms of organisation and ensuring that things don't get mixed up with each other, but I understand that it can be easier to keep track of the one document.
Challenges
Challenges
There were a few obstacles that stood in the way during the beginning of this project, with the biggest issue being with communication. Even though we set up the Discord server for the group to be able to easily contact each other if need be, it seems that there's still an issue with some people in the group not answering messages directed towards them, whether that be an issue with notifications not being pushed or something else. I have noticed that I also have this issue sometimes as well, as I tend to leave a message that I can't answer with a good response for later and then forget to respond later. I will try to overcome this communication issue by getting the phone numbers of my team so that, if the need arises, I can contact them directly, and I will also monitor the Discord server more often.
Another challenge was with GitKraken. We had a real issue with learning how to use GitKraken for a number of reasons. GitKraken, as we found out, is an unintuitively-designed program that is not very easy at all to learn how to use when you've never used it before, and at one point we even had to start a whole new repository from scratch because of the issues we were facing. We did eventually learn enough of how to use GitKraken so that it wasn't seriously impacting the delivery of the project, but there are still some things that we need to learn how to use to make our lives easier.
Future Goals
Future Goals
There are a couple of ways and things I can better improve my skills for and do differently next time. For starters, in regards to communication, I have already presented the solution to others not being in better contact by getting their phone number so I can contact them directly if needed, but I also need to work on my communication skills as well by answering any messages directed at me, regardless of if the answer will be what the team wants to hear or not, and I need to answer honestly, as I think it's better for the team to know what's not working than to not know at all.
With GitKraken, the only obvious way to overcome that challenge is to learn how to use it better. I'm sure we will have a better time using it as we continue to learn things about it over time.
References
References
(Sorted alphabetically)
Alexandre Chassignon (2008). L'Odéon [Image]. Flickr. https://live.staticflickr.com/3285/3078493320_f83652c502_k_d.jpg
Comp Form. (n.d.). Microgames. Retrieved December 16, 2022 from https://compform.net/microgames/
IGI Global. (n.d.). What is Mini Game. Retrieved December 16, 2022 from https://www.igi-global.com/dictionary/mini-game/87151
Johnson, M. (1996). [Microgame HQ homepage]. Microgame HQ. Retrieved December 16, 2022 from https://micro.brainiac.com/
Lofberg, I. (2016). Beginner’s Guide: Psychological Horror. Film Inquiry. Retrieved December 19, 2022 from https://www.filminquiry.com/beginners-guide-psychological-horror/
OMOCAT, LLC. (2020). OMORI [Video Game]. https://store.steampowered.com/app/1150690/OMORI/
OMOCAT, LLC. (2020). OMORI cover [Image]. Wikipedia. https://upload.wikimedia.org/wikipedia/en/c/cd/Omori_cover.jpg
RHG1951. (2021). Wario-ware-inc-mega-microgamesUSA [Image]. Super Mario Wiki. https://mario.wiki.gallery/images/thumb/c/cd/Wario-ware-inc-mega-microgamesUSA.jpg/1200px-Wario-ware-inc-mega-microgamesUSA.jpg
Shepard, A. (n.d.). SH1Boxart [Image]. Silent Hill Wiki. https://static.wikia.nocookie.net/silent/images/c/c2/SH1Boxart.png/revision/latest?cb=20151123185611
Silent Hill Wiki. (n.d.). Silent Hill (video game). Retrieved December 19, 2022 from https://silenthill.fandom.com/wiki/Silent_Hill_(video_game)
Spaulding, S. (2009). Team Leadership in the Game Industry. Course Technology. https://ebookcentral.proquest.com/lib/sae/reader.action?docID=3136130
Page updated
Report abuse