TruffleCore Journal
From Weekend Prototype to Published Mobile Game
A year-long journey from a weekend prototype to shipping Taffy on mobile, plus the lessons we learned along the way.
The short version
A bit over a year ago Sami asked a simple question:
Would you be interested in building a mobile game? We could work on it a few hours per week and just move it forward steadily.
Henry and I said yes.
I’ve always liked games. Years ago I made and published a small top-down shooter for mobile, and I had a few unfinished prototypes as well. Nothing serious. So this felt like a good excuse to try again; a new hobby, something practical to learn from.
At that point I didn’t really think about publishing anything. It was more about the process than the outcome.
Now the game is live on Google Play and the App Store. And I’m genuinely proud of how it turned out. Especially how we managed to polish it into something that feels like a real, warm puzzle game — not just an engineer-driven side project.
Taffy: The Truffle Trails is out.
- Android: https://play.google.com/store/apps/details?id=com.trufflecore.taffy
- iOS: https://apps.apple.com/us/app/taffy-truffle-trails/id6755523038
Kickoff: January 26, 2025
All of this started on the first proper project day.
We chose Unity because it was the obvious cross-platform option. All of us had touched it at some point in the past, but it had been a long time. So in reality, we started from scratch. Before meeting up, we watched a short YouTube intro just to refresh the basics of the Unity Editor UI.
Then Sami, Henry and I gathered at my apartment.
Sami had prepared initial game design documents with fairly detailed descriptions of the core mechanics. We went through them together and used them as a base. From there we started refining the ideas, writing more concrete notes and breaking things into actual tasks.
The goal for the first phase was clear: Build a prototype that includes most of the core mechanics. Then evaluate if it’s worth continuing.
At some point the discussion shifted to something less technical — should the game have a main character?
For some reason, a cute pig felt like a good idea. It was slightly absurd but still warm and friendly. Henry was the one who first pitched the pig-and-truffles combo, and it stuck. After that came the naming discussion. Sami suggested Taffy Truffleton. It sounded pig-like and charming enough to work. The alternative was Bacon J. Sniffington (Bacon J.S.), but Taffy felt like the right choice.
The overall vibe that day was genuinely excited. I had prepared some food, we had snacks, and the atmosphere was relaxed but productive.
By the end of the day we had a tiny working prototype with placeholder graphics.
It wasn’t much — but it was enough to feel like this might actually become something.
Prototype snapshots
The first two weeks
The core mechanic was already there from the beginning — draw a path and guide the character to the finish line. Interestingly, that part did not change much over the year. The idea was solid early on.
What we struggled with was implementation.
Since we were essentially relearning Unity from scratch, a lot of time went into figuring out where things should live in the project structure, how to separate UI from gameplay logic, how to organize scenes, prefabs and scripts in a way that wouldn’t become a mess later.
We were learning constantly while building.
One of the early decisions that turned out to be very important was building a level editor. We identified quite quickly that without proper tools to create levels, testing and iterating the game would become painful. So instead of hardcoding levels, we invested time in building an internal editor with a full feature set.
That decision paid off later.
Unity itself is extremely powerful. But at the same time, as a new (or returning) user, it often feels like developer experience is not the first priority. Even basic things required digging through official documentation, forum threads and YouTube videos.
Quite often we found ourselves searching for solutions to problems that every game in existence must have already solved.
The first moment when it actually felt like a real game was surprisingly simple.
We had the basic mechanics working. Then we added very rough prototype graphics on top — some were almost wireframe-style visuals exported straight from Figma, which I was also learning at the same time.
And suddenly it clicked.
Even with placeholder art, it already looked and felt like a game.
Prototype snapshots
The first six months
We worked on the game steadily — at least in theory.
In practice, motivation came in waves. Sometimes Sami was clearly the driving force, pushing things forward while me and Henry were more on the sidelines. Not because we didn’t care, but because energy levels varied. That’s the reality of a side project done on evenings and weekends.
During the summer we decided to change the pace.
We rented a cabin for a weekend with one clear goal: push the project forward properly. That weekend turned out to be a real turning point. For the first time it felt like we weren’t just experimenting — we were committing.
We worked on design decisions, implemented features, discussed scope and even did some early market research. The project moved forward in multiple dimensions at once.
And since we are Finnish, the setup was predictable: sauna, grill and a palju (a wood-heated outdoor hot tub). Work sessions, breaks, sauna, repeat.
As you might expect, great things happen at those kind of moments. Such as this very first track for the game (didn’t end up in the final version though). Listen here: https://suno.com/song/2b3976f9-710f-4d44-b5a3-903c964e5151.
Somewhere during that weekend we also realized that if this is going to be published, it needs a proper name behind it.
That’s when TruffleCore was born.
The name was slightly random but still logical. It references the roots of everything — Taffy, the truffle-hunting pig — and at the same time it sounds like an actual game studio. Something that could exist beyond just one project.
After that weekend, the project no longer felt like a hobby experiment.
It felt intentional.
Polish and pivot
By autumn, most features were implemented and the majority of the graphics were in place. The game was fully playable from start to finish.
At that point the focus shifted from building to polishing.
Our initial release target was Poki, a browser-based game platform. It felt like a natural first step — lower barrier than mobile stores and a good way to validate the game.
Poki’s approval process includes structured playtests. Each round meant 500 real players and recorded sessions. We submitted the game multiple times.
Based on the recordings and analytics, we tried to understand where players dropped off and what might be unclear. Poki has specific performance targets for acceptance, and we didn’t meet them.
So we improved onboarding. We added tutorials. We clarified UI. We adjusted pacing.
Each iteration made the game more guided.
At some point it became frustrating. From our perspective the game was already in a good state and easy to approach. Our friends’ playtests supported that view as well. Still, the metrics didn’t align with Poki’s expectations.
After enough cycles of “one more improvement” and another 500-play test, we made a decision.
Maybe the game simply wasn’t a perfect fit for Poki.
Instead of endlessly optimizing for one platform’s metrics, we shifted focus to what we originally set out to do — release on Google Play and App Store.
That decision simplified things.
We stopped chasing acceptance and started preparing for release.
The mobile launch push
One of the first practical realizations was simple: we needed a website.
Both Apple and Google require things like a privacy policy, and it made sense to have a proper front page for TruffleCore and the game anyway. Since all of us have a strong background in web development, this part wasn’t a blocker.
We coded a simple website, bought a domain and hosted it. Now we had something official to link in the stores and elsewhere.
Device testing itself was surprisingly painless. The game worked well on actual phones. While the website was under construction and store submissions were temporarily stalled because of it, we used the time to make smaller improvements and tweaks.
Submitting to the stores required more reading than coding.
We had to go through policies related to privacy, data handling and monetization. Since we wanted at least light monetization, we set up AdMob for ads and implemented In-App Purchases to remove ads via a Supporter Pack.
The App Store process was slightly simpler. Beyond Apple’s review process, we only needed our own testing. Because of that, the game was released on the App Store a couple of weeks earlier.
Google Play was stricter.
They require at least 12 testers in a closed beta for 14 consecutive days. The 14-day countdown only starts once the 12th tester joins. While waiting for the period to pass, we continued polishing and even implemented a new feature: Daily Challenges.
Nothing major broke during testing. Still, before pushing the release button, we decided to submit one more update. Fourteen days is a long time when you’re actively working on something.
Interestingly, during that period we also revisited many of the “improvements” we had made for Poki. Some of them felt overengineered for mobile, so we stripped or simplified several things.
At the very beginning of February, we finally pushed the first public release to Google Play.
That was the moment we reached the original goal.
A few days later we released our first larger update on both platforms — adding Daily Challenges and polishing visuals and small details across the game.
Published game preview
Closing thoughts
I learned a lot.
Unity went from something I had touched years ago to something I now understand on a much deeper level. I also learned what it actually takes to publish a monetized game — privacy policies, store guidelines, ads, in-app purchases, testing requirements. And along the way, I became much more familiar with using AI tools as part of the workflow.
Was it worth it?
Yes. Absolutely.
I would do it again.
The most surprising moment in the whole process was probably the rejection from Poki. There are many games on the platform that, in my personal opinion, feel less polished and less enjoyable than Taffy. But that’s fine. Platforms have their own metrics and priorities.
In the end, we released the game on bigger avenues anyway.
Looking back, one thing I would do differently is simple: arrange more in-person coding sessions. Those weekends and meetups were easily the most productive and the most enjoyable parts of the project. Progress was faster, discussions were clearer and motivation stayed high.
Seeing the game live in the stores is still a bit surreal.
What started as “maybe we could try this” is now something real.
And that feels good.
If this story piqued your interest and you’d like to give it a spin, here are the direct links to stores:
