Expeditions: How we built the biggest Lily’s Garden feature to date
Over the years of working on Lily’s Garden storyline, there have been several ideas about exploring a mystery-focused story spin-off. We already knew that our audience liked mystery stories and on top of that, true crime literature, films and TV shows were becoming increasingly more popular. And so it became clear to us that it’s time to properly start pursuing this idea.
This is how the Expeditions project came to life.
From Whitney’s Mysteries to Lily’s Mysteries
This project started off as its own game and its protagonist was one of Lily’s Garden’s nerdiest, mystery obsessed characters, Lily’s good friend Whitney. The team spent some time trying to settle on the direction of the storyline, but in the end decided to re-write the entire story with Lily as the main character. This is when the project got green lit.
Once the game direction was settled, it was time to put together its development team. The timing was perfect, as we had a team of artists and designers weaning off another project, and so they jumped onboard. This is when Jon and Mikkel, the project’s game design ‘octopuses’, started their new expedition.
The newly assembled team began working on the game, but the idea for the storyline was still very much in its infancy, so they spent most of the first months nailing down the missing pieces. The initial idea was that, like in Lily’s Garden, the player would be moving around the map and renovating areas, all whilst solving a murder mystery as a part of a Murder Club.
Whilst developing the concept, Lily’s Mysteries team was approached with the idea of transforming the project into an Expeditions feature within Lily’s Garden. At the time, our product team discovered a trend of expedition features popping up within casual games. The team immediately jumped on board, but here is where the real challenge started – building a huge, extremely complex feature within a 5 year old game that was Lily’s Garden.
Lily’s Gardens Expeditions
Before going any further, the team took a step back. “We had to ensure that the project we’ve been building could be plugged into Lily’s Garden in the correct way,” explains Jon, “There were a lot of things that had to be adjusted and several issues popped up that had to be resolved. There was a lot of back and forth trying to figure out how to move forward in the right way.” This whole process took about a month and at the end of it, the team was able to create a trimmed-down version of Lily’s Garden, where the project could be worked on.
“This allowed us to do more rapid prototyping,” says Jon. Adding new code to a huge project such as Lily’s Garden can cause the engine to compile for up to a minute, whereas working within a trimmed-down space takes just seconds. The team continued working in this environment until it became necessary to move into the full project, to properly test the game before release.
At that point, Roche, one of our Unity Tools Programmers, joined the crew. Her addition to the team was crucial, as it was no small feat to move Lily’s Mysteries, its own game built on its own principles, into a mature game like Lily’s Garden. The team had to establish a new development pipeline, new workflows and in the middle of all of this, they switched to working in scrum, as the entire company moved away from following a more traditional waterfall approach.
Roche started off supporting the team with smaller tasks. “The first big thing we worked on was a system called Dialogue 3D. For the expeditions project, the team wanted to work with 3D characters in our dialogue system, which until then supported only 2D characters,” she explains. On top of this, she updated all the shared modules within the Expeditions feature to ensure they were in sync with the latest code updates, as well as that the code was fully synchronized with Lily’s Garden codebase.
Building the game’s core
Before figuring out how everything will tie together on the technical level, the team had to finish developing the meta layer of the Expeditions feature. This would set the ground for everything else moving forward.
The team first looked at the market for inspiration on what other games did with their Expeditions projects. At the same time they re-visited the original idea of Lily solving a mystery as a part of a Murder Club. This led them to deciding on having the story set on an island, which offered the perfect setting for exploration, and it also clearly separated the feature map from the original Lily’s Garden map. It also had to be a feature that could be unlocked by any player, no matter if they’re on level 100 or 15000 – which meant that they had to think carefully about the characters they included in the feature, so as not to disrupt the original game’s storyline.
In the end, the team decided to simplify the story to just Lily solving a murder and to somehow involve Luke, as he’s the one character in the game that is present from day 1 and appears throughout the entire storyline alongside Lily. The team brainstormed all the different ways that this story could go until someone came up with the idea of Luke sitting behind bars. “For some reason, this idea immediately clicked and everyone absolutely loved it,” Jon laughs. This is how they locked in the final story of the Expeditions feature. The storyline was generic enough that it enabled the team to not have to dive too much into the relationship between Luke and Lily and the goal was simple – solve the island mystery and help acquit Luke of the murder he was accused of committing 🤝
At this point, Mikkel, the game director and a gameplay programmer started solidifying the concept, quite literally, with sticky notes and an empty wall.
The aim was to nail down the design concepts and then create solid tech implementation plans on top of them. They did so by something Mikkel refers to as ‘event storming’: “We went through all the different types of behaviours and actions a player could take within our Expeditions map,” he explains, “We covered every possible scenario. We discussed what actions a player can take when they open the game and what will be the responses from the device they’re playing on. We brainstormed about what it means when a player ‘interacts’ with an obstacle on the map. Do we see any visuals or animations when they do so? We also discussed in-depth the technical implementation of the designs, to see what we were already able to do and what we’d need to develop from scratch.” All the game functionality was lined out on the walls and occasionally more people joined in to share their context and perspective.
For Mikkel, this was crucial to get right. “Our ultimate goal was to eliminate as many questions as possible at the very start, so that we could nail down the barebone of what this feature should and could do. We didn’t want to discuss hypothetical scenarios, we wanted the feature to do certain things and so we focused on finding ways to make them work from the technical side,” he adds. This also opened up many side conversations, which allowed them to dig even deeper into specific concepts.
Building a common language
As mentioned before, the biggest challenge for the team was ensuring that the Expeditions feature and Lily’s Garden game work well together, and that they’re able to innovate within the feature without breaking the rest of the game. For Mikkel, Jon, Roche and the team, this meant creating new layers of functionality within our code and also re-using older systems.
Once the designs and technical plans were finalized, the team started breaking them down into smaller pieces. This was important as it allowed others to get quickly familiarized with the concepts, even if they were not a programmer or a game designer. It also set the baseline for the sprint backlog, which initially culminated in a whopping 1000 tickets! Writing user stories for each sprint suddenly became more challenging, and as more people joined the project, it became very obvious how important it is to find a common language to talk about things.
The team was now well and fully in their storming phase. Team members often found themselves in situations where they were using the same words, but understanding completely different things. Roche gives an example: “We realized that when we talk about the ‘editor’, we understand this in different ways, depending on whether we are a programmer or a designer. When the designers talk about the editor, they are referring to Unity itself and the tools they use to build features. For me as a programmer, I think of ‘editor’ in a more technical sense, meaning editor-only code. Runtime code cannot reference editor code or else builds would fail, which is why the distinction matters for developers.”
A long time was spent on fully aligning on how they should talk about things, so that everything got done in the correct way. For Jon this meant that he frequently had to write multiple tickets about the same subject from different angles, to allow team members to fully understand their task.
Ultimately, for the game designers and artists, who were constantly producing new content, this process had to be as smooth and fast as possible and for that, they needed new tools. For the tools programmers, like Roche, it was important to enable the content people to get their work done smoothly both within the editor and in the pipeline. As things came full circle, it was crucial that both sides could communicate about what they needed from each other in the right way.
When developing and producing at the same time
And so, the team kept working. The content creators had to use new tools whilst they were still being developed. They were giving feedback as they worked and then waited for the changes to be implemented or for complimentary tools to be developed. They were finding the middle ground between building fast and building to last.
This was the part of the process when the team learned the most. Balancing stability and speed whilst chasing perfection was no small feat. Going through the scrum process allowed them to move forward step by step and to take away something new from each individual sprint. “This is why getting those design concepts, technical plans and supporting tools was so crucial at the start,” emphasize Jon and Mikkel. “Building a lot of tools allowed us to minimize throw away code and to instead focus on making things that are keepable and can be used long-term,” they add.
Finding the right balance and figuring out when to prioritize what was the biggest learning. The second learning came after that, when the team realized that people working with these ‘work in progress’ tools have learned their quirks and knew how to get around them, but for new people onboarding on the project it created real challenges.
“I ended up writing a 20 page documentation on how to use the tools and on how to set up the entire process when starting the next Expeditions season,” says Mikkel. “As the tools evolve, the documentation needs to be updated, so it’s a very live and constantly evolving process.”
The tools that made a difference
For those more curious about the specific tools the team developed, this section’s for you.
New navigation system
Whilst developing the Expeditions feature, navigating the map became a difficult task. The feature was developed using a navigation mesh, which allowed the player to move Lily’s character around the island. This was a great solution until the original game duplicated the new mesh. The team was pushed into finding a solution and so they developed a separate navigation system belonging only to the Expedition feature, which also allowed the game to use both systems at the same time.
New fog system
On top of this, QA kept reporting unusual holes in the fog covering unexplored areas of the Expeditions map. Unlike Lily’s Garden, where the fog system is used to add fog in desired areas, the Expeditions feature requires fog to be present everywhere by default and removed selectively as the player progresses.
The team quickly realized that they were using the same camera to render the fog layer as Lily’s Garden, which caused areas of overlap between the two maps, causing holes to appear. The solution here was to create a separate camera layer which belongs to Expeditions only. They also introduced a new tool which removes fog in specific areas as the player progresses, fixing a use case the original system was not designed for. Simple, yet very effective solution, which used an existing system with a slight twist.
New data saving system
One of the biggest tools they developed was the new data saving system. To give you some context – within the Expeditions map, there’s thousands of objects. In Lily’s Garden, every part of the map has its own area which is its own file. Not all files load at all times because they are not needed, it depends on what area the player is focusing on. This system caused several problems for the Expeditions project. Firstly, saving thousands of objects in map areas would have been way too heavy for the game. Secondly, area loads are indexical on camera position, which means that a “data” representation of interactables had to be available at all times for game feature specifics such as navigation and guidance. This led to a lot of discussion and brainstorming, and resolved in a brand new way of saving data files.
The new system took a while to make as it was extremely complex, but it allowed the team to have the needed data representation of interactables available at all times. It was now also possible to save all the objects in a much more efficient way which did not require them to be saved in map areas during build time. They achieved this by creating text files which had all the information about the interactable objects, what they do and what they connect with. The trade off was that while it allowed for faster loading speed inside the game, it made authoring more complex for our content creators. All of our data was now saved in one huge text file, which made finding causes of errors a lot more difficult. To make it easier to work with, further new tools were needed.
Reflections
“Despite the challenges, this system proved to be a great way to store data and to do calculations and optimisations. It can now also be used in new games that we’re building”, says Jon. Innovating within legacy systems comes with many challenges, as they were not originally designed for higher complexity and optimisation. For the Expeditions team, this brought many challenges, including how they rendered objects and interactables in the map area. Jon explains: “A big learning for us was that we have to think about these things when starting on a new project. We need to think early on about how we want to structure assets, so that they don’t block us from making improvements in the future.”
There is also the matter of balancing flexibility and complexity. “When you brainstorm and prototype, you get so many ideas about things that you’d like to do. It’s great to work with systems and tools that allow you to test ideas out, but you have to be aware that this comes at a cost, as it allows for user errors. If you’re only a few people on the project, it’s easy to make workarounds, but when more people are involved who haven’t learned the rules to prevent errors, a lot of things start to break. A huge learning for us was that it’s better to design things in a more stringent way,” reflects Jon.
The biggest feature in Lily’s Garden, ever
After months of development and re-building, the team started producing more stable releases and new builds without severe crashes. “Perfection does not ship games fast,” laughs Mikkel, “but we also could not just keep producing code and creating technical debt along the way. The real value comes from our players experiencing what we have built so far.” Expeditions were finally ready for a technical launch which showed very promising results. After that, they released to a small group of players, which went well, and later on to a much bigger group.
“Data started rolling in and the numbers kept getting better,” smiles Jon. “We had an ARPDAU increase and players were leaving so many nice reviews about the feature. It was incredibly motivating to see positive results after many months of hard work.” And then finally, Expeditions feature Season 1 was released worldwide to all of our Lily’s Garden players.
It was the biggest feature we have released in Lily’s Garden, ever. After the success of Season 1, the team continued working on Seasons 2, 3 and 4.
For Jon and Mikkel, building this feature meant stepping well outside of their role responsibilities. Jon started as a Cinematic Artist and ended up doing game design and direction, whilst Mikkel started in area set-up and ended up working with the graph system, game designs and documentation. “It’s really fun working on new games,” says Mikkel, “People get to wear so many hats and you have to be very flexible with the kind of tasks you take on. It’s of course challenging, but so much more rewarding than being in a very set production pipeline. I’ve learned so much.”
For Roche, who loves to refactor things and really understand why something doesn’t work and how it could be done better, working on Expeditions gave her a lot of valuable knowledge which she can now apply to other projects. “We work a lot with shared modules and want to re-use as much as possible,” she explains.
Jon wraps things up: “I love the mindset we have here about constantly trying to make things better. Instead of spending money on R&D, we develop, innovate, optimize and produce, all at the same time. Of course this adds the extra challenge of knowing when to stop, so the project does not suffer from having to build too many new things, but it allows us to get better at doing what we do, all the time.”
Expeditions challenged us in many ways and looking back at the development process, there are a lot of things we could have done differently. What we don’t know, however, is whether other solutions would have been simpler, or just as difficult to do. All we can do now is to look back, learn and keep working on making things better. There is so much we can take away from this project and apply to new games that we’re making, which already gives us a big advantage. There is a lot to be proud of.
