If you’ve ever wondered how some of your favourite videogames are created, or even been involved yourself, it might not come as a surprise that award-winning game development is a complex art with many stages involved.
For PlayStation, the genius behind some of its most popular games is SN Systems – a Bristol-based company who create the development tools that enable game developers to make bigger and better games each time.
SN Systems has seen substantial growth in the decade since it landed in the city, including an ever-expanding team housing some of the most highly knowledgeable and experienced in the game development tool space.
With so many layers behind the creation of brilliant games and a team of specialists at hand to tell us more, we caught up with two of SN Systems’ PlayStation Development Tools Specialists, Edd Dawson and Sean Eveson, to find out what it’s like for them to be working on one of the more hidden but integral aspects of game development.
TechSPARK: So what’s your role at SN Systems and how did you end up there?
Edd Dawson (pictured left): Since I joined SN I’ve worked as an engineer on a number of teams and have made contributions to our debuggers, linkers, binary utilities and SN’s distributed build system, each of which we deliver to PlayStation developers.
At present I am the technical lead for the Linker and Binutils team. This involves all aspects of the software’s development, coordinating the technical direction of the products to suit the needs of our extremely exacting customers, and also being a line manager for the team.
“If [the linker] doesn’t work correctly PlayStation games can’t get made”
Most of the team’s time is spent on developing the linker. It’s a piece of technology that C++ developers rarely interface with directly, but it’s a necessary step in the typical game development process. It’s extremely important that the linker is both correct and fast as hell. If it doesn’t work correctly PlayStation games can’t get made. If it’s not fast, it will be a source of frustration for game developers as all the code for a game must pass through the linker each time a modification is made to a game’s source code.
Sean Eveson (pictured right): I’ve been working at SN since I graduated from university in 2015. Since joining I’ve worked in the toolchain team on a number of projects on or related to the compiler.
I’ve worked on the compiler itself, measuring runtime code coverage, doing compile-time static analysis, and ways to compare and test the debug information produced by the compiler. The more optimal the code produced by the compiler the smoother the games will run, and the easier it is to find bugs in the code the more time developers have to improve the game.
TechSPARK: What’s the first thing you do when you get into the office?
SE: As soon as I get in I filter through and read updates from the LLVM mailing lists, looking for changes or discussions that we should be aware of or involved in. After that I pick up whatever I’m currently trying to implement or fix in the codebase.
“We work closely with other groups in Sony Interactive Entertainment and members of the LLVM community”
ED: On the bus to work, I typically skim-read Hacker News for anything relevant to my team, or others in SN. Once in the office, I’ll also review what’s been happening on the LLVM mailing lists and our internal issue-tracking tools.
We work closely with other groups in Sony Interactive Entertainment (SIE) and members of the LLVM community. These people are often in different time-zones so catching up with activity regularly is pretty important. Once that’s done, I’ll typically resume work on the highest priority engineering item on my team’s backlog.
TechSPARK: And what else do you tend to do in a typical day?
SE: The team has a quick daily meeting to keep everyone in sync. Throughout the day we often chat details about what we’re currently working on, or what would be good to do in the future. I’ll also spend some time reviewing others code internally and upstream, and respond to any feedback on my own changes.
“A lot of code is produced in a collaborative fashion with other team members”
ED: I agree with Sean that development work performed within the team is rarely done in isolation. At a minimum, another member of the team reviews the code you’ve written, but a lot of code is also produced in a collaborative fashion with other team members.
The products that the team is responsible for also interact with other tools and software such as the compiler, the debugger and the kernel, and so communicating with other teams is also often a necessary part of the job.
TechSPARK: That sounds great, but do you ever have any technical challenges to overcome?
ED: Our team has recently switched to working with Open Source technology (OSS) from LLVM.org.
While OSS has many benefits, it also introduces challenges. We have to take care to introduce changes that either have a clear benefit to upstream LLVM users, or are integrated locally in a manner that can be maintained indefinitely.
I would say that even an average-sized PlayStation4 (PS4) game is significantly larger and more complicated than the majority of other software applications. This means our customers are somewhat atypical LLVM users and their needs are not necessarily the same as the other LLVM contributors. We have to cater to these needs while maintaining harmony with the direction that LLVM source code is moving.
SE: For me, it’s that the compiler and everything that comes with it is a huge codebase that changes extremely rapidly. Everywhere you look there are pieces of code you don’t understand yet, solving problems you didn’t know existed, written by experts with years of experience. It can be pretty daunting, but whenever you do anything you end up learning all sorts along the way.
TechSPARK: Are there any daily practices you or your team take part in to keep things ticking over each day?
SE: We use a Kanban board to keep track of what we’re working on and what is coming up in the future. It’s very dynamic and it gives us some structure and an idea of where we are, while still allowing us to react to sudden changes, like high priority bugs cropping up.
ED: Yes, and we follow a Scrum development process with some adaptations to our particular situation. It’s relatively lightweight and allows each member of the team to contribute to our planning and identify areas where our workflow can be improved.
I think one of the most important practices associated with this methodology is the daily stand-up meeting. This lasts no more than 15 minutes (standing-up goes some way to ensuring that!) and helps everyone in the team to understand what everyone else is working on and raise any problems they’ve encountered that day.
Another important aspect of our workflow is ensuring our products are tested thoroughly. Every change that’s submitted to the source control has to include test cases demonstrating that the desired behaviour is now exhibited (and undesired behaviour is absent!). If a broken product gets into the hands of a customer it can be very expensive to fix, for us and more importantly, for game developers.
TechSPARK: But what about lunchtimes? What do you get up to then?
ED: At lunchtime, I often get some ridiculously hot noodles from Chilli Daddy. I think I might be addicted. There are multiple markets and food outlets within 5 minutes’ walk from the office so if I do feel like something else I can always find it.
Once the noodles have been dispatched, I’ll sometimes see if one of the PS4s in the games room is available and play Bloodborne. I think I might be addicted to that too.
There are also squash courts close by, so if I can find a willing partner I’ll sometimes head there for 40 minutes before getting something to eat.
SE: Most days I grab a sandwich from the nearby market and get back to the kitchen to chat games, films or anything else with whoever’s around. On Fridays a bunch of us usually head out to get a pub lunch.
TechSPARK: We like the sound of a pub lunch, but what’s the best thing about working at SN Systems?
SE: I think the best thing is how much everyone cares about the quality of what they do. There’s a huge difference between making something that just does the job, and making something really well that you can be proud of.
“There was a great moment when something I’d been working on found a really well-hidden bug causing crashes in some game code which they had to fix before shipping”
ED: If I had to pick one thing I like about working at SN, I would have to say that there’s always loads more new stuff to learn. There are people that have been at the company 10 years longer than me that will say that too, which I find both humbling and encouraging. Having super-demanding customers and working with a wide variety of interoperating technologies means everyone’s always looking for new avenues to explore and untapped research to exploit.
TechSPARK: Great, so what’s been the highlight of your career at SN Systems so far?
ED: Every so often you get to interact with the game developers that are using the tools you produce. That’s always really valuable as you can better gauge what they really think about them. That’s helped us improve what we ship a great deal over the years. It’s especially satisfying when that’s acknowledged and you’re told in person that you’re team’s efforts are appreciated.
SE: Yes, it’s always great getting feedback from co-workers and customers who like what you’ve been working on. There was a great moment when something I’d been working on found a really well-hidden bug causing crashes in some game code which they had to fix before shipping.
I also got to go to LLVM conferences in the U.S. and Europe. In both cases the talks were really interesting, I got to meet loads of people from the community all over the world, and as well as being very helpful for all my work it was great fun.
SN Systems are now recruiting for new developers to join the team in its Bristol office. To find out more, check out the SN Systems website or follow them on Twitter here: @SNSystemsEU.
- You may like: How do I become a games designer?
