Waste Your Wedding
- Itch.io
Made with: Unity
The project
A hungry woman wanders in a wedding venue to eat a gigantic cake.
But can she stop her suitors from marrying her along the way?
A light-hearted adventure starts!
Context
Used to game jams and short projects, I wanted to challenge myself with a longer solo project and a larger scope.
I set myself a 3-month time limit, working only in my spare time while also doing an internship (so about 3-4 weeks of effective work).
My goal was to have 30 to 60 minutes of high-quality gameplay, to make everything by myself, and, most importantly, to see the project through.
This postmortem covers what went right, what went wrong, and what I learned along the way.
Rushing the concept
My first mistake was rushing the concept. I chose a unique theme (weddings) which I don’t often see in games, especially for a gameplay-heavy game, but I jumped straight into development at the expense of properly defining the project’s pillars and intentions.
A week later, I had a working prototype, but the gameplay wasn’t fun and the direction was unclear. I spent valuable time trying to figure out what the game was supposed to be. Eventually, I managed to bounce back by reevaluating my intentions and by prototyping more gameplay, which I'm happy about now.
The final main mechanic: gaining an additional jump when hitting something, for aerial gameplay
What I learned: The beginning was tough because I had to find a fun idea from scratch. To gain some time, I started a game idea bank where I keep my concepts, making it easier to pick one when I’m ready for a big project. And most importantly, I relearned the hard way how crucial it is to establish strong pillars and intentions early on to guide every major decision throughout development.
Choosing the right Art Direction
I like to resolve key aspects early on to avoid doubts later in development, and art direction was no exception. This animated mockup was the first thing I created:
With just this, I could better visualize the game’s feel, colors, characters, and scale. I also decided to limit the color palette to just five colors for the entire game, which helped streamline the process. I kept the environment simple to maintain clarity but focused on lively animations.
The final color palette
What I learned: Looking back, the color limitation was one of the best decisions. While it was challenging to make key elements pop, it allowed me to iterate quickly and stopped me from obsessing over colors. Plus, it created a unique visual style that set the game apart from other pixel art games.Developing a scalable game
For this longer project, I focused on building scalable systems. I aimed to keep the code as generic as possible, relying heavily on a simple OOP principle: composition.
The structure for an enemy object, with several components attached (in red)
For example, each enemy had separate scripts for specific functions like health, movement, shooting, and animation. By using composition, I could attach small, independent scripts to objects without dependencies. This allowed me to quickly prototype and iterate on features, since the code was reusable and flexible.
What I learned: As always, reusing code saved me the most time during development. And by keeping my scripts generic, I’ve built an even larger library of reusable code for future projects!
The problematics of a larger project
One of my goals was to have at least 30 minutes of gameplay, which was a first for me as a solo developer. Creating the content for that length wasn’t the hard part, but I definitely underestimated the effort required to elevate such a large amount of content to a high level of quality. The level art, in particular, took much longer than I expected, even with the minimalist style.
What I learned: The more content a game has, the more work it takes to maintain quality. That said, I’m proud I avoided the common pitfall of overscoping in terms of quantity.
Conclusion
This development was a ride, but I learned a lot and I'm proud to have seen it through to the end. Being a solo dev gave me freedom to make creative decisions and learn new skills (like shaders and music), but it also made everything more time-consuming.
Even though I started off on the wrong foot by not clearly defining my intentions, the development remained steady, and I made consistent progress every day, even with limited time.
It wasn’t the easiest production I’ve worked on, but I’d gladly do it again! The final game is available on itch.io.