Welcome everybody. I'm so sorry. We're running into late. My name is Nicky Armstrong. I'm the lead programmer at Silver and Games. You can also hear my dog. We're having a little little moment.Um uh Yeah, so I'm the lead program at Silver and Games uh which is an indie studio based in the UK. Um We're all fully remote, so I'm in Newcastle in the UK. Um But I'm quite obviously Australian, so I'm ex tech and ex mining software. And so this talk is about um the differences that I have found between operating as a programmer in a fully tech studio, um a studio full of programmers and being a programmer in a game studio where you also have so many other disciplines. You've got animators, artists, everybody flying around. Um So that is, that is what we're gonna be looking at today. So I'm gonna just switch to my slides and we'll keep on going. So, software is a service. I'm sorry for the Clickbait title there. Um It very much uh was to draw you all and it is about how the code team is operating in service of the other disciplines uh in in the studio. Um, so what I'm gonna be going through today is, um, what does a code team in a game studio do? Um, oh, the screen is black. I'm so sorry. It says that it's sharing at my end at this point we're running quite late.

Um, it works for somebody else. All right. So it's working for other people. Fabulous. Um, that's good. Brilliant. All right. So, outline of the talk. What does the code team in a game studio do for a start? Um Some of you might not know then where does the conflict come from? So what is the problem that we need to solve? Uh as the code team? Um And what solutions can we employ uh to manage these relationships? Um And make sure that the goals of your team, your code team and the goals of the other studio or the other disciplines in the studio are all met. Um So what does a code team do? Um We do so many things and depending on the kind of studio that you are in, uh will depend on the kinds of things that you're asked to do. So, bigger studios will have different code teams for each of these points. My studio, my team does all of these things and there are only four of us. So this is what we do. We make the game, all of the controls, the abilities, the A I, all of that stuff. Um The lower level systems, uh building the engine uh doing optimizations, making sure we've got good frameworks, good architecture to start from. Um We support the other disciplines.

So that might be through tools, programming um to building internal tools, supporting workflows um supporting the tech requirements of the other teams. So a lot of the time you'll be working in a low, a lower level language you'll be building in C++ or something like that. Um Other teams might have access to uh a design language, a scripting language, maybe a node based language or a drag and drop language. And so your job is to build the tools for them to be able to write in that language or you might be hooking up the code side. So you might be given the animations um and you might be hooking them up to the characters, do the right animation at the right time, things like that. So where is the conflict in a studio made up of so many people? Um If you're a tech only studio, at least this has been the case for me uh in a tech only studio of 40 people that was made up of 40 programmers. And so 40 programmers, maybe in little agile teams each working on our own bit of the software and then coming together uh for the delivery. So that easy to, easy to handle in a game studio, it might be 40 people, but this is across lots of disciplines.

So it might be that you've got a code team of four people and then you've got an art team of four people, an animation team of four people, tech artists, designers, uh Q A production, audio loads of different disciplines that all need to be working together. So the code team, we have a schedule that we need to keep to. We've got dreams and goals and ideas for the game and we've been given things that we need to do. So we need to do console support. We might need to shift on different uh levels of hardware. So we might need to support different levels of PC MAC, the switch PS five things like that. We might want to build test architecture. Uh We need to support build systems. So we need to have continuous integration. Uh We need to have source control somehow. Um But we also need to build the player facing parts of the game. So the designers, the creative director, they have a schedule of priorities for us that they've given us. They uh tell us what they want us to build so that we have a game at the end of it. Um And some of those things directly are our priority. So directly, they're telling us you need to build the player, you need to build the enemies, you need to do these things. Some of those things are incidentally our priority. So the narrative team might come to us and say, hey, we need to build a dialogue system.

So we need you to make us tools to do this and we need you to talk to the UI programmers and interface there. Um And we need to make that whole pipeline work. We need to get audio involved so that we have maybe voiceover. Uh So we have lots of different things that we need to take care of. Um the team might have a need for tools. So in order for them to do their job, we might need to integrate Jira with different front ends. We've got maybe dialogue, writing tools. Uh We might need to do source control. Uh front ends maybe or the build system, front end. A lot of the conflict is gonna come from uh in a team where you're all programmers, everyone has a pretty good handle on Git, right? Everyone has a pretty good handle on. Um What do you need to uh how do you, how do you use the command line? Right. We might all be quite familiar with command line. We might all be quite familiar with the different types of front ends, familiar with GIT lab or github with GRN with uh source tree, things like that. Um They're things we've been using for many years, maybe in a game studio, you have non technical teams or less technical teams that have never used these tools before. So you might want to or you might be asked to build them um easier front ends to use.

Um And we might be needed for advice. So to get different uh or better performance on different hardware, you might have the art team coming in asking you how many lights can we have or um how do we optimize having all of this grass in the scene or things like that? So there's just so many different areas that you need to be aware of and you need to be juggling. Uh We talk about keeping all of the plates spinning. Uh So you need to be aware of all of those things and keep them all um all on the go uh while you're working with all these different disciplines. So what is the solution when I came to Super R Games? Uh I was made the lead of the team. Um And I'd come from a tech background primarily. Um And one of my biggest problems was focusing only on my team and only on what the code team was doing and thinking that if I just kept the code team spinning, um then everything would be OK.

The biggest thing that, that I learned was that you really need to be thinking about communicating with all of the other teams and that's not just inwardly. So it's not just so you understand what all of the other teams need from you, but also so that they understand what you need from them. And so that they understand what your priorities are as a group team, when you're working with non technical teams or a non technical disciplines, the biggest thing that you need to learn how to do is communicate your tech requirements in a way that they can understand and they can understand why it's important to you um that you have a test framework and why it's important to you or why it's difficult to make the game work on lower end hardware.

Um So the biggest skill that you can have is communicating technical ideas in a to less technical disciplines, it's important to recognize your priorities. So you absolutely cannot have everything as a P one because if everything is a P one, then nothing is a P one. So for each delivery that might be a sprint, a milestone, a release, you need to know what you are focusing on and you need to be OK with nothing else getting done. So is your priority tools building for the teams? Is it performance? Is it game mechanics? Is it a I what are you doing? Forget everything else. Um It's also very important to recognize your strengths and your limitations. Um For example, if you are going to build tools for the team, you need to make sure that you have the time to do that properly, the time to do that well, um and the knowledge to build them. Well, it's very easy for you to think. Oh, Yeah, code is just code. I'm a gameplay programmer, so I should be able to build a tool. Um But there's a reason that in bigger studios, tools programmers exist, it's a whole discipline, it's a whole career. Um Being a tools programmer. So if you in a smaller studio as a gameplay programmer are gonna commit to building tools, you need to be sure that you can do that well. Um because if you, if you don't, you're gonna be creating yourself a maintenance headache.

So you've made a tool for the team, they're gonna find bugs in it. They're gonna find that it doesn't quite do what they want it to do and they're gonna find, uh, that they are gonna request different features for it. So you're committing yourself to maintaining this tool for the life of the project, for the life of the studio, potentially. So you, if you're gonna commit the time to do it, it's not just the two days to hack together a little, get front end, it is the time to commit to maintaining that tool. Um, for the life of the project, you need to make a schedule. This might seem very, uh obvious, but you need to have a schedule and you need to have it written down and then you need to stick to that schedule and then the two points under this, you need to be flexible and you need to be firm and it de depending on context. So normally we think, you know, once you plan sprints the sprint, you've got it signed off. You've got all your acceptance criteria approved. That is immutable. We're not gonna change that, but it is ok to buffer in time for support tasks. So it might be that the design team have said to you, we think we're gonna need some time for support, but we don't know what that looks like yet. We're not really sure exactly what we're gonna need from you.

Um It's ok to say, ok, well, I will leave a day in the sprint that is unassigned. No task on that day. We, we've got a whole day of time um for you to spend on what you need and you can tell us what that is when you know what you need. If you don't need it, we've got backup tasks uh that we might use. Um But the flip side of that is being firm. If you design a day and the design team have a date, then do not let them have a day and a half. Do not let them have two days, tell them you have a day and once you've used that day, that's it gone. We have other priorities and explain to them clearly what those are. Um So it's ok to also be firm. Um Everybody in the studio is relying on you for the things you've promised. Um So mid Sprint Scope Pro that should be pushed back on. Um Unless you have that over time um operate on a one in one out system. If somebody requests something, if the design team says, hey, actually, this is the highest priority for us right now.

And you say, well, the highest priority until you told us that was this thing for the narrative team, then take the design team with, you, talk to the narrative team and suss out what you should be working on and it may be that they agree the design team's request is more important and you can swap that out and then you don't do the other work but do not try and be all things to all.

People do not shove everything in the front, make your team work over time. Communication is important. And then the last point is to let go, that's my biggest point. Let go of your ideals as a code team to be in control of what you're working on. Um Because game development isn't like that game development changes all the time. Um People are not gonna necessarily understand what you're working on. Um Let go of your need to code sometimes because I, I've spent a lot of my time writing code, but I've also spent a lot of my time in Excel, making these schedules and in meetings, communicating with other teams. Um So the most important takeaway I think is just to let go of your idea of what a code team should look like and let that be dictated by the needs of the studio, the needs of the game, um and the needs of the other disciplines. Um and that is all. I'm happy to take questions if we have time. I've raced through this because I was a little bit late and it is now 10 past 11, which I think is the end of my session. Um but if there are any questions then that is ok. Alright. Well I don't see any so thank you very much for coming.

I'm sorry it was a little bit hectic um but I hope it was interesting um and I will see you all in some other events maybe. Bye.