As per usual, anything said during the show is subject to change by CIG and may not always be accurate at the time of posting. Also any mistakes you see that I may have missed, please let me know so I can correct them. Enjoy the show!
Last week ended with 76 total must fix issues: 10 blockers, 50 criticals, 14 highs, 2 moderates and no trivials
Most recent bug where the quantum drive is concerned is traveling way too slow in the system
Disconnection/recovery logic has seen some work
Tightened focus for the first test plan for the Evocati - goal is to crush bugs via specific feature sets, the first being Traversal
With the tightened focus and the bugs fixed, the number of outstanding issues is now 26
A big challenge is to fill the universe with interesting content and things to do
Designers will use the Mission System and other tools to create interesting and reusable content
The system can look into the universe and adapt missions to the location to make the universe feel more alive
Subsumption allows complex systems to be broken down into components that can be quickly and easily combined
Many of these Subsumption base components can be customized at runtime to respond to a given situation
Subsumption has now completely replaced FlowGraph for creating missions
Subsumption is still a visual scripting system but allows things to be build in a more modular way and reused
An ongoing challenge is developing critical "endpoint systems" (underlying tech like pathfinding, Useables, etc.) sufficiently
Subsumption Visualiser was developed because the on-screen debugging of activities was inadequate
The Visualiser evolved to include mission debugging, editing variables at runtime, on-demand conversations
Subsumption can access the Mission System, activities and reputation: it's basically the core flow of the game
Subsumption and the game code are being built up feature by feature to give designers a massive toolkit to build content
There are two types of missions: more story focussed missions from mission givers and more "random encounters in space"
Designers can use timers and different logical triggers to affect mission flow
Tony prefers using procedural tech to create a canvas for more handcrafted content over purely procedural content
Content should feel reactive rather than strictly scripted, the occasional bizarre occurrence isn't out of the question
Mission templates are designed to be open to "narrative dressing" to keep them interesting
Designers work very closely, and productively, with the writers with a lot of back and forth
Sandi Gardiner (SG): Hello, and welcome to another episode of Around the Verse, our weekly look at Star Citizen’s ongoing development, I’m Sandi Gardiner.
Josh Herman (JH): And I'm Josh Herman.
SG: We’ve got a good one for you today. Later in the show we’ll be talking to Tony Zurovec and others to learn more about the improved mission system that’s set to bring a whole bunch of new gameplay to the persistent universe.
JH: But before we tackle that, it's time for another edition of the Burndown, where we discuss all of this week’s progress on the Alpha 3.0 release.
SG: Let’s check in with the team to see what issues the Devs have been battling.
Eric Kieron Davis (EKD): Welcome back to Burndown, our weekly show dedicated to reviewing progress on issues blocking the release of Star Citizen Alpha 3.0. Last week, we ended at 76 total must-fix issues, which was prioritized as 10 blockers, 50 criticals, 14 highs, two moderates, and no trivials. So let’s catch up with the team to see how we’re progressing.
Matthew Webster (MW): Cone of travel show distance set too far, taking ages to go between moons or destinations that should not have the slow version of Quantum Travel. About 25 minutes ago, or a half-hour ago, Mike Dillon put a comment on it, and the way of dealing with it is for Mike to fix this issue, being to probably revert his change.
Michael Dillon (MD): So, the most recent bug we got for the quantum drive had to do with travelling way too slow in the system. Our star system is massive; not as large as the actual solar system, but it’s scaled towards that, and we recently wanted to have short-range travel between very close points, so the points around a planet. Unfortunately our calculations, we didn’t take into account how fast we were going. So what we were calculating dynamically for the short range had to do with how fast do we hit travel speed, and how fast do we slow down. One solution we put in towards that was to also fixing targeting issues, we replaced the physics push we were using, where we pushed the ship along its forward with a calculated envelope of where you should be, we could pass in time, go five seconds in you should be here at this speed, that also allowed us to trim our ramp up, ramp down times working with design so they knew they could modify that to shorten that angle, and it allows us to, now, travel slowly around the planets, but still get the fast travels between the moons themselves, so it only takes like five or six seconds, maybe ten depending on how far away. We’re still working on tuning those numbers so we have nice long and fun travel, so you can get out and walk around the ships and stuff, but it still doesn’t take half an hour to go from one side of a planet to another, cause that’s just not fun.
We had another issue, kind of led off of that, where we ended up going too fast because we over-accelerated in the other direction, and everything way too far. So it’s been a matter of balancing out the code, making sure it’s calculating things correctly, and working with design to get the visual and the feel that they want, and then working with Vfx to make things look pretty as it’s going, and everything’s coming along really well on that, so now it’s working pretty well, we’ve still got a few tweaks we want to do, but overall it’s working really solid.
Rickey Jutley (RJ): I would define the agenda the week before, you’d be testing that agenda, we would be figuring out the issues with that, and we would be coming up with something that we could look to review in the event that that thing wasn’t available. Right now what we’re going to suggest is commodity, inventory, cargo, that whole gameplay loop of being able to sell as well and maybe looking at the kiosks. If that does have issues, then there’s other things that we can look at in terms of missions or even areas of being able to traverse to different parts. There’s a lot of different things that have been locked off for complete so the whole idea here is, you know, we’ve got to look at them.
Chris L. Smith (CLS): So recently we were regressing a bug on the PU for the 3.0 build, I went to drop a ship onto a character on a pad, just to see the animations at first. What ended up happening is the ship exploded.
David Colson (DC): The ship blows up and the player is just standing there like nothing happened which… so ship flies into him, pauses cause it’s freaking out… ship blows up and the guy is like ‘no problem’. There is another video, ship’s like flying into person and then blows up and the guy is just floating there like didn’t care, nothing happened.
CLS: QA we want to go bigger and better so I spawned a Starfarer, at that point I got up to speed and sure enough Starfarer exploded as well.
DC: So this is obviously kind of an issue and looking at what was going, it ended up being a few different issues. Like initially it started with why is the ship blowing up, which was… there some code added for the Gamescom demo because small ships would fly into the Idris and the Idris would immediately blow up. So some code was added to figure out the mass difference between the Idris and the ship or the two ships colliding into each other. It had the knock on effect of working incorrectly when you’re flying a person into the ship because there’s obviously huge mass difference between the ship and the person and it worked backwards because it wasn’t intended to work in this situation. It added huge amounts of damage to the ship and destroyed the ship. Getting hit and the damage was being applied but you will still standing there like nothing happened then we would like ask the game, ‘what’s the health of the player?’. It’d be like zero and the player’s still standing there, walking around like nothing’s wrong. So you need to manually trigger death which was another step that needed to be done. So now eventually a person in first person view and the ship like flies at you, and a bit of a pause but the player is killed, blood on the screen, everything’s good and the ship hasn’t blown up which is what we want.
Matthew Intrieri (MI): A few of these I was looking at them are related to like the way Eric was describing the bugs, you pull on one thread it actually trickles and solves a bunch of Jira tickets like Prospector not taking damage on the engines, it’s the UV2 overlay issue that I keep trying to push up to a higher level. So I need to talk to Engineering today during our door sprint to say ‘these are two must haves that I need to accomplish 3.0’ the rest is like nice icing on the cake 3.0 stuff but these are my must haves.
Unknown UK Design Dev: Stuff’s going through … the ships at the moment, I say things keep going differently wrong with them. Like audio will be gone one day, back another. We’re currently doing a massive test which is the UV2 worn maps and damages on them, about a third of the ships - maybe a quarter of the ships - appear just not to have it set up at all.
Tom Sawyer (TS): So another important 3.0 feature that we’ve been focusing on this time is the disconnection/recovery logic. So what this means is we’re now able to track graceful disconnects versus ungraceful disconnects. A graceful disconnection is any time that you bring up the main menu in the game and you explicitly choose to log out, that’s a graceful disconnect. In an ungraceful disconnect could be any situation where you lose connection to your ISP, or you know perhaps the client crashed and you’re trying to get back into the game. So if the backend detects that an ungraceful disconnection occurred then we save player metadata as well as create some reservation tokens for individual game servers for your spot. So then when you log back in you, you’ll immediately be presented with a pop up data log that says ‘hey do you want to reconnect to the game server that you were last connected to’. So if you accept, the matchmaker will immediately put you in that instance and at that point the network objects between the server and the client should automatically sync up. The goal is to get you to a spawn in exactly the same location in the universe that you were at the point of disconnection.
Erin Roberts (ER): I want to get… I want to go to Evocati the first thing I want to make sure we can do is traverse the system easily and well and that’s all this set of bugs is about. You know, from going in, taking off, ATC working, QT working… we’ve got to go to locations. All that kind of stuff if we can just get that working so it’s not, you know, I’m not going in maps trying to work out whether I can jump to places or so forth. If you can do that kind of stuff then we have what I think actually is a really good start for Evocati so it’s a lot of fun, it’s fun. You go down to the planet, you do certain things and then once we get this set of 26 bugs left, you know, don’t forget these 26 bugs I want fixed to go to Evocati with but I’m sure we’ll fix a bunch of other stuff at the same time and stuff like that. Then we basically go and get that in and once we get that set of bugs, you know, that set of bugs fixed then what I want to do then is sit down and go over with Todd and say, ‘right, what’s next feature we want to focus on’ and we’ll pick another say 10-20, you know, like a feature like let’s say, ‘let’s get trading working properly’ and then maybe 10-15 features and we’ll say, ‘right, here’s the 17 bugs for that’. That’s the next release for Evocati, let’s get all this stuff worked on and then we fix it all in the background and we basically pick a feature at a time, nail it down and keep them going that way and that’s how we close this out.
EKD: So as we talked about last week, we’ve tightened the focus for our first test plan for the Evocati which will be traversing and experiencing the expanse of the new universe and all that entails. Then while we’re getting larger test support, we’ll continue to polish and bug fix more features, push them out for testing and so on and so forth until release. Now at the time of filing this we reduced our total must fix issues by 50, some by fixing bugs and some shifted over to allow for a more focused polish of traversal and like Erin said this brings us to 26 issues stopping this first release for the Evocati group. So come back next week to continue getting an in depth look at the road to Star Citizen Alpha 3.0 release here on Burndown.
JH: Remember we also published an updated 3.0 production schedule report every week, you can find it on our site to explore further details on the status of 3.0.
SG: Let’s now turn our attention to the mission system with all the moons and planets planned for Star Citizen. It was important to design a procedural mission that could provide plenty of content.
JH: Yet we needed to do it in a way that also incorporated hand crafted missions and characters to make sure that the universe feels alive. The blending of procedural and hand crafted missions has been a goal of ours from the beginning and with the release of 3.0, you’ll get to experience the first implementation of the new system.
SG: Let’s check it out.
Tony Zurovec (TZ): The most appealing aspect of Star Citizen to me is has always been the level of freedom that it promised. The idea that you’d be able to wander through a massive and extremely detailed universe and craft your own unique path. I’m fine with limitations being imposed but they need to be done within the context of the game so that, for example, if a player acts like a criminal the game needs to have mechanics in place - security forces, a bounty system, the concept of reputation, an understanding of ownership, and things of that sort - so that the game can push back as appropriate. Ultimately it all comes down to choice and consequence - that’s part of the real world and it ought to be part of the game as well.
David Pollard (DP): Big challenge of the game is there is such universe and we’ve got to fill it with interesting content and interesting stuff to do. And the work that I’m doing on the Mission System is to try and create tools that the designers can use to generate interesting content and also reusable content as well.
Rich Welsh (RW): Rather than the designers having to say “In this mission there should be three ships and two of them should be pirates and one of them should be security.” What they should be able to say is “Hey we need a ‘stand off’ mission where pirates and UEE are fighting each other.” And the system can look up into the universe and go “Well actually in this part of the solar system it’s a really wealthy area so there might be a lot of security ships.” So we’ll spawn a whole bunch of security ships and maybe one plucky pirate who made his way in and was trying to make a break for it.
Alternatively it could be like “aw this is a really rough neighbourhood. It’s a really poverty stricken area of the universe. It’s a bit rough.” We’d want a bunch of pirates, or maybe one or two pirates but with more pirate reinforcements ready to jump in and join them. So at that point it becomes a much more procedural living universe rather than the designers specifically saying “Hey every time you come to this particular section of space you will find two pirates one UEE.”
So what we want to be able to do is to say “Here’s a ship. It’s got an engine room. It’s got a bridge. It’s got a mess hall.” And designers want to be able to say “Right it’s going to need two pilots, four security staff, a handful of engineers. Go.” And our system needs to be able to identify where on the ship those characters should spawn. Also set them up with behaviours to run.
TZ: Subsumption allows complex systems to be broken down into hierarchical components that can be quickly and easily combined to create logical and layered systemic effects. It does this via enforcing a lot of structure so that the base elements know how to properly interface with one another and so that non-programmers can quickly construct large quantities of content.
The speed of implementation is actually extremely important since larger component dictionaries equate to a greater ability for the system to craft an appropriate response to a particular set of inputs. NPCs don’t start to truly look intelligent until they can understand, prioritise, and appropriately respond to a lot of different stimuli. And missions start to very quickly feel boring and repetitive if there’s not enough variation.
So with Subsumption these base components are just the starting point. Many of them can be algorithmically modified - customised - on the fly so that the game can more effectively respond to a given situation.
RW: Tony’s Subsumption Editor allows the designers to specify those requirements for a ship. So they can say “Right, you need this many pilots with these behaviours. You need this many janitors with these behaviours.” But picking sensible locations to spawn these characters has been quite a challenge. We did end up for a while with characters spawning on top of tables and stood on the top of the spaceship. And then over time we’ve refined it. We’ve gone “Well they’re not really sensible places for the characters to be.” So it’s been an improvement … a slow process but we got there.
Edward Fuller (EF): The thing that Subsumption allows us to do is I can just find a location on three planets. I can find an outpost on one of those planets out of tens of hundreds of outposts - however many we have. And then I can find a room. And then I can spawn a box in whichever one of those.
TZ: It’s now reached the point where designers have moved away from FlowGraph entirely. Which was a particularly important milestone since they’re now able to start realizing some of those inherent force multipliers. We’re now in the process of … we’re now in the process of training designers how to most effectively utilise the system. This is going to take some time since it involves getting them to think about some things differently than they have in the past.
EF: So it’s a lot more, lot more open. We have a lot more opportunities to do missions that are more expansive.
Luke Pressley (LP): When we decided to go to Subsumption we were left with a choice and that was whether we’d go in half-heartedly - we’d keep the old missions there and support them, keep them alive in FlowGraph and just make the new missions in Subsumption - or whether we’d just rip it up and start again. We can’t have designers and coders keeping two systems alive because bugs appear all over the place. You can never just say “This is done and it will always stay done.” You have to always support these things. So, yeah, we started again and that gave us the opportunity to revisit all those old missions and give them the Subsumption touch which is … we can never do the variety, the randomisation, things like that in FlowGraph; it’s just not possible.
EF: Working with Subsumption is quite similar to how we used to work with FlowGraph. It’s still a visual scripting tool and we still have to build missions with objectives and logic to progress a mission. But Subsumption allows us to build things in a more modular way now. And a more reusable way. So if we’re building say … if we’re going back to this mission where we’re picking up a box on a planet, for instance, in an outpost, we would make a little bit of logic that is reused for any number of missions where it’s something where you pick up a box and it shows the objective where you need to take it and then when you drop the box the objective appears on the box. We only actually build this logic once in Subsumption and then we use it multiple times in many missions. Now that seems like a really small little thing but having to only be able make that once and then use it multiple times across mission content actually means that the experience is more consistent and it also frees us up to do more interesting things.
TZ: One of the big challenges to getting Subsumption up and running has been getting the right people in place. I’ve built similar, but considerably less advanced, systems over the years for other games so I was able to pretty quickly get a sense of how I wanted the architecture to actually function. What I really needed though was a counterpart in the game side, someone that had dealt with a lot of the same issues and spoke the same language but that had a really … a really, really detailed knowledge of CryEngine. And so we lucked out when we were able to pick up so many talented people from Crytek in early 2015. One of those in particular was Francesco Roccucci: a Lead AI Engineer with a ton of experience. We’ve since added a number of other people to the effort and the end result has been that things are now moving along at a pretty solid pace on a number of different fronts.
The last thing that I’d mention in this area is - that continues to be a challenge to getting Subsumption out the door - are what I’d call the “endpoint systems”. These are the pieces of technology upon which chunks of Subsumption logic often depend.
Pathfinding, for example, has been … it’s been operational for probably a couple of years but it’s only been relatively recently that a lot of the visual glitches started to finally get addressed. Such things they might sound purely cosmetic but - abrupt turns, hugging walls and improper acceleration - they quickly rip you out of the game world and break that sense of immersion that we’re aiming to get.
There have been a lot of other animation issues - particularly with regards to useables - that had to be solved before characters could properly interface to everything from chairs, to control panels, to crates, and so on.
Subsumption is tightly integrated with our Object Container System which means it had reach a certain level of maturity before we could move forward.
And this is actually just the tip of the iceberg: there are many other systems upon which Subsumption depends that had to reach a certain level of functionality before the system could really start to flicker to life.
That’s actually why getting Subsumption into 3.0 is such a big deal. It means that a lot of critical game systems are now starting to either come online or have reached a certain level of refinement. Which is why I expect gameplay to start making considerably larger leaps forward in the future than it has in the past.
Francesco Roccucci (FR): One day I was just trying to get a couple of guys - the debug of two guys and usually we debug on screen - so we have some functionality on the game where you can look at a character, press the slash button on the num keypad and then you will immediately show on screen what he’s trying to do as a behaviour. So it shows the behaviour, let’s say, the activity in which he’s in, the sub-activity in which he’s in, the logic he’s running, the variables that are running and what we call the “personal log”.
And the personal log is similar to what we’re talking about … about the story because the way I tend to write behaviours is really to tell the story of their decision flow. So you can read and say like “Oh, I’m really angry now I need to go to pick up something. Oh I couldn’t find something then I’m going to go buy something else.” And you can see from the story if something goes wrong because you know which story you are trying to tell and if something is odd then you immediately spot it.
But then it was impossible to debug two guys at the same time because of the space on the screen. So we create the Subsumption Visualiser that is the … representation of Subsumption in the game, in the engine.
And the beginning was just debugging activities and then I had the help of Dave Pollard because he also wanted to debug the missions with this other designer. We say “Okay, then I will add the mission debugging.” And it started like something that we needed and then people really started to like because they say “Oh, now I can keep track of an infinite amount of log: not only the last five lines. And I can see things changing.”
And then we started to implement other functionality, for example, Dave helped me implement the ability of changing variable values on the fly. So you can take a behaviour that has some timer of five minutes. You say “You know I really test it. I just want to make sure. I’m not waiting five minutes for the screen!” You can change timer value, or you could reset some of the values just to make sure things get triggered again.
And then we were talking with designers. Then of course when we started to work on the conversation their problem was like “Oh but I cannot play the whole mission just to trigger one conversation that is at the end the mission.” So worked with another two programmers that is here in Germany, that is called Gabriel, and we made what we call the “conversation tab” in the Subsumption Visualiser. And there you can see all the available conversations.
When you select one you can see which participant in the conversation are needed. And then you can check on the game which one are available. All the actors that are in the world; you can select them and then press start. And you can retrigger a conversation over and over again to make sure that the flow of the logic is correct. Or you want to test the lighting on the game? Weah, you can trigger the conversation and make sure the lighting is good. Or is it set up correct? Yes, you can trigger it again. Or you want see the animation blending - if everything is correct for animators - they can just make a test map, place three guys, if the conversation has three guys, and trigger it even not in the real environment.
So we’re trying to really make a tool that allows this designers to speed up in their process. Because the other thing I always like to really to push is if you don’t allow designers to be quick in what they are doing they will have fear of iterating. And if they fear iterating you don’t get the right gameplay. The idea is, yeah, if you allow designers to have the right tools they can iterate much more on their levels, on their logic and is you can achieve the best results for gameplay reason. You just don’t want to … to make designers scared of iterating or the logic. Like “Oh no if I change this one now I need to spend another five minutes to retest it. Mmm, yeah I don’t have time for that. Right?” There should always be time for tweaking and iterating. And it’s what we want to achieve.
The Mission System and the activities and the reputation, they all live under the Subsumption umbrella. So the good thing is - and is why we did it that way - is because we want to be able to access all different systems within all the logic of the game. So the mission is basically the core flow of the game. Right? It can be single player campaign where the mission is pretty much your campaign and then the sub-missions are the chapters of the game or the sub-missions of the chapters.
PU missions will be completed more like generic and more dynamic and these missions will access data from the characters that are available in the world, what they are doing, what their reputation is, the layout of the worlds. So we can access from the object container structure, for example, this is the root of the universe. We want to go to this planet and we know which planets we have available. But then there are other things that we generate at runtime, say we spawn a pirate ship - a pirate Idris - with a specific crew member and this one is defined in Subsumption, in the specific platform structure. And this spaceship with the crew can be accessed by the Mission System to give either commands to the guys or to create the specific logic that you want for telling the story.
And this is the reason why I spent time refactoring all of this. Because it’s the only way in which we can create specific logic that is reusable across all the parts of the game and that we can basically expose in the right way to the designers.
RW: Designers want to be able to obviously create content for the world and they find that they want to be able to give … spawn ships, give them instructions, tell them to fly to a point, shoot a target, defend an area. Because it’s a new tool and because it’s new data that the designers are putting in we then have to go “Oh, alright, cool. So you guys want to be able to defend an area?” So we go away and we go “Right, that’s what they need now.” So we add the … we get Tony to add the function to his editor. We then go to the game code and build that “defend an area” code up so the ships are then able to do that.
Then we pass it back to the designers who go “Alright great! Now they can defend an area, we now want them to to be able to fly off into space in a formation and lead an attack.” So we’re like “Okay cool.” So it’s the same sort of thing: we go back to Tony and say “Right, now that they’ve got this, they want this extra thing.” So he starts adding it to his editor and meanwhile we start handling it in the game code where we’re able to build up features one by one until the designers have this massive toolkit available to them to build new content.
FR: There are different ways of getting missions. And different ways of just accept missions. So a lot of your interaction will happen through your mobiGlas as well so you can see what’s available to you even from a mission giver. Maybe he’s not going to give you just one mission, he’s going to say like “Oh, look I have this packet of missions available for you. Which one you want?” And same is around, you can say “Now I am in this area of space there are these missions that are available to me. I want to accept this one.”
RW: There’s certainly two types of missions. There are the more story focused missions I guess, where there’s a mission giver who says “Hey I’ve got this situation, please go deal with it. Here it is.” They give you an objective to meet and then you fly off and meet that objective. Or don’t meet that objective.
DP: The mission broker is a system that runs on the servers and takes into account the player’s reputation and criminal status and various other economic factors in the area that they’re in and generates a list of missions ... appear in the player’s mobiGlas and allows them to just accept the things that they’re interested in. And it also talks to the mission givers as well and the mission givers can ask the mission broker what missions are available that they can offer to the player as well. So it does all these things together.
RW: The other kind of mission is random encounters in space. It’s possibly wrong to call them a mission it’s more of a random encounter in space. But in terms of how the designers would set it up it’s still … it would still be built as a mission just the trigger would be you’re flying in space, nothing’s happened for a while and entered an area that feels like it needs some action. And we go “Hey, here’s a spontaneous mission that’s popped up.” And you don’t necessarily get an objective: it might pop up on your radar and say “There’s a rescue that needs happened” or “We’ve detected pirates in the area.” But it would still be handled as a mission. But, yeah, that would be more of a “take it or leave it” kind of situation as opposed to the missions where someone’s explicitly said “Hey, I’ve lost my dog. Go find it.” and you’re like “I’ve got you. I’m going to accept this mission and go do that.”
FR: Designers can create timers or different logical triggers. So it can be if you enter a specific area where you shouldn’t enter then maybe it’s like “Oh, now I start to spawn lots of pirates.” Or it’s like “Oh, you're very close to finish. You save five out of six characters. Now I will send you another lot of pirates.” So they can really generate the logic they want and create the logic they want through this tool. This tool is super generic and it’s just very efficient because we try also to run only the logic that is active at that moment. So we can run a lot of missions for a lot of characters.
TZ: I’ve never had any interest in purely procedural content as in practice I think it tends to feel very formulaic and repetitive and bland. That approach, it gives you an infinite amount of variation but when there’s nothing more I think it falls apart on the experience. It lacks the depth to really make an area alive and unique and interesting.
My personal taste is that I want key NPCs at the given location, for example, to have real back stories and well thought through motivations and reasons for being there in the first place. And not to be NPC facades that have had their traits rolled from a random number generator and whose connection to the rest of the universe feels isolated and bereft.
We actually use procedural tech extensively but it’s just one of many tools in the pipeline, and its primary purpose is to set up the background - the canvas - upon which a more detailed and intricate picture is going to be handcrafted. We’re actually taking the concept one step further in allowing handcrafted content to be algorithmically placed onto procedural backdrops and then customised in real time based upon inputs from the game.
RW: Tony’s always said the game should be this interactive universe - this very emergent gameplay style universe - so rather than having everything hard scripted and feeling like it’s been placed there and you turn up and it just was there. It feels like it should be reactive to the player, so as the control of power in the universe ebbs and flows then so should the encounters that you come across.
From experience players seem to enjoy things happening that aren’t quite supposed to happen. So long as it’s not game breaking. So long as it’s not ludicrous. If a pirate attack popped up in a safe stronghold but it only happened the once it would be this rare event that I don’t think players would have a problem with. Obviously if it started happening all the time people would start seeing it as a bug. But it is fun for these things to randomly get thrown in. That’s partially the power of this system: if we’re able to make it so that it’s able to choose that just enough so that it’s keeping players entertained but at the same time not enough that people go “Well, this just doesn’t make sense. Logically pirates wouldn’t be attacking this space.” Then I guess we’ve done our job right.
The players make their own stories as part of the game so it’s like they’re flying along, they find there’s a pirate ship attacking a civilian vessel and they fight off those pirates and rescue the civilian. They’re then later able to find that civilian ship is elsewhere and it’s almost like they’re tracing the threads of these stories on their own as they’re being built around the player.
That’s not to say that will always be the case. Sometimes it will just be “Here are some pirates. Let’s fight those pirates.” But it would certainly be nice if we’re able to start tying these missions together. And maybe tying missions onto the back of other missions. So you save a civilian say, in a … from a pirate fight and he turns around and goes “Oh, my ship was damaged. I was meant to take this cargo - this valuable cargo - to somewhere.” And suddenly it opens up a whole storyline for the player where they could potentially take that cargo, or steal that cargo, depending on the inclination of the player.
But it starts letting the players build their own stories and I know certainly from speaking to Tony he was hoping that there’d be a civilian rescue mission, so you’d fly in and start defending this civilian. More players join, start attacking you because they’re playing as pirates. And suddenly you’ve got an all out war between a bunch of players. And at that point the players are really building their own narrative. It’s less “Hey, here’s a very small mission encounter where we’ve turned up, shot some guys, and left.” It’s become more like “Hey, we turned up to try and save this guy and then these players turned up and started fighting us. So then I called my friends and they turned up and started fighting them. And then we tracked them back to their base and a whole bunch more of them turned up.
LP: When we develop a mission from scratch we start with a very high level direction from Tony and then I take that away and flesh it out into a mission with objectives. And then I’ll run that by Tony and Todd and if we get the thumbs up we … we then … so I sit down and I flesh it out further and I try to think of all the ways I can keep this mission open to narrative dressing as possible. A really simple example of that is “Go collect a box.” Very simple objective. And you can think of thousands of ways to dress that differently to make interesting.
But when you start talking about more complex missions with several objectives - complex objectives - the narrative dressing you can put on that? There’s less variety you can get out of it. So that’s where the writers come in. I try to leave it as open as possible and give examples of ways I think we can do this. And then they’ll just build on top of that. Give us ten more ways we can make this sound different. All we might need is a different prop for this or something.
And that process is very fluid and it’s great to work with those guys. We’re in pretty much daily communication, usually, but when it comes to these … the mission creation part there’s a constant back and forth of mission designs and then dialogue and mission text coming back that we can go over and go “We need this changing because the objective’s such and such.”
We’ll come up with things that affect the way the lines are written. And these … the writers, Dave and Will, will pitch something back to us and we’ll go “That’s amazing!” And turn it into a mission or an objective. Honestly it’s great working with those guys and being so close to them. And it’s great when they come over here as well, actually sitting down with them and thrashing out …
For example, I’d say my favourite example that writer-designer relationship is Tessa Bannister, who is a character who lives on an ICC probe. Between the writing, the actor and the implementation of the lines we managed to create this really, really likeable and vibrant character that the players, they seem to really love her. And my small part in that was the way we arranged the lines. The writers will give direction on each line to the actor. The way the lines come back there’s always a very slightly different tone. So she might be supposed to be upbeat for all these lines but she’ll be upbeat slightly more on one of them.
So what I did was, obviously I listened to all these lines and the way I ordered them - because it was just linear progression: you meet this person and then you do missions for her. So when you meet her at first she’s as neutral as that actor can be - she’s very buoyant - but she’s quite neutral. And then the more missions you do for her she likes you more and more and more and more friendly until she’s genuinely excited to see you. And just building that kind of arc for her was … I really enjoyed that and it seems like the players really felt that too.
So the intent of the Mission System is to be able to create this … It’s a universe right? We can’t be designing individual missions to fill it. We have … and craft individual missions. So what we tend to do is create mission types which themselves can … there’s a base flow but they can be in random places. They can be a completely different reason for needing to do this mission. You can be attacked by different people at different points throughout it, or not. There are a whole load of variables.
So we create this template that has the option of all these variables and then that can be generated over and over and over and over again. And I’m not going to say you’ll never play the same mission twice, not in 3.0 anyway, but the moment you have this full galaxy and we’ve gone in and marked up all these different places for it to be and come up with all these different enemies and such, it’s very unlikely you’ll ever get the same mission twice.
SG: It’s exciting to be seeing all these new gameplay elements come together, when combined players should have a wide variety of missions and unexpected encounters just waiting for them to create their own Star Citizen story.
JH: That’s all for this week’s episode, thanks to all of our subscribers for making this all possible. This month’s Jump Point will be released this Friday so subscribers should check it out.
SG: Yes, check it out. Also thanks again to all our backers for supporting the game, we truly appreciate all that you’re doing to develop Star Citizen.
JH: Until next week, we’ll see you…
SG/JH: Around the Verse.