Molecule Profile: Amy Phillips

Amy Phillips goes by the title of High Priestess of Tools Code, which unsurprisingly looks pretty darn good on a business card. Her real title, Lead Tools Programmer - while not quite as grand - is just as important, as she and her team spin up whatever tools the various teams across the studio need. Here, we chat to her about her love of puzzles, solving people’s problems, and that classic Mm randomness.

Hi Amy! What do you do here at Media Molecule?

I'm Amy Phillips. I'm high priestess of tools code at Media Molecule. Obviously, and unfortunately, that’s not my real job title. That came from the time I went to GDC (Game Developers Conference) seven years ago. I had to get some business cards and they foolishly allowed me to choose my job title. So I went for high priestess of tools code. I'm actually lead tools programmer in the proper studio language, but I like being the high priestess. It sounds powerful and fancy.

So what does that actually entail on a daily basis? Are you working on improving the tools that you use in Dreams?

No - I can see why you might think that, but we don’t actually make the tools that players use in Dreams. Basically, there's a team of four of us on the tools team and instead of making the tools that players use, we make the tools that the Molecules use. This can include creating or sourcing solutions to fix anything that is getting in the way of Molecules doing their jobs. So there's a lot of talking to Molecules and figuring out what’s causing them issues, what's slowing them down in their work, and what's kicking them out of flow state when they're working - then trying to figure out if there's anything that we can do to help with that. So we work on making builds for continuous integration, so that whenever a programmer checks some new code in, we have systems that go and build that code and quickly alert the programmer if they broke anything, which is really handy as that’s quite easy to do! These systems are able to put a build together of the new code quickly and deliver that to QA or content creators, or whoever might want that build.

And we've created some automated testing as well, so that when code is checked in, we run a whole suite of tests on it to try and figure out if we've broken anything. We also help out with localisation, taking the game and translating the new text so you can play in French or in Spanish and ensure that everything is translated. And there’s a whole lot of shuffling data around from place to place due to wrangling with source control. That's the system which we use to keep track of the code and make sure that we know what has changed and why it's changed. It lets us go back to previous builds of a specific version so we can reproduce a version that we've previously shipped to players, for example. Anything that falls between the cracks is a tools thing, which is nice because you get a lot of variety and the chance to talk to lots of different people across the studio.

Do you get many common tool requests, or are they all quite different depending on the need?

They generally tend to be quite varied. Because we work with so many different departments across the studio, the requests we get can be wildly different. We've been trying to update our documentation of how to deal with the various requests that we get, because there are some repetitive ones. Things like, 'I've got an old crash and I want symbols for it because I'm trying to unpick what on earth has happened here'. And so that's quite a frequent one. But we get all sorts of random things.

So what kind of tools do you actually come up with when people send you requests?

Often, Molecules need to be able to get builds quickly. When we started working from home during 2020, we lost our really fast networking. In the office, you could just download a build super-fast. But we all went to work at home with varying levels of quality internet connections, and so we had to work on a bunch of improvements to our tool for distributing builds to try and make it use less bandwidth. So there was a bunch of code designed to try and make it use what you had already on your local hard drive, and only download the things that you really needed to over the network. There's lots of technical stuff, but I'm a programmer so I like all that technical gubbins. I used to be a network programmer, where I was working on all sorts of interesting and tricky problems. That was mostly back when I was working on Burnout racing games, and trying to get the racing cars across the network to look and behave in the same way.

How did you end up getting into this tools role from a network programming background?

Well, I started off as a sort of general coder at first, and then I was an AI coder for a while before moving properly onto network coding. That was when we [at Criterion Games] did Burnout 3 and brought that online. And then I moved to Media Molecule and was a network programmer on LittleBigPlanet in the early days. After a while, I went on maternity leave, and when I came back, I wanted to be part time working two days a week. Unfortunately the network code role didn't really fit into those two days a week, so I was looking around for other things to do - and I noticed that there were various issues that were just falling through the cracks across the studio. So I started picking up those tasks, and it became really helpful for people to have someone to go to when they needed something.

The role evolved from there, really. It's not about reinventing the wheel, it’s about finding things that are not working particularly well and tweaking them to make them work better. It's very rewarding because you get immediate feedback from people. For example, if you improve a build distribution so that the UI (user interface) is nicer, and you can choose your favourite builds to put them to the top of the list, people will immediately give you feedback; if someone gets something nice, then they always say thank you, which is lovely.

Did you study at university to learn coding or did you pick it up by yourself?

Funnily enough, I actually fell into it somewhat. Originally I went to university to do maths and I did maths for my first year, but that was really hard. So then I swapped to physics for my second and third year, which was a bit easier. But still, I don't know - it just wasn't that interesting to me. So then after third year physics I swapped again and I did computer science for a year. And I was just very lucky that my university was super flexible about what you did. So I did computer science and really enjoyed it, and it just somehow clicked.

I graduated with a computer science degree and then a friend of mine, who worked for Big Blue Box Studios on Fable at the time, wanted me to visit him in Guildford. So I went to visit him there for the weekend, and he got called into the office because they had a deadline, so I went into the office with him and met the nice, friendly people and saw that they had a scooter and snacks in their office and it was so cool. And I was like, 'Oh okay, video games, this could be for me'. So I sent my CV to all of the video games companies in Guildford, and got a reply from Criterion and ended up getting a job there. So yeah, I was sort of super lucky and almost fell into it.

What do you find most interesting about working at Mm?

Definitely the people. I love working with the people at Mm so much. They’re a bunch of very clever people, but also really kind and lovely and very creative. When you're talking to people at Mm, it's always talking to them as a person first and then your job role second, so you feel very equal. I really like the atmosphere of everyone being people first, then their job role, and where each of you can have a whole discussion about how things are going and what issues they are having and what's going on. And actually as a tools programmer that's really useful, because generally if someone comes to you and says 'I want this thing', chances are it’s not what they actually want. So you have to sort of track back and ask, 'Okay, so why do you want this? What are you trying to achieve? What's the overall context for the request?' Because then once you've got the overall context, you can figure out if other people also want the thing and how best to implement it and what they actually want to do, rather than what they've just asked you for.

So since you've been at Mm almost since the start, what's been your favourite thing to work on?

It’d have to be the first LittleBigPlanet because it was such a challenge. We sort of didn't quite know what we were making, so it was all forming as we went along. To be honest, I don't really understand how it converged into a single product, because there were just all of these interesting ideas going on and a bunch of experimentation. I was still a network coder at that point, but I just loved the random experimental nature - although I think the team has still got that randomness, to some degree.

So that would be another of my favourite things about Mm: that we just go off and do interesting creative things, and that it feels so collaborative as well. It never feels like just one person with this grand idea. There is a sort of a core of what we're trying to make, but then everyone gets to input into it and contribute stuff that fits within that core. I think that's quite rare for a game studio that everyone across the company gets the chance to be creative.

Do you have any tips or advice for anyone that might be looking to get into tools programming?

I mean, a degree is useful because a degree in something programming-related, like computer science, will teach you a bunch of the fundamental concepts that will help you when you're trying to understand why your code is behaving the way it is. If you can understand the algorithm that you've written or the data structure that you're using, and how that then uses the cache and why you're getting weird performance issues, it makes the process of figuring out the flaw in your code much more simple.

But I also think game jams are a great opportunity for meeting people and making connections, as well as just trying stuff out and flexing your creative skills. And if I’m honest, realising that it’s actually really hard to finish a game is a real eye-opener to whether you want to stay in this industry or not. It's very easy to start a game, but really hard to finish one. I guess it's a bit easier at university because someone has designed this course to teach you the things that you need to know, whereas if you're teaching yourself, you have to do the work yourself to figure out what things you need to know and then teach yourself on top of that.

Mm staff seem to have a lot of interesting items on their desks. What's on your desk at the moment?

Hmmm. I don't have anything very interesting on my desk. What do I have? Oh, I have a puzzle book - Journal 29: Oblivion. It's basically a book of puzzles and they're a bit complex because they’re essentially lateral thinking puzzles. First you have to figure out what the puzzle even is in order to be able to actually solve the puzzle. But they’re really good if you’re into puzzles. I've also got a postcard from a friend whose website I updated in exchange for a book with a postcard in it, and I've got my Kindle, and a random Mm pin. I’d probably say the most interesting thing on my desk is my lovely mug. My mug is very cool - it's called the Cup of Courage and it's got inspirational quotes like You Are Capable. Do Not Be Afraid. Be A Warrior, Not A Worrier. Go At Your Own Pace. You're Stronger Than You Think. And a unicorn saying, 'You are so magical and worthwhile'. Unicorns make everything better.