Star Citizen Live: The Bot Whisperer

So I'm Francesco Roccucci, as you said. I'm the AI director in Cloud Imperium Games. I started in the company in 2015. It was February. So it's quite a while I'm here. And I'm basically responsible for all the high-fidelity AI. So everything that you see, how they behave, what they do, what they should do, which systems do we use on the servers. This is what I'm responsible for, with my teams. Right now, the AI team is structured into three major teams. I mean, as people can also see from the monthly reports, we are kind of four now. We have a little bit of extra help from the vehicle team. So basically, we have the AI Tech team, the AI Feature team, the AI Content team, and the vehicle AI team, where there are some people in the vehicle team that start to do a bit of AI work. Diego. And so the AI Tech team basically is supposed to empower the other teams with technology to fulfill the features that the projects need. The AI Feature team is supposed to take this technology and apply it to multiple features that are requested by the requirements of the different games, Star Citizen and Squadron. And then the content team is mostly made of designers and animators. So what it is meant to do is to take all these technologies and features and build a lot of content. So yeah, these are all the people that either report directly to me or I support and oversee and try to help as much as possible.

So everybody's having fun with this whiteboard because I love writing on the whiteboard. So there is a little bit of stuff that I used to explain things. So we have this room now and lots of people come and we talk about stuff. I like to draw to help myself. So even when we do meetings right now, I try to move the board next to the camera and then I draw stuff. So there is some usable stuff, like usable channel definition. We are trying to simplify a little bit some of the verbs we use in the actions that AI can perform in the world so that we can unify a little bit better and make a little bit more consistent some of the things that we have. There's some high-level explanation of how Subsumption data works and how Subsumption low-level core logic works, how we essentially run time data and static data on the different behaviors and mission logic. And then on the right side, there are some of the actions of the spaceships that we want to do, some of the setup of the usables, like counters, chairs. Yeah, a little bit of everything.

So basically, when I joined the company, Tony Zurovec had this speech for this architecture of AI where there is a little bit of separation between what we want to do at high fidelity, what we want to do in a simulation state, and so on. And Subsumption is the name he gave to this architecture. What it actually turns out to be in reality is a combination of stuff. When we say Subsumption, I think it's always very broad, because it contains both something that in regular AI development you would call, for example, behavior trees, or activities or behaviors from the actor perspective, the AI agents. Then we also include stuff like mission logic. I think we can talk about what it is at an AI level and an architecture level and what it is on the implementation side. So I think what Subsumption wants to do is model the world in a way in which it becomes believable and realistic. How you do that is with a combination of things, because in reality, when you do game development especially, the AI is a big chunk of the experience that you have, but also it's not something you can see in isolation. AI is the output of the work that all the teams do, and there is a really large multidisciplinary effort into making AI look good. People sometimes think it's a bit of magic, there's a behavior running, and then that's it. But AI is, first of all, a lot of animations, because animation is the way in which we convey what actually is happening behind the scenes. The same is voice, what they say. In reality, the smartness of people, and why we consider ourselves smart, is because we can express our thoughts. And how do we do that? With language, which is a construct that we make to express feelings and ideas. And AI, in a way, needs to model this concept, but also make sure that whoever experiences it understands what they're doing. Because my classic example is, you might have combat AI that is great, and it's moving behind covers. You don't even see it. It pops up behind you, and it kills you. The feeling you have is that they're cheating, even if they're not cheating, because it's not fun to play against it. So I think we always have to balance between having the right tools to describe what the AI does, what the world does, what the AI is supposed to do, and then making sure that what we describe translates into something that the players can actually perceive as smart, but also fun and also understandable. So Subsumption is basically the architecture that tries to achieve this, from multiple directions, and it tries to expose this sort of language to multiple departments in a way in which they can really perform their duties, basically.

Yeah, I think our game is particularly unique on some of these things, for different reasons. One is, I think in the last weeks there's been a lot of discussion in the industry about games in development and how things actually look behind the scenes of a game. I think we have this special position where we actually show a lot of the game that is still in development, because we are still in an alpha stage. What that means is that usually in development, you pick your battles based on where you want to be, not just where you are. So right now, for example, the things you're going to juggle are the time that you have and the resources that you have, and you need to try to balance which type of task you want to take. So let's say we want to have combat AI. You need to have a specific set of features there and a specific set of functionalities for designers, for example, to balance the game. Balancing means how accurate they are, how often they should shoot, which type of tactics they should play, where they should be, and so on. Now that one, as you say, needs to use a specific set of CPU cycles to do some of this calculation. And you need to distribute this calculation, because the more you're doing in one frame, the more the frame costs. You have a much quicker response time from the AI because everything is done in that server frame. But if the frame rate goes down, then it means you have more latency on how the player can react to that, and so on.

Now, in our multiplayer world, of course, we have two parts: you want to have a very high frame rate on the clients, and you want to have a high frame rate on the server as well, because the player might see the world at 60 frames per second, and then the server might run at 3 frames per second for different reasons, or 10 frames per second, or 15 frames per second. You have a really wide range of CPU usage on the server. So, for example, for Siege of Orison, I think one big focus for us was trying to optimize that usage overall, not just on the AI, because using a lot of CPU cycles for anything would impact the AI, but not only. It might impact the elevator that comes, it might impact physics calculation, anything pretty much.

On the AI side, in previous companies I worked at, the games I worked on were very much single-player games. Usually you have a very strong control on how many characters you want to enable. So maybe you have 16, 20 enemies active at the same time, and those use certain things. In Siege of Orison, we had peaks of 2,000. And 2,000 NPCs are not that simple, 2,000 NPCs that might fight the player, not just background NPCs or stuff like this. Now, can you be smarter on that side? Absolutely. Is it something we want to support long run? That's sometimes the question we need to answer. Are we expecting to have one server with 5,000 NPCs active at the same time? As you mentioned, we are working towards Server Meshing. So then the decision comes: do we want to invest time right now to make sure that we can run 5,000 NPCs on a server? Or are we expecting that we have 1,000 NPCs on each server at maximum, eventually with a lot of servers? 500 NPCs? You need to decide those types of budgets. Are we expecting to have a population manager that is smart and decides there should be 20 NPCs here and only one there because nobody's around there? Should they come out of a spawn closet? These are all pieces that are coming together right now. But when you don't have them, sometimes you either need to say, well, I accept that unfortunately we are not there yet with the level of experience, or no, I want to invest two months trying to be smart.

One good thing that we discovered was the vision calculation. Because on a really high-performance server, you can distribute vision calculation in different ways. You can consider either a frequency of update, meaning you want to update somebody every second, or half a second if it's close, and a different frequency if they are far. Or in the amount of ticks, you can decide. So we had something exposed from our core systems that could say, I want to update every 30 updates. But 30 updates at three frames per second is different than 30 updates at 30 frames per second. So we switched a lot to frequency. But even in that case, frequency means that if you want to do two updates every second for 100 NPCs that are around you, it's a lot of updates in that frame. That means that if you already have a low frame rate, it would be just lower and slower. So I think it's a lot of balancing there.

You said 2,000 NPCs that spawned throughout the entire server. In the first versions of Siege of Orison that I saw, the event alone was spawning 700 to 800 NPCs. And that was one of the great things about that event. It wasn't just designed to create new content for the players. It was designed to push on all the seams of Star Citizen and to see where we can get it. And we got the 100-player servers because of the research that was necessary from pushing on that stuff. We got all these other improvements. But I think in the end, the version that went live still spawns 400 or so NPCs during the course of the entire event.

But in the meantime, people can also be somewhere else, where they activate other locations, and there are other NPCs or other missions that can still run on the same server.

But it's also, I think, for us, the enjoyable part of our job is also that pretty much you could continue to push it forever. You might never be happy with the state in which you are. I think, for example, perception, we could work on making it faster for a really long time. So I think it's iteration. For example, I'm really happy already with the stuff that went into Siege of Orison. That doesn't mean, as you said, that I consider it done. I consider it far from done. But it was a really good and nice step towards a lot of improvements that we put in. And I think you need to be also proud of the iterations. Usually people would see the final game, and now they see a lot of these iterations. If you look at them one right after the other, sometimes they don't feel like a lot, but I think it's also great when you see, even from the community, some comparison of how it was in 1.5 to 3.8, 3.17. And I think there have been really a lot of jumps in the game.

Me and Steve are great, because I think we also used to work together. I mean, on Crysis we worked together already. Animation is a fundamental part. Animation and communication, dialogues, those are what really make AI stand out. For me, there are a lot of examples of good AI. One classic one is, of course, F.E.A.R., where if you think about how they implemented this, the technology itself doesn't have to be rocket science sometimes to give you the feeling that those things are very smart. There was a lot of really smart crafting of the environment, smart setups by the level designers. So this is why I was saying the AI is the product of the collaboration of lots of departments. To make it look good and make it look believable, what we work on a lot with Steve, for example, is that he is the person in charge of all this look. So whenever we do previews, we always work on iterations, white box phases and keyframe animation, where what we work on a lot is trying to iterate through the gameplay, because one thing is looking good, and another thing is looking good for the gameplay, because we're not making a movie. So sometimes you might create an animation that looks perfect, but then when the player plays in a certain way, you don't even see it, or it's not reacting correctly, as you say. You cannot blend correctly, or you cannot transition from one place to another. Reactions are a really important scenario where you need to have a balance between the amount of animation you want to create to get the believability, but also structuring them in a way in which it's easier to transition from one to another, so that the categories that you want to play make sense for what you're trying to communicate to the player, and use the different types of techniques that we have.

So basically, the way I grew my skills in my career is that the behavior is critical; it's the central part for the AI to describe the decision flow. Then the decision flow needs to go into making sure that it shows what the animation director wants to show. And this is where I think it always seems so complicated when we talk about stuff, but really, you're trying to solve a complex problem. The complexity needs to be somewhere. And I think the critical bit is making sure that the complex parts are distributed over the ownership of different departments. So for example, the animation director describes the flow, describes the animation state machine that you want to create, how to transition from one state into another, what is allowed to be done. And then the decision flow needs to explain what the AI wants to do, without tying those two things together too much, because you want to have these things flowing nicely. And yeah, so me and Steve work a lot together. He's fantastic. His experience is absolutely great for us, all the things we always discuss and always want to push. Hi, Steve.

So for me, I can say I'm super lucky, because I always dreamt of doing this, and eventually I've been lucky enough to manage to get it. Of course, it's not just luck. It's a lot of effort you need to put in, and a lot of energy, blood and tears, but also in life you always need to be lucky to find yourself in the right position at the right moment. But basically, I think it was when my dad bought a Commodore 64. Well, I think it started a little bit earlier. I was at my cousin's place, and he had a Videopac, a Philips, very popular in Italy at that time, a little console. And I still remember it. I was probably four. But I still remember nowadays that feeling of looking at the screen and having this joystick that was moving stuff on the screen, and I was like, wow, this is fantastic. And then my cousin got a Commodore 64, I got a Commodore 64, and I started to program, and I just started to mimic him pretty much, because I loved to do that. And yeah, that's where I started to program. I was probably seven. And at that moment, in Italy especially, it was not so much about artificial intelligence per se. There were people talking about it, but there were no computer science studies. It was electronic engineering. So I was always saying, I want to study to become an electronic engineer and do video games. And that's where I started.

I was quite a nerd. My high school was a math-based high school. I started to do computer science engineering. In Italy you have a bit of a difference between pure computer science, which is part of the sciences, where you have mathematics, physics, and then you have engineering informatics, which is the computer science part of engineering. So I did that one, because there was more specialization in artificial intelligence. That is what I wanted to do at the time. And I had the opportunity, when I started to do my master's thesis in Rome, at La Sapienza, to have really good mentors. One is also here working with us, Andrea. They taught me a lot about coding, about C++, and in that lab we were doing a lot of robotics as well. And with our professor, it was really exciting. There were two main classes at that time, also with Andrea; he was the assistant of the teacher at that time.

You and Andrea go all the way back to high school?

From university. It's quite a long time. And I think he has a super strong background in lots of stuff. This is why I'm super happy to have him on board, because he has skills and knowledge about AI, not just about what we do, but even things that we might want to do in the future, and more research topics as well. But yeah, basically we did a lot of classes about learning, about vision. We applied it to robotics and stuff like this. And once I graduated, I started to apply to lots of video game companies. I was hoping to start with an internship or something like this. And then I got an offer in Rome first, from a company that was making software for satellites. So I started there, since I didn't get a lot of answers from video game companies. I was like, okay, this is still pretty interesting. C++ code, so it was something that I still wanted to do. And then after my first week there, I basically got an offer for an interview with EA for an internship in Germany, a country that I pretty much didn't know anything about at that time. But my wife, at that time girlfriend, was studying in the US for six months in New York City, doing her thesis at Columbia University. And at that time I was like, it seems like a good opportunity. We're far anyway, I can do six months as an intern in Germany, and then we both come back to Italy and I find a game company in Italy. And I was working at EA Phenomic. I was an intern on this game called BattleForge, which was an RTS game based on cards. It was one of the first EA games based on trading and collecting cards, but the cards were used to summon units in an RTS world, and then you would use them as in an actual real-time strategy game. And after that, I basically moved to Crytek. I got an offer from Crytek. I started to work for engine licensing, so I was hired as an engineer for engine licensing. But I think the good thing there was also that the team was not super big, so I had to learn a lot of the stuff for the engine in general, and I had the opportunity to work with a lot of really, really talented people. Marco has been one of my major mentors at Crytek as well. And I had the opportunity to learn a lot of stuff, not just about AI. I recognize that a big chunk of my knowledge comes also from learning about other systems, because I think having the larger overview of how things work is really powerful sometimes. And at the beginning, it was like, but I want to do this other thing, and I need to fix all this other stuff. But it was really powerful in terms of knowledge. And this, I think, is very classic in a career, where you start as a junior or as an intern, and sometimes you're like, oh, but I need to really fix this bug. Similar to when you study, and you say, why do I need to study that subject? When is this ever going to be useful? And then you say, oh, that's where it was going to be useful.

I always wanted to do AI, basically, because my background outside gaming is that I always played role-playing games. And for me, it's a lot about acting. It's a lot like, well, we are in this world, so it's a lot about telling a story, and a role-playing game is a lot about playing a story or telling a story, depending on whether you are a player or the master, the dungeon master. I mean, I played a lot of Dungeons & Dragons. I love a lot of the fantasy settings. I did LARP. A lot of nerd stuff that I loved. And these are my fondest memories. Actually, this is the funny connection with Germany: the first role-playing game I played was The Dark Eye. That is a very popular German game, because it's a bit simpler. D&D in Italy was getting a bit more popular at that time. And I was probably nine, 10, I was in elementary school, with my best friends, and my best friends also had a really nice shared passion for those things. So I think AI has always been related for me in a way in which, for video games, it is the closest to the tools that you have to tell a story and to make people escape reality into a world that tells the story that they like. And this is why I've always been fascinated by that. I've always been attracted by that. It's the way that I have of using my skills to tell stories to people, to make people live in a different world.

I think at that time there was the search for some new challenge for me. During Crysis 3 we had a really nice group; we were four AI programmers on Crysis 3. And then after that, I really wanted to try something different. And I think CIG was a really good place, because first of all, there was the common technology, the base technology that was in use at the time. But also I think the project is just way over the top on almost everything. There's a lot of everything. There is a search for the best possible realism that you can achieve, and so on. That vision was really large. So I think for me it was just a really good place to continue to grow my skills, because I think you need to always challenge yourself. Here, I feel like you never challenge yourself enough; there's always more space to challenge yourself. So I think it's a really good place where I always feel very satisfied with how much I can learn and how much I can improve. And there is space where I can improve and get better.

So when I joined, a lot of the AI was taken care of through the middleware that we were using at that time; we were using Kythera as a middleware. But then we moved into deciding that we wanted to have more in-house development. So yes, then I built the team pretty much from scratch, where Marius and Andrea have been the two first team members on the tech side. And Shanine was our producer since pretty much the beginning. And then the team grew from there. So we started with three people pretty much. And we started to work a lot closely with Tony, when we started to move a lot more development internally. He really pushed for Subsumption at that time. And then me and Tony pretty much started to crack on implementing all these things, where he made a lot of the external tooling for the Subsumption editing, this C# tool that we used for a lot of stuff, and I basically ran all the runtime code, all the low-level code, how the graph gets executed, how all the tasks run, and so on, together also with Marius and Andrea. Andrea, with his background, took care of a lot of the ship stuff, especially the 3D, this really unique approach to 3D pathfinding and 3D movement that Andrea has worked on. Marius has supported me on all the navigation stuff since year one, pretty much. And I think that has been the foundation of the team.

And right now, I think we are super lucky, because the people we have on board are fantastic. We have some new juniors that started a few months ago. They're doing super awesome. They're really fantastic. I'm really excited, because I think people will see more and more improvements, because of how the team has been growing and the type of culture we are trying to push, which is a culture where everybody helps each other, especially, and everybody tries to share as much as possible the knowledge that they have. We still try to keep people responsible for specific areas, because engineers love to have their own expertise and grow in a specific way, because otherwise you can never be super good at something. But all our stuff is very shared. We push for knowledge sharing, but also sharing the usage of the systems, so that the more you use it, the more people feel responsible to work on common stuff. So we built it from pretty much the base, from zero, to right now: me, Marius, Andrea. We have two tools programmers on the core team, like Michael Madsen. We have Fadi, who just joined us as an intern tools programmer. We have Alex. We have Daniel in the UK as well, who just joined a few months ago. It's fantastic. We have Jake, we have Jacob, Wout, we have Andrew. They're all fantastic programmers. I hope I didn't forget anybody.

I forgot one person. It's Chris, who also joined us recently. It's hard to find people to grow a team in a way that's not disruptive, for different reasons. Not only because you want to grow in terms of skill; you want to give people enough of your time to grow them into their roles, but also it needs to fit from a personality perspective. And I think those guys are fantastic because they fit both ways. They fit on skills, but they fit also on personality. They are super motivated. They're super excited. They're bringing so much to the table, even in terms of new ideas and new approaches.

Absolutely. It's definitely not the way I want it to be.

I have more insight on the low-level technical things. We spend a lot of time on this, making sure of some of the things, because AI doesn't grow in a linear way. It's the classic 80%: you do 80%, and then the last 20% takes 80% of the time. But I think we are still at the point where not everything we do is actually visible there. Not everything is yet live. Not everything is yet there, because maybe you have some behaviors that require some setup, and that setup is not yet there. Or maybe there are some things that we're doing for Squadron that are not yet in the PU. There are lots of those improvements. Or maybe there are things that are related to Server Meshing. I think AI is, in a way, a little bit the unlucky child of development, because it doesn't come together until the end, in a way. So whatever game you develop, unless it's a sequel of something, you have a very rough experience during the development, because of animations missing, systems missing, and so on. We are in the middle, where we have a little bit of animation missing, a little bit of system missing, a bit of optimization missing, and you experience all of this. So the way I see it, for example, we still have a lot of behaviors in the PU running that we want to replace, and it depends on the resources you have allocated to drive that or something else. So I'm personally seeing a lot of improvements, and I'm not necessarily frustrated, but also a little bit sad that people still need to experience some of the bugs and the problems that we have. I'm not happy about that, but sometimes you cannot immediately see why you need to live with something. I think people will be happy anyway when this is out. And I think there is a little bit of pain that you need to endure. Now, of course, there can be a discussion: is this too long? Should it be less? But this is hard to say in the abstract. I'm coming from a scientific background. For me, everything is based on data. If you don't have the data, it's really hard to decide: is this a good decision or a bad decision? You need to always balance it. But for me, of course, I would like everything people experience to be at least at the level it is when the servers are fresh and you have a good experience, because I think the majority of players are also starting to enjoy that type of experience, despite a lot of things still missing. For example, once we released the reinforcements, you see a little bit of the things that we are doing in this recent view, and yes, you have to iterate by fixing, as any development does. The fortune is that when you release in our environment, you don't have those six, eight months of only bug fixing that development usually has on something that is locked, because we are really impacted by a lot of the changes that happen. Let's say persistent streaming comes in, and that one in a way has another impact. And then do you want to fix everything before you release, or do we have more of an iterative process? These are larger decisions that we have to take so that people can see the progress of the things we are doing. So yeah, it's a complicated question. On specific stuff, there's also a lot of coordination between teams. What I'm always joking about is that if people perceive it as an AI bug, then it's our responsibility 100% to make sure that it's fixed. The reality is that sometimes you have dependencies that you need to sort out to get some stuff resolved. But this is why I like AI so much, because I really like to have this overview of things that end up being AI. Again, I'm the first one to say that it's definitely not at the point where I'm yet proud of what we have there. But I'm proud of what we are doing. And I know that what we are doing is the right thing, the right direction. And my goal, of course, is to make people experience these types of things as soon as possible.

I think the experience of Star Citizen will be very unique, not just on the AI side, but in all the systems. Star Citizen and Squadron 42 in general. This is why I'm here, because my take on the company and on the project is that those projects will be fantastic to play. And not only fantastic, but they will really give you some experiences that you will not be able to experience somewhere else. Fantastic doesn't necessarily mean perfect. Perfection doesn't exist. But it means that for a lot of people this will be a unique experience. For me, the goal is to have the similar experience to when I was a child playing games, where it was like, I'm in a different place. And we have a lot of things in the pipeline already that will be released slowly into the PU from the work we are doing, and it doesn't have to wait until all of it is finished. We are already in the process; in the next updates, there will be more and more of the stuff we are working on. And hopefully we will do some other shows where we can go more into detail. The good thing here for us is that it's never all or nothing. It's going to be: you get this one, you get this one, you get this one, slowly while we do it. There are a lot of things coming.