The King's Jest

The King's Jest is a multiplayer mobile party game where players compete in short rounds, using the phone's own motion sensors to move and dodge obstacles.

The project was built during a cycle at the Apple Developer Academy, where the team had just three months to conceive, build, and ship a game on the App Store — one whose mechanic or dynamic had to be genuinely different from what was already out there.

Starting assumptions

From the very first meeting, the team settled on Core Motion — Swift's native kit for reading the phone's movement — as the basis of the mechanic, because of how much it could set the game apart. To push that further and give the pitch a strong story, we went with local multiplayer, on the assumption that having players physically together would make the experience land harder.

Among Us came up as a successful mobile party game, but it stayed out of the benchmark: it did not meet the core criteria we had set for the project.

Because this was an entertainment product, there was no way to know whether the mechanic, the format, or the audience would land until the MVP existed. So during discovery we wrote those unknowns down as hypotheses, to be tested against the game in real use:

Storytelling

We set a simple narrative frame to give the game an identity without getting in the way of the gameplay, using the story only to create a connection and give the challenges a context.

Set in a fictional medieval world, the game runs on dry humour and moderate difficulty: court jesters competing for the approval of a cruel king. In the single-level MVP, that comes down to a platform race through a dungeon, where players have to escape without falling into the lava.

Testing in a controlled setting

After launch we ran controlled tests with two groups of four to eight players, aimed at validating local multiplayer and the core mechanic. Participants matched the audience we had defined up front: 14 to 30 year olds, with a range of familiarity with games.

The results pointed to the game engaging people who already play, who were noticeably keener to go again. On the back of that, we decided to take the game to a gaming event, to test the hypothesis at scale in a setting much closer to that audience.

The validation data exposed limits in the original audience, in the multiplayer model, and in how far the game could scale technically. From there, I led a strategic turn for the product, aimed at widening its reach, creating more chances to play, and opening room to grow.

The behaviour we had observed — players beating their own records — was turned into a way to play.

With no monetisation model in place, the focus is on understanding how long players spend inside matches, since that time is a direct signal of engagement.

Building an entertainment product put the whole team on unfamiliar ground. The goal was not to solve a direct pain, but to create something different, fun, and worth remembering.

It became clear that thinking about a game runs on a different logic than utility products. The decisions go past efficiency and usability into engagement, surprise, and whether anyone wants to play again. For all that complexity, it is what made this project so enjoyable to build.

I worked mainly on the strategic layer of the product, moving between the designer and product manager roles. Over the course of it, I confirmed both my interest in and my aptitude for work that calls for product vision, organisation, and constant communication.