Project Overview
My Pet Flesh Monster is a pet care simulator with an aesthetic that blends cuteness with a bit of the grotesque. The gameplay loop consists of taking care of your pet by feeding it, cleaning up after it, playing with it, and putting it to bed, and then bringing it to pet shows where it competes in appearance and trick competitions. The appearance competitions are based on the general happiness of your pet, and the trick competitions require you to play minigames to complete a variety of tricks for points.
My Role
I was one of three designers on the team, and I was also elected Product Owner later in the project when the team realized we were in desperate need of one. My job as a designer was to handle the design and programming of the minigames, as well as creating the documentation for the core loop of the game.
VDDs from various points in the development process
As product owner I essentially worked to reign in the more eccentric members of the team. We had a very small development period and a lot of ideas, so my job was to stop the team from branching off too far in a direction we wouldn't have time to pursue fully. I worked with our producer to keep meetings on track as well.
Key Takeaways
In our postmortem of the project the team said we were happy with our finished product, but I think it's more accurate to say we were more happy with our process and that we were able to have a product we could consider "finished" in some way. I learned a lot of strategies I like to use to work and gained a lot of experience working with a team of skilled developers.
On the design front we were confronted with the issue of our game not being fun, and the solution that we decided on, that I regret, was to make our competition be minigames, we thought that we could slap interactive elements onto it and that would make it fun, and by the time we had implemented it we didn't have time to create a new solution that the whole team could agree on. These feelings have also taught me to bring up concerns I have to at least someone so that potential problems are addressed as early as possible. We agreed as a team that "finding the fun" early was the most important thing to learn from the project as we didn't focus on that and instead aimed for aesthetics and genre that we were able to agree on.
Example of early functionality