The Akupara Game Jam: Rosie’s Inn

Akupara Games
11 min readJan 14, 2021


With two weeks left in 2020 right before the holiday season, we decided to take a break from some of our usual publishing, development and porting tasks to instead have a little fun. The Akupara Game Jam saw teams of developers, artists, writers, and designers come together to create prototype games and let the imagination of our teams run wild. Today, we’re getting the ball rolling by showing off the first of three prototypes. You can play the game right now on or Gamejolt for free, or you can keep reading to get a little insight from the game’s designer, Buddy Sola.

What is Rosie’s Inn?

You can play the game for yourself right here or take a look at the video above to see what Rosie’s Inn is like in action, but for the sake of completeness: Rosie’s Inn is a management sim where you play a quest giver assigning quests to NPC adventurers. If you’ve ever played a DnD game where the party picks up their first adventure in a local tavern, imagine you’re the bartender giving them the lead on the goblin bandits just up the road.

But if the question becomes: “What are the quests and who are these adventurers?” Then that’s when we get into the meat and potatoes of the game. In Rosie’s Inn, different adventurers will be particularly suited to particular quests. Sending a ranger, who’s used to silently stalking prey and sneaking through the woods, to break up a riot outside the Lord’s estate might not be the best choice. Sending that same ranger to hunt down a dire bear, though, will likely return much better results.

So, part of the game is going to be making the critical choices about what quests are suitable for what adventurers, but another piece of the puzzle will be managing your quests, adventurers and gold strategically in the tavern itself. You’ll start with 500 gold and then invest gold into every quest that you send someone out on. Then, when that adventurer returns, they’ll bring back a certain amount of gold depending on what happened. Most quests turn a profit just by succeeding at them, but you can also critically succeed at a quest, bringing a huge windfall back to the tavern. At the same time, however, you can end up sending adventurers to disaster instead. Sometimes, they will fail their quest and you’ll be out the gold you invested. In dire cases, the adventurer might perish and be removed from your playthrough entirely.

If you want to get to know your adventurer’s strengths and weaknesses, you’ll need to spend time talking with them in the bar. Keep an eye on the clock, however, because you’ll only have twenty minutes to play. Every minute you spend chatting with Grimgi the grumpy dwarf priest is a minute he won’t be out slaying zombies. At the end of the twenty minute period, the game ends and you’ll get to see some statistics for how you played! A high score is represented by the amount of gold you ended with, so if you break open the bank be sure to share that with us!

The first draft of the tavern’s layout

Where Rosie’s Inn Started

When the Akupara Game Jam was first announced to the company, we all submitted ideas to one another, blindly voting on our favorites. In just a couple sentences I had to pitch Rosie’s Inn to other members of the company to try and entice them to come play. A number of our team members found the idea of Rosie’s Inn exciting and, so, our Game Jam team was born. It was my pitch, so I’d be the game’s designer as well as narrative design. Kyle Holmquist also joined as a narrative designer. Jaden Davis came as our programmer, Drew Montemayor would take care of our art needs, and Justin McGinnis would make sure things ran well as Quality Assurance. Wrangling all of us, Chris Nguyen would serve as our producer.

Here’s the pitch:

An economic sim, you’re a tavern keeper in a generic fantasy setting running the local tavern. As adventurers come through, they pay you for leads on nearby adventures, like local bandits or goblins in a cave. To get those leads, you need to buy them off your patrons, get them drunk enough to tell you, or eavesdrop on their conversations. You get paid a percentage of the loot that comes when the adventurers come back, so you need to give the right leads to the right adventuring parties so they have a higher chance of success. (A party with a cleric will do better against undead, for instance.)

Now, you might see a couple differences between that pitch and the final product! The pitch includes a number of extra systems that, once we put a bit of time into thinking about it, increased complexity in a way we couldn’t sustain. For instance, picking up the quests via patrons was something I vaguely wanted to add to the game; it’d help explain how the quests come in, create a more immersive experience since you’d need to both “buy” the quest and then “sell” the quest. It’d make you something of a fantasy middleman, which I thought was interesting. But it would also require a more robust system for random patrons hitting the bar and so we decided to leave it aside for now. We hoped we might have the ability to come back to those mechanics and flesh them out, but decided to ship with the message board as the source of quests for the game instead.

Another system I described in there that I ditched fairly quickly was the idea of adventuring “parties.” At first, I was thinking about that typical dungeons and dragons scenario: you and your group show up in a bar and get a quest from the bartender. But the moment I started thinking about how parties would work, I immediately realized it would be out of scope. For one thing, a party would have a much easier time covering the demands of a quest. If I have three or four slots that I can put adventurers into, I have that many more chances to then create quests requiring those adventurers’ strengths. Therefore, I’d logically need to expand the parameters of the quests to include more specific criteria to check the party for. In the context of a full game, I might be willing to put in that time and effort. In the context of the Akupara Game Jam, though, we needed a simpler solution. Thus, we decided that adventurers were lone wolves. You had one chance to assign them and get the right results. On top of that, it meant we didn’t need to balloon the adventuring pool. Right now, there are nine different adventurers that you can choose from. If we need to support parties, though, we’d likely need to expand that number dramatically, and doing thatwould strain a player’s ability to intuit and remember which of their adventurers did what.

All that said, the final piece of the pitch absolutely made it into the final product. I always knew that the skill test for the game would require a player to assign their quests appropriately and that a critically thinking player should do well, while a lazier player should do poorly. This would eventually become the mechanical crux of the game, the fulcrum on which everything played off. There are spaces for skill expression in the players’ other decisions; tactically, players can make interesting choices about whether they save quests for high performing party members or compromise with sub-optimal adventurers just hoping to get a straightforward payout. But the core skill test and challenge to Rosie’s Inn would come from accurately and acutely identifying the strengths and weaknesses of a character and interfacing those, like a key into a lock, with the parameters of any given quest. Holding onto that nugget, we decided to move forward with the title, making a few interesting new decisions along the way.

Some designs for the tavern keeper herself!

Where Rosie’s Inn Ended

About one week into the project, the team and I had a meeting. We had a low level prototype of the game up and running, but there was a real question of where we were going to go from here. Following in the footsteps of many game jams before us, I had scoped the project too low, cut too much complexity to try and get a working build out fast but without giving the team a big picture to look forward to. In that meeting, we had three key insights that helped lead us to the path of the game’s final design.

First, Chris told me not to worry about scope. This seemed like heresy at the time! Game jams famously scope out of control into something entirely unworkable and unreasonable. It’s so, so easy to come up with systems, additions and expansions to your game when it’d be impossible to implement them. But the insight that Chris had was thanks to his role on the team. While the initial build was functional, it was drastically incomplete and I needed to share more about the direction of the game. In other words, I needed to let Chris, as producer, decide what was in scope and out of scope. Additionally , I needed to focus on giving everyone the full picture of Rosie’s Inn, even if we couldn’t implement everything.

The second insight came when Kyle suggested we add a definitive timer and use gold to measure a high score. I had initially imagined that the win state of Rosie’s Inn was more implicit than explicit, that players would eventually reach a goal and quit of their own volition rather than the game giving them a true game over screen. In a certain sense, the game had an explicit lose-state, since you could hypothetically have all your adventurers die, but Kyle suggested we cap the encounter and make it a test of efficiency. This was a stroke of genius since it gave players clear, discernable goals to strive for. Much like the clear goal of a categorized speedrun, the clear goal of raising as much gold as possible fueled players’ desire to continue with the game for its twenty minute run time. Some players would take everything they learned in their first playthrough and use that insight in their second! Having the timed win state in mind also created real tension in the game’s main challenge. Waiting on characters to return isn’t very dramatic without the ticking clock hanging overhead. Now, every second reading quest text had real value assigned to it. Hesitating to assign someone a mission cost you gold in the long run and gave your decisions real weight and meaning.

As for the final insight, Drew suggested that we keep character art to just portraits and use generic art with different colors for the interiors of the tavern. If you’ve never worked in games before or never participated in a game jam, you might be surprised to learn that the biggest obstacle to any prototype getting out is always art. Having a clear, efficient art pipeline with equally clear and efficient goals meant that we could reasonably finish the art for the prototype without being constrained by it. Initially, the prototype was likely to only have six characters rather than the nine in the final build. By simplifying the art to expressive portraits instead of long-distance anduninteresting full body shots, though, we could expand the number of playable adventurers (increasing the complexity of the core gameplay) while at the same time focusing on the most important art for those characters: their expressive faces.

From there, I prototyped the nine classes. Kyle and I split them in half, each of us crafting personality profiles for every character as well as their respective tavern dialogue scripts. Each small piece of dialogue actually serves more than just a flavor purpose: it helps communicate the underlying mechanics of the game! Something I always wanted was to keep the underlying systems of the quest assignments oblique. By nesting crucial pieces of information within the dialogue of each of the characters, it created a reason for players to get to know them. As you read their character dialogue, you were both learning the backstory and personality of this character and the way they functioned in the game proper. Similarly, the quests themselves were written to point you in the right direction when it came to their underlying parameters, but not explicitly break those parameters down. Skilled players will learn how the characters interact (or don’t!) with each individual quest you send them on.

Interestingly, this created a simple matrix of the different characters. All characters had two traits, one basic and one advanced, that were sharedwith other characters of similar disposition. The basic traits are built to be straightforward and easy to understand while the advanced traits might be a little tougher to discern. A character’s basic trait will typically decrease the failure rate of whatever quests they end up going on while their advanced trait will typically increase the critical success rate of those quests. This meant that matching a character to a quest needing their advanced trait is overall more lucrative (but no less risky!) than matching a character to a quest needing their basic trait, which provided less risk but a more meager reward. The very best players will learn which quests align with characters’ advanced and basic traits so that they can simultaneously increase the chance of a critical windfall and decrease the chance they will fail.

Failure is always possible, though. Not all failures will be lethal, of course, but it always needed to be in the equation. For one, it creates a need for players to conduct many field tests with their adventurers. If they immediately send someone on a mission and get critical successes every time, their interaction with the system is a little too binary and clearcut. It’s about their ability to see rates of successes over time more than their ability to mix and match once. Additionally, it creates a dynamic in the overall tavern that’s very important. Losing an adventurer, especially early in a run, can really hamper your ability to earn gold. Now, you’ll be getting quests for things that no one on your roster is quite suitable for. You’ll get them close, for sure, and as you come to understand the matrix you might make educated decisions about who to send where, but having someone perish on your runs makes the overall gameplay much more dire and strategic.

A mock-up of the ten characters’ portraits in game

Where Rosie’s Inn Goes From Here

Well to start, the game has been released! But Rosie’s Inn will still remain in my head for a good, long while as I continue thinking about the game and its systems for many months to come. If you’ve played the game, I’d really like to know what you think! Join the Discord, tweet at us, or send me an email! If you play the game enough to get more than 3,500 gold, send a screenshot to buddy [at] akuparagames [dot] com and I might just have a special surprise for you!

Next week, we’ll be featuring the second of our three game jam prototypes. This one will have you worrying less about the high score, though, and more about just… surviving.