How much power does a designer's user story have over the coding team?
TL;DRA designer's user story is a starting idea whose granular details often change through iteration with the coders, as in the kiosk price example, where decimals are used only for display and stored money stays whole numbers.
It could vary a lot based on the feature. One thing that I was doing recently, which is relevant to this, is the prices of things at the kiosk, because the quantity in which you buy things can be small enough that it's pretty cheap per unit. Currently, the price that I last heard from Pete Mackay for hydrogen, one one-hundredth of an SCU was like one UEC. Obviously, you're talking about a very small quantity there, one one-hundredth of an SCU. But if they price it starting at a very small unit like that, something our viewers might not be thinking of immediately is you probably need to have decimal point numbers for variance, if the economy is like, oh, well, hydrogen price is up right now, so it's 1.1 UEC or 1.2. But currently, everywhere in the game, money is an integer. It's just whole numbers, like one, two, three, four. And it's a very deliberate design, because floating point numbers, if you know anything about computer science, can lead to some weirdness. But the simple answer is, when you're talking about storing important things, like banks do this, like your computer clock does this, you want to use whole numbers, but really small whole numbers, not these weird decimal pointy numbers. So we sort of went back to them and said, hey, we really don't want to change how we're storing the players' money to be these sort of fuzzy decimal point numbers. So what we're actually doing is these prices in the kiosk can be floating point numbers just for these prices, but then when we actually store it and sell it, we'll just round up. So if you bought at 1.1 per hydrogen, you bought like 1,000, it ended up being like 1,067.4 or whatever, we'll just say, okay, you're spending 1,068 here. So we're only using the decimal point numbers in part of this whole process. Then we'll round up. So that's maybe a little contrived example.
I guess what I would say is that for me, whenever I get some design and some user story like that, there's an idea here. There's kind of the overarching idea. The more granular in the detail you get, the more tactical it is. That also means the more granular details are often some of the things that are more likely to change, either because of technical limitations or iteration or whatever. It's an iteration both on design and technical implementation. So it's not like you get a user design story and if I ask a question, the designer is going to be totally offended or something like that. But at the same time, I understand that it's playing a role in our game, and it has a lot of thought put into it. So I'm not just going to point something out and just be like, no, we're not doing that, or that's stupid, or whatever.
It is absolutely an iterative process. I like to say this a lot: no game design survives first contact with a coder. You tell them how you want it to play, and then they will tell you, you can't do that, but you can do it this way if you just change... It's just one of those things where, this is the experience I want to achieve, how do we make this happen? I could tell you how I want it to happen, or you could tell me how it's going to happen. Sometimes you're like, it's so simple, it's just a grid. It's like, yes, but... And then, ah.
There's this system that's already in there, there's this system.
Yeah, it's kind of like, oh, I want to do this thing. And it's like, yes, but in world space, that's this thing. And it's like, oh, do we do it that way? It's like, we do it because of a completely unrelated system that you've never heard of, but because we want to stream that information in, it can't be stored in this place, so therefore this. And you're like, okay, well, what if we just change this? It's like, let me think about it. And so the smartest person in the room goes away, solves the problem, and then is like, does it fit?
And then the designer responds, no, go on.
And so then you come back and ask, does that fit the experience that we ultimately want? Okay. And so I think it's one of the reasons designers, when they get better, learn to listen more and stop telling.
I think honestly the same thing goes for programmers. And then, of course, you get it working. Not perfectly, but you get it working well in your own private little environment, and then you go to integrate it into the game, into the game code, with all these other game systems, some game systems that were developed a year ago, two years ago, that haven't been touched...
I'll give you a perfect example that just came up. So we got this cargo grid working. It's great. It's got all these features. You can do all these cool things with it. But there's one ship in the game that has the cargo grid on an elevator, which is the Constellation. You lower the elevator, you can walk through the cargo. You raise it, you can interact with it, you can't walk through it. It's one of these things where you don't think about it until you get into the game. You're like, oh, okay, yeah, that makes complete sense because of the way our zone system works. But it requires some iteration on the tech, because we didn't think that far ahead. It's only one ship in the game at present. There'll probably be more.