Overgrown Postmortem
What Is Overgrown and Why Did We Make It?
Overgrown is a fast paced resource management game in which you have to keep a multitude of houseplants alive. Move and water your plants to keep them healthy while avoiding obstacles such as cats and swarms of bugs. Keep your plants in these overgrown houses happy and healthy! Overgrown was created over the course of an academic year and two five credit courses. It was started by 5 people in the fall and grew to 10 core members in the spring after 13 of the other 21 games in development were cut. A total of over 2,400 hours were spent creating this project and it was released to Steam on May 14th, 2021.
We had two major inspirations when choosing this project and two major development goals that informed what we were going to make. We knew that we wanted to make something that was unique in some way, something that challenged the preexisting standards set by the existing body of games. This manifested itself in Overgrown as our balance between a cute plant game and a hardcore time management strategy game. Specifically, making plant care into something stressful was something we thought would be interesting to try. The second inspiration was probably more of an unconscious one, but I am certain that the pandemic and quarantines influenced our choice of subject quite a bit. When our lead designer first had the idea for this project we all loved the idea of working with plants. The first of our two goals was to make something that could be played in short and frequent play sessions. Almost like designing a mobile game specifically for the PC. We saw the uptick and influx of people to the gaming space with the pandemic and thought that it would be an interesting idea to explore making something for these people who are now working and playing on their computers all day. The second goal was specifically a development oriented one, which was to by all means necessary avoid crunch and artificial stressful deadlines. While this decision did affect things like how and what we planned for, I am happy to say that people did not have to work long forced hours or rush things in order to produce what we envisioned for the game. These inspirations and goals all had a significant impact on how we worked and what we produced in order to get what we have today. For the rest of the retrospective I am going to be talking mostly about our development in the spring, which is when we went through the development and release phases. The work in the fall was pre-production work only; identifying the game concept and building a robust prototype to inform our work in the spring.
What Went Well
When we started building the game we knew that we were going to need to present a lot of information to the player in a small space, and very quickly. To this end we immediately started building UI. Doing this early gave us a base to start from and we then had the resources in the second half of development to completely rehaul it; improving the aesthetic and the ease of access. Every single piece of UI was changed in the development period to better present the information it was giving and we have received a lot of positive feedback from our testing base because of that.
Here is our first version of the UI.
Here is the final version of the UI!
From start to finish we had planned all along to produce a lot of content in this game. From our three distinct sets of level assets to the levels themselves and even things like our fully outfitted customization system, we have produced a ton of content for Overgrown that we are really proud of. But the most important part is that we were able to think through exactly what we needed to create in order to deliver each section of the game, and we did so very accurately at the start of development. This is what allowed us to get so much great art into the game, more so than a herculean effort from our artists.
The third thing that we did really well with Overgrown was to have an early and focused, well focus, on testing. We not only did this through testing the game often, almost always 2-3 times a week, but we also developed an original tool that let us gather player action data directly from their play session and automatically sorted it into categories for us. From there it was easy to look at the data, build graphs, and find trends that let us know which areas of the gameplay need to be altered to provide a better player experience. These highly specialized sets of data were able to provide us with insights that would have otherwise been impossible to get from surveys, discussions, or player observation; especially in our remote environment which limited the observation we were able to do.
What Went Poorly
Right at the start of our official development period, we were already met with a bump in the road. The game we were making and the plans we had for the future only called for one dedicated programmer, however, after other teams/projects were cut we ended up having 3 programmers in total on Overgrown's development team for the last few months of development. By itself this is an inconvenience, but it put us in a weird position where we needed to create work for the programmers to do while not creating a ton of work for the other developers. For example, we couldn’t create more features because that would require work from the designers and artists to fully realize. Because of this we had to find some inventive ways for the programmers to contribute in valuable ways. One of the things we did was to create a CICD system that helped us out a lot with the management of the repository. However, we didn’t fully understand as a team what each of these programmers was doing until later in the project than we would have liked. In fact I would say that the worst thing about the situation was that it took us too long to determine exactly what each person was responsible for. Not that we weren't trying to figure it out, but we should have applied more resources earlier to solving this issue; instead of letting small complications and problems fester for weeks. Or in fact creating a plan for this scenario before it happened would have been ideal.
Remote work may work excellently for some teams and some projects, but for us it was a huge strain on our overall team workflow and mental states. Not being able to really see people, to hang out with them in the same room, or to grab food together, etc was straining for all of us and definitely wore on our motivation as the project continued. Is it something that we could have changed? No,, but it is something that certainly had an adverse effect on our team and is something that we were constantly trying to improve upon and mitigate.
The last issue I want to mention is our treatment of bugs in the middle section of development, it's not a perfect comparison but it would be around when you would be pushing for an alpha state. During this time we did a lot of bug sweeping. We didn’t sweep the bugs out of the house, we just swept them under the rug and put a sticky note down saying “Yup, there are bugs under here”; but then moved on to laying down the next rug. Essentially, we needed features in order to create our levels, and our level pipeline was working faster than our features were being made. We wanted to keep making levels so that we could look at all of them together and get data for all of them, but we didn’t put enough value on the time it would take to go back and fix those features or how poor the feedback might be because nothing works quite how it's supposed to. We did get some very valuable feedback from creating all of the levels as fast as possible. It let us try some different things with level design and balance that we wouldn’t have been able to do before, but it also meant that we didn’t have time to properly respond to player feedback and implement better iterations of UX for some of the features later in the game.
What I Would Change
The number one thing I would change if I were to do this project again, is to make less overall content. Yes that is something that evolved into one of our goals early in development, yes I said that it is something we did well. And those things are true, but the side effects of trying to make so much content (at least in our environment and our context) were detrimental to the core gameplay experience. This manifested itself in two ways. The first is that because we had so many levels, very few of the people who tested our game wanted to play the whole thing. The second is that by focusing on producing more levels and more features, we sacrificed making each system and feature as fun to play as possible.
Let's dive into testing. Our testers are unpaid, but they are required to be there as students. This by itself makes for a lot of unmotivated people. On top of that, Overgrown is a very difficult game and many people are going to really dislike it, just as many will love it, so a lot of the testers have absolutely no motivation to play very far into the game. This would be ideally solved by breaking the game into smaller chunks and having testers play one section. However, in Overgrown it's really important to learn from each level you play and apply that to the next level. If we started the testers in level 9, they would be so incredibly lost and we would get no valuable feedback. So we got stuck in a bit of a predicament where the only effective and available solution would be to have less levels. We did not want to cut content from the game just because we couldn’t get user feedback on it, so we had to settle for giving people the game and letting them progress as far into the game as they wanted. If we had not already built our (amazing) data tool this would have been pretty problematic, but as it is we were still able to get data sets from testers no matter how much they played. Some of the survey responses were most likely inaccurate if people hadn’t experienced the whole game, but we took that into account when we looked at the results each week.
The second issue had to do with the tradeoff between content and iteration. Because we were trying to do so much, we started to move into a Gantt-like or waterfall-like system instead of being highly iterative. We definitely did not abandon iterative development all together, we iterated on every single system multiple times, but we sometimes got caught up in what our end goal was instead of focusing on what we had right now. Let me illustrate this with two examples I haven’t talked about yet.
The first is the lighting system within the game. Overgrown’s lighting serves two purposes, it needs to indicate to the player where they should place each individual plant type and it needs to light the levels in a pleasing way. We soon realized that balancing these two things was extremely difficult. And we knew that almost since the start of the project. But because we wanted to do so many other things as well, we never (figuratively) sat down and worked on the lighting until it functioned exactly how we wanted it to. We kind of just assumed that we would be able to figure it out eventually and make it work. This sort of worked, the lighting does its job, but if we had invested more heavily in this earlier via original systems or shaders then we would have been able to finish with a much more usable system. As it is, it just passes inspection.
The second example is almost the opposite of the lighting system. The last feature that the player experiences is a bug swarm that will eat the player's plants, and they can counter it by moving the carnivorous plant around the level. Because this was only in the last few levels we got a lot less feedback about it from our players because many of them never knew it existed. By order of priority, this was also the last thing we turned our attention to because we had other things that either affected more of the gameplay or would affect the players' experience sooner. With these things combined we implemented a shamefully low amount of changes to the bug swarm system and were not able to get the mechanic to a place that we were super happy about. This is an example of something we might have cut and focused on other areas of iteration and polish in order to deliver the best possible experience in those areas. In the context of our development, we ended up just not having the resources available to dedicate the proper amount of attention to this system.
In conclusion, we had a lot of things go well, we had some things go wrong that we couldn’t control and some that we could, and the one major change I would have made was a conscious choice/experiment that we made at the very beginning of the project. We most certainly could have done better in so many ways, but more importantly we learned a lot from this game and the way in which we chose to structure the project. I am immensely proud of the team for producing and releasing what we did these past few months and I know I will be able to use this project as a great reference for my future work.
*While the opinions of my team members were taken into consideration and influenced my thoughts, this writing is my own and does not necessarily represent the thoughts of the entire team.