No, I'm not. I'm still part of the production team under senior producer Eric Davis, while we are still looking for a marketing and community coordinator or manager.
BL
Ben LesnickDirector of Community Engagement, Online Strategy and Spaceships
We may be very close to a community manager, but Darian is a producer.
TL;DRNo Gamescom schedule yet, but it is hoped soon; instead of one big presentation there will be several events spread over the whole show.
BL
Ben LesnickDirector of Community Engagement, Online Strategy and Spaceships
They're working out venues and travel schedules and whatever else goes into that, booth setups. We hope soon. I know they've been signing contracts seemingly every couple days. As soon as we have the schedule, we'll give it to you. But we're spacing things out over the whole event, so there will be something for you no matter when you choose to attend. And it should be good. I know people were confused because we're not doing the same giant event; that is more to do with where we want the game to be then than anything else. Normally we get to six weeks out and we focus on some particular feature set that we want to show off because it's exemplary of everything we're doing. This time we're just doing ordinary production all the way up to it, and we're going to show you where the game is on the floor and at some private events with our backers.
Ben LesnickDirector of Community Engagement, Online Strategy and Spaceships
The only difference is we're not the ones setting up the stage and putting Chris Roberts on it. He'll be doing stuff at Gamescom, but he will be at all these parties talking. We're all going to be there. Are you going to be at Gamescom? I don't know if production sends people or not.
I don't know. I haven't heard anything. If production is going to be out there, it's probably going to be Eric, or someone from the UK office probably. Many of us will be there.
TL;DRThe Xi'an Scout conversion is a single-seater with four articulated, dual-sided thrusters that can turn up to ninety degrees; Cutlass thrusters may rotate only for VTOL, possibly the Freelancer too, with landed and flight states for the Reliant.
Yes. We can start to talk about that. just to start on a few of the comments about the Xi'an Scout which i'm currently implementing for the hangar ready, in the hangar.The actual name of the vehicle is the Aopoa Khartu Al. It is the manufacturer Aopoa's conversion of the Xi'an scout for human use. It currently has a single seat and no ejection capabilities. I just want to put that out there. We decided that for a light fighter of this size the current single seat arrangement worked best for it. In the future we may have a variant of perhaps another Aopoa manufactured seat that has multiple seats but the current iteration of the Khartu Al is single seater.The thruster questions on here. Yes, the Khartu Al will have four articulated thrusters. The thrusters themselves will orient themselves to actually be able to complete a turn a turn up to ninety degrees for the outer most axes. Each of the thrusters themselves will include the retro thrusters in the front so they'll be dual sided thrusters which will greatly allow the Khartu Al to have a lot of maneuverability so that the main thrusters can actually contribute to horizontal and vertical thrust as well.
Right. The way we're going to do this, we're going to allow the main thrusters to contribute to sideways thrust without actually animating them as quickly as they need to provide that thrust. One issue what we had with the Cutlass, that we still currently have with the Cutlass. Is that having the large thrusters provide thrust in the actual vector that are facing makes the thrusters so that they're really floppy and so from the rear, when the Cutlass is flying should we provide any type of vertical thrust to provide stability for the ship.We found that, they're simply too floppy and it just looks awful. So the way to do this is to provide that thrust and actually throttle the, speed at which they rotate so that will have a ship that has this type of nice, floaty motion without having four long wings that simply flap in the wind which will make it look awful. So we're still developing that and we will of course have that available for the engine and for future ships so that, that will become available. In the near time, we're considering making the Cutlass thrusters only rotate for VTOL.The same is maybe true of the Freelancer that way they still will have joint rotation without that weird floppy animation. Some other technology we will need to develop, the Khartu Al is one of the first ships that will have a landing and flying mode, which are vastly different. you'll notice it is very folded up when it's landed and will expand out like a flower when it's in flight mode. The same will be true for the Reliant.So what we'll do is, we'll create states for the ship; landed or in freeflight that way the thrusters know how they're going to behave and will allow things like; turning them off when it's in landed mode or for the Reliant because of the vertical orientation of them. We will know how these thrusters are supposed to affect the ship because of those two states that the ship is in.
Yeah, how does something like... we have our Flight Engineer: John Pritchett, who works on the ICFS and SCM how would does this change what he needs to do as far as flight controls are concerned.
That's a great question! We would need to discuss with him how we would need to signal the ship, so that it knows which orientation its in. I think that's a simple variable in the ship will determine when it's not in landed mode or when it's in flight mode and then John can then, recalculate what the actual thrust from each of the thrusters, needs to generate in order to maintain proper flight based on that orientation of the ship.
TL;DRXi'an, Banu and Vanduul are each currently a single species-wide manufacturer, though more alien manufacturers may come later, with care that alien designs fit human ergonomics and the story.
I figure we would just tack this one on since we were just discussing the Scout. So right now Xi'an, Banu and Vanduul are kind of their own, I don't want to say brand, but I guess species brand in themselves.
Correct. The Vanduul components were implemented as Vanduul components. The Xi'an components will not, they'll actually be ... as we're doing a component refactor, the Xi'an components will be actual manufacture components. So we'll have "human" components that are on the ships so that you can upgrade them, exchange them them out, etc. In the future I think we will work with the writers and then come up with the alien manufacturers, each with their own components and capabilities. So that we can do things like have Xi'an specific components or whatnot. For now we are currently going with the human componentsDV: One of the things, if you guys actually watched the 10 for the Developers with Sean Tracy and Steve Bender, one of the things they talked about was human-to-alien analog components. For example if a Vanduul is how X feet taller than a human you don't want a human wearing a Vanduul t-shirt because it's going to be a lot bigger. So we also have to take that into consideration as far as when we create these alien manufacturers. We can't just take an alien t-shirt and throw it on a human and say "hey we're done". We have to take into consideration if the humans' size are; that their dimensions are; whether it is compatible with human ergonomics at all. So rather than just creating a bunch of alien manufacturers we want to make sure it is something that is realistic; that fits into the story; and actually fits into the game mechanically as well.
Right and that's a conversation for the Khartu-Al: the control scheme are these two spherical control components that humans will put their hands on. It's just a prototype at the moment we'll refine how that actually works but the early example of that was on the ... what are the Vanduul ships ... the Scythe ...
That's why Zane, our UI guy, he put static across the UI as if trying to show that we are trying to translate alien technology into human use. So it's still a little buggy in game, so it was a little flavour to that.
TL;DRComponents are being reworked one system at a time into physical, size-appropriate parts that can be repaired or swapped, with balance passes so upgrades involve trade-offs, while shields are being refactored into emitters and generators.
This is a big topic. We are currently tackling each of the components one system at a time. I'm sure you've noticed that we've recently just refactored the coolers that did involve resizing the components because there will be real components in the game, on the ships.
Yup, they'll be size appropriate for their capabilities, placed on ships, with ships that have interiors such as the constellation or the future Idris or any of the larger ships we will have access to them from the interior so that when we implement damaging gameplay, which were still designing at the moment, you will be able to access them and have a crew member run down the hall, go down to the powerplant that has been damaged and then actually repair that by access the component from a panel say in the hall that contains that particular component. So there will be real physicalized items that are in the game.
Treat it a lot like Scotty from Star Trek kind of thing where someone has to go down a fix the shield generator or fix the warp core or something like that.
Exactly. So if the engineer does notice that, "hey we got the coolers damaged, now we don't have cooling on the right side of the ship." You can send the engineer down to physically fix that component or perhaps even trade it out for a brand new component and get back instant access to the cooling capabilities that you just lost.
Yes, So, that may be a possibility. What does that entail? Well we're refactoring all of our component so that we actually keep in mind the capabilities, the positive and negatives of each of the functions of that particular component. Dave mentioned coolers so cooling capability, power draw, signature, these are things that are going to be integral for how the coolers will work. What we need to do then is get that system in and then take a balance pass to figure out, "Okay we have a size one," let's say, drake ... I don't know if they've actually created a cooler at the moment but, Drake cooler well, where does that sit as far as its capabilities. Is it a C grade item? What does a C grade item mean?We define that and then we can place those on ships that would be appropriate for that part. Size two or a medium sized cooler would go on one of the larger ships. It has it's own determinants and positives which you can decide how you want to output your ship by the purchasing the component or when we have future gameplay which you can salvage components, perhaps you can actually pry one off a large shipment and say, "Hey this is way better than mine, I'm gonna go and place it on the holotable and include that on one of my loadouts for one of my ships." Also in the future we may allow the capability of particular like craftsman to hone certain components so that they can actually improve them. Maybe the get better at improving a certain manufactures coolers and power plants.
Yup and then you can earn your credits or do whatever you want to do and become that go to person in the Star Citizen Universe to get better at that particular skill. What else did they ... Oh, so the tuning, So what does tuning and balancing mean? Well it means different things for each of the components. What is ultimately does mean is that we figure out what each of the components do, what their range of capabilities are for their particular stats and then we make realistic ranges for those particular values.We've done a pass of coolers, we're in the middle of doing powerplants and we are in the middle of refactoring shields as a system entirely so we will have shield emitters on the ship that are powered by shield generators. So when you upgrade shield generators by purchasing a new one, you will increase the shield capabilities of your ship. Things like, well a number of faces will most likely be tied to the ships but, the regeneration rate of the ships, the absorption of the shields rather, how quickly it can shunt power from the primary face that you set onto the ship, these will all be things you can upgrade by purchasing new shield generator components.
Speaking like someone in the middle of combat, you want to redirect further energy to the front or to the aft or from the you know forward starboard side.
So if you have a lesser performing shield generator for example, it may take longer for a shield face with zero health to recover and get back any shield capabilities. So you may consider purchasing or finding a better shield generator to upgrade that particular capability. That may mean more power draw so you actually have to purchase a powerplant that is capable of powering all the components that you decided to fit onto the ship. So that's what balance entails.We're currently, most of our components are outclassing their capabilities so powerplants generator more power than you'll ever need, coolers can cool more heat than you could ever generate. What we need to do is as we implement this components, we need to step back and take a look at what the actual values for the components that we've created, what are those ranges? What are those extremes? How do we figure out how these components fit within those extreme ranges and then figure out, "Okay, this is the sweet spot for that particular component, and this is where it sits."As the player, you decide by mixing and matching the components onto your ships, how they actually work and whether they provide the desired functionality that you want to implement.
I'm trying to remember correctly, I think Matt Sherman explained it to me. For example the ship had two shield emitters, it could be there's one in the front, one in the back or one left or right, I mean you pretty much have two halves of a shell correct?
Right so bubble makes sense, front back makes sense, I think six is the next logical step, but that is a function of smaller ships. Now when we get to capital ships, ultimately what we want to do is, you'll want to have say four shield emitters, one that controls the front quarter, the second quarter, the third quarter and the rear quarter. Each of them controlling their own faces, that way we'll have gameplay in which you destroy the shield emitter or the generators that are connected to the front port faces, you actually have a chance in now infiltrate the ship from the front and give you an incentive to go after the sweet spot in the front that you've dedicated so much time to destroy with a squadron of small fighters.
Well now let's say you have a long carrier like a Bengal or Pegasus or even an Idris I mean you set up something that long, you could even have mid bulk emitters so if one of those gets taken out you still have an opportunity to have something sneak in while one of those shields are still on before it pops back up.
And I think it'll allow players to figure out strategies not only to attack shields, but defend themselves. If you find that you frequently outclass in the front, well let's get some shield generators and upgrade them on the front side because we know that's our weakest point of entry.
Yeah, eventually we'll get to actually figuring out how the engineer can do things like shunt power or priority to those shields and so, this is a big discussion on one of these systems and we're doing this for each of the components as we go down the line.
TL;DRProducers don't need to master coding or design but must understand what teams are doing, and communication and anticipating bottlenecks are described as their most important job.
That's an interesting question, one of the goals of what production is is we basically try and make sure that designers like Kirk have the resources they need to make the game possible. So, while the production coordinator for the tech design and engineering team. It's not my job to know how to do coding, or how to do engineering or necessarily know how to do tech design, I just need to make sure they have the resources they need, make sure the information is being correctly funneled to them. Now, ultimately what can cause a bottleneck is something like lack of communication or what else would you consider...
In development, we need to keep those channels open and ensure that everyone knows what they need to do and are expected to do. That way we don't have issues where, 'hey, I didn't know that Jimmy over here was supposed to be doing this. I've been waiting for him to finish this other task, which prevents me from implementing thing I wanted to do...'
A good producer will be able to keep their team in the loop at all times, an excellent producer will be able to preemptively predict what obstacles are coming down the road. Be able to foresee what things down the road are going to bottleneck, such as knowing what the other teams are working on. For example, we have Mark Hong, who is our art and animation producer, so if I am working on a particular feature as a producer... my goal is I want to be able to talk to Mark and find out what he's working on. See how what he's going to do is going to effect what Kirk's team is coming or is doing down the road.So if we see Kirk is working on a particular component for a ship, if I find out from Mark early on that that ship is going to be delayed or the art isn't coming along as quickly as possible it's my responsibility to provide that information to Kirk say, "Hey, we have a little more cushion time as far as that particular ship so if you have something else you need to work on, some low hanging fruit that you want to complete in the meantime". That's where the producer comes and lets these guys know, that's what's available.As far as specialization, it's useful to be able to talk to those developers at an educated level, like I said before you don't need to know how to program but at least know what those programmers are doing and what they're working towards. Same thing with tech design, we necessarily don't need to know everything about game balance but we need to know what their objective is and how do producers help them to complete that objective.
From a developer's standpoint, it is my responsibility to inform producers as far as the things they do need to know about that particular task so they can make an educated choices about scheduling and task party, etc. At the same time, when I do need to talk to say one of the artists or animators directly, it should be part of my duties to inform the producer in charge of that particular individual that that is happening that way they can ensure that maybe a higher priority task should take precedence or they know to follow up on that task in the near future and we can all figure out... hey, were you along that timeline, are we getting close to being done because this person is waiting on that. So, juggling tasks and figuring what priorities of things is the resource we use from the production team.
So, it's kind of a nitty gritty behind the scenes look at game development, it's not the most romantic or glamorous type of question but it is one that's important. That's why we wanted to address it, there are things that go on behind the scenes that help streamline a lot of these things other than just making pretty ships and cool levels.
TL;DRComponents were sized into standard boxes so same-size parts can be swapped without custom geometry; most fit only their own slot, though some categories like ammo and fuel may be interchangeable, and smuggling holds are under discussion.
Yep! Smuggling is a topic that has come up for piracy or just being able to stow equipment safely for you, on your ship. That is a topic we're in the midst of discussion for. There was a pass on components for each of the component types, they were mostly done by, they were spearheaded by Elwin who took the, metrics that we use for the ships and for any of the buildings in FPS, the...
Right. These are the standard minimum doorway size that we have on the ship. The standard minimum walkway path that we need. Things like seats, turret sizes, weapons, any of these components we took a look at them and decided "Ok". A size one small component should be roughly this size, and no bigger than that size. So we took the maximum allowable size for the component and ensured that all those components fit that size, fit neatly in that box. So everythings boxed, box shape.That way we can ensure that when we build a ship that has a physicalised component when we swap out a size one, say radar, then we can actually implement another size one radar in the same space without having to have custom geo just for that enclosure, and that ensures the swapability of components and allows us to make components that are unique enough to, make you want to get a different type of component to suit a different need.
So it's actually something that we've discussed in the past where we're finally starting to see it come to fruition as the standardised modularity. You might have heard some of us talking on previous Ten for the Producers and Ten for the Designers that we've been look at trying to create standardisation for these sizes for a long time.And that was something that was spearheaded by Elwin. By creating standard bounty boxes you create a template for every single size one, every single size two because now we have a range measurements that we can utilise to put those onKT: Right, and that's important for us as Designers because when we're implementing a ship in whitebox we can take these bounds that we create for the ships and we know that this is going to require a size 2 component of this type. We need to ensure that it is placed in the ship roughly around here. Well we'll need access to it, because the ship does have an interior so we can communicate to the Artist that there needs to be a core goal or some kind of wall in which there is a panel that we can access this so when we go to actually repair it or swap it out or salvage it, if you're a pirate!There is the capability to physically access that object. What's also interesting about that is when we eventually have the ability to damage these components from the outside, so we'll have gameplay and you're shooting up a ship from the outside you know you can target the shield generator because you can take the shields down. Well you know where that is roughly in the ship you can start shooting around it,and you will know that it does embody a physical location on the ship, and you know where to target that particular component.On a converse when it is destroyed you will also know on the ship. The engineering can tell you, "Hey get on down to hallway A and repair the shield generator". That crew member will know exactly where to go, which panel to pop open and which component to repair.
Or in your cargo hold you could have a whole crate full of different shield generators. Your engineer runs down, take one out, go run back to the cargo, grabs the new one and throws it in there. So not actually fixing it but replacing it as wellKT: Right. So that's just part one of the question, part two was: what are the.... Are we going to allow rechangeability of components? In general no. So most components will be in a specific spot, slot put together for that component. Some of the component types though, such as ammo, fuel, I think there was one more. I can't remember off the top of my head but there is a category of components in which you can choose to fit anyone of those types, that fit in that particular range of components in that slot.So if we do have say a smuggling hold that is placeable on our pirate themed ships. That is a component type you can choose to fit onto that ship. If however if you really want to on the same ship, fit it for longer quantum travel or further distance. Maybe you'll choose a quantum fuel or a regular fuel canister instead. If you really want to fit out a ship with a lot of weaponry, well let's put an ammo box in there instead. So there is a category of component types that we are implementing in the near future. However for the most part components will fit into their actual designed slot.
But at the same time. Let's say you have one labelled as a fuel tank and technicality it's actually a cargo hold. If let's say a player's a police officer that's trying to investigate this pirate ship and he see's a fuel tank there, well he knows pirates tend to use these as cargo holds. I remember hearing someone discussing about being able to scam them and be able to trick scammers as well?
Fuel tank or an ammo boxKT: Fuel tank. And it actually has that, when we implement that actual scanning gameplay, perhaps there's a way in that it actually mimics the actual, the component that it's trying to pretend to be that way you can smuggle, or use it as a smoke ring canister, because we're only going to make a finite number of ships and so there's no way that we can say that "Hey we can randomly generate these smuggling holds".So each ship if you take a minute to study you'll know that "Hey it's a capability of it having this smuggling hold". So let's figure out gameplay in which you can make use of that item and still get away with that gameplay by giving us the capability to whoever is trying to scan that particular item.
TL;DRThey say they do feel pressure to top each release and are confident they can, claiming that planning and standardised production practices keep improving.
Essentially asking with every release do we feel pressure to out do ourselves every time. And that's a ubiquitous, unanimous yes. When we released 2.0 that was with much great fanfare that we finally released multi-player, multi-crew technology but we already had our sights on 2.1 and now we've got our sights on 2.2. And every time we release one of these patches, yes the pressure is there to deliver, but we're always confident that we can deliver more and more. That's kind of the ... that's kind of what we do every single time. If we tried to release inferior content every time ... we want to make sure that we are wowing you guys with every new release. That's why we are constantly showing you guys new ships, new technology. That's why we have discussions like this to keep you guys up to date on what we are working on. So is there pressure? Absolutely, but we are pretty confident that we can out do it each time.
This includes things like planning for the future. May not have been so great at that in the past but as we overcome more and more hurdles and get to each goal, we get better and better at planning for what we'll need, ensuring that we can achieve these things without simply having it as a line item in an email "hey we know what we're going to do how do we get there?" Figuring out the steps that we need to take and incrementally improving on each of these processes is something we are getting better and better at every day.
This is actually where a lot of production work comes in: being able to pre-plan what those objectives are. We may, let's look at 2.3 or 2.4 and beyond, we may have a rough idea of what we want to be in those patches and ultimately Chris is going to dictate we want in those patches, what content we want to deliver, so it is up to Production to be able to pre-plan all these schedules out. And this is where a lot of our tools like Jira, Microsoft Project ... what we are starting to do is standardise a lot of ... in fact as Kirk mentioned, as we do this and fine tune this standardisation of our practices is going to help us accomplish those goals and make them higher quality each time because we are looking what tasks we have done in the past; what we've completed before; and how can we apply those same practices in the future. So I guess just as long as we keep on trucking it's going to get better.
TL;DRKirk Tome says ship hulls and shields shouldn't simply be made bigger across the board; instead, once systems like shields are refactored, each ship and component gets a balance pass to make combat more tactical.
I mean yes and no. This is a very fair criticism of some of the, especially the Arena Commander, battles. What we need to do when we are refactoring each of these systems, shields is being refactored as we speak, we then need to take a balance pass and figure out what we need to do to change the min and max ranges of each of the values in the system.So for example, with the shields we are going to introduce gameplay in which you can do things like give priority to a certain shield; or change the way it can repair faces faster; or do shield face hardening; or the way in which faces can absorb damage or deflect damage away. So once we implement these systems and get that gameplay into the game then we need to go and sit with each of the ships and start shooting at the ship, figuring out "okay, well ships of this size with this particular shield can withstand this much damage for this amount of time" and put that all in a big chart and then figure out where each of the ship lies and if we need to tweak any changes.So to answer you question, we do need to better balance passes for each of our systems. Making hulls and shields across the board larger may not be the best way to do that.
Sure, and so what we can do is, we can take a look at each of the systems individually, shields, hull, health, mass, damage per second, by weapon type, etc. and figure out "okay, where in the realm of the things that we want to look at, like DPS for weapons, where does that particular weapon sit? Where should it sit?" If it isn't sitting in the right place we figure out "okay, we need to tweak these particular values and make sure that they do fit a role for that particular component type.So yes we want to make gameplay more interesting. We will do that with balance. I think this will definitely come into play as we start making larger and larger ships because as we do implement ships, or ship types, that we haven't before we need to figure out "okay, how do we do this without breaking what already exists?" So if we make, say, the Constellation, if we made it impossible to destroy with a couple of Hornets it wouldn't be very fun. So figuring out where, again, the ship lies; where the capability of each of its systems types should lie and ensuring that those values are correct is part of our jobs and we need to be better at that.
At the same time let's look at real world analogies or comparisons: if you have two people on motorcycles that crash into each other at high speed chances are they're both going to get wrecked. Pretty quickly. If you have a car hit a motorcycle the chances are the car will be a little dented but the motorcycle will be pretty totalled.
Right. So that also comes into play when we're designing ships. We can't make a ship that is just OP, in which playing any other ship types is just no fun.
So we figure out how is it better than other ships, yet consider if you have a fleet of smaller ships can they take it out? Let's figure out a way we can do that.
TL;DRThe developers say features and ships are planned together so a feature has content to use, such as a ship for a mechanic, and the supporting systems must exist before the ship is built.
This is where a lot of the strategic planning and communication between production design comes into play. This is also where good direction from management, Chris or Ben, also comes into play. So when we release a feature or a ship thematically, for example, if we wanted to do a salvage feature, ideally we want to have content for players to take advantage of that.So, a salvage specific ship would be a good example of releasing when we released the salvage mechanics, same thing if we wanted to release a repair mechanic, you know having the what's is it... Endeavor. Having that come out at the same time would make good sense. If we created a mining mechanic using your example here, if we created the mining feature but we don't give players a ship to do mining on. It's a feature that's basically sitting there waiting until we have that feature completed or a ship to take advantage of that feature. Ultimately, this is where planning and preproduction and communication comes into play.
Right, so none of these things are coincidental. When we do decide to create a ship and decide a release date for it, we need to ensure that the systems that make that are unique to that ship actually exist... are designed out and are implemented from code and tech design so that those systems are in play by the time the ship is actually created.
Doesn't make a lot of sense. So, there is a lot of design that goes into that... quantum travel is a great example. We needed to decide what quantum travel was, how it realized itself in the game, how the component interaction for quantum travel was, standard things like the distance for quantum travel, time for quantum travel, quantum fuel is a thing now so we implement quantum fuel as a part of quantum travel. That's a system that needed to be designed before we created a bunch of ships that were capable of doing quantum travel.
TL;DRLanding and quantum travel capability is decided ship by ship based on role, with no size limit set yet, and medium-size and larger ships will have walkable interiors, though no date is given.
Great question. We are discussing that now. However for the most part, the, we are deciding which ships are planetside landing capable or not when we design the ships. One interesting topic that came up was, for some of the snub nose or smaller fighters, we are deciding to either make them Quantum Travel capable or atmospheric landing capable. As a trade off between for having such a small ship you need to pick one that suits the needs that you are looking for.This is especially important when we have ships that are capable of carrying smaller ships. The Connie is an example of one, though the Merlin doesn't actually function on it yet, but when it does, you'll get the capabilities of what the Merlin is able to do when that comes online. For other ships that have snub nosed fighters for example or a carrier ship you can decide Well you know what I really wanted to park this carrier outside of a planet and then go down to the planet surface using all these smaller atmospheric landing capable ships.Or what I really want are a bunch of say like taxi style vehicles that allow you to shoot across the galaxy and then meet up with other ships very quickly. You'll need to make a decision. So as we design each ship we are deciding whether or not they are Quantum Travel capable and atmospheric landing capable. So these are things we're deciding and it's on a ship by ship basis.When will we get to see this? Well that's a great question! We're still, we're working on these we're making these ships as fast as possible however all of the ships that are medium size or larger are definitely going to have interiors that you can walk around in. I discussed earlier things like being able to access the components from the inside. That's going to be a big thing and so yes there will be interiors that you can walk around with, walk around in. And then interact with other crew members, components, systems. There will be standards things we have like beds, bathrooms, etcDV: We want to give players a reason to walk around these large ships. A reason why you want to walk down this hallway and open this door and other than just, besides having the reason of just having a large ship. We want to give you guys a reason to walk down that hall, open the door, access this panel. Apart from just being for that reasonKT: And then we'll need to make decisions such as how do we make modular components for these ships so, at least on a ship level for well when we create a ship like an Idris, it's impossible to fill every square inch of that thing with custom geos so we need to figure out what a standard hallway is, what a standard room is like, what the engineering station is going to be like, what the, if there's an engine housing room, if there's a cargo area that we can make modular and place on several parts of the ship if there are landing areas for that ship how do we figure.We make choices so that we can make a ship that's functional and is within reason schedule wise because we want to create the best as quickly as possible these are things we consider when we are designing and ultimately building the ship from nothingness to something that we can actually see in the gameDV: Let me give two examples. For those who are anime fans look at the Cowboy Bebop anime series. you've got the Bebop ship that carries: spike's, swordfish. And you've got also Faye and Jet's smaller ships. They use the Bebop through Warp Gates carrying those ships even though the Bebop can land trans-atmospherically it still has smaller ships that it can with it.But if you look at something like Battlestar Galactica where they have giant fleets of ships and some of them are orbital space stations that are jump capable but something that is shaped like a ring or like an orbital station is not going to be able to land so you want to have shuttles and lighter ships, well they're called lighters, that can go inbetween ship to ship or trans-atmospherically up and down.We'll even have orbital docking yards where you get up from there and you take a taxi or a shuttle back down to the surface. It's ultimately going to be decided by what that gameplays need is, what the ships functionality is going to be is, what the role that ship is going to fill. So ultimately there's going to be an ultimate large size of what ships can land something like...
I don't think we've made that decision yet. I think we're going to decide on those capabilities based on the role of the ships. "What is that ship made for? What is the reason to own that ship?". Then we'll make a decision about those particular characteristics at that pointDV: Right. I can figure something like a Bengal Carrier trying to make a landing would cause major atmospheric problems.
TL;DRDarian Vorlick says a joke that offended some backers changed how he presents information, and both developers say they read and consider all community feedback, though some ideas aren't feasible.
This is a very subjective question and we filled you with a lot of technical details today, especially as far as a lot of component information. We get a lot of input from all around because this is a crowdfunded game we get a lot of input from players on where they'd like to see the game go; what ship we should create; and ultimately while we are following Chris' visions we still like to solicit feedback from the backers and our from audience.The most interesting one that I got was a possible cultural faux pas I did back in one of the original 10 for the Producers where I made a joke, what I thought was a pretty safe joke, it did end up offending a couple of backers from a particular geographic region.
Someone asked me how did I meet Travis or what's it like working with Travis. And I said I'd met Travis in a, I think I said, Serbian prison camp: he took a knife for me once and I've been indebted to him ever since.
It was said, just, offhandedly there was no intention ... I could have said a Japanese prison camp or an Antarctic prison camp. It didn't matter, the joke was regarding the prison camp itself that he took a knife for me once and I've been indebted to him ever since. That was the joke but because I used a certain countries reference that does have a history of particular turmoil a lot of viewers from that region were really upset. And I know it sounds very superficial but it actually did change the way present information and the way I think about certain answers and the way I actually approach certain individual within in the company as far as being more, not necessarily being politically correct or culturally aware, but it did remind me that we have a very wide audience. And while trying to walk the neutral line is an impossible thing ultimately there is a way information can be presented in a very humorous way and while still being able to maintain an objective conclusion.
I can't think of anything specifically. What I will suggest though is that we do get a lot of feedback from the community and it's terrific. Keep it coming. We do read everything and we do consider everything. Some things are simply impossible to implement or it's not feasible within either the design or the scope of the systems or the ...
... the world we're creating. However we do enjoy all the ideas. Any idea that comes from the backers and the community is welcome. So let us know your feedback because without you voicing your opinion we don't know what you guys are thinking. So continue that and we welcome it all.
Yeah. We could be working on a great idea from our perspective, looks absolutely amazing and kick ass, but we put in game and realise a lot of players aren't using it because they might find it boring or it may not fit the original vision we had for it. So this is where a lot of feedback from you guys comes in.So I want to amend my answer a little bit: while that one instance I gave is something that changed my perspective we do look at everybody, as Kirk says, we do look at everybody's suggestions and it is those suggestions that help mold the game.
TL;DRThe two producers answer lightheartedly: one would have liked to work on animation and character performance, the other on lore and writing, though both say they enjoy what they do now.
It's yours. So I spent a lot of time learning the craft of animation, getting a degree in acting, just all the things you need for a good solid performance of a character, and so that was actually the path I was going in. So for me what I would love to do, or what I would have loved to have done, what I would dig into (probably too much) is the animation side: performance and characters and just conveying a story, because I love telling stories.
Probably the lore or writing aspect. Given that I've got a background in publishing and writing I would love to be a project managers or just oversee how the writing develops. Creating that kind of mythos is incredibly interesting for me. I have a deep seated love for traditional printed media. There's something romantically classy about holding a book in your hand and knowing that this is something that you had a hand in putting together. But I actually like what I'm doing here: being able to interact with developers on design and engineering, it's different from anything else I've ever done. I like new things.
TL;DRThe producers say they draw the line by choosing when to stay at schedule level and when to dig into detail, knowing enough to ask good questions and spot bluffing without interfering with designers' or programmers' work.
It's very tough. We're going to get to later, I think there's a question on ownership but when we talk about what our backgrounds are, what we're experienced in and what we know we'll tend to spend a little bit more time in those. So you hire different production with different skillsets to provide you different perspectives. So if you have a producer that's very technical they may know a little bit more about the detail so they may answer those questions better. As you said in that post, "know enough to be dangerous", right?
It's great, it's exactly right. So I think the question's "how do you draw the line?" You just got to figure out what you need to dig into. For me, it's good to have an overview of the schedule; to plan it; to work with your leads and your team; but then sometimes you have to get into the weeds, you have to dig in even further. So it's not necessarily you shouldn't do one or the other: it's more you do each at different times.
That and when I first started here, I'm not a coder, I'm not a programmer, I'm not an engineer, so there was a little bit of a feeling of displacement when I first started because I wasn't really sure if I would be able to talk at the level that's necessary for the engineers and designers. But just through sheer saturation I feel I can at least carry on a semi-decent, intelligent conversation that doesn't rely on just grunts and pointing.
So being able to have a conversation about the Item system or the Entity Token system with developers, like on a phone call this morning, I think we should know enough just to be able to ask questions on how progress is going and know when someone is bluffing us. So we have to be able to read, what's the word I'm looking for, anticipate what the needs of that particular discipline are. We don't need to be experts in it, we just need to know enough to be able to converse with the developers and be able to manage those tasks.
For reference, this is what we were talking about on a Skype call we had this morning with our UK office, with one of our programmers Stephen Humphreys, and he's in charge of our Entity Token which is the sequel to GOST. So I am not fluent in FlowGraph in CryEngine but with the way the Entity Token system's working I know enough about what they are trying to accomplish with it to at least know what the end goal is; what they are trying to do to get there; what the voids are; and if a certain person leaves an aspect of this project what more resources do we need to allocate to that.
And knowing who has what skillset is absolutely necessary knowledge to have in order to be able to fulfill that void. So in talking to Mr Humphreys we knew that he was making progress on certain aspects, certain concepts; I need to be able to ask how far is he; where's he going with it; and i had to be able to converse with him at a level where it showed I understood what he was trying to do.
I would say lastly I was just re-reading this about "how you maintain that overview?" That's kind of the point of production: we are the third party perspective; we are the outsider; we aren't in the weeds per se so we are able to get a large overview. So I think, intrinsically, by being Production and being required to not know everything down to its base level that allows us to keep that overview. Right? So then we chose, as producers, where we should learn more information to help understand that better.
That becomes a double edged sword because the more technical detail you have, where does it stop where the producer starts getting more involved with the actual technical, for example, if the producer can read code or write code it doesn't mean that he's going to start jumping in and changing people's code when he sees a mistake or he feels something should be changed. That should be up to the designers and the programmers, and the producer should just be there to guide them towards the specific objective and not interfere with what the designer and programmer is doing.
TL;DRThe producers estimate task durations by asking developers and scaling for project needs, add a roughly five to ten percent buffer, and admit schedules quickly become obsolete when blockers appear, so it involves a lot of guesstimating.
I don't think one is necessarily contingent upon the other one thing we do is talk developers and ask them how long they think it will take and this is predacted on their knowledge if it's something they've already done we as producers will have a good idea to taken them in the past. We look at the scale of what their doing and we upscale it or downscale it based on the project needs.If situations like technical blockers pop up something we've mentioned in previous Ten for The Producers videos is every time we put together a schedule and publish it for the team it soon becomes obsolete because dates and how long someone takes on a take can change from day to day we may need a programmer on a task pulled off because we've got another blocker that needs a fix and that may even become related to what he's working on. Because we are a I wouldn't say a small office but we have a limited number of resources that makes each time how a developer spends on a particular project that much more valuable. So being able to plot out that time is a very tricky thing to do.
It is and how do you plan for that? It always comes down we've never done it before the teams never done it before we've talked about this before at the end of it just add five ten percent buffer they will take 2 weeks so we give them a little bit over two and a half weeks and say that's our coverage. So you'll tend to see production bloat things a little bit more but that's usually to protect the team. You want to over deliver as opposed to the other way around where people over promise. Anything that's part of our job as production is to go we're going to add a little bit extra time because even if comes down we deliver faster and then we'll know for the next time as well.
On top of that let's say that I ask Mark Abent to do a programming task and he gives me an estimate that it takes fives days. Is that five days from now or five days worth of work? That's something we have to be concerned with as well what resources does he have at his disposal as well?
And being a live plus development pre-production plus production and you also have to add in a certain amount of bugs. It's a good question and it does come down to we're doing a lot of guesstimating and you have to trust the team the team usually knows the best or if they've never done it before you just add a bonus and go.
TL;DRThe producers say the consolidation is only just underway, point to the co-located audio team as an example of its benefits, and have nothing to say on the Freelancer remodel, promising to look into it.
So this one is a good question. I know a lot of people have wanted to know more after Chris sent that email out to inform how this was going to work. People like to read what is said and then what's between the lines and there was no real reading between the lines on this one; it was truly just looking at the business, looking at the project and seeing what's best for us to do it as fast, as cheap as we can: which we're always doing! Every day we're doing that! Every hour we're doing that! So you're going to see changes and in normal game development this happens: you go through and you revamp the team.
The previous places I worked we revamped or reorged every year, every six months! It's pretty common because you learn so much more: like I know how to make that ship faster so I don't need so many people, or I need more people, or whatever the case may be. It's just the nature of business.
Have we seen anything? So this is in process of happening right now! We are talking about it because it was just announced and these things just don't happen [snaps fingers] over night! But we are moving quickly on them, so for instance one of the examples is we looked at our amazing audio team, the majority of them if not all of them (except for one) is out in the UK led by Lee Banyard. It's a fantastic team, they deliver quality stuff and they are very quick. The turnaround is very quick and their communication is solid and yadda, yadda, yadda: all the things that make teams great.
And their all in one place together. And I think that was one of the things that when you see "why are they doing so well?", Well they're all in one place together. They're always together. So when things come up they just turn and they get it fixed so they don't have to wait twenty four hours for an email to come back. So that's a lot of the things we're doing: just putting little things in place that make sense. So we'll still have our multiple studios because it still makes sense to have that but we are unifying and I think we'll start seeing the knock-on effects of that in the coming months.
TL;DRDarian Vorlick explains that tasks are broken down together with team leads, and Eric Kieron Davis says problems are handled by re-evaluating bids, resources or location, including moving pipelines between studios, rather than blaming individuals.
So this is kind of plays into key about what Eric was just talking about how we're trying to centralize all of our resources in particular offices. Now our team hierarchy, we have a lead for each team for example, we have a design lead, we have an engineering lead, we have an art lead. So these leads pretty much head that team, now when we created a task for someone, these tasks are generated in collaboration with those team leads, that way the team lead is always aware of what their subordinates are working on and we as production can see an overall picture on what work needs to be done.So the kind of tasks that get dictated to us by the leads, we look at let's say what features are coming down for the next patch. We'll sit down with the design leads, what do you need done for this so design lead will give us a list of we need this in there we need to have that in there, so we look at these features, break them down into individual tasks and look at which developers are free under that particular lead, for example with art team, if Elwin we need to have a concept for actually our hangar ready ship, we see okay we need to see one of our artists Daniel, he can do this, Gage can do this, Patrick can do this, so us as production it's our job to kind of make granular on how these tasks are broken downEric Kieron Davis: And to speak to the other question because I think that was good for the last question, the other question is, when someone is having a difficulty right, that's I think you touched on that a little bit. That's a great question and what actions have you taken? Anything, everything right? We've gone everywhere from evaluating maybe the task what incorrectly bid out, maybe we said two days and it's 3 months, major mistake right we got to get those leads again. Maybe they've had computer issues, maybe we've pulled them away too much to bugs for live things like we said in the last question I haven't been able to get to it.Maybe it just isn't working with the structure so to the last question talking about shifting things around, we've gone all the way from having full pipelines move to different locations because they had the staff for it, it wasn't necessarily because someone was failing and can't do their job, get rid of them it was more okay this isn't working out here lets evaluate why, oh, it makes sense here because they have more people, they have the right resources or maybe we realized there's one person here that needs to be apart of it, the rest are in Frankfurt, or vice versa, it's more about again, constantly evaluating as we look at our hiring practices, who we bring in, look at our overall tasks and then we shift those responsibilities around which is one of the cool thing about having as I've called it before, "follow the sun development". We shut down, UK opens up, Frankfurt opens up, Austin right, vice versa, we kind of keep things moving along so we can keep things going as fast as we can. So that's some of the things we've done, and we'll continue to do it.
TL;DRThe producers say staff changes are handled with contingency plans and divided responsibilities rather than everyone knowing everything, that cultural and language differences between studios are a real but manageable challenge, and that blame is avoided in favor of fixing root causes.
There you go! A lot of those could be answered in different portions...I think that's like 4 of 5 different questions, I think the first one to speak to for sure is staff changes, production changes, responsibilities, sharing knowledge.
In this industry, in many industries of creativity. People move around, it's a very common place. People get another job, people get a promotion, they change, their spouse needs to move around the country, their kids need to go to another school, there's all kinds of reasons people come and go, it's a pretty fluid thing it's just business, right? Any company any industry has this, this is not new.So for us it's about building contingency plans and understanding who can own what in the current environment. So as somebody ships out, there's by no means ever an expectation that every producer needs to know everything, there's no way we could all do that, at the number of production we have at this company alone, it would be an overwhelming amount. So yes, we do break it down by responsibilities, we do try to say alright Darian, you're going to work with the engineering and design team in Santa Monica, you're also going to work on live releases, you're also going to do X, Y and Z, that's what you're going to try and own. You will be likely involved in these three things and you may hear about "this" stuff because it's in your studio, so you should be aware of it but by no means he's required to know it all.In fact, we have to trust each other, so yes when someone says hey I got another great job, my wife needs to move to this, my husband this, right, whatever. We go "cool, here's the contingency plan", we start to either shift out that work, look at what we may need to rehire right? It's kind of the part of the last question, re-evaluating the business needs and then we can filter that out. So if it makes sense they go okay that chunk of work that person was owning, we can probably still cover that here for a short period of time until we get support, we'll do this this and this and we'll fan it out. But ultimately we'll have a longer term plan of okay the job will go up on the website or we'll promote this person and were going to give these responsibilities, so we come up with a contingency plan and then we generally have a contingency on back of that.We also you know, you may have heard this before, the hit by the bus plan, as vulgar as that sounds and how much I hate that because I never want anyone to get hit by a bus, the idea is that would we still be able to function? Yes, we want to make sure that people are, they understand enough of what everyone is working on so we can step in to help whenever possible.
It's also a good sign of good management practices that the company doesn't fall apart I mean if you're someone who's so central to everything that if you can't leave for a day without things falling apart, that highlights a lot of inefficiencies in that management practice, you should be able to step away for weeks on them, because as a manager as a project manager or producer, everybody should have an understanding of what they're doing and that if I step away, those things continue on like clockwork.
Yes, that's right. So there's some other questions in here. There's a good one in about difficulty exchanging information with cultural barriers, that's a great question and in fact these are two good guys to talk about it. When we were in our previous place expected to work in China for many months to set certain things up, certain operations, and that was kind of, for me personally, I know I've travelled but that was my first on the business side dealing with cultural barriers and so yeah absolutely you work with anyone that's not within 50 miles of yourself there are cultural barriers, whether it's phrases you use or the terminologies in an email or knock on effects. I just use that in this thing but that's apparently a very large thing you use in the UK, we don't use it here at all. There was also someone reference soccer, I'm sorry football, and how we should do something and I'm like I don't understand that, what are you, use basketball terms, or something else.
Yeah, that's right, and that's obviously our silly examples but there definitely are on the business side, questions. We do have that added element of, 'oh what does that mean or how do we do that or you know'. It's not as bad with other english speaking cultures, right? But I know our Frankfurt office, those guys are all very fluent in english so it's worked pretty well,but there are definitely challenges.
It also helps that we have our guys going back and forth between offices. We have our UK producer Ricky Jutley, we've had a few of their designers here. We've sent a few of our guys out there so there is kind of a cultural exchange that goes on and it keeps the company more homogenized and unified in how we view things.
Yes, yes you have. That's a good question, it's not always as simple as that. Poor workmanship isn't always that one person failed at one thing, this is a team effort, it's always a team effort and so we want to look at it that way. We do like to find where a problem is at the root and fix it for sure but we don't run around and going "oh this is wrong, you did it!" Blame games don't help anyone: they don't help in family, they don't help in business, they don't help in a team.
That's right. So it's more about understanding what the problem was, going to the root of it and then going let's figure out how to solve that problem on a mass scale as opposed to just, you know if somebody is a problem, obviously take the correct business steps for that but that's not necessarily what this conversation is about. But there are things you want to fix so you want to find the root cause and fix them.
Communicating, making sure that you're clearing communicating it because if they don't, maybe the expectations weren't clearly communicated and by clearly communicating it expectations that is the step to you know, because then if they fail again.
TL;DRComplex components are handled by weighing options like hard coding versus flow graph and prototyping them, and production avoids carrot-and-stick in favour of collaboration, daily stand-ups, and occasional hard lines on what can't go in a build.
So, on the first one if a component becomes too complex or cumbersome...this actually ties back to that Skype conversation I had with Steven Humphreys regarding entity token system. One of the things we talked about is anytime a designer uses the flow graph system or using flow graph as a designer, it pings the network and the more times you use flow graph to ping the network, that's going to cause more and more bandwidth problems.So, one of the things we want to do it is look at is using flow graph the most effective way of doing this design feature on the ship. So, from that it becomes a conversation between the designers, would they rather just hard code it, would they rather flow graph or entity tokens through flow graph. So, these are things that are planned out in advance but there is some research and development that goes into it, we do some concepts, some proof of concepts for prototyping to see which one works better.
Yeah, to speak to the next question about in terms of carrot and stick methods...I personally don't believe in carrot and stick because if you see the old adage of carrot and stick, it generally means whatever it is you're pushing for with this carrot is going to get tired at some point, right, cause they're never achieving that goal. It's more about making something attainable, more about working alongside their leads, it's more about constant and consistent daily motivation. It's not about sticking something out there and going, 'All right, let's go get it, if you don't get it you're going to get hit'.That's not going to get anything done and we work in a very creative environment, we're making video games, we're making experiences, we're making entertainment...we're not building a cog, we're not building a car, we're not building something that's been proven, we're making stuff up as we go along. It needs more, I think, finesse than carrot and stick, I think that's using very old production processes....
Yeah. I think that's largely true of a lot of game studios where production ruling with an iron fist is an antiquated model and largely doesn't work out because so many people have valuable voices to add to the content of the development of the game. It's a much more collaborative effort, there's no single moment where production is, 'this is what we need to have, this is what you're going to be working on and absolutely nothing else'. So, we have a lot of sit down discussions that we've mentioned before with our international colleagues. We also do daily stand ups with the development team to see where they are in every task, what roadblocks they have, where they're at, do we need to do anything for them to help them get their job done.
And here everyone is excited to work on this. The passion drives all of us to work hard everyday, every second we're at our desk and if you get distracted, that happens but that generally doesn't need some forceful motivation.
That's right. Look what this does, isn't it cool. Then balancing positive feedback with critical critiques and hard lines, how to balance them...you want them both. You don't want everything to be negative and constantly down even though in this environment we're trying to make things better so we're always looking at things partially with a negative eye. So we need to motivate... what's good about it, what's successful, how did that go well. Let's say that last release, we all want to pick it apart and say how horrible it was, we agree with what you're saying, we read the forums and Reddit...yeah, this was horrible and that's stupid and this sucked but we have to go but we succeeded here, here and here and everybody loved it. Awesome, let's keep building on top of that while fixing the bad things. It's easier for us, we're all in that critical mind set to make things better.
There are sometimes where we have to put a hard line down and say, 'no, cannot include this into this build'. I know you love it and it's something that you really, really want to see fleshed out but we just don't have the resources or the time. If we can get it out for the next patch awesome but we would like to see some more testing, some more tweaking, some more balance on it and definitely some more input on whether it's from our QA team or the big man CR himself.
TL;DRMuch of the work is planned months ahead but finished late, so staff often see the result only days before or on the live stream; the team calls its project management mostly agile with some waterfall.
So for clarification, if we ever joke about having to prod the team into shape, please understand it is always mentioned in jest. Very rarely, do we ever need to cajole or coerce them into doing something. I think it's because they know I have a sword hanging on my desk that I don't need to do that to begin with. (They both laugh). But it is an interesting question because a lot of the stuff we work on is planned out months in advance, however, a lot of stuff during, let's say stuff we are working on towards Citizen Con, we're still plugging away at things even until the 11th hour.So there may be features we've been trying to fix, trying to get into the game. We may not see it until like a day or two before. Or we may only see one aspect of that project, and we won't see the completed or finalized thing until we are at the event. Because we are only working on one facet of it, so being able to see it in completion, the complete fruition of all our works, we see it on the live stream when all you guys see it.
I guess like when you have an actor working on a film, they only do their lines. They don't see the final film until like a private screening or something. So this is very similar, we won't see the final product until either just days in advance, or during the live stream, and that's why when you see us watching the live streams, we are cheering along with you guys because this is awesome, we get to see what we've been working on for the last two or three months.
Yeah, we keep our heads down, and it's hard to see the whole thing all the time with how big we are. It is a bit of both. We do have a master schedule that is laid out, and we are constantly feeding into that. The stuff we are showing you, because of the environment we are in, we're showing you the stuff as much as we can as often as we can. So unless it's a big reveal that we want to show off to you guys, like we did at (DV: Bishop's speech) Citizen Con, Bishop's speech, we might hold that a little tighter because we want to make it cool to get you excited, but for the most part we are trying to show you guys everything we possibly have all the time.But we do have a longer term schedule that we are feeding into, and we're delivering as much as we possibly can as often as we can that feed into that. Because everything you are seeing is still building that large universe, right, and that's why Chris built this out kind of at the beginning as modules, so we can show you here are the pieces that make it and here's exactly what we are doing.
Even on Around the Verse, the Art Sneak Peek and stuff like that, so they may see that piece of art or concept artwork, so knowing those kinds of concepts are being previewed, we're still working on facets of that concept or that ship, that terrain, whatever we are previewing, so that by the time it is released to the Hangar or into Arena Commander, or whatever we work on in the Persistent Universe, that is the culmination of months worth of work, but you've been kind of seeing the progress all along, because we do like to share that transparency with everyone.
RightEKD: We follow more agile, but we take a lot from waterfall, right, because we do have this large thing we are trying to deliver, and all these milestones for each of those. They are kinda living within each other, because agile is more this micro deliveries within these larger milestones.
DWIT system. Do whatever it takes. Now, as far as Mad Max or Jurassic Park, I'm going to photoshop a picture of Eric on Chris Pratt's face from Jurassic World, and different designers faces on the velociraptors when he's standing in the pit kind of like this.
That's a tough question, because it's, I don't know if you've heard, it's like herding cats, right, you have people who are very passionate and know what they have to get done, but keeping them all together is a challenge, but a good challenge. Okay, last question!