Star Citizen: Reverse the Verse LIVE - Looking For Group

That first meeting, we were going in and was like, OK, we're going to do party mechanics, party systems. Sit down in the meeting, we're going to go over everything. All right, Chris, what are we looking for? What's the scope for our initial stuff versus what we want to do? And he's like, yeah, so groups are everything. Everything's a group. And so we're doing everything. And we need to have that foundation. We can't just sort of piecemeal it out to be like, here's the party and we'll integrate it with groups some other time. No, everything's a group. AI's groups. Anything that...

Insurance club membership.

Yeah, that's a group. If your criminality missions, these things will put you into groups. Everything is a group. Groups are groups. Groups of groups are groups. Organizations. Yeah, it's crazy how many things this ended up touching when I was like, oh, I'm going to invite somebody to my party. This is day one. I've got an idea for how... oh, my God. Oh, no. So yeah, it's been quite an undertaking to figure out what all those moving parts would be and how they would sit in for everything.

Yes, very much yes. Both, because it's something that people have very particular expectations for. One of the things that came up early on was, well, this is going to be chat. It's going to be part of the system. How are you going to handle that? And then we're like, well, how is chat solved elsewhere? And the answer to that is in 100 million highly configurable and very specific ways. And if you get even one of those things wrong, people are like, I'm not going to use this. I'm going to go use the other thing that I already like. And groups behave a lot like that, parties. And so while I'm certainly very excited to try to get as much community interaction into and supported by the party system, it's also a daunting task because of those expectations, because how people play is going to be so personal, and how people play with their friends is going to be even more varied and personal, because a personal relationship with this person that you play with is just going to be different than this other person you play with, and you want those both to behave as expected even though those expectations are different.

Yeah, I think in the ATV that we did yesterday, something that I had said is the way to look at the parties and groups and the features that we're working on is sort of two things. They're not separate, they're part of the same whole, but what we're delivering for 3.2 is basically the party system, playing with your friends right now: I invite Ken, I kick Ken because I don't like him, I invite Calix, and you're playing there. And all those simple requests, those things going on. And so what we want to do right now is, all right, let's use this old system, give it some new UI, use mobiGlass, make the player experience better, because that F11 menu is a little nightmarish. Get some F11s in chat.

That was a big part of it, right? You needed all this arcane knowledge to use any part of the system.

Make it more user friendly, attack what we can right now, and with Benoit, build underlying systems that can tackle things like orgs, things like the Insurance Club membership that I brought up before, and all these interesting different features. The cool, fun stuff hopefully we'll get to deliver soon, but we start with: let's address the current problems while building a framework for better things later. Those are the two things.

Now, some variation of this question comes up quite a bit. There's a notion that the trading system is somehow linked to the grouping system, and I don't believe that's the case. Trading system would be more a service beacon kind of thing.

Not quite. It sounds like you have an answer. I'll let you go first.

A little bit. I guess they're only linked in the sense that sending people money and other items and stuff, in my opinion, should be handled using similar aspects of the shop code, which is something else that I wrote. So they're only linked in the fact that I would work on both features. But I do want to see that, because right now there's not an easy way to send aUEC to your friends outside of service beacons. So I want to see a design on my desk to get more shop stuff for trading and sending money and things.

I can already add that we've actually touched on this question on the aforementioned Calling All Devs. And while trading is not actively in the game right now, the initial design step is for it to be an evolution of the service beacon system. I don't remember what episode that was, but you can find all episodes of Calling All Devs available now on YouTube.

It's part of the whole contract concept of: I'm going to create a job and send it out to a particular person and they'll accept that. And then when things conclude, you'll transfer money. That seems to be the core element of it. We had wanted to get mission sharing, reward sharing, all these aspects into the group system. But those, again, start to balloon out into whole systems that are, A, not already set up to think about the party and groups and influence moving around in that way, and B, have a lot of things to test. So it was very much not safe to get that in in the timeline for tier zero, particularly because just getting everything built over to the new system took a fair amount of the time that we had. So I imagine that you'll be setting up essentially a contract and rules for how payment gets distributed among your party, among your group if you have any org dues or something like that. Those would all be individual things that get set up. And the party would just have an umbrella of rules for how to handle most situations that you can then deviate from, to make it as easy to use as possible and also give you the customization that you need.

Correct. Not for tier zero. Yeah, we're trying to make it so that you can even complete a mission based on the party. So even if he has the mission and everybody is there with him trying to get it done, I think that he still needs to be the one to complete the mission in order to get the reward payoff. And so that's one of those issues of: this needs to be dealt with in a deep and holistic way, or else things like that just won't work the way that they're expected to. As far as reward sharing, we were initially thinking maybe we'll just split evenly, but not everybody's going to want to do that. Where are we going to put the options to opt in or out of that system? And it's just not ready yet.

It wasn't a free feature, unfortunately. Something like, and Ken could probably speak a bit more to this, having your vehicle be unlocked for your group members, you could get that in pretty quickly with the systems you already have. We'd probably just have a half-assed solution of trying to get missions to work with groups. So Calix said it best, really: a holistic solution of, this is how the mission code changes to accept multiple people. Like if my friend kills a dude, I killed the dude. Mission success.

Groups are intended to be able to contain organizations and their features, which is why we had to make such a broad approach for the first time. But those two things aren't linked yet in Alpha 3.2.

Something worth mentioning too, at least for internal terms: when we're saying groups, it's usually the more generic thing. This could be just a group of friends that like to talk to each other. So that's the generic thing. Whereas a party is specifically: we're all online playing together right now. So groups could be everything. Party is a specific case of a group.

Well, you don't actually have to be online to be part of a party. Sort of.

Yeah, group is more of a thing that will be mostly used on Spectrum, but the party system will be on Spectrum but also effectively doing something gameplay-wise.

Yeah, it also handles all the stuff about if you get disconnected, how do you get back into the same instance, if you're doing any matchmaking at all.

Yes, so party is more of the gameplay-wise groups.

So it sounds like there's a distinction between groups and parties that we'll probably be chasing around for the next couple weeks or months over development, trying to better delineate what constitutes a group versus what constitutes a party.

Yeah, right now they're the same, but in the future you could have groups that are not parties. Like 10 guys, we all talk and play together, but maybe only two are online right now.

You could use a group to turn it into a party and be like, all these people are in my party again, but now I'm going to go play with these people instead.

Like during the Vulture promotion, we mentioned, I think it was a Wayfarer's Club. That would be a group.

So group could be everything. It's like the rectangle and a square thing, right? A square is a rectangle, because it's just a subset of what a rectangle could be. Groups are everything. Parties are a specific kind of group.

Maybe I can answer the question. For now, it's set to eight, but it can be decided by design when we push it out the door. So it's not decided yet. For now, internally, it's eight.

You might want to talk about the reason why it's eight, because of the old party system.

No, I just realized that it's not something about it. So it's just fixed to eight somehow.

Yeah, well, I actually know a little bit about this from other conversations with Kirk. You have to start with an arbitrary number. Whenever you're doing anything, these processes start with: let's just pick a number and see if we can hit it and see how it works. And then from that, you decide whether that's too much and you go down, or it's not enough and you go up. One of the great things about running a live environment in the middle of our development is we don't have to make those final decisions on our own. We can pick an arbitrary number like eight, put that system out in 3.2 as eight, and then watch for the next three months, six months, nine months how these parties come together, how easy it is to fill, what they can do versus what they can't do, and then adjust that number holistically, based on what we see in YouTube videos, what we see on Twitch channels, what we see in Spectrum conversations. So it's one of the great advantages that we have of having a live environment in the middle of our development. We don't have to do tons of internal focus testing to figure out what that number is. We can start a place and let you guys tell us what that number should be in many cases.

One thing to add about the max number of the party: the system is designed to hold, I'm not saying unlimited, but a potentially unlimited number of players in the group.

But there's a lot of unknowns in that. The amount of data that the party needs to keep track of, of each other's members, having that be unbounded is potentially problematic. So eight felt safe. Let's not deal with those problems just yet. We have so many other problems.

Yeah, many, many problems. News to me, I thought eight was coming from the old party system. It is coming from the old party system. That's what's really interesting, maybe for people interested in a more technical aspect of what we're working on. To deliver what we wanted to deliver for 3.2 with new UI for the party system and various new features, there were a couple of critical features that were locked behind the old party system that we could not just redo. So the biggest thing is getting into the same server as your friends from the main menu is handled by our back end. Guys in Austin are writing it. The General Instance Manager is this big piece of code which gets people into servers. The GIM. If this has been talked about before on RTV, it's the GIM. And so we need this to get people into the same servers. And we talked to the guys in Austin, like, hey, we're redoing partying. We want to get people into the same server. What do we do? We need your help. And basically they're jam-packed with tons of work right now. They could not separate out the party aspect from the GIM that we needed right now. To bring it full circle, the thing that's interesting, technically speaking, is the old parties are not fully deprecated right now. A new party also has an old party, and they're basically functioning in parallel. So all the old UI still works. You could bring up F11. You could still do that, because when we make a new party for you, we're also making an old party behind the scenes that you don't have to worry about, so that you could get into the same server as your friends. So they're both in parallel.

And that's just because the feature teams don't always work in parallel. You guys have hit this part, but our platform team in Austin haven't been able to...

Yeah, they're scheduled out up the wazoo. So next quarter, I think they're trying to separate some of these features out of the GIM. But currently, that's where the eight comes from, I believe: because the old party's at eight. So we need to say, all right, well, we're keeping parity with the old party system for now.

It is redundant. I mean, explicitly, that's a redundancy. MobiGlass is the Spectrum integration side of it. It's meant to be where you do any management of your channels, management of your contacts. All the stuff that used to be the F11, hold, right, alt, F, tab, all of that fun interaction is all trying to be folded into mobiGlass, for one because that makes it discoverable to new players. If you know how to access mobiGlass, then you can just find this, as opposed to needing to know what the interaction is to turn on or off your visor chat. Additionally, when we start doing more stuff about the channels that you can have, including these chat lobbies that are on Spectrum, you'll be able to select which of those things will be displayed on your visor and which of those things you are chatting to, or that you're active on, when you do the shortcut chat. But you're not going to get that level of configurability on the visor, because the visor is explicitly built to not be interactive in that way.

Minimalistic. It's kind of like the mobiGlass is your iPhone and the visor HUD is your Apple Watch. You get all your communications on your phone, your web browsing, your emails, your text messaging, and then you set up which ones actually buzz you on your watch, where it's easier to see.

I think I saw a bug that's currently being throttled by streaming, that if you get too far away, it'll just stop updating your information. I don't know if it's a bug. I just saw that was a thing.

So there's a problem: when the entity goes outside of a certain range, it stops updating. And since the marker is also an entity, it is getting affected by it. We are planning to fix it, but I'm not entirely sure if we can get this out in 3.2.

We're deciding if we're planning to fix it.

Well, I also have to imagine there are some performance considerations too, because sometimes that culling, the thing that you refer to as a bug and you say is not a bug, might actually help us in performance. If we don't have to update people from eight different locations around the Crusader system, that could be a benefit, especially as server populations begin to expand past 50, and now you've got everybody sending constant updates. It's not a bug, it's an emergent behavior. So it's a thing that needs continuing investigation. We need to decide whether that's something we even want to address, because, like anything, a big part of bind culling and object container streaming and all that stuff is about limiting the information that we send halfway across the galaxy for no reason.

In the future, we can decide whether we want to manage this design-wise, or technically by updating the position.

We just tell design what they get and they're happy about it.

Not that I know of. There's certainly nothing that I have seen on my radar, although part of that is just how much is focused on getting 3.2 stable and working, so that hasn't been a focus. The bigger thing was making it so that if you met somebody in chat, if you met somebody in the world, you should be able to group up with them. We added it into the interaction. I think Ken did that as well. No, Chad did that. Chad did that, and I thought it was you because he needed your code to make it work, if I recall, because you two had sort of mutually blocked...

Yeah, we were mutually blocking each other. He needed my code, I needed his code to test.

Now, I do want to add that when you say it's not on our radar...

It's not on my radar. Sorry.

It's not to say that the feature has been ruled out in any way, shape or form. It means that US Feature Team One has not been tasked with doing a looking-for-group system. That's all that means.

I'm going to take this one actually and say that we covered this two or three weeks ago with Kirk Tomei and Mark Abent on our scanning-themed RTV. This is not a tier zero implementation. You won't see this in 3.2, but yes, the intention is to use the group system in conjunction with the scanning system to send telemetry from other ships out.

Yeah, I think I saw that question scrolling by, and I think that it mentioned something about being able to see who another ship has targeted. That would also begin to interact with the component system, and which items you have would determine that behavior. Groups would also be a part of enabling that, and not having authority over how that behaves.

Exactly. You might have a cheap targeting system that works fine for yourself, but isn't designed for a group interlink. But you use a component, subcomponent to improve it, to do multi-ship kind of stuff. But yes, the intention is yes.

Yeah, but those sorts of features sort of hinge into more like fleet sharing, which was waiting on orgs and was also just kind of complicated to start to think about at this point. I think that we're open to it working that way, but it certainly doesn't support that yet.

It's not a tier zero thing. Also worth mentioning that when you see free-floating cargo, when a ship blows up or something like that, nobody owns that. That's free game. But if it's locked in the grid, then yeah, it's persistently owned by that ship, which is persistently owned by the person who owns that ship.

But that at least means, if I understand correctly, that if I and my group of friends manually truck in a bunch of those boxes, they will be owned by the ship that we put them in.

Yes, which you have the keys to, basically. Almost, yeah. The kiosks are a bit of a different story. Currently, you can't access ships not owned by you through a commodity kiosk.

That's why it's part of the whole question about fleet sharing: whether or not you have access to that ship outside, in those kiosks.

So we're all in a party. You can carry a box off a ship that Ken owns, but you can't go to a kiosk and then sell that and have it disappear from the...

Well, if it's something that I've picked up and put into my own ship, I can certainly sell it, because I own it now. But I can't access his ship from the drop-down in the commodity kiosk. Certainly, like Calix said, there are broader questions of what is a fleet in the future, so maybe you could say, all right, now this guy can actually access my ship from this terminal, but currently not in tier zero.

Okay, so the broader answer to this question is with regard to how community and people interact. The two biggest touchstones for me personally with regard to multiplayer interaction are Jedi Outcast and City of Heroes, both of which I think did an incredible job of building culture into their systems. The way that people use those mechanics just felt drastically different than a lot of the games that were coming out that had similar goals, similar stated systems. I just felt like you really got a lot more willingness for players to interact with each other in a variety of ways: sometimes positive, sometimes negative, sometimes just recognition was a thing that could happen. In terms of designing multiplayer features at all, those tend to be my touchstones. Of course, when you're thinking about chat and group systems, looking at MMOs, looking at WoW and Elder Scrolls Online and other games that have taken a variety of approaches, and trying to see which things, particularly with things like WoW, which has so much legacy and is also updating and looking at all those things. One of the things I think we were looking at for a minute was The Division, in terms of how they presented the information, more so than the system itself, but how you let players just know what's going on. A myriad of influences.

Okay, so when the party leader disconnects, he'll be kicked out of the party, and the party leader will be transferred to the next player.

Okay, so the party leader doesn't get five minutes?

They also get five minutes.

So when the party leader disconnects, he doesn't get kicked out of the group. Is he still the leader in those five minutes?

No, he'll be kicked out of the group.

No, no, no. Those five minutes when he's not yet kicked out: is he still the leader?

It's 12 noon, and I'm the party leader, and I get disconnected. Up until 12:05, am I still in the party?

Yes.

Okay, so I'm not removed from the group for those five minutes?

No.

For those five minutes, am I still the party leader?

Yes.

Even though I'm not online?

Yes. As long as you're in the party, you preserve your role. When you get kicked out of your party, that's a different story.

So for those five minutes, you'll have a party that can't actually invite anybody else to the party?

Technically, yes.