This post is a transcript of 10 for the Developers: Episode 07, material that is the intellectual property of Cloud Imperium Games (CIG) and it’s subsidiaries. INN is a Star Citizen fansite and is not officially affiliated with CIG, but we reprint their materials with permission as a service to the community. INN edits our transcripts for the purpose of making the various show participants easier to understand in writing. Enjoy!
10 for the Developers: Episode 07 – Full Transcript
Elwin Bachiller (EB): Greetings fellow citizens. Welcome to the next episode of 10 for the Developers, I’m Elwin Bachiller Junior, Lead Vehicle Artist in LA and I’m here with…
Patrick Salerno (PS): Associate Technical Artist Patrick Salerno.
EB: And we’d like to thank all of the subscribers for making this show happen. Without you guys we wouldn’t be able to put this operation together and you guys really help us develope the game.
So patrick, I have a question for you.
EB: It’s from EarthFyre.
[0:54] EarthFyre asks: What aspects of the development process do you enjoy, or perhaps find difficult but rewarding?
PS: What aspects in particular? Well, I like the challenge mainly. You come in everyday, and it’s a different type of puzzle to solve. You constantly learn new things, and there’s new tasks. I need to be specific. Lately I’ve been learning how to put ships together and then tear them apart again and that’s cool to me. You go in, you see the model, you see how it’s put together; you yank out the pieces, put them in the xml and then you go in the engine and you shoot it. Then it blows apart, and there’s explosions everywhere.EB: Yeah your favorite part is breaking all of the hard work that me and my team do.
PS: Yeah, basically.
EB: Yeah, that’s great. Well for me the most rewarding part for me is just when the whole thing comes together and you finally get to climb into your ship, turn everything on and take off and fly. Ultimately, I mean obviously I enjoy doing all the artwork for it and the struggles you have to go through to make that happen, but when you actually get to play the asset and everything works the way it’s supposed to, that’s the most gratifying moment for me; cause ultimately I want an awesome game.
[1:56] Coldgas asks: What have you been working on the past few days? Any details you can tell us about?
EB: Yeah very easily. The last couple of days I’ve been very specifically been working on the beginning development stages of the Caterpillar. That means doing some whitebox work, that means taking some concept work and bashing it in to make sure it all conforms with the gameplay. It also means starting to do some work and research on how materials work. So specifically we’re putting a lot of effort into developing how the paint wears on the metal in the Drake ships because they have a very different style than Aegis for example. So that’s what I’ve been up to.
PS: Ok. For me in particular transitioning from optimisation to helping create these, they’re called ship set up levels and it’s where you bring all the pieces together. In terms of optimisation i’ve been finishing up just the level of detail pass on all of the flyable ships in the game to get a little bit more performance out of them.
Did a segment recently on that, goes into more detail. But, yeah! Putting all the pieces together, trying to make the work flow and the pipeline a bit easier for other artists. Just go in, check out the ship, shoot it, look at it in different lighting conditions, look at all the lights etc, etc.
[3:18] Belzoth asks: Can you define what a successful ship is to you?
PS: To me in particular, well, to me a successful ship is one that has made it through the entire pipeline in an efficient manner. What that means, in particular, is going through all of the different phases of development , from concept to actual modeling, texturing, lighting, the whole destruction system, and just making it into the engine, and performing optimally. To me, that’s a successful ship. That means that it went through, you know, who knows how many hands and then ended up, you know, boom, in-game going, ready to go. You don’t have to go back and fix things that you’ve broken. That’s a successful ship to me.
EB: Right, I mean I can agree with that, to some degree. I know you are really focused on the development part of it, but I think to me, a successful ship really is a ship that when I first show it to someone, they’re like holy -, I wanna fly that thing right now. That’s basically a successful ship. And I hope we can develop a lot of those.
[4:20] Daz asks: When optimizing, are you aiming for specific number of assets/triangles on screen at any given time? With backers keen in getting into some big space battles how do you determine what is possible and what ship count to set? Given that it is possible for citizens to pack a bunch of ships into a small area close to each other causing a huge amount of detail to be visible at close range, how do you manage this?
PS: It’s kind of large question. There’s a lot of variables that come into it but really … really every ship is a bit different. Every ship is its own puzzle you need to solve. And your general goal is to get them down to roughly the same level. So what I mean by that is at least just in terms of level of detail, when the model slowly disappears we’ll focus on that. That’s really important. That saves a lot of performance.
When you are up close to someone, you see the ship: it has all of its internal stuff, all of its external stuff. All that full detail stuff, right? But when you are far away, you may not realise by you are not rendering all that stuff. Like things get culled: the interior might disappear, the model might degrade in quality a bit. Not noticeable. That’s where it comes down to. Things like that are where we come in and we look at the statistics and we say “How is this performing? How many ships can we have in an area? How much detail can we get at various ranges?” And then we just optimise from there.
I mean for a specific number? Really there’s not specific number of assets or … it’s just like, you know, whatever people’s computers can really handle based on what we use to work with.
EB: Yeah. I mean the beauty of having this game run on a PC is that the more power you have, the more of the beautiful visuals you can have rendering at the same time.
EB: So part of it is hardware related, but obviously we’re trying to optimise as much as possible to make the game run as smooth as possible for as many people as possible.
PS: Yes. Exactly.
[6:16] Farasalt asks: Has there been a particular time when you have had to make a decision to not implement the most ‘realistic’ version of a part due to technical/design limitations and if yes, why?
EB: Interesting, so I spent a lot of time working on the Merlin and I made that thing so that you’d be able to open up every single compartment to access, every single component, but for technical reasons I had to rip all that stuff out at the last minute and cap the holes to get the ship to run because it was pulling way too many draw calls.
So that’s one example of many that we’ve had in the game, but the process of developing a game often tends to be trying to go as far as you can with a specific type of idea and developing it as far as you can and realizing, “Oh man, this isn’t going to work, so how do we solve this problem with less resources?”. So that’s just kind of a theme for game development in general and that’s what happened with the Merlin. It made me sad because it looked really awesome when you pushed the play button and everything popped open.
PS: I saw it, it was so cool.
EB: Yeah it was very cool. Maybe we can get that back into the game at some point in the future, but at the moment that was one example of what we had to tear out.
[7:37] Amontillado asks: How closely does LOD work tie into manufacturer style guides? Does knowing what makes a MISC ship a MISC ship help you create LODs for say the Freelancer and Starfarer more quickly or does it make little difference?
PS: Well actually not really much at all. The concept for the ship and the main base ship and everything that makes it up is based on the Manufacturer Style Guides. LODs are based on the actual geometry for the ship itself and the best way to optimize that down to a level where we can include it with all the other ships and maintain high performance.
So LODs aren’t really based on style guides. You might, you might try, you obviously want to keep the silhouette of the ship and keep it looking like, you don’t want it to just look blocky. So if this ship has these nice curves along the edges you don’t want the LODs to just block them out or chop them up, you want them to maintain that shape.
EB: Right. I mean what that does mean though for LODs there are some ship styles that are more difficult to deal with, because of that. So a very blocky ship, generally speaking a very blocky ship, would be easier to LOD because you wouldn’t notice the changes in the surfaces as much as you would as a ship that’s a little bit more rounded, so yeah. Style Guides don’t affect it, but the Style Guide does, indirectly affect, how hard it is to make the LOD for it.
[8:55] Wolf_Frakken asks: It was mentioned on INN by Lando recently that the Caterpillar will be somewhat of a benchmark for Drake ships as far as design and looks go. From your perspective, could you expand on that more and how it will affect the Buccaneer, Dragonfly, Herald and Cutlass? How could you see the designs changing based on what you’ve done with the Caterpillar? I know it is hard to live up to everyone’s expectations, but without teasing too much, how excited should we be about what is coming to the rest of the Drake line?
EB: You should be very excited for what’s coming for the rest of the Drake line! And it is incredibly hard to live up to any expectations for the quality bar for these ships! But it is true that the Caterpillar is going to be sort of the first, I guess the flagship, ship for Drake. I know we have the Cutlass already out there, and that was one was developed with techniques that we’ve improved on since they were created.
So we will have to go back and sort of upgrade those to the quality of the new ships. So we’re trying to hit the bar of essentially what the Retaliator is. So the Retaliator has the latest and greatest technology built into it and I think the Gladius does as well and the Gladiator might have most of that in there.
So we have a lot of ships that are already starting to set an example for the kind of quality bar that we want to go for, and also the techniques that we’re using for various reasons. Damage, variety. Making sure that we keep our texture resolution high enough requires us to build our ships in a certain specific way. So ships like the Cutlass were not developed that way.
EB: And so it will have to get an upgrade. Now the Caterpillar is sort of the shp that we are pushing for to define the look of what Drake is. So when we’re done with that one we will end up having to reuse some of the textures that we developed for it, some of the shape language, maybe even some assets.
Whatever makes it easier for us to develop the future ships. Then apply that to the Cutlass, do the same thing with the Herald, do the same thing with the Dragonfly, and the Buccaneer. Ok I wasn’t sure those names were public! So you should expect that the lineup for Drake will look a family of ships.
So if I look at a Dragonfly I should immediately say “Hey that’s a Drake ship!” For this and that and that reason. So we’re definitely trying to unify the looks with something we’ve been working on. All of the manufacturers you should be able to see this now between the Starfarer and the Freelancer. The UK team did a really great job unifying those two ships. They look like they’re exactly from the same family. The Reliant also because it used a lot of assets that were involved in the UK. So we’re trying to do the same thing with Drake and the Caterpillar is the first one online.
PS: Yeah. And then as Elwin was saying as we build more ships based on our Style Guides you’ll see a more cohesive look come together. ‘Cause the more pieces you have from things you remade you end up getting a giant library based on these pieces and design aesthetics. So it’s easier for existing artists, new artists to just come in pick up, go “Oh that’s what that manufacturer looks like”. Based on existing ships versus the hardest part is coming up with it. You’ve got all these different manufacturers and each one needs to have a unique aesthetic
EB: Yeah, yeah, cool. Next question
[12:18] Cavguy asks: One of the fascinating things for me watching you guys build Star Citizen is how you pull it together. Can you talk through the changes to the ship pipeline over the last year and how it’s reduced the time it takes to get a ship from concept to flight? Also, do you think there is room for improvement (maybe we can get the Carrack sooner)?
PS: Yeah. Definitely. I think you might actually be a bit better answering this question per se but from what I’ve seen from the ship pipeline as a whole, from Concept to Tech Design to Implementation, we’ve definitely made progress. Because we’re working more closely with our other studios, we do a lot of the tech and the design and help with the engineering. And it’s all just coming together and you’re seeing things, higher quality, more complicated assets, coming out quicker. Right? Versus concepting it, building the tech, putting the tech into practice, experimenting on it, breaking it, fixing it, and rebuilding it. Right? The pipeline’s come together which means assets are getting pushed out faster.
EB: Yeah. Absolutely. To speak specifically about what some of the changes … what some of the changes have been to the pipeline specifically in developing the ships. We’ve moved slightly away from a paradigm where we had concept fully developed for a ship before production started going in to work for it.
So now what we’re doing is we’re spending a lot of time upfront working with Game Design to make sure that all of the mechanics that the ship needs to comply with, or the space that’s required for the player to walk around in if it has an interior area, is all blocked out ahead of time, and before we even give that to the concept artist, to make sure that when a concept artist does his work it all fits with the game rules and we don’t have to worry about having to too drastically changing the concept that’s already been developed.
Changes will always happen but doing it this way allows us to catch any problems really early on before anybody spends weeks or months of their lives developing an assets that then has to be reworked in the future.
So for the Carrack specifically we have plans to build that “soonish”. That’s the best I can say about that. But right now Anvil is one of the those manufacturers that still needs to have its library filled out. So Aegis, for example, because of the Retaliator and some of the other ships in their line, they have quite a bit of content to draw from to develop the newer ships a bit faster. With Anvil we’re not quite at that point yet and so when we get there we will be able to hit our stride and be able to develop ships faster. What will most likely happen is the Carrack will probably help develop that library for us because it will be the first large, multi-crew Anvil ship that we probably work on. And so that’s how we’ll develop our assets to then, in the future, be able to build ships even quicker.
[15:21] Johan_26 asks: Two separate questions: On the development side, are there many manufactured hull pieces that are shared across the ships of a single company? Like hatch, thrusters, seats, doors, panels, etc? On the game side, visually speaking, how customizable are the ships in general? (like in a Need for Speed underground manner). I know about the possibility to change the seats but could we expect some more customizations like an interior paint job, switching to fancier escape pods/beds, changing the whole dashboard, more powerful headlights, better kitchen, etc.
EB: I think it’s a tentative yes to that second part. Just to hit on the whole manufacturer sharing assets. That absolutely a yes. It’s almost, it’s absolutely necessary that we do something like that in order to develop the number of ships that we have to make. So what that means is that we will have escape pods that are common to Aegis for example and you should expect to see those escape pods in other Aegis ships. Docking collars, same thing. You may even see chairs that are shared among the same manufacturer.
Right now, you will notice that on the Freelancer, you’ve got a specific type of chair which also exists on the starfarer, which a very close version of that also exists on the Reliant. And there’s a couple of reasons for doing that. One, it keeps the look and feel the same so you can identify what manufacturer built your ship. Two, we can actually build a ship much faster. Right, sharing of assets within manufacturers is absolutely something we have to do. In terms of customization, we are still working on what the full range of customization is. The most obvious and sort of start of the customization process that we really want to hit is allowing people to change the paint jobs on their ships. We’re exploring a couple different ways of doing this. We haven’t quite implemented a full working version of it yet, but it’s something we are building our current ships to support.
PS: Yup, no, definitely, just on Elwin’s note, I mean part of the development process is making something, trying out different techniques for it, and find out whether it works. So we do a lot of R&D into different ways to do it. Some methods make the cut, some don’t. We used to have a paint system that was… it was a little harder to work with. We had paints, we had it working, and it’s just, it’s a juggle. You say “does this help the pipeline?”, “is there another way we can do this faster?”.
That constant iteration is kind of why we like working here as well. You can make changes to things, and find a better way to do it. You’re not just stuck somewhere, you know? You might have to go back and change old stuff occasionally, but in the grand scheme of things, it’s gonna help the entire pipeline. So, we’re making everything basically as modular as possible within sensical terms. So, should be able to go out and get other parts. So definitely, modularity is something we already have and can expand upon. We just have to make sure it’s a good use of time management and et cetera, et cetera.
EB: Right, right, and just to touch on what you mentioned of us previously having a paint system. That system was harder to work with. But it also became… it created a conflict with the way we wanted to do damage, just because of the specific implementation method and as a result of that, we went in favor of the damage to find a different way of doing the customization of the paints.
PS: ‘Cause the damage is so much cooler
EB: Well, yes it is.
PS: Bomb metal melting away and everything! So instead of saving… basically, the way it works is you have UV maps, if anyone knows what those are, it’s where the textures get painted onto and the way the tech works is the damage shader kind of, it works over the UV maps, but you also needed the UV, the paints in the UV too. So they were kind of sharing the same space, right? So we were like well, what do we pick? Then we’re like “Well, the paints can probably be done a more another way, and more efficiently, and this is just the best way for the damage system to work”. That’s how, kind of how where opportunity calls for it.
EB: That also, I mean, that also kind of touches back in the “what features have we decided not to implement”. That is one of them. Yeah, so we’re working on a much better way of allowing customization which… the goal is to let people not only change, you know, at least several different colors on their ship, but also attempt to allow them to pick, decals for their wings, or whatever, that way they have like a massive happy face or whatever they want to put on it. So we have some prototypes of that working and I think it’s going to be really cool, but more work has to go into it.
[19:59] Eschatos asks: (A) When you’re designing for this, is the final damage state of a ship intended to reflect specific damage? (For example, is the tail/cargo section being destroyed because that’s where it was hit?)(B)Is the intention that we’ll be able to survive something like that if we’re not in the damaged section of the ship and have a spacesuit on?(C) And thirdly, do you have to consider the repair mechanic when designing damage states?
PS: Yes. That is pretty much exactly how it works. What we’re doing on the tech design side and this is going to get more in depth as we go too. You hit a specific location damage can transfer from that location to another location. There’s probabilities. So if you hit like a wing and there’s components under there, like shield generators or something. That can be damage and that creates a rippling explosion that goes and blows up something else.
So we’re trying to create a very dynamic damage system. So at a base level things break off, wings snap off, tails snap off, body snaps in half, three main parts well three or four is like nose, neck, body, tail. So when your ship is finally 100 percent destroyed if your neck is destroyed you’re just boom! You just kind of blow up. But if your tail broke off you might still you know airlock, thunk, and try and coast back to base. It depends on how it’s going. If you have a critical series of events that happen that might destroy your whole ship.
EB: Yeah. I mean if you trigger catastrophic damage it’s game over!
PS: Yeah it’s game over your whole ship’s going to blow up. So at the end yes there should be areas that you can see, especially like in non 100 percent destroyed state. You should be able to see exactly where you got hit during your fight. But at the end when your ship is blown up you know you got shot in the wing but it’s listing, you didn’t get shot in the tail.
And then 100 percent is a complete model swap into the husk chunks at the moment with an overlay VFX that bursts out. It’s all blended together so you can’t really tell. But unless you’re going back for repairs. You don’t really need to see that one area where you got shot in the wing. It’s all about performance. How can we keep realistic yet persistent damage?
EB: The next part of this question is: Is the intention that we’ll be able to something like that if we’re not in the damaged section of the ship if we have a space suit on? I think you kind of touched on that?
PS: I did kind of touch on that. Yes it is in the design board. Right now you just blow up and die. Your spaceship’s blown up right? As the damage and how it transfers get more in depth we can end up just probably saying “Airlock door closed you’re all safe”. I don’t know honestly I don’t really have 100 percent specifics on that. But I do know conceptually it’s possible and it’s what we’re leaning towards ‘cause that’s realistic right?
EB: Yeah. I think that’s ultimately the goal. Obviously game design is still working on the specifics of how that functions. Because as per the example the back of your ship gets blown off and that’s where all your power plants are, and you’re stuck in the front but you’ve got no power does that mean you’re basically stuck on a floating husk? So there’s more than just the realistic aspect of the game, we have to worry about what the implications for the gameplay are as well.
Okay so the last part of Eschatos question is and thirdly, do you have to consider the repair mechanic when designing Damage States.
PS: Yes you do because you have to think of what’s going to need to be repaired, what’s going to be left behind even if the mechanic isn’t full implemented, you should still think how is the player going to repair this, which of the player will see, what tools are at his disposal. It’s a big difference, just think conceptually, okay this isn’t how it is or anything, but if you have a spaceship and it just flies into a hangar and a bunch of nanobots repair it or something that’s one way where you don’t have to be too interactive, but if you’re a dude with a blowtorch and you’re up there, the ship is a completely different spot; you’re getting completely different visual, all sorts of stuff is going on.
EB: Yeah. That repair mechanic is still being fleshed out.
EB: I think it’s going to be really cool. It’s a lot more dynamic than what we had before. It’s important to keep in mind our damage system is not what we started with. So we use the term damage states, but it doesn’t actually reflect what it is anymore
EB: Right, It’s a lot more organic than that. So previously we did have something called damage states where you’d shoot the wing and there would be four different version of the wing and different states of damage.
PS: 25/50/70 and 100
EB: Exactly, that’s gone. So the way we’re doing it now is we’re actually building the internal supports for that wing and when we shoot the whole surface it will blow a hole to through it to reveal the interior. There’s no damage state, it’s just how much damage has that part taken.
PS: Correct and the only damage state is the really the 100 percent at this point. Are you destroyed or not?
PS: And that’s when you get the detach command and then boom the wing or tail goes flying off, but until then, it’s mainly just the shader doing the work and it’s hitting and it’s rippling out and it’s tearing apart and then it’s transparent and you can see the metal ribbing of the inside of the ship and then that shows a more visual version of the wear. So it’s less memory because you don’t have four different models per separate part of the ship anymore that just has to do damage.
PS: And it creates a better visual due to the way the shader works.
PS: So I mean we’re working on the pipeline all the time, optimizing the tech, coming up with new tech, implementing that and so far it’s looking really cool.
EB: Yeah it’s very awesome and it’s also a lot more satisfying to see the damage happen where you shoot.
EB: Whereas previously that wasn’t the case. You could shoot the tip and the base of the piece would start to break off.
EB: So thanks for joining us on this episode of 10 for the Developers. I’m Elwin Bachiller Junior, Lead Vehicle Artist in La with
PS: Patrick Salerno, Associate Technical Artist.
EB: And thanks again to all the subscribers for making this show happen, you guys rock.
PS: Take care.