I am very excited to begin chronicling the progress and development of my senior game project, Overgrown. Overgrown's development began last semester during Fall 2020 where my then team of 5 sat down and brainstormed a possible list of game ideas which we would be interested in pursuing. After going through the process of prototyping each of our game ideas for one week each, we settled on our favorite game idea, a level-based resource management game where the player is tasked with caring for a multitude of fickle houseplants which have resources needing to be met and cared for. After successfully creating an in-depth prototype of our vision for the game we were able to pass through the selection process at the end of the semester and continue on with Overgrown into the final semester of our senior year. After this selection process was finished for all the senior games we went through a recruitment process where we were able to choose which new team members we wanted to add to our team for this final leg of development. Our team size has now gone from 5 to 10, allowing us to essentially double our development efficiency and content creation. I am very excited to see what we are able to create in this short span of one semester and I am confident that our final product will be a complete and fun game experience which we are all proud of.
Our Team
Ian Kehoe - Lead Producer
Ariana Cook - Lead Designer
Ryan Swanson - Designer
Faith Scarborough - Lead Artist
Tessa Nelson - Artist
Adam Dionne - Artist
Hannah Mata - Artist
Simon Steele - Lead Programmer
Adam Clarke - Programmer
Jason Gold - Programmer
Sprint 0 - Onboarding (Jan 26 - Feb 1)
During this first week of development on Overgrown, our team spent the majority of our time onboarding our new team members and getting everyone used to our new workflow for the semester with the added challenge of a larger team. We used this first sprint to plan out everyone's roles on the team, what kind of work each member will be doing, and generally getting everyone used to their new team members so that we can ensure a healthy and productive semester.
My tasks this sprint included:
Onboarding our new team members and getting them used to how we will operate as a whole
Writing our working agreement as a team
Meeting with Ryan to decide each of our roles as designers moving forward
Deciding on our design goals for what we want to have finished by the end of the Greenlight phase
Onboarding
The onboarding phase for our team actually began during Spring Break while we were all home on vacation. Before Spring Break began our team was able to set up a Discord server so that we would be able to keep in touch during break and begin to get to know each other before our final semester started. During our break period, we decided it would be a fun team bonding experience for us to set up a Minecraft server where we could all jump into a voice call and play together. This ended up being a really fun and positive experience, as it allowed each of our team members to get to know each other in a setting that was stress-free and leisurely. Once the semester actually began we had multiple meetings together where we discussed everyone's roles on the team, explained to everyone what our workflow for the semester would look like, and introduced our new members to our project, Overgrown.
Working Agreement
Our working agreement is a document that our team as a whole gets together into a meeting to write and discuss. This document lists all of the things we as a team agree to abide by throughout the development of Overgrown, and it is a nice experience to be able to write this document together so that everyone's opinions can be heard and discussed. Our team's working agreement is as follows:
Show up to meetings on time. If you anticipate being late or not arriving, send a message asap. Meetings end at the scheduled time.
Be honest about your task progress. Let the team know if tasks will be late.
Post your daily standup every day. Read the standup every day. :)
Post media in your discipline channel when you finish a task to get feedback on it.
Keep on topic in the meeting, have an agenda for every meeting.
Everyone should push their own work onto the repo.
Everyone should have their webcam on for meetings.
Emote on messages that desire feedback, especially if you do not give written feedback.
Meeting with Ryan
In this meeting, Ryan and I joined a voice call and discussed what each of our individual roles as designers on the team would be. I asked him what his biggest strengths as a designer were and what type of design work he most enjoys doing. From this discussion, we came up with a detailed list of what each of our roles would be and what type of work each of us would be assigned to doing. This meeting was very helpful because it allowed us to better understand each other as designers and what each of our unique strengths and weaknesses were. We wanted to ensure that both of us were happy with the type of work we were doing, as well as ensuring that all our work would be as high quality as possible. For example, we decided that Ryan would be the main Level Designer for our team as he was more comfortable and skilled in creating levels than I was, whereas I was more comfortable with Systems Design so I would be mainly in charge of designing our new mechanics.
Greenlight Design Goals
To finish off the sprint, Ian, Ryan, and I discussed what we wanted our design goals to be for the end of the Greenlight phase. The Greenlight phase is meant to be 3-4 weeks long and in that time we are tasked with prototyping to some extent all of our core features and mechanics. By the end of Greenlight, we should have an understanding of exactly what our game is, what mechanics and systems it is going to include, and a detailed plan for development during the rest of the semester. Our team's Greenlight Goals are as follows:
We are going to prototype our three prospective major mechanics and choose two of them based on the prototype's viable application to our game.
We are going to design a fast-flowing pipeline for level creation and use it to make at least one level.
We are going to create a Master Asset list that contains all of the art assets that we foresee ourselves making.
We are going to create a Master Audio list that contains all of the audio that will be produced for our game.
We are going to create a Master Systems list that contains all of the technical systems that will be within our game.
We are going to restructure and reword the existing tutorial in documentation so that we clearly tell the player how to play the game in multiple ways.
We are going to create tools that can be used by the developers to create levels faster and make changes to those levels that the players desire.
We are going to remake our character so that we have a base for all of its customization features.
We are going to create the functionality for a system that will allow the player to customize their character and play with those changes in-game.
We are going to create a functional 3D space in which the player starts before they enter a level.
We are going to re-style the UI so that we can more clearly convey information and advance the context of the game.
We are going to port our game to the Nintendo Switch console.
We are going to create a full library of modular pieces which we can use to build all of the level layouts.
We are going to make balance changes to our current levels to create a solid base on which we can scale our difficulty off of.
Sprint 0 Reflection
Overall this first sprint was very informative and helpful for the whole team and allowed us to get a good understanding of everyone's roles on the team, everyone's strengths and weaknesses, how our team workflow will be organized, and our goals for Overgrown. I'm glad we were able to take this first week to plan out the rest of the semester before diving right into development as it was nice to have this baseline understanding and knowledge. Without this planning week, I feel that we would have been a bit lost and confused if we had jumped straight into development.
Sprint 1 - Knead the Dough (Feb 2 - 8)
Before getting into what my team did this sprint I want to give some brief backstory into the strange name for this sprint, and each of our sprints moving forward. During development on Overgrown last semester, our team thought it would be fun and interesting if we named each of our sprints to correspond to a different stage in the growth of a plant. For example, our first sprint working on Overgrown was named "The Seed Has Sprouted," the second "Taking Root," etc. During this sprint we decided it would be fun if we continued this trend of unique sprint names, however, instead of being plant-related we somehow came up with the idea to have each sprint be a step in the process of creating ravioli. While the names of our sprints are unrelated to our actual game or work, I think it is a fun and unique way to keep everyone's spirits up and add a little extra fun to each sprint when we get to decide on the next step of our ravioli-making process. In general, I think it is good to have something fun and light-hearted like this for the team to enjoy together so that we can be reminded to not only work hard on creating a great project but to also have fun with it along the way.
During this first official sprint in the development of Overgrown, my team worked on creating a strong baseline from which we could expand upon in the coming weeks. This sprint was mostly dedicated to planning, with team members writing up detailed lists and descriptions of our future mechanics, systems, levels, art assets, and other general plans for development. While not a lot of actual content was finished this week, it was definitely useful to spend a long period of time planning out exactly what we wanted for each aspect of our game so that everyone on the team was on the same page and we could quickly jump into content creation immediately after.
My tasks this sprint included:
Deciding on our plan for our future mechanics
Creating Pinterest boards for each world theme for the Artists to reference
Deciding on our plans for our future levels
Discussing with Ryan and the Programmers what designer tools we would need to have more efficient level creation
Discussing with Adam D. our plans for character customization
Showing Ryan how to use the Icograms web tool
Deciding how we want to change the tutorial notes to be more clear and concise
Future Mechanics Plan
During this first sprint, I was tasked with deciding what new mechanics we would be adding to Overgrown and how exactly they would work. During the last semester, we had previously prototyped a Pruning mechanic in which plants would become visibly overgrown and needed to be pruned with gardening shears in order to keep them healthy. In addition to this, I wanted to add a few more mechanic ideas for fun and interesting things to require the player to do. After coming up with a list of ideas and discussing them with Ryan and the rest of the team we decided to go ahead with these 3 mechanics: pruning, an AI cat that wanders around the level and knocks over plants, and carnivorous plants and bug swarms. After deciding on these mechanics to move forward with I then wrote up detailed descriptions of each one and added them to our Design Document.
During this brainstorming and decision process, I had to keep in mind what kinds of mechanics would add to the fun and challenge of the game, and which would just detract from it. I wanted to add mechanics which felt challenging for the player but also felt fair. I knew if the player felt that a new mechanic was unfair or they could not understand how it worked they would just become frustrated and it would detract from the overall experience of our game. Keeping that perfect balance between something that is both interesting and fun, but also challenging and sticks with the theme and pacing of our game was my biggest challenge for this task.
World Theme Pinterest Boards
In Overgrown the levels are separated into three separate worlds/themes: a Rural Neighborhood, an Urban Apartment, and a Forest Log Cabin. Our plan is to have four levels within each theme, for a total of 12 levels by the end of development. In order for each world theme to feel consistent between all its levels, the Artists needed to know what my vision for each theme was and how they should appear visually. We decided the best way to get my vision across was for me to create a Pinterest board for each of the themes and share them with the Artists so they could easily see what I was envisioning.
I will link these Pinterest boards here:
Future Levels Plan
Because we are aiming to create 12 unique levels for Overgrown we needed to have some solid planning for what each level will entail so that we can have good pacing between each level and they each feel different from one another. For this task I was responsible for planning out what rooms each level would contain, the general size of each one, and which mechanics would be present in which levels. With our future mechanics, we did not intend to have every mechanic in every level as it would be too overwhelming for the player, but instead, we would introduce them gradually and one at a time. I decided it would be best to have the cat mechanic appear in the Urban Apartment world and the carnivorous plants and bugs swarms in the Forest Log Cabin. This decision was made mostly because the cat felt like it belonged more in an apartment setting, whereas bug swarms felt more natural to have in a forest setting. As of now, we are planning to only have the cat appear in the second world, and the carnivorous plants and bug swarms only in the third world. I am unsure if in the future we will create a level that contains both at the same time, but that is a decision that will have to be made later on once we see how difficult each mechanic is for our players and whether it would be too overwhelming to include them both simultaneously.
Designer Tools
We decided early on that Ryan and I would like to have certain designer tools created by the programmers which would allow us to more easily and efficiently create levels and balance the game's mechanics. While it would take away time from the programmers to create these tools initially, in the long run it would definitely save us time in development as we designers would be able to work much more efficiently. Ryan and I had a meeting with Simon and Adam C. to discuss what specific tools we wanted them to create and came up with this list:
A player data log that records various player actions as they play and outputs it to a file which can then be uploaded into our feedback form by testers. This would allow us designers to go over the data and determine which parts of our levels may be too difficult or too easy, where exactly players are struggling, player habits, etc.
A numerical indicator above each plant spot in the level editor which would show the light level of that spot. This would allow us designers to more easily see how much light each individual plant spot is getting and move the spots/design which plants will be in each level based on those light levels.
A way to more easily access all of our level assets such as floors and walls, furniture, plants, decorations, etc. without needing to jump around to multiple different folders to search for specific items.
Character Customization Discussion
Adam D. and I had a short meeting to discuss what our plans would be for the character customization system moving forward and what would and wouldn't be out of scope for the project. We originally had two ideas for this system, either having set characters which the player can choose from with their own outfits, skin color, hairstyle, etc., or allowing the player to completely customize their own character from scratch with no set characters built-in. Our biggest concern for allowing the player to customize their own character was the scope of creating a customization system, as well as creating enough clothing, hair, and other options for the player to feel like they truly can make whatever type of character they want. After discussing this for a while we decided that the benefits of creating a customizable character were worth the risk and we did not think it would be too out of scope to accomplish, at least to some extent. Even if we were not able to create as many customization options as we would like we still felt that it would be worth it to allow our players to choose their own character to play as instead of having to choose from pre-set ones.
I feel that this is a calculated risk on our part. It is likely that we will not have the time to create as many options as we would like to have in our game, however, I do believe we can create enough to still feel satisfying to the player and have the system as a whole be worth it.
Showing Ryan Icograms
Icograms is an online website tool that allows you to create your own custom isometric rooms and environments. I found this tool during development last semester when I was the only designer on the team and I wanted an easy way to plan out and test different room sizes and layouts. The tool itself is very easy to use, there is a panel on the left side of the screen organized into different sections which have a multitude of different house pieces which you simply drag and drop onto a canvas. From there you can snap the pieces together to form rooms, add furniture and decorations, and scale any assets up or down to the preferred size and position. Because this tool is fairly straightforward this was a brief meeting to show Ryan how it works, but mainly to show him my own workflow for how I had previously been using it, such as the correct sizes for floor and wall pieces so that both of our room layouts would remain consistent. This tool has been very helpful for concepting new level layouts because it is so quick and easy to use, in addition to the fact that you can create an account on the website in order to save all of your designs so you can always come back to it later without losing any work.
Tutorial Note Changes
Coming into this second semester of development we already had a tutorial system in place in our first level which told the player how to play. However, the tutorial as it is now is pretty long and wordy, and players most likely are getting bored from sitting there scrolling through multiple lines of dialogue in a row. During this semester we decided we want to revamp the tutorial dialogue so it can be much more clear and concise without boring the player with too much information all at once. We decided the number one issue with the current system which we wanted to change was to remove the long strings of text which the player just sits through and reads without doing anything. Some of our tutorial dialogue was already connected with player actions, the dialogue tells the player how to do something and then they actually go and do it in order to progress to the next tutorial dialogue. We decided we want to try to do this with as many tutorial notes as possible so that the player is not just reading words on a screen but is actively performing those tasks in order to better learn and understand how it works. In addition to this change, we decided a good way to cut down on the number of words in each tutorial note would be to accompany those notes with some simple illustrations. This way we could not only tell the player how a mechanic works but actually show them as well.
My biggest concern with the tutorial system is that it needs to be completely clear to the player how each of the core mechanics works, but at the same time, players will get bored if each tutorial note is too long with too much detailed information. I believe having tutorial notes with both text and simple illustrations is the best of both worlds, as we can cut down on text while retaining the player's understanding and conveying the same amount of information.
Sprint 1 Reflection
As a whole, this first sprint of development went well in my opinion and we did a good job of coming up with some concrete plans for the future. Very similarly to our first week of onboarding, this week of planning and discussion was very helpful to ensure the whole team is on the same page, understands our goals for our game, and is ready with detailed plans for our work in the coming sprints.
As far as challenges on my end, this sprint definitely tested my skills as a designer, especially when planning important aspects of the game such as future mechanics and changes to existing ones. I want to ensure that our game can maintain a good balance between challenge and difficulty, and fun and reward. Striking that balance is not something we will get right on our first or second try, but is something we will be consistently working on throughout the semester in response to feedback from QA tests and from our professors and peers. I am confident that with this first sprint we are laying the groundwork for a successful semester.
Comments