Back to Search
How do you go about designing a ship, say for data running, when that's yet to be implemented and there maybe isn't the best idea of how it's going to work yet, while avoiding a concept that leads to a lot of feature creep? How do you constrain that, and how do you end up with something that works?
Dan Trufin · Lead Systems Designer, Foundry 42 Frankfurt

Yeah, this is one of the things that's always between the ship pipeline and the system designers. Generally, they get to be a lot faster than we are, and that's when we get into situations like you mentioned. But we tend to, even if we're not ready with a full finished system, tested and fun to play, we still have a pretty rough idea of how we want the gameplay to be. So there are systems that we have not written parts of the code for yet. But we know, yeah, it's going to work like this, like this, like this. And everyone kind of agrees, yeah, that makes perfect sense, and it's a good idea that we will implement in the future. We know it's coming. So we can start establishing metrics for all these boxes, and we can start figuring out what distances we want certain types of gameplay to happen at, and then they can start: okay, we need these distances in the ship, we need that much space for certain cargo or data storage, and then they can start building accordingly. Yeah, it's a tough one, and I wish we had a bit more resources to start making the gameplay and testing it and it being fun and then doing this part, but since this is the resources we have, we go ahead and we try to make it as close as possible. There obviously are adjustments. It doesn't stay as we originally thought, but we're getting pretty good at making estimations and getting as close to final even before the systems get tested. A very good example of this was the mining ship, the Prospector. So the ship was pretty much completed way before we had even a line of code written for mining. We experimented with it, and there were a few adjustments that we had to do in how the mining arm functions and where you can point it and stuff like this. But eventually the ship pretty much stayed the same. We're talking a 1% change in the ship compared to rebuilding the entire ship from scratch, which is what we don't want to do, obviously.

John Crewe · Vehicle Pipeline Director, Foundry 42

When we're in that situation where the ship is quite far ahead of perhaps the full implementation of something, we spend a lot of time between Todd, Dan, Tony, Chris, hours and hours of meetings, to just flesh out that design in our heads and go, right, we could go this way with it, we could go that way with it, we could go this way with it. But they all have these common points in the design. So for the ship side, we'll build around those common points. And if it's something that is like, well, we'll go with that for now, but it might have to change from a machine that does this to a machine that functions like that, we'll make that room in the ship easily enough to be swapped out one for another, so we don't have to rebuild. We very rarely try and build a ship around a single feature that is so unknown that it could result in the entire ship being wasted. So we always try, and we do a lot of design prep work, and then we try and sort of bank areas where we can, just to future-proof it.

- asked by Ivan in
Open in pop-up
Open in new tab
Click to copy link to YouTube
|
Published on this date.2018-08-25
Save Card as Image
ID: GLUWkAMlspU_827 (Click to copy)
Perma link (Click to copy)
All Q&As from this episode