James Tyler

Well, for me, I think principals are people who specialize in the subject matters that they focus on. And they really know that; they're also very dependable. Hear that, Luke? No, but they can also see complex features through and also guide more junior designers and even senior designers, and show the juniors the ropes and show them the systems and talk them through the whole process of developing Star Citizen and stuff like that. Maybe Elliot has something he'd like to add.

Yeah, we're kind of like an information well. We need to know a lot about all of the systems we own in case anyone needs to know something about, say, "Oh, how do I set up jurisdictions?" And then they know to come to MFT and they can talk to the principals, even though we might not work every day with them. We're like a sponge. We have to remember that information and not let any of it go, so we can go, "Oh, right, okay, this is how that worked." But for a lot of the time, we've been writing a lot of documentation, so we don't have to answer.

Documentation, it's like you have so many designers and they come to you asking questions, and at some point it's like, I can't answer the same question 20 times. I need to start writing this down. And then a lot of it's just pouring all of that information onto pages so that more and more people can just digest it in their own time.

But the worst thing that comes from that is that obviously we're still building the game. It takes you a full day to write this huge system up and you're like, "I've done it." And then the next day, one of the engineers will go, "I changed how this works." And you're like, "Oh."

About three years ago, I remember trying to write a document about how to put multiplayer logic into missions. And I started writing it, and then I was like, this is going to take ages. And I just knew on the horizon it was all going to change. So I just went, "Luke, I'm not going to write that now. I'm just not going to bother. It'll be out of date by next week." But we've written them now, because things have solidified a lot more, but at the time they were not super solidified.

I've seen both sides of the coin as well. When I first joined, I found a couple of little systems where I'd go to Elliot and be like, "Please help me with this, I don't understand it," and then he'd be like, "Yeah, that part is tribal knowledge, and we're going to do better and we're going to write that documentation down." And then Ed and Elliot have gone away and spent, like Elliot said, a day writing this. And it saved us so much time further down the line when me and Lars or whoever's coming back to these things, we can just read it. There's GIFs, there's all sorts to help us out.

Modules. Verbs and modules. Verbs are the gameplay type, and then the module is what they plug in to achieve that verb. It could be multiple, could be one.

Gotcha, so the idea would then be that with all these features, all the modules and everything, they can now go into Pyro and just start adding missions all over the place.

It's just like Lego, they're just putting the bricks on top of each other and figuring out what they want to build. I have made some hideous Lego, though.

I think one of the things that stands out as well from MFT is the fact that we do make those modules for everyone else to use, but we also think of the developer experience as well: how do they want to use this? How can we speed up the mechanic for them to even just place it in the game and whatnot?

Yeah, and modules aren't done once they're made. Elliot's probably adapted some of those modules, added new features as content teams want to express missions in ways that current modules just don't quite serve. And then he goes back in and adds those inputs and adds that functionality. Even more possibilities are possible.

And back to documentation for all those new additions.

Well, as you mentioned, unlocking those areas for those teams was one of the major goals there. And we thought, when it comes to racing, how can we make an implementation that can be used in so many different ways? Because obviously the PU is like a sandbox; you want to be able to just plunk this down wherever you want. You want to make interesting locations. So when it came to racing in general, we looked at what came before. We had scramble racing in the past and we wanted something new. And we looked at what people enjoy doing, and we looked at the community in general as well. There's so many amazing racing communities out there. And what they'd done is they had these leaderboards on a website that people raced around. Now, you had to trust the person had done it in that time, or there was no way of them actually having their times tracked officially. So we ended up coming together, me, Ed, Luke, working on this design together and thinking of the best ways of basically giving them those capabilities of being able to do that in the game. Time trials, akin to rallying, was kind of the first thing that came to my head. I'm a big fan of rallying, like Colin McRae and whatnot. And it also benefited in a way that you didn't need a million different people in that one location to do the race. If no one else came to that location, you could still have a fun time on your own. That led us to the current implementation, really. We do have some future goals, and I think Ed will speak more on that. But it was super fun to make.

I've been working on XenoThreat, trying to get that up to speed with 3.18. It's a lot in 3.18. Persistence is the big one, the big fundamental change. Making a dynamic event work in those situations, it's a lot to do.

I imagine just little things like, now it tracks mission progress. I've seen people on PTU say, "I did a mission a week ago and I came back and it was still listed there."

Well, mission persistence isn't something that we have properly in 3.18. It's more that so much has changed since XenoThreat last ran. It touches every system. Every system has persistence in it, or not in it, or whatever amounts of it.

Wasn't there a bug previously because of persistence, where if the Javelin was destroyed its records stayed there and then the other Javelin was trying to come in? We had that with the AI reinforcements that land: if you blow that ship up, the other one's just like, "Well, I'm still going to try to land there," even though you still exist. It's a fun thing to battle.

We will be seeing the changes mandated by persistence for the next two years. Everything up to this point was made for the game in a certain state. And now with persistence, there's changes to the AI, like, "Hey, if there's already a crashed ship there, maybe we don't land there."

It's also quite challenging to work on a game that has persistence turned on by default. Because what we do is we run servers locally and test our stuff. But if you shut that server down, it persists. So when you run your server again, it's still there, and all the stuff is exactly as you left it. Sometimes that's annoying because you're looking for a fresh state, but it isn't. That's persistence. And so you're like, this is like making games again. I've never made a game where I have to worry about persisting things from my previous run. You really do have to think in a new way to work in that situation. When you're fixing bugs, you have to be really mindful of that, because you're thinking, okay, is this bug still here because it's persisted? Because I had an issue with that. I was setting up some elevators, and the bug was there. I fixed it, and then I ran the server again, and the entity had changed. I fixed it, except it persisted in the broken state. So I was like, okay, fine, this is only a bug in this moment. So if I purge the lot and go again, it really is fixed. But it's challenging, but it's kind of fun.

It also messes with our debug tools. These are all good things, by the way; this is just the war stories. When we're playing, say I'm testing a UGF mission, or I'm waiting for the shuttle because I'm testing something, and then Liza's like, "Hey, you got a second?" or Jane's like, "You got a second?" and I go over to them. And then I come back and I haven't turned god mode on, which will stop me from dying. And all of a sudden, my food and my hydration levels have gone to zero. So my guy is having the worst time of his life. He can't see anything, I can't hear anything. And then I'm like, ah, I put on god mode and then I do my bug. But then every time afterwards when I log in, my guy is still dying of hydration permanently until I actually purge the server and restart.

I think the funniest thing that happened to me was during time trials prototyping. Because persistence was coming in and I didn't realize what it was going to do, I'd logged out mid-race, went away for my lunch, and came back to record a video for an internal review. I thought I was doing really well in this race; I was on time for the Platinum. And then all of a sudden, my wreckage was just at the end of the race, and I just smashed right into myself, which ended my race prematurely.

On Kareah, we were actually debugging it and all of a sudden we fly in and there's three of the chief of security. They're super bosses, they're super tanky. So I come in there with a pistol just to test something, and there's three of them, like, "There he is." And I just got lit up instantly. That's a problem.