TL;DRThe friend system starts simply, with website contacts populating the lobby, and will iterate alongside the game, while the social module brings initial persistence of purchased items that players can reset.
JE
John ErskineStudio Director, Cloud Imperium Games Austin
Sure. So in December when we launched the lobby system and we launched the contact system on the website, we started by populating the lobby system with your website contacts. On the web, there's not a great interface to be able to respond to a friend request in the affirmative without either sending an email or doing something like that. So we have kind of a Twitter-esque style where you follow somebody and that makes them a contact. And so as we have more robust interactions in the game, where it makes sense that you initiate a friend request and then they're connected to their client and they get a pop-up and they can accept it, or they have a mailbox or something like that, as this moves more into the game, we can follow some of that on the web. Maybe we'll have a mailbox on the website as well or some other things, but we're sort of starting with the simplest iteration that gave us the functionality we wanted in the lobby system in December, and then we'll just continue to iterate on that as we move forward, lockstep with the game.
Another thing just to add in relation to some of the stuff we've been talking about is basically the fact that starting with the social module, we'll have the initial phases of persistence, and this is another one where each iteration of the Persistent Universe module throughout this year will wind up adding more and more functionality. And what we're aiming to do is basically give you the capability to pull over everything that you've purchased on the website and actually store it for the first time over in our Persistent Universe database. Now since the game hasn't actually launched, we don't really want that Hornet that you pulled down from the website, that you will eventually be able to take out into space before we actually officially launch whatever you want to call the first full iteration of the Persistent Universe module, we don't want that ship to basically be able to be blown apart and you lose it, given the fact that some aspects of the game will still be unbalanced, etc. And so what we're going to wind up doing is adopting a middle ground that will probably persist for the next eight or nine or 10 months. And what it will effectively do is pull down everything that you purchased from the website, store it in the Persistent Universe database, and you will be able to log off, log back on, and whatever changes you've made to your ship, whatever damage you've incurred, in the relatively near future that should start to persist until you wind up actively telling the system, probably via pressing a button either on the website or within the game, to reset your status, at which point it will go ahead and clear out whatever the current version of your inventory is and re-pull all of that stuff down. And so what you're going to have for the short term is kind of the best of both worlds, where you'll have all of your equipment, you can go out, lose it, get it broken, et cetera, and then start right back over. And this will wind up being invaluable as we go through testing through this year. And we've actually got things like mission status, ship damage levels, inventory loadouts, all sorts of things that we actually will need to do a lot of testing on.
So these are all basic building blocks of the game at this point. We're talking about persistence and data architecture and server configuration and writing of servers. This is all stuff that we have to build to put various aspects of the game, that in some cases already work and in some cases have to be built from scratch, together to be a big consistent and persistent universe.
TL;DRFriends' online status is fine, but enemies' whereabouts would stay in-fiction (spotting, tips, paid information jobs) rather than a tracker, while instancing merges players by party and friends only in crowded areas to hinder griefing.
Well, I'm not so sure about... Definitely when you go into instances, it's not like you only show up with your friends. Basically, part of the rule set is who are your antagonists, who are your friends, and there would actually be slots reserved for those groups, right? So there's slots reserved for your friends, and there's also slots reserved for your enemies. So if you happen to be flying around in space by this asteroid field, and a group of, I don't know, whatever the infamous pirate group is that you're locked in a deadly battle with, is flying around there too, they would spawn in, because it would be known, with your character, your organization, that would be a known antagonist for you, and they would be part of who would be in it. In terms of knowing where they are, that would be kind of the way: either, like I was saying, you find a place and they spawn in, or the same would probably happen on the planet side. I mean, you just want to know if they're online or something, even if you're not close to them?
No, no, no. I guess what I mean is, knowing when your friends are online, that's fine. Friends is one thing, enemies is another. Having it out of fiction, knowing when your enemies are online, is not something that I would say we would do. I would say that when it's your enemies, that's all in fiction, as in you're in the right location, or you're seeing them there, or you've gone to where you know they are, or someone's tipped you off and said, oh, I've seen the dreaded pirate group over by this asteroid, and so you go, okay, well, here, I've set my nav destination, I'm going to quantum drive over there. And then you would go and see them. That would all be in fiction. So I don't know if that's answered the question.
This also comes down to the fact that space is really big. And if we're only providing the information about a contact, like if you're using your contact list to track your enemies, and all we tell you is that they're in Stanton, that's a lot of surface area to cover.
Well, I think the other thing is that there are specific missions and jobs that we're planning for in the Persistent Universe. So one thing could be, okay, I'm paying money, I'm searching for this person, so I will pay a thousand credits or whatever for good data, not made-up data. And then people spot that person and they send the information to you and say, oh, we've seen him in this location. And then you go there. And so that is actually adding gameplay to the functionality of that.
But that's also, like you said, not magically precise. In other words, if someone sees them at a location and then they take off and they have not been seen in the last five minutes, you have no good idea where they're at. Another thing, just to clarify, it seemed like there was a little bit of confusion on the instancing, what I was talking about in regards to shunting players over to common servers based upon their party affiliation, their friends, their skill sets. That's purely in regards to areas that have too many players. In other words, it's an overflow mechanism. If you go to a distant asteroid field and there's two other players there, then the server that's maintaining those guys has absolutely no problem basically merging you all into the same instance. It's only when you start getting a picture around Terra Prime. There could be 10,000 players flying around in space. You're going to have dozens and dozens and dozens of servers. Same thing for when you're actually down on Terra Prime, the city. There could be 50 instances of that city. So which one do you actually go into when you actually land at your hangar? Well, it would prioritize that and go, well, you probably want to go into the instance where your party members are. And if you don't have any party members that are actually already on Terra Prime, then it'll look and go, well, you probably want to be merged in with your friends so that you can actually walk around, interact, say hi to your friends, and so on and so forth.
So this has a benefit, right? And the benefit to players is that it makes it hard to grief another player. And the way that we are engineering it is such that you can still play with your friends whenever you want to, so that that's not hard to do. The thing we don't want to do is make it hard to play with your friends, and the thing we do want to do is make it hard to grief, and consistently grief over and over and over.
And that is the precise reason why, earlier on one of the previous panels, we were talking about how the mechanism that we're using right now to initially populate your friends list is not at all related to what we're going to be doing in the near future, because right now I can form a link to you regardless of whether you want it. And that goes into your friends list right now, and we definitely do want you to know where your friends are. And so that's the whole reason why we're going to wind up tweaking that whole system and going to the proper 'I invite you to be my friend, you have to formally accept'. And at the point you do that, then we get the automatic link between both of us.
Part of it's from game design and how the game feels. Part of it's performance-wise, since we are still fairly early in the project, so we haven't done all the optimization we're going to to maximize how many we can fit on one game server. Then there's going to also be how many we can fit on one machine, how many game matches we can fit on one machine at a time.
Your client connects to our universe services, just like it actually does a little of this already with the hangar. And when you enter your ship and go select what you want your match to be, then it will connect you to a game server that the matchmaking service chooses that's available, when it talks to an instance manager that tracks all the game server instances running. And then your client then redirects its CryNetwork, its gameplay connection, to that game server. And then the match starts up.
Not in the first release, but definitely planned. We want to have the machines in basically data centers in all our main different regions, so you will get connected to ones that are closer to you with lower ping times.
Even before we get to there, as we test internally and we increase the number of players, we also use a load testing system that we've developed that runs the game client but in a headless mode without any graphics. So we can put all these artificial players in to help us make sure that when we do release, it doesn't crash and burn. Then we start ramping up the number of people we're going to have in. And we'll keep an eye on it as it goes up to make sure everything's okay, and as we find problems we'll fix them and then continue ramping up.
It's very dynamic in that it will adjust to situations that change, such as in the demo videos that you saw where the crates fell and the characters moving actually changed where they were moving and changed where they walked to, used different things for cover.
So it'll give itself a new hierarchy all the time based on what's going on in the scene. And that's also what's going on in space as well. Like I saw the bit where they'll avoid each other. There'll be a collision situation that they'll be able to avoid.
In the future, they'll see the character-based AI with characters on planetside and such moving around. But then they'll also get to see it in the first-person shooter aspects, like with boarding actions and such, where you have squad-based AI and multiple characters in combat and reacting in a realistic manner during the shipboarding.
We even have it where as the economy of a planet changes, the characters you might see on the planet and the different jobs they're doing will change based on the changes to that economy. So then you'll see you might have a different AI controlling that character because they have a completely different profession or the economy of the planet is going up or down.
Yeah, it was time. We had the time available on the engineering side to really fix these last few issues that we thought we really needed to before releasing. We have our high-def dev kit prototype so that we can see it at higher resolution.
TL;DRThe patch adds client-side persistence as a first step: changes to the ship or hangar are saved locally, with more use planned and a step toward full persistence.
It's the first part of persistence overall in the game. On the game engine part, we've added basically the interface that the game engine will use for persisting things when we have the persistent universe later. And it will interface with the rest of the universe cluster. But for now, we actually have it running on the client. Paul Reindell, the lead engine programmer in LA, implemented this where basically, when you change things on your ship or change things in the hangar, it will save some data locally on your system to remember where you moved the weapons or things. And we're going to make more use of this in the near future.
That's step one, right? A lot of the things people wanted to do, there's a couple of reasons. One is they want to be able to customize or make things their own, and this will allow them to do that. We've got some stuff coming up next week, which we won't talk about, that we'll be able to test this with. And we're going to need your help to test it. And then also, it is, as you said, the first step into the big persistence.
In the full game of the Persistent Universe, that persistence will move out of the client and that code will end up being used on the server instead, in the game servers. And then that code will talk between the game engine and the game code and the persistent services in the universe cluster. And they will handle the saving and loading of it. So it won't actually be on the client anymore.
Well, here you can see we actually have it running. This is what the left eye and right eye, what you would see in the Rift, and you can see here, I'll move my head, and you can see the head tracking. Right now, we're doing some camera unification to make it so the first-person camera, when you're walking around in the first-person camera, when you're in a vehicle seat, are unified, so when you look around while you're in a vehicle seat, it will work like this.
TL;DRThe team is starting to use parts of Scrum, with short cross-discipline stand-ups and Skype links to Chris across studios, combined with a larger waterfall-style plan.
We're starting to use Scrum as our development methodology. We're just starting with some pieces of it and seeing if it works well for the team and if the team likes it. It's called an agile methodology. It's to have big bang for the buck. We're starting with a stand-up where we have a cross-disciplinary group of people working on a feature. And we have a 15-minute meeting. Right now we're doing it every other day, three times a week. We try to say what we've done since the last stand-up, what we're going to do up until the next stand-up, what we're planning, and if anything's blocking us. And if we have any miscellaneous discussion other than that, we try to have it at the end. That way everybody else can leave. That helps in that if we've been heads-down coding for a day or two, it forces us to communicate, report to our peers what's been going on, and also if something's blocking someone else. Yes, Chris is very involved in the development. Using Skype is a nice and inexpensive way of having a teleconference presence, so he's part of the whole stand-up and the whole development process. Even though Chris isn't here, he is here.
See, isn't that pretty neat, guys? Literally, with our distributed development process, the ability for us to now connect digitally and see each other's faces as we develop is really important. With offices in LA, Montreal, Austin, we're on Skype every day. We really like that technology. We've got Google Hangouts. We use that a bit, too. We use YouTube, as you guys have obviously seen here. So it's very important to us. Chris is involved in all aspects, as you can see. He's in every meeting. And it's pretty cool to be able to see how that works. Regarding Agile and Scrum, we're just using bits and pieces. We're not completely that way. We use a combination of waterfall and Agile Scrum, for those of you who want to know. We like the bigger design. One of the weaknesses Agile Scrum seems to have, in some of our opinions, is that you don't aim really big. You do lots of smaller tasks to hopefully get to something big at the end, but you miss the ginormous big plan that you want to get to. So you combine the two and you create Star Citizen, baby.
Basically, making sure the technology of the game works, that we don't over-engineer, we don't under-engineer, that we can put out both the Squadron 42, the single-player and the multiplayer parts.
In three words or less. No, I'm just kidding. Basically responsible for all the technology, the project, and the studio. It's different every week. It's especially hectic right now as we plan everything and really get the project going. Could be anywhere from looking at technologies we can reuse or license, working with the programmers for what we're doing now on technical design, reviewing that and working with that. Team building. Hiring, interviewing, and I actually get to code sometimes, too.
Right now, probably planning. Getting the short term and the long term of the project planned out. We have a lot of moving parts right now. We have several people who know the CryEngine really well and the rest of us are really learning it. We are looking at the server side, and planning what to do there, technical design.