What does an engineer do with that information?

I think the first step is always complain and say, why did you do this to us? But it usually starts with getting a feature request from design, where they will do their best to outline, not exactly how these different designs need to be implemented, because that's our job, but what exactly they expect to see. So there's things we talk about, like user stories, where, oh, we've got Jenny here who's going to go buy 10 SCU of astatine, and it's going to go into her Cutlass Black or whatever, and we expect her to go to the commodity kiosk, and they'll outline images like, here's step one, two, three, four, and then she clicks purchase. So they need to do their best to outline exactly what it'll look like in the game, so we can interpret: oh, all right, if they need it to look like this, here are the underlying systems we'll need that can achieve that end user story.

When we look at a design like that from a technical perspective, you're looking at what it's going to take, the resources that are involved, kind of the timeline. You want to tear it out. You want to immediately raise any concerns, potentially, that may seem like they're not very difficult, but if you understand how the engine works and what tech we have right now, could actually make it take a lot longer. And you come up with a plan. You have a kickoff meeting to kind of hash all that out. You kind of establish a baseline of where you want to start from with the design and kind of where you plan on ending up, especially if you have an upcoming release. And so, yeah, I like gameplay programming. And the reason why I got into it, I imagine Spencer as well, is because of the very reason that it's so closely knit with design that you get to work in that more creative aspect. You're doing something very technical, but at the same time, you're doing it in collaboration to make something that's creative and fun and tangible.