Developing Bake It under quarantine

We launched Bake It, our hypercasual baking game for mobile, on April 28 -- around six weeks on from when we started working from home ahead of official COVID-19 lockdown guidelines.

In what was and continues to be an incredibly turbulent time for people and businesses all over the world, we feel extremely fortunate to be in an industry like mobile gaming, where a sense of relative continuity in day-to-day affairs is possible. Our job is to provide satisfying and stimulating experiences to fill the small spaces between other activities. Although the virus has been disruptive to many lives and businesses, people are still keen to fill their time with the light puzzles and challenges of games.

But of course, not even in our industry has everything continued as normal. I think it's worth digging beneath the surface a little to reveal exactly what went into the creation of our first ever remotely-developed game, how we were forced to adapt, and what other developers might be able to take from our transition from studio-based development to collaborating from home.

We feel extremely fortunate to be in an industry where a sense of relative continuity in day-to-day affairs is possible

Bake It began as a pitch on a pre-lockdown Creative Wednesday in early 2020, delivered by senior game designer Gabriel Tanasic and I. Creative Wednesdays, in less troubling times, are when the entire Kwalee team gathers in our presentation area to hear new game ideas. This process is open to the entire company and, while working from home, we are continuing the format digitally to keep the creativity flowing.

If a game idea gets buy-in from the majority of the company, in a vote held directly after a pitch, we get a team together and build the prototype. I try to pitch as many ideas as I can, not only to get them greenlit but also to get as much feedback from my peers as possible.

What we left behind

You're probably getting a sense already of how much our game development process, from the very outset, is tied into our physical space. Like many developers, we love our studio and under normal circumstances we're always moving between one another's desks, communicating quickly, discussing ideas and potential solutions to problems.

And with Bake It in particular, we knew there would be a lot of problems to solve. We wanted to give the player a sense of freedom in an authentic baking experience and we didn't want to cut any corners, relying on extensive R&D to develop tech that would simulate the process accurately and make it as fun as possible.

Simply put: if we could have chosen our first ever project to take on as a remote team, Bake It would have been pretty low down the list. But that's what ended up happening when we took the decision to begin working from home, thrusting us as a company with zero history of remote working into totally unfamiliar territory.

Sweat the small stuff

Immediately, we knew that communication among the design team would be even more vital, and that there was a greater risk of misinterpretation leading to wasted time in lockdown. If you're collaborating remotely, you'll need to be even more thorough with your documentation and keep strong visibility on the more intricate moving parts of your project. Recognising this, we kicked the project off with the full team, talking through everything we wanted both visually and functionally in as much detail as we could.

We were quick to set up communication tools like Slack and Discord to simulate the office environment as best we could, using specific chats to show off our work in progress to one another. We also set up remote VPN access so that designers and producers could take control of developer's machines and tweak camera settings, variables and the like, just as they would in the office.

For us the solution was to take a small step towards micromanagement to compensate for the loss of shared space

Our aspirations for Bake It were to create three unique versions of the game to test, each with significant differences, simultaneously. Testing and iteration is always important for us, but for a simulation game like Bake It, it felt especially important to get the physicality of the dough and icing feeling spot-on. We played with the tactility of the ingredients being used to allow players to make as much of a satisfying mess as possible. We also experimented with different mechanics based on real-world baking techniques, like cutting the top of the bake to give a flat icing surface and flood glazing.

The hardest part of hypercasual game design, and one of the most important, is game flow and UX [user experience]. When you only have a short burst in which to entertain the player, maintaining a satisfying pace that complements the challenge and interaction is key. How long should it take for the dough to drop from the piping bag to the tray? How long should the camera take to angle up for the baking process? Should we trigger the celebratory VFX after the character receives the bake in their hands or before? All of these small decisions come together to form the enjoyable game loop.

More regular communication is necessary to achieve this when working from home. It's important to find a solution that makes sense for you and your team, and for us the solution was to take a small step towards micromanagement to compensate for the loss of shared space. That might be a word that comes with negative connotations, but adjusting these small things on the fly via remote control or regularly reviewing work-in-progress videos went a really long way in helping us understand where we should be sinking most of our time when it comes to polish. It also helps to reduce the distance between us and prevents developers from feeling as if they're butting their heads against these issues alone.

The final stretch

It's easy to assume that the hard work is done once the team gets into bug-fixing, but we find that this phase relies more than most on quick and efficient communication between our development and QA teams to tackle issues and hit deadlines. It's a lot about communication; if the teams are detached it is easy for simple issues to be turned into hours of unnecessary back-and-forth on "This is what I think should happen" bug tickets.

Our QA team is the best I've ever worked with, dedicated to quality and willing to lean on communication and education to solve issues before throwing them into a database. They are empowered as a team, which saves everybody a lot of time. To make sure that this didn't change when we entered lockdown, our QA team was the first to trial "always-on" communication tools, keeping Discord channels live and open at all times to ensure uninhibited conversation. For a team that relies so much on internal collaboration to hunt down and resolve in-game issues, this was essential.

We've recently made certain roles open to remote applicants indefinitely, which is a step we never imagined taking

As I'm sure is reflected at many companies, QA under normal circumstances is one of our most physically active departments. We're used to them being on their feet a lot and moving to where the important conversations are being had in the studio. For Bake It and other games worked on under lockdown, they quickly began to simulate with an open (digital) door policy and being prepared to jump onto video calls whenever something needed their attention.

Finally, and in many ways the opposite of what we found to be necessary on the development side, the QA team shifted its structure, with our head of QA delegating a lot more responsibility and ownership to the more experienced members of the team. Key figures quickly proved they can be relied upon to be vocal and organised leaders of our projects day-to-day, and all of this combined to make the QA department one of the most efficient from day one.

The launch

Of course, the next step for Bake It was to finalise and launch the game as a remote team, which was another totally new experience. What was usually a firm, decisive moment between stakeholders was suddenly a more cautious and gradual approach to the decision to press "submit". With everybody remotely reviewing builds independently, it was an anxious wait for thumbs up from all before we felt comfortable pulling the trigger. I think that to some extent our concern in the build-up was healthy, ensuring that we focussed on quality control in what was a very complex and taxing development sprint.

If you're all conscious of the potential pitfalls of your current situation as a team and invested in avoiding them, you'll see that very little coaxing is required for everyone to step up. All of this culminated in us actually delivering the final build of Bake It a day early, and the game went on to be downloaded more than ten million times in its first month. It's now nearing 20 million downloads.

Perhaps even more significantly for us, however, Bake It showed a company with no real expertise, history or interest in remote working that we could continue to develop and ship games remotely. Indeed, we've recently made certain roles open to remote applicants indefinitely, which is a step we never imagined ourselves taking. We're certainly not the first company to have this revelation, nor will we be the last.