Thank you for 1st place!! + Some reflections on the development process

Hi friends! First of all, we are super excited and honored to have won 1st place in Spring 2D Jam 2025! This is our first time winning a jam and we’re so happy people enjoyed our silly little game. From all of us at Studio Lavacado, thank you so much to everyone who played, rated, or gave feedback.

Oh yeah, we have a team name now! This is our fourth game jam together and we have every intention to make more games together in the future, so we figured it’s a good time to name ourselves. Those who’ve played our games before might recognize the name as a reference to our first-ever jam game as a group. It’s been almost exactly one year since then, and Floramino is not only our first win, but a testament to what we’ve learned in that time. We wanted to document some of those learnings in a quick postmortem, so let’s get into it!

The initial idea for Floramino was pitched in the early hours of day 1 of the jam. Shoutout to Mr. aoiazure himself for coming up with the idea of flower tetris (and, later, the absolute banger of a game title), but it took some back-and-forth to come to the idea of real-time order fulfillment with a queue of randomized orders. All of our past games have been relatively closed-ended: we put a lot of effort into building individual levels and puzzles that could be played through once and effectively never again. This time, we wanted to make a game that players could pick up quickly and replay indefinitely. 

To that end, the initial game idea, which involved more complex logic with each flower having specific requirements and individual puzzles that would only have one correct solution, was ditched in favor of simple shape tiling and a concept that would be intuitive for new players, even without reading the instructions. The theme of "overgrown" inspired us to add the weed-spawning mechanic, which we believed would add more pressure and complexity, while still keeping the vibes chill and cozy!

Within the first few hours of the jam, we had a full design doc and list of tasks and deliverables. In past jams, we frequently struggled with over-scoping in this stage, so we wanted to be extremely cautious about clearly defining the necessary features for the game, leaving nice-to-haves as stretch goals and prioritizing the completion of a fully playable build before anything else. We ended up being pretty successful at this, and managed to implement every major feature outlined in this initial design doc. 

This isn’t to say there were no changes between the pitch and the final game: there was a lot of iterative fine-tuning of design details, like the rate of plant growth or order creation. (Fun fact: we initially planned to have variable growth speeds for the same flower shape, and shearing a flower was originally supposed to kill it.) But overall, the finished game looked super similar to the initial design, and we didn't have to frantically cut any ideas at the end. As we gain more experience both with game dev and with collaborating, we’re slowly getting better at understanding our own workflow and estimating how much art and code we can produce in 48 hours. At the same time, we're trying to be simpler and more intentional in our designs to ensure they can actually be realized.

Art was a major focus for us from start to finish. Fortunately, by now we have a pretty practiced workflow: we have one artist in charge of everything in the background, and one artist in charge of everything in the foreground (sprites and UI). We try to lean into the fact that our artists have naturally different art styles: it makes it a lot easier for the player to distinguish what’s important and what’s just flavor in the game. Choosing to render in pixel art has also helped mask style discontinuities, but we still put a lot of care into making the game look visually cohesive, greater than the sum of its parts. 

For Floramino in particular, we took a lot of new approaches towards pixel art: rather than treating it like sharp-edged digital illustration (which we’ve done for past jams simply out of a lack of experience), we scaled down the resolution to force ourselves to learn and work with the constraints of pixel art, incorporating techniques like anti-aliasing, avoiding jaggies and doubles, and strengthening the silhouette of our sprites. A lot of information has to be condensed into a much smaller resolution when doing pixel art, and with a smaller canvas, we can be a lot more intentional about placement of each pixel.

Of course, this was not without its own challenges. Both of our artists come from more digital-art focused backgrounds, and the workflow of sketch → lineart → rendering is interrupted when making pixel art, in particular because sometimes there isn’t the resolution or space to have full line art. We’ve learned that in pixel art, the lines aren’t a separate entity from the colors, but rather work together with the rendering to shade and strengthen the silhouette of a sprite or object. 

We really cared about making the game look cozy and cute, but with such a limited time-frame, we had to find ways to make the art process go faster. Reusing or flipping parts of sprites can be really smart and efficient—for example, the top half of the hydrangea is the same sprite, but with the colors adjusted. And for the background idle animation, only one frame is actually pixel perfect. The rest of the frames of the animation are a result of gratuitous liquify tool use, which means we lose the integrity of some of the pixel art, but for a many-fold increase in speed of production. We still found time to throw in some extra flavor animations—there are three different animal animations tucked into the gameplay background! We didn't meet every art stretch goal, but we're still super happy with how cohesive it looks.

On the implementation side, we had three devs working on the game together, but we faced a lot of difficulty parallelizing work in the early stages: until the core functionality is built out, it’s impossible to work on developing additional features, making it hard for us to each work on separate tasks. We spent the majority of day 1 together in a VC, collaborating on creating the basic grid layout, click interactivity, and seed planting. Our early implementations included the base game manager and representations for each of the seeds and tools. There was a bit of overhead in this phase for setting up well-defined classes with organized relationships to each other, which definitely paid off in terms of our coding velocity down the line.

In past jams, something we always struggled with was properly laying out the class structure and using design patterns effectively. This resulted in individual features being scattered across multiple scripts and methods, requiring a frustrating amount of time to change or debug, especially when you’re running up against a deadline. While I wouldn’t say that we managed to completely avoid that this time, investing some time early into building some structure definitely helped later on. In fact, this has been our only jam to date without some mad panic in the last 2 hours because of some sneaky game-breaking bug we couldn’t find the root cause of. We might have just gotten lucky this time, but at least with the few bugs we did encounter, debugging was a lot less of a chore than it had been in the past. We did get a bit sloppier as the jam went on—similarly to the art process, sometimes you just have to do the quickest solution to get something done. We hard-coded in a list of number IDs for each tool, and especially as the hours got late, we kept mixing them up, resulting in some weird behavior. Fortunately, this was pretty easy to rectify, thanks to the groundwork we laid.

Another thing that helped avoid last-minute panic was building early and often. Just because the game works in the Unity editor doesn't mean it works on a browser, and just because it works on my browser doesn’t mean it works on every browser. We learned that the hard way with our first jam game, Lava Chef, where our UI did not scale consistently across screen sizes and resulted in a good chunk of players not even being able to click the “play” button. We made sure to post a draft web build at the end of day 1 just to avoid another Lava Chef situation, and we continued to upload and test new builds as we added more features. 

By midday on day 2, we had managed to connect most of the core systems together, and the logic for each component was complete. The game was technically playable, but no one other than us could play it, because the UI was missing: you couldn’t even see the orders or what tool you had selected. Since a lot of the UI art was still being worked on at the time, we created a set of placeholder sprites that would allow us to visualize the final game and create a fully playable, albeit ugly, game. We had 2 playtesters play the game and made a few small balance changes based on their gameplay, including retuning the timers, raising the number of orders given at once, and modifying the end screen so players wouldn’t accidentally click past it. After working on the game for nearly 2 days, we had completely lost any notion of what it'd be like for a totally new player to try it, so having the perspective of an external playtester was definitely helpful.

Using the placeholder sprites, we could add in the logic and animations to the game interface while the artists finished drawing. This went a lot more smoothly than in past jams, as we learned to make better use of Unity features like the Animator and Canvas rather than reinvent the wheel. As the completed art trickled in in the last hours of day 2, we began to swap out our placeholders with finished art, and added some neat polish, like visual effects for hovering over buttons, an animation for the order queue, and color tinting to show when you can’t place a plant somewhere. Having the time to focus on polish felt like a luxury compared to past jams, and was definitely only possible by having a tight scope to begin with.

You might notice that up until this point, we've almost completely neglected audio. We really regret not making the sound design a priority in this game: we like to compose some original music for every game, but our composer was way too locked in programming and ran out of time. We still aimed for a lot of cohesion with the music and sound effects we did include, trying to hit that perfect springtime farming sim vibe. But we didn’t add them to the game until the last minute, and it was really challenging to test. We ended up having some issues with audio looping that we didn't even detect until the final build.

Nonetheless, we managed to publish the game in time! 5 hours early, actually, but that’s mostly because of time zones. We did wake up early before the jam ended to squeeze in a few last-minute QOL changes, including an alternate rotation control scheme for trackpad users. Our artists had been decorating the itch.io page while our devs built the game, so everything came together really quickly. 

Ultimately, Floramino is a lot of firsts for us! It’s our first jam game where we felt experienced enough to approach it with intention and organization from the beginning, and that translated into our first jam win. We’re also super happy so many people seem to like it—it’s already got more plays than all our other games combined. Yippee!

From our players, we’ve gotten a lot of requests for an endless mode, so we’ll definitely be adding that in the future. We also have some ideas for a progression system where you can earn tips from completing consecutive orders and put those towards upgrades to improve your garden! We really love this idea, and we’d like to keep adding to it in the future. Let us know what you’d like to see, and thank you so much for playing 💚

Excitedly yours,

Studio Lavacado