Building Big Impact, One Brick at a Time: Marginal Gains in 'LEGO Horizon Adventures'

[Music] So, welcome to my talk, Building Big Impact, One Brick at a Time, Marginal Gains in Lego Horizon Adventures. So, let me start by introducing myself. My name is Adam and I've done a whole bunch of stuff in the games industry starting in QA and then I ran my own studio for a while but most of my time has been spent in co-development as a game designer at Splash Damage and Studio Gobo. Most recently at Studio Gobo, I had the privilege to be lead designer on Lego Horizon Adventures which released in November 2024. I also love cycling, which you may not think is relevant, but bear with me and we'll see. So, what we'll learn today at the end of this presentation, you will learn that

while marginal gains may seem small, their impact is massive. I'm sure you've experienced when something isn't quite right when making a game. Maybe it's a clunky workflow, a tiny friction point, or a small inefficiency that slows you down. It's nothing big enough to derail development, but it's there nagging at you. But what if I told you that fixing those tiny toe stubbers one by one could be the key to building something exceptional? Marginal gains are not just about polish. They're about unlocking massive impact over time. So within this presentation, I will provide a bit of context and background. We'll look at what marginal gains actually are with some examples. We'll see the results of applying those marginal gains. And we'll take a closer look at some examples from the development of LEGO Horizon Adventures.

Finally, we'll look at how the learnings from Marginal Gains can impact your work going forward and ultimately make your next game even better. But let's start with a bit of background. A brief history of British cycling 1903, no sorry, 1908 to 2003. Now, you may be thinking that I've got you all here to bang on about cycling. That is only the halftruth. Uh, bear with me because this is all relevant and it's how I came to learn about marginal gains. So, if you know anything about British sport and cycling, uh, sorry, and the Olympics in particular, you'll know that Great Britain is really good at pedaling. But it didn't always used to be this way. In nearly 100 years, Britain won only two gold medals at the Olympic Games. The team pursuit in 1908 and the individual pursuit in 1992. A British team or rider had never won the world's biggest cycling event, the

Tour to France. And during this time, bike manufacturers actually refused to supply British teams because they didn't want their brand associated with such abject failure. But now let's look at British cycling between 2003 and 2018. In 2003, British Cycling hired a chap called Dave Bellford as performance director. He's Sir Dave now. In 2008 at the Beijing Olympics, Team GB won 60% of the available gold medals in cycling. In 2012 in London, we won 70% of those golds, breaking nine Olympic records and seven world records along the way. And as well as winning gold in the Olympic time trial, Bradley Wiggins became the first British rider to win the tour to France in 2012. Another British rider, Chris Froom, won the tour to France again in 2013, 2015, 2016, and 2017. and Garrett Thomas

became the first Welsh winner in 2018. But how did they have such an incredible turnaround in a relatively short period of time? No, not drugs, marginal gains. Marginal gains is more of a philosophy than something tangible that you can point to and see obvious results. The concept is simply that hundreds of small improvements compound to create massive gain. So, here's a quote from Dave. If you broke down everything you could think of that goes into riding a bike and then improve it by 1%, you'll get a significant increase when you put them all together. Let's look at some examples of marginal gains as used by British cycling during this time. So, when looking at where improvements could be made, there were obvious examples such as using lighter tires and conducting wind tunnel tests on clothing materials. Incidentally, Brit British

cycling team Sky were the first team to wear indoor speed suits outside during the tour to France. But there were also less obvious changes. They identified that while on the that while on the tour, they would sleep in 21 different hotels as they traveled across France. That's 21 different beds, 21 different mattresses, 21 different different pillows. That's 21 different sleeping postures. So, they brought their own mattresses and pillows with them on the tour. They also hired a surgeon to teach the team how to properly wash their hands to reduce the chance of infection because obviously you don't perform as well if you've got a bit of a cold. And this image shows how they painted the inside of their team trucks white, which was not just an aesthetic choice. They did it so that it would show up dirt more clearly to help keep components free from contamination. Now, eagle-eyed viewers will notice that this is a rival team's garage, but Team Sky

did do this first, and everyone has since copied the practice, as is the case with a lot of the games that that British Cycling and Team Sky did. So, the thing with marginal gains is that they are often not noteworthy on their own and can be barely perceived as changing anything at all. But if you got 1% better every day, you'd be 37 times better after one year. Incremental improvements are easier to achieve than large goals. It's why most New Year's resolutions fail. Ideally, you would have an end goal that you can break down into smaller chunks. For example, don't say that you're going to go to the gym every day for one year. Just say that you're going to go to the gym tomorrow. And if you do, say that again the next day and so on. So let's look at this on a graph. If you improve every day and regularly improve your baseline, improvements compound and

the outcome is more than the sum of the input. But equally, if you get 1% worse, you'll quickly deteriorate. So remember how I said that if you became 1% better every day, you'd be 37 times better after one year? Well, to put that another way, if you invested $100 and you earned 1% interest on that every day for one year and did nothing else with it, at the end of the year, you would have $3,778.34. So, that's all great, but this is GDC, and I don't think anyone in this room is planning on running a professional cycling team anytime soon. What can we do in gamedev? So, as a quick disclaimer, this is a supporting mindset and does not replace your normal tasks, sprints, goals, etc. Instead, marginal gains will operate in

the background. It is not intended for you to block out time in the week to think of marginal gains. Rather, you will encounter areas or identify areas as you work. You can, of course, block out your own time if you wish and you find that useful, but it's not a requirement. So identifying marginal gains firstly we you need to identify where improvements can be made. You are the person closest to your features. So you are the person that is best placed to find improvements especially on a process level. What are some of the less obvious areas that can be marginally improved? So it may not be as big as a bug, but even something that adds a little bit of friction could be a good candidate for marginal improvement. Think about what small change could be made to mitigate this discomfort. You have the power to make these small

changes. At the very least, you can and should make sure that the relevant people hear your concern. Be proactive. Don't wait on assuming that someone else will highlight this friction point. And even if it's been improved once, ask yourself, can it be improved again? The answer is probably yes. So now let's take a closer look at some of the things that we did on Lego Horizon Adventures. We'll start by looking at process improvements. So, we had Switch consoles placed to where people were actually working so that it was really easy for them to pick up a console and test their changes on device without needing to go to a designated play test area. This also meant that anyone was free to jump in and play the game on the target platform. Leads play tests. So, often feedback was siloed to each individual department.

For example, audio would give audio feedback. Level design would give level design feedback, but our leads play tests became a forum for raising opportunities for marginal gains. By having every department represented in these, collaborative improvements were regularly raised. Feedback trackers. So minor feedback was easily forgotten if it wasn't added as a bug. But so many of these things just didn't feel bug worthy. So we created pages on confluence for each biome where people could submit suggestions for minor improvements and toast stubbers. We triaged these weekly and it became another forum to find and identify these marginal gains. Boss pods. So small teams are nothing new, but our boss team benefited from only being three people and having quick and regular catch-up meetings. In contrast with our other machines which had bigger teams, the iteration speed on bosses was noticeably faster.

So let's now look at some examples from the development side. So our challenge system used to have the rewards on individual data assets. So we moved the this into one single data table. This reduced the margin of error considerably and made rebalancing data 100 times easier. Enemy spawn icon. So we used to have a a tiny generic icon that just got lost beneath meshes. So it was very time consuming trying to find and iterate on enemy spawns. So we added our own custom icon, this beautiful little watcher, which made identifying the spawn locations much easier and easier to iterate on. chest arrow. Uh, so for too long we didn't really know which was the front of a loop chest because they were very symmetrical in their design. I still

kind of think that those clasps looked like hinges. Um, so we added an an arrow to show which side was the front. This meant that they could be placed in confidence and we stopped getting bug reports saying that chests were facing the wrong way. Ingredient summaries. So ingredients are the different items that add variety to our combat spaces. Things like stealth grass that allows players to hide, hazards that can harm players, or items that can be used against baddies. We created recipes from these ingredients to create fun interactions for players. But it wasn't always obvious what these recipes were asking for when looking in the editor. So we set up summaries for our ingredient recipes. So instead of just an index number, we could see at a glance what each recipe was asking for. Here we can see that we prefer barrels to be close to falling pillars as this creates a more interesting interaction for players. Machine pivots. So changing every individual pivot on a machine was time

was timeconuming and prone to error. So our tech animation team added additional pivots to to machines which allowed our animators to move entire sections at once. This not only saved time and reduced uh the margin of error, but it massively helped achieving our toy- like movement that we were striving for. So, a lack of good debug tools will always add friction to any project. Fortunately, we had a really robust debug menu that let us jump to specific chapters, view certain cinematics, populate our inventory, and loads loads more. And we started to build this in our first prototype and just continued continued to iterate on it throughout development. This saved time for for developers from from all disciplines, but particularly QA validation checks. So encounters are made up of different combinations of enemy types and often mix and match between large, medium, and small

machines as well as human cultist enemies. But not every room in Lego Horizon Adventures supports every encounter type. And sometimes it was unclear why a setup wasn't actually valid. We created these validation checks that told you in plain English why an encounter was invalid, which massively reduced investigation time. Ledge grab visualization. So we used to have to load rooms after making ledge traversal sections to check that distances were valid. So, we made a visualization that shows the viable jump distances for ledge grabs in editor without needing to load the room to play test it. This also allowed us to create more organic setups that showcase the full range of traversal animations. And finally, we have some examples of product improvements. Now, you could fairly argue that these are just polish features, but they can and should also be considered as

marginal gains for our players. We allow players to skip cinematics and conversations if they're not interested in this content. This adds value for players who are replaying the game, speedrunners, or simply players who aren't interested in story. This was also a a development gain for for QA as it meant that we could get to certain content much more quickly to test specific elements. waypoint markers. So, there can be multiple different paths out of the same combat space depending on which version of a room is loaded. So, having a waypoint marker helped players orient themselves after combat and remove the frustrating feeling of being lost or stuck. We wanted players to explore off the main path to find secrets. So, we have these silver studs, but sometimes these were too well hidden. Silver studs are used to communicate to players that they were both veering off of the main path, but also guiding them towards hidden secrets and treasure.

This led to players looking out for silver studs and actually taking in more of their surroundings. Accessibility. So, I am personally very very proud of the range and quantity of accessibility features we were able to add to Lego Horizon Adventures. Providing a range of options means that more players can enjoy our game in a way that is comfortable for them. Accessibility is largely built on on on making marginal gains to existing features. So to give just one example, we offer players multiple aiming modes that would increase or decrease the radius in which attacks would snap to valid targets such as enemy weak points. And given the target demographic, we were conscious that this could easily be someone's first ever video game. So we really wanted to make sure that that experience was a positive one for them. representation. So, Lego Horizon Adventures has an extensive C customization system that allows players to customize not only

leg, body, head, and hair parts, but also skin and hair color. I think my favorite addition though was adding the sprinter and dog groomer minifigures as these feature prosthetic legs and a coclar hearing aid implant respectively which further increases our representation for our disabled players. Now another thing that is relevant to all of this is the circle of concern versus the circle of control which you may have heard mentioned elsewhere but basically everyone has concerns and everyone has things that they can control such as how you react to a certain certain situation. In order to reduce the amount of concern you have grow your circle of circle of control and in the context of marginal gains. If you see something that can be improved or that concerns you, find something that that you can do to increase your control and reduce that concern. That might be making a fix yourself, raising it in sprint planning, or

entering a bug. At the very least, post about it in Teams or Slack and see if anyone can help. This is exactly what I did that led to us getting the sprinter and dog groomer minifigures in game. So, let's bust some myths. Realistically, there is a finite number of times that something can be improved. That's okay. Don't stress about trying to find marginal gains in everything all the time. As development continues and the game becomes more feature complete, perceived impact can decrease as features become more polished. Remember that any change, no matter how small, contributes to the overall quality of the game. Marginal gains are hard to measure. It can be difficult difficult to know if a change really has made any difference at all. But please trust the process.

Some ideas will be beyond the scope of what you have available to you. It's okay. It's still worth communicating this as it may benefit f future projects or in the previous case I might have just overestimated how long something could take. So be aware of any potential impact your change may have to another person or discipline. If your change isn't isolated to your area, make sure that you communicate with anyone else that may be affected before making that change. Some days you won't make improvements. It's fine. Remember, this is a supporting principle. So, it isn't the be all and end all if some days are missed. So, how did we manage to build marginal gains into a development mantra at Studio Gobo? Well, the first thing I did was to introduce the topic, which I did by

presenting a very early version of this talk to my team on a previous project. I then shared that recording of the presentation to the full studio for anyone else who is interested in watching. It is really important that your team knows that you trust them and will empower them to make these improvements themselves. One way we do this is to call out and celebrate when we see a marginal gain in action so that the team sees that we are excited to see those changes. This isn't a oneanddone approach. you will need to continue to repeat the message and continue and I I continue to iterate and update this this presentation for the benefit of new staff and partners. And over time, more people will champion these marginal gains, and you'll naturally build a group of evangelists and cheerleaders to the point that it becomes an almost everyday occurrence to see your team discussing and celebrating the minor improvements they're making.

But ultimately there can be no single source that finds all the marginal gains in a project. And this can only reach its full potential if gains are being found and actioned by a broad range of people across all disciplines and levels. So let's wrap up and take a look at some key takeaways. You are the person that is best f best placed to find these improvements. Think inside and outside of the box. While often not being notable or noticeable, small improvements increase our baseline and compound over time to create massive gain. This approach really benefits from having commitment from everyone or at least as many people as possible. Now the nature of marginal gains is that they are small and hard to quantify. But we can already see examples from other

walks of life that this approach works. If British cycling can go from being a laughingstock for 100 years to being the dominant force in Olympic cycling within five, think what you can achieve on your next game. So, if you enjoyed this talk, we have much more LEGO Horizon Adventures con content at GDC this year. Most of these have already happened. Um, but for those of you in the room with me now, uh, we've got Stick to It: Creating a UI identity for Lego Horizon Adventures with Chris tomorrow at 11:30. So, check that out. And if you're watching this online, hello. Uh, all of our talks can be found on the vault. So, check those out, too. Believe we have some time for questions. Um, so head to the mics and uh I'll answer them. You can also reach out and grab me on LinkedIn as well if time runs out. Thank you.

Hello. Hi. Um, you mentioned that these are really hard to track, but I was wondering if you have any examples of how you did track any of the gains just so you had something to show your team. Yeah. So, I guess the the best example of that is the feedback trackers we used um for each individual biome. And while these margin gains kind of they they work on a kind of case by case basis, right? So, if you're improving um like something on a process level, some of them are really easy to see. It's like, oh, like um cook times went from 20 minutes to 18 minutes because we made this little change. Like that's saving time. The feedback trackers for the for the rooms um when we triaged them, um we just kind of like crossed them out and archived them. So, if you really wanted to, you could go back and see, oh, like we made these changes and fixed these

seven towers on these rooms. um on their own they're they're not they don't have any perceived impact at all but like the whole point is that all these little things do compound and then you get a great benefit at the end. Thank you. Thank you. Uh hey I think on one of your last slides you had champion gains as one of the bullet points. uh was that about celebrating the small gains and how did uh do you have examples of kind of celebrating this? Was it in team meetings or was it emails or Yeah. Um yes. So the question is how did we champion games? Right. Um so one example is um when I had the slide of the enemy spawn icons that wasn't submitted as a marginal gain. That was just something that our lead level designer did because he was getting fed up of trying to search through and find these icons. Um, so when he posted that into our level design chat, first thing

I did was like, that's a marginal gain. Like, love it. Like that's going to save us like a little bit of time. So, primarily it was through kind of teams messages. Um, it has kind of become a bit of a running joke at gobo that every little thing we're like, "Oh, marginal gain. Hey, Adam, a marginal gain." Um, even at breakfast yesterday there was a typo um that said range juice instead of orange juice. They're like, "Well, it's a marginal gain. They've not pressed a letter." Um, so yeah, like as I say, like over time, you just build that that kind of group of evangelists and you keep on banging on about it enough, people do listen to it eventually. Hi. Um, so clearly you're quite successful in getting people on board with the the the whole concept and and the practice. Did you have any particular push back or kind of difficulties in actually getting people to buy into it at, you know, either the studio or individual level? Um, so did we have any push back? I think not so much push back. It was more kind

of a question over does this work? And it's it's a very hard thing to point to and say, "Oh yeah, because we've made these like 200 little changes, our game is now like an extra like two Metacritic or or something." So this is why I talk about cycling is because that's a very clear like quantitative way to see like British cycling were rubbish. They started doing these marginal gains. Suddenly they were winning Olympic golds like every every four years and like tour to France and things. So, um, when I say trust the process, it's a bit of a cringy term, but you kind of do just have to trust it. Um, and yeah, I think when when when there's a marginal gain that positively affects an individual, so this is mainly on kind of process levels. If someone's suddenly doesn't have to load up the editor to check the chest is facing the correct way or they stop getting bug reports saying like this chest opens backwards um they then

see the benefit of it as like okay so if this is helping me something else could be helping someone else. Thank you. Thank you. Amen. Up the tune. Um first maybe. Um so how do you ensure that the marginal stays marginal? Ergo there's the fallacy of engineers overengineering etc. And also maybe second um how do you also make sure it's relevant so to say. So so how do you keep it small and relevant? Yeah. So how we keep it small is like we have fantastic production team at gobo. So if there's ever any question of like this is going to impact things and a lot of it is if it if it's not something that that you know that you can do yourself immediately that's when it goes into the the kind of think of posting on teams or just um raising it in sprint planning

because if it is a bigger job than you think it is you've at least started that conversation and then if it is a larger thing you can then task it in properly like what we don't want to happen is when these these little changes end up being big like big features to work on. Um and then in terms of like keeping it from from kind of kind of bloating and overengineered um as I said before you just have to trust individual developers and as long as they understand that if they're if they're working on something that's not a task, they're not working on that task. like if you're saying yes to this, what are you saying no to? And then just allowing them to kind of make that judgment call. Um and we will always just empower them to do that. Thank you. Thank you. Cool. If there's no more questions, um we'll wrap up. As I said, you can reach out to me on LinkedIn um or grab me

afterwards. Thank you. [Music]