
My name is Jeffrey Friedman, I am a Game Designer who specializes in Systems and Narrative Design. Over these past few months, I was a part of the team RattSkum which consisted of myself, a Sound Designer, an Artist, and a Producer. During my time on this team, I also worked as the Lead Programmer for the project.
Hollow Reef is a video game developed during the Fall of 2019 spanning a 1.5 month development period. Through many interesting challenges, the team managed to put together a solid demo that showcases the many different core systems of the game with some exceptions. In addition, the demo manages to show off the general narrative context and feel of the game while supporting both of these with incredible art that brings it all together. While we are all incredibly proud of what we managed to put together in such a short time, there are still some shortcomings that need to be addressed.
During this postmortem, I want to focus on a few key points that I feel are necessary to touch on regarding the overall development process and our experiences with that.
- The struggles of designing and developing a systems heavy game without a dedicated programmer
- The growth that came from needing to cover parts of development that were outside our comfort zones
- The weekly commitments that were underestimated which lead to heavy crunch at times
- The improvements to team communication over time and how it led to a more put-together and cohesive final product
Before I actually get into the nitty-gritty of “What went right…” and “What went wrong…” I want to first go over the simple question of…
What is Hollow Reef?
Hollow Reef is a calming, tend and befriend styled experience; the Player inhabits a recently deceased soul who finds themselves in the expansive, barren plains of Hollow Reef. In these vast wastes, you encounter and care for a giant Golem made of bone: a benevolent beast that with the right amount of nurture will grow an extraordinary, expansive garden on its back. A new twist on the gardening and town-creation genres, Hollow Reef seeks to provide an interactive creature experience where the ‘pet-surrogate’ is both a lovable NPC and an upgradeable home-base. Explore the land of the dead astride your Golem companion, chasing off gnawing scavengers with your Lantern, and tending to its luscious garden to create a wonderous, living, breathing-town for other lost souls.
As a game, Hollow Reef intends to be a calming experience where the Player cares for a massive Golem creature and constructs a town upon it’s back for other NPCs in the world to live. The Player interacts with the game in two different manners. The first being the Player Character (PC). As the PC moves around the world, they can interact with both objects and NPCs in the world. This allows them to farm Flora, talk to NPCs, complete quests, and explore ruined civilizations in order to find both the story of the world as well as new things to add to their town.
The other method of interaction is the Player’s Build Mode. While in Build Mode, the Player is able to purchase placeable tiles that can be used to expand their Golem as well as plant new types of Flora.
Hollow Reef was designed to have all of its systems somehow flow back into each other, no matter what it might be. In addition to this, the game was also designed to have a core narrative that would unfold as the game progressed that would work in conjunction with the NPC narratives being told along the way, but that will be talked about more in-depth a bit later.
First, I want to talk about what we, as a team, did well during the development period…
What Went Right
1. A devoted and motivated team. In order to develop any piece of collaborative media, the team behind it needs to be working together properly. Not only that, but the team needs to have a clear goal of the finished product they’re currently working on. These people also need to be ready and willing to change things about the product that are not working while also making those changes feel like they belong in the product. Throughout basically all of the development, the team worked hard to make the vision we all had become a reality.
Of course, this was not without plenty of hardship along the way. Typically for a systems-heavy game, you would want a dedicated programmer working to make sure that those systems were all implemented and functioning properly. Unfortunately for us, a team of 2 Designers, an Artist, and a Producer, we did not have that luxury. That being said, we never let that become an excuse to stop us from creating the game that we all believed in.
Every member of the team had some kind of involvement with the actual code base of the game, which really alleviated the stress of the two who were mainly doing the programming work. We worked our butts off to make sure we would have a product we were proud of in the end, and we kept working at it right up until the very end.
2. A constantly evolving product. The first version or concept of a game is never perfect and it will always go through changes during the development process. While there are teams that will struggle with the process of updating their games and responding to both user and peer feedback, our team absolutely shined in this regard.
Arguably one of the strongest components of our team during development was how quickly we responded to the feedback we received. If we knew we needed to implement a new system in order to improve the player experience based on feedback, it was typically in by the next time the game was playable.
This wasn’t simply a one or two-time thing either, this was a consistent component of the team’s work ethic during the development of Hollow Reef. Even at the very end of the development cycle where we had been informed that our game’s introduction sequence was extremely lacking, we were able to implement a tutorial that fixed the issue within the next few days.
Our game changed tremendously throughout the time it was in development. We went from the very basic idea of using purchasable tiles to expand a town on a Golem to including a full overarching narrative, NPCs to interact with, and a world to explore beyond just the Golem itself.
3. Setting good foundations. One of the team’s strong suits was being able to set up solid foundations for all of the different pieces of development. While this did mean we weren’t in the engine as much as we could’ve been, we spent the time creating solid documentation to work off of as well as the basic architecture the digital game would be based on.
This was a very involved process for the whole team. We had to ensure that not only could the team understand the information being put into the documents, but could we easily transfer that information into an actual playable game. While we hit some roadblocks along the way, we definitely managed to pull through and move right into full development.
4. Solid overall communication. Throughout the semester, our team made it a very high priority goal to try to keep in touch with each other as much as possible. While there were definitely some inconsistencies that will be touched on later, for the most part, the whole team did a great job of keeping others updated. I know that personally, I tried to make sure my team knew what I was doing by constantly posting work updates as I was working. In addition to this, I also posted a list of Patch Note changes once I finished my work and had pushed it through to the repository so the team immediately knew what I had worked on and changed.
In-person work meetings was where the group really shined though, whenever the whole team was in the same lab working on the game, there was always a lot that got done. We fixed some of our most difficult bugs and gameplay issues in those meetings just because of how well the time was able to bounce ideas off of each other. This isn’t limited to just a few members either, every member of the group was involved in constantly trying to make the game better.
5. The Gameplan. As a team, one of the first things we did after we decided on a game that we would be working on for the rest of the semester was devising a plan for the entire rest of the semester. This plan went week by week, describing what the goals of each week would be as well as getting a basic task board set up for that week so that we knew exactly what we would be working on at any given point in time.
What Went Wrong
1. Lacking a Programmer. This was by far the most detrimental thing for our team as a whole. While we were able to get the game functioning to a decent state. We were unable to get every system complete before the deadline. This can be fairly easily attributed to the fact that the person headlining the programming tasks, myself, was also headlining the design aspects of the game. Unfortunately, while I am quite confident in my design abilities, my general lack of programming skills really began to show. That isn’t to say I was completely incompetent, quite the contrary actually. It wasn’t that I didn’t know how to program, it was more along the lines of nobody on the team had the experience to do the programming quickly and optimally.
This created a lot of periods in the game’s development where tasks needed to be pushed back another week because they turned out to be more difficult than previously anticipated. This eventually led to certain systems not being fully fleshed out, or some barely even being represented at all. This also caused issues in the addition of other content such as the Narrative. With myself working so heavily on the systems of Hollow Reef it became very difficult to find time to write out complete narrative stories for the NPCs and the game as a whole to follow.
2. Spotty communication at times. While not a consistent issue, this is definitely something that needs to be acknowledged in some sense. While I personally feel that I did a solid job overall of properly communicating with my team. I will also acknowledge that there were times during development where my communication was spotty and I had some issues being punctual. This led to me being late to meetings from time to time and in the most extreme cases, I missed a meeting in its entirety.
This wasn’t an issue that was only present with me though, pretty much the whole team had a time period during development where their communication fell off a bit. While these issues were remedied by the time the semester came to a close, they did still cause issues during development time.
3. Not asking for help enough. This is a bit of a weird one to put down. As stated before, one of the team’s biggest issues was the lack of a dedicated programmer for the entirety of development. While teams were not allowed to contract out programming work like we would be able to for Narrative or Sound Design (we had both already). We could go get help from others with issues that we were having. Unfortunately, for one reason or another, I had a lot of issues actually going to ask for help while coding.
While I did start to get a little better about it as the semester progressed, it definitely caused us to slow down a bit in terms of programming developments during production.
What Could I Have Done Better
I think if there’s one thing I could’ve done better during the development of Hollow Reef, it would be to try to split up my workload a bit more. I was taking on an incredibly large amount of work as both the Lead Designer and Lead Programmer, and while I was splitting the programming tasks with our Artist, I definitely feel that I should’ve tried to communicate more to my other designer in regards to what pieces of the game they could be doing more with.
I definitely feel like if I had done a better job of splitting up the design tasks, I would have had more time to work on the other responsibilities I needed to worry about while also ensuring that the work was in fact done. It’s even shown in my hours logged that I had many weeks where I was going way over the 12 hours simply because I just had that much work to do.
Where I Am Now
Despite all of the issues and hardships that came with the development of Hollow Reef, I think I’m in a much better place as a designer now than I ever was before. I came into this semester as someone who knew that I could do the work but never had the confidence in the finished product to not treat it like a joke. This was present during my team’s initial prototype presentations when I showed off the game I had worked on ‘Horizons’. During this presentation, I was nervous, I was putting my own work down, and I treated the whole game as if it was the worst thing I’d ever made. The truth is, it wasn’t.
I have grown in so many different ways this semester it’s actually quite astounding to me. As a Designer, I was able to gain more experience as a dedicated Systems Designer. This had me documenting, scripting, and implementing, so realistically I was able to touch all of the pieces of systems implementation on a pretty constant basis during the semester. Not only that, but I was also able to dip my feet into the work that I really wanted to focus on, which was Narrative Design. While I was unable to really implement all of the work I had done for the narrative of Hollow Reef, just getting down to documenting it all was a really great experience for me. I was able to gain a lot of practice in world-building as well as populating that world with believable characters.
Finally, I was able to really work on kicking out my bad presentation habits. I’ve grown to really have faith in my work, and I know when something I make actually has merit and value. I think this was really well shown in our team’s final presentation before the Midmortems. When it became my turn to talk about the actual world and story of Hollow Reef, I didn’t just default to what I normally would have in the past. I wasn’t stumbling over words, I wasn’t poking fun at the content, and I made sure that I spoke calmly and with confidence.
From systems design to narrative design, programming, presenting, all the way to just being more confident in myself and my work. I have come an incredibly long way in such a short amount of time, and I’m seriously looking forward to just how much more I’ll grow in the future.