Virtuos on Co-Dev, Custom Tools, and Staying Ahead of Performance Problems

You know, even though I'm here and talking about the different tool sets that, like, Virtuous has done, my message is more, let's try to be more proactive in our approach to optimization. I try to build your own tools yourself. Even if you're you're a small developer, you're maybe just two people or ten people or or twenty, whatever the size, building something small to help you track where your game is in terms of its performance, that's already a step in the right direction. Like, it doesn't matter if you use what Virtuous has or not.

Welcome to In Development, the podcast where we dig into the real technical work behind building games and interactive worlds. I'm your host, Jay Slingren. And today, I'm joined by Marios Michelides, who leads the engineering services group at Virtuos, one of the biggest co development studios in the world. We get into what co dev really looks like today, from building custom tooling for partners to dealing with the constant push pull between artistic ambition and performance.

Mario's shares concrete examples like the million triangle elevator button problem, how their team built tools like Goliath to automate performance tracking in Unreal, and why catching issues immediately on a daily basis can save studios from those brutal end of project crunch cycles. If you're a small team or a growing studio or getting closer to shipping your first project, this one's packed with lessons on being proactive instead of reactive when it comes to optimization. And with that, let's dive into the interview.

Well, Marius, thank you so much for joining me today.

Yeah, Jace, thanks for having me.

Awesome. So, can you tell our audience a little bit about what it is that you do, what's your position right now, and and what does that mean?

Yeah, sure. So right now, I'm working at Virtuos, which is one of the largest co developers in the world. And at Virtuos, since we do co development, I'm mainly focused on running our engineering services unit. So we have a group of studios where we fall under this kind of label that we call Virtuous Labs, where most of our developers are focused on developing technology, tools, doing rendering, gameplay features, etcetera for our partners. So my responsibilities fall on understanding what kind of challenges our partners face, how we might provide some solutions to help them along the way, as well as making sure that our projects are on track, that our staff are happy, and that in general, we're able to find the success that our partners are looking for.

Yeah. Something that really surprised me when I first started understanding the co dev landscape and how that works is how much of co dev is actually tools development. And, you know, these kind of tinkering in the engine, especially if you're working with companies that have their own proprietary engines, like needing to actually get in there and make updates to those, not only for your own team to use, but also for their teams. And I I had always thought of it more of just coming in to help with, like, creative assets or finishing something up or maybe performance optimization, but it's actually much more embedded in that whole process of making these kinds of tools to help what they're doing fairly early on in the process. Does that sound accurate?

Yeah. That that sounds like, yeah, what we're seeing ourselves in the market because there's been a few things that have been changing over, would say, the the last few years. So, of course, we've had lots of proprietary engines in the past, and they themselves always have a need for more tools and tech to support the development of their game and their engine. Right?

They've kind of got, like, two stacks to do. But as more and more of these proprietary engines have, let's say, phased out as developers seem to prefer using Unreal or Unity in some cases, they also have to develop tools that they perhaps used to have in their past engines or just in general to support the types of games that they wanna make. So not all everything is always ready out of the box in those engines. Right?

And so you still have to create a tool or a tech that supports the pipelines that your developers need to adhere to for whatever project and game that they're trying to create. So, I think, as part of co developers, it's probably one of the earliest types of work that we get involved in because you can really get in there in preproduction, which is when you kind of wanna get started. And then probably during production, you can finalize these tools and and these other tech.

So when you're developing that, when you're working on that, what is your toolkit? What are the tools you're using to make these tools, I guess?

Yeah. So for sure. So there's a there's a few different facets. Right? As a co developer, we will use any technologies required by our partners.

So this could include tools such as, you know, Perforce or Blender, Houdini, Visual Studio, and and kind of anything else that they're using. At the same time, we also have our own internal r and d team that develops tools for use in house, but that we also make available to our partners. And these are generally around performance optimization, automated testing, content creation, also tools that are there to assist designers make the type of game that they want to make. So beyond performance optimization, we've built our own narrative tool or a kind of like a a mini map planning tool.

We call it the world planning tool. So etcetera. There's lots of different things that we use internally on our projects, but also make available to others.

Got it. And what about the tools that you use internally for making those? Are you primarily writing these using Visual Studio Visual Studio Code, JetBrains Rider? Know, what's the rest of the tool stack look like for you?

Yeah. So for our own internal tools, we tend to go with open source frameworks where we can. So a lot of the tools that we've developed so far have a web component to it. One of our philosophies has always been to give visibility to as many stakeholders as possible or at least give them the opportunity to see the status.

Right? And if you can do that through a tool, then that's great. So we'll use, Blazor as one of our one of the pieces of our tech stack. And because there's this online component, of course, we use, a database.

In our cases, we'll use MongoDB. But we have had to modify what we use whenever we apply it to one of our partners' games or projects. Right? And then internally in terms of like what our coders like to use, I would say there is a preference towards Writer if they're developing something related to Unreal Engine.

But of course, they'll also be using Visual Studio if they are developing, you know, for for another engine which would be easier to use with Visual Studio than let's say, Writer.

Yeah. Got it. Okay. And then what about for task management, things like that? Do you do your own task tracking or do you use Jira or P four Plan or whatever that your client is using?

Yeah. So internally, it will depend on the type of project that we have structured with our partner. If it's something that we need to deliver to them, we will give them as much visibility as possible. So that generally means integrating with what they're using.

Internally, we tend to have a preference towards using Jira where where possible for managing whatever tickets or whatever iteration or stories that we need to address. And we we remain flexible, of course. We we have to be. That's kind of the nature of the work that we do.

As someone who works at a co dev studio, you must really develop a diverse skill set because you're having to work in all these different methodologies and different tools based on the clients you're working with.

Yeah. That that's true. I think there's there's two things that tend to happen with developers at Virtual. So one is either they develop, you know, a very good generalist baseline across many different tools because they've had to touch this, they've had to touch that, they have to touch that. Or we have other developers who are like, this is the tool that I love and I am going to learn it to death and I will be the expert in this area, right? And I've definitely seen that with team members who are using systems like Houdini particularly because of the complex nature.

Yes. Exactly. Right. Yeah.

So so it really really really specialize in that and I think that's that's super interesting. Especially now, think as as games are still expected to maybe have a certain size, but have perhaps less developers working on them. A lot of decisions have been to move towards procedural content generation and Houdini is a very powerful tool at doing that.

Yeah. Absolutely.

Awesome. So for today's discussion, we wanna get into some of the challenges, some of the things that you've been trying to do. And you mentioned performance earlier. That performance optimization is a part of it.

And I think that's something that touches every single game. Honestly, not just games, any kind of project. Performance is always a concern. And so tell us a little bit about that.

What does that problem look like when shows up and maybe give us some concrete examples to set the stage for this.

Yeah, for sure. So, I think one of the key benefits of being a co developer is you're able to work on many projects. And since we can work on many projects, we find common pain points between them, and as you're saying optimization is one of these pain points. I've seen it happen on several different projects and including one I worked on personally where we constantly had to restart our optimization work because there was new content coming in, we ensured that this new content and the game code were running well enough so that the game could continue being developed, But then more content would come in and so the performance would get worse and it seemed like this was happening in cycles and we were never able to get ahead of The actual work itself.

And what ended up happening is that the schedule was really tight for the project. The content came in kind of late. We had to increase the team massively to make sure that the bug and optimization targets were So not only do we have optimization, we also had to have a bunch of bug fixing. But there was so much to get done that it required a much larger investment that I think we wouldn't want to pay now.

Right? We wouldn't really want to have this massive team to resolve these problems. We'd rather, let's say, think of things in a smart way a little bit earlier. Let's learn from this painful and costly experience.

Right?

Yeah.

And one, stop developers from sending too much, but also a lot of overtime went in. Like I remember our our team, our developers, our producers, everyone was just, you know, spending so much time on this particular project and it has an impact, right, on developers lives themselves. And so, if we can also tackle that, that's great.

That was a constant problem that we had when I was working in VFX in Hollywood was that push pull between, yeah, we got it done, but also everybody had to work overtime and now everyone's really burned out versus planning ahead, like how do we how do we more accurately anticipate what we're gonna need, how do we make those workflows better. So, I can definitely relate to that challenge. Right?

Yeah. And even another another example that I can give you is that another project that our team was working on, So this is another tool related to our performance optimization stuff. Right? Where it's kind of an asset validation tool, but effectively, they basically were working on a project that had already been in development for several years and there was no such pipelines in place.

And so we needed to build a tool to kind of find all of the assets that were kind of blowing up performance budgets on specific scenes. For example, like, there's an elevator button that was millions of triangles. There is no need for for an elevator button to take up so so much space, right, and and performance overhead. So through tooling, you can find these things and you can work through them in an automated way as much as possible with manual intervention whenever is necessary, right?

So, these things shock us and yet they they happen continuously. For sure.

For sure. Yeah. It's easy to let something like that slip through, and it is hard to catch. Like, that is a good point, that as a human just going around the scene, are you zooming in on every little thing, checking out its triangles, all of that.

Oh, yeah. Abs absolutely. It's too it's too much. Games are too big nowadays and they're so complex. So, there's so much content in a game and creators really want to have these living, breathing worlds with immersive stories and so, what they want to have unique objects, they want things to really feel different scene from scene, right?

So

We should be able to make that vision, their vision, a reality. Let's try to do it in an intelligent way, and try to do it in a way where things aren't developing slowly as a result. Like, we can still keep a good pace of development while having a very tailored experience. We I think we just need to be smart about the way we approach our tooling and technology to get us there.

Right. Yeah. And I feel like lately, performance has been kind of a hot issue online. I feel like I've seen a lot of videos ranting about bad performance of Unreal Engine games recently since Unreal Engine five, and then also all the reaction videos of people saying, no, it's not Unreal five's problem.

It's that you're doing your game wrong. You know, you're not optimizing it, all of that. And I think that really, like, that's the hot topic right now, but it's really just that performance is always a struggle. And it's something that, like you said, there's that push pull between performance and making the artistic vision that you want Being able to make that game.

So can you tell us a little bit about, you know, if you're looking at making this tool to help with optimizing, help with measuring some of these things, validating assets, the first thought that comes to my mind is, well, doesn't doesn't that already exist? Isn't that already built into Unreal? Don't they have those tools? So could you maybe set the stage of what's already there and what might be lacking?

What would be helpful to have?

For us at Virtuos, we have different tools to tackle different problems. I think we've kind of taken this approach rather than doing like something massive because as I was mentioning before, we wanna make some of these tools available to our partners as well. And so we realize that every project will need to have their tool sets modified in specific ways. Right?

So we haven't developed some some super tool. We've we've broken it up into different things, and they all have their own place in the development pipeline. We have one tool which is specified on finding the nitty gritty performance hotspots, problems that are arising in different areas. We call that tool Goliath, and it has a very good integration with Unreal itself because Unreal provides a bunch of performance profiling tools already.

Right? Like, Unreal Insights is very, very powerful. Right? So you can get the information, the performance information you want from Unreal.

What you don't necessarily have is a good way to visualize all of this and an integrated way to capture all of this data in an automated fashion. So perhaps the the components are there within Unreal, but you still need to build something out of it. So this particular tool that we have which is called, Goliath, it's, our performance tracking platform where you're essentially like placing cameras in a level of your game and it's automated within your CICD system. So as soon as you're you're running it, it will take all of that data from whatever test points that you've set up, and then it will crunch all of this data, it will pop it into a back end, and then the data from the back end will be read by a website.

So Unreal doesn't provide a website. Right? It doesn't provide these things, but we want to be able to offer a dashboard to our users really to fulfill that philosophy I was talking about earlier, which is give visibility to as many people as possible on where the project is at any given point in time. And developers can choose who has that visibility.

I think, it's useful for as many people as possible to have it because, for example, with this particular tool we have a programmer mode and an artist mode and the artist mode is just like less data available and it's more focused on things that would interest an artist while programmers have access to everything. And one of the challenges with this particular tool development was getting that Unreal Insights integration. It was initially integrated with the CSV profiler of Unreal, which I think was easier to work with. But Insights is very integrated, itself with the engine and then finding a way to take all of the data of an Unreal Insights capture and basically triaging that data.

So understanding what is actually useful in a particular scene, what components of the Unreal Insights capture kind of fit together, and try to not overload the the database with all of these like large files, but still have the important information available to users.

So I think kind of like all of that interplay is something that we like to have with our tools. We're we're augmenting what the engine already provides and hopefully along the way developers have a better understanding of the health of their project.

Right. That makes sense that part of it's not just getting the data, but how you present it. How do you make it useful, right, without having to dig into it? I feel like I've watched a lot of videos and tutorials and read up on how to understand Unreal Insights and, you know, how to dive into all those things. But to have something that surfaces that for me makes a lot of sense that and then not having to spend as much time diving through those and I could integrate it throughout.

What was that process like starting out, though? Like, we go back to that experience you said where right at the end of the project, we ended up having to hire all these people and probably went over budget and all of that just to meet our deadlines.

Starting from that point, you said you tried to apply your learnings from that into making new tools. Where did you start? How did you identify, like, what's the most important thing we need to get done first?

Yeah. So I think, again, this is where we find ourselves kind of privileged, I would say, in the codevelopment space. I am not here to say that GoDev is, you know, the answer to everything. Right?

We are we're here to help our partners with whatever problems they have. Right? And so we actually had a partner who was like, I am developing a game for a platform which is not very powerful. I kind of have a system in place which works.

It's not giving us everything that we need.

So, Virtuous, could you please develop a better system for us? And so, thanks to the idea that they had, we're like, okay, we built it out for them, the collaboration went really well, we worked with them for a couple of years, and we thought, okay, this is a really good system. It helped them to create their game, so it must be useful to other developers. And I think this kind of also fits in with a couple other trends that I've personally been seeing is that there are a lot of new studios that have been set up by veteran game developers, so they don't have access to past tools and technology at their disposal.

So it's kind of asking ourselves, okay, or asking them, what did you used to have that you thought was really, really helpful to you that you would like to have in your new project, but you don't and you would have to build again? And I think every studio can build their own tool. They're all capable of doing that. We are under pressure to reduce cost of game development.

So, I think if we can create something which in one way is generic enough that could be applied to multiple projects, but at the same time customizable enough as well so that it can then respond to specific needs that they have, I think we're we're in a better position there to to kind of serve this trend. And second of all, like, the the other main trend that I see is that and we're talking about this before, is that a lot of existing studios that worked with proprietary engines are moving to commercial engines such as Unreal and Unity. Right?

And so because they're making that transition, they also don't necessarily have the experience in those two engines that we do. And so kind of combined with those, we start to ask ourselves, okay, what are the tools they used to have? What are perhaps the missing links? And how can we develop one thing that could serve multiple studios and then kind of present it in that way?

Right. And I know some of some of your work that you do is taking tools from other engines and kind of rewriting those for different engines so that people have that flexibility of we really liked getting to use this, but we're using this different engine now. How can we incorporate that into our current workflow?

Yeah. Yeah. Yeah. Absolutely. And think it's important for us, where possible, to kind of think along these lines of maybe, you know, sharing more similar tech amongst each other rather than kind of develop everything in in a silo.

Because I think it's easier to maintain, I would say, in some ways, but to each their own. Everybody loves their own tech and honestly, it's just cool like developing something new. So, you know, if you wanna make your own thing, just make your own thing. Like, you know, even though I'm here and talking about the different tool sets that like Virtuous has done, my message is more, let's try to be more proactive in our approach to optimization.

I try to build your own tools yourself. Even if you're you're a small developer, you're maybe just two people or ten people or or twenty, whatever the size, building something small to help you track where your game is in terms of its performance, that's already a step in the right direction. Like, it doesn't matter if you use what Virtuous has or not.

And so in that, like, when you're thinking about this tool, Goliath, that you've made And the insights that it helps to surface, have you noticed any particular trends of what's different compared to what people would find just using Unreal Insights or kind of more out of the box performance tools? Like, does it tend to surface different types of issues sooner? Like, things about, I don't know, shadow maps or finding those assets with too many polygons or I'm just kinda wondering like what What are some things that that would bring up that you might not catch otherwise?

Yeah. I think it's very game dependent, to be perfectly honest. I would say that the the classic issues are there in terms of lumen and Nanite cost on performance in Unreal Engine. Those seem to to be the case.

But I wouldn't necessarily say that, you know, our tool is surfacing specific problems. Yeah. In in the way that we're kind of referring to them. It's more being able to give the vision over a set period of time on how the performance is evolving.

So, in other words, if you've pushed a new feature into the game and this feature has a noticeable performance impact that has been picked up because you've got your test points in Goliath, and here's the test point that fired off, and you're like, okay, things have increased here. So there's a few different actions that one can take. One could say, okay, I'm just gonna see how it plays out. Maybe it was just this change list somewhere was a problem.

Let's wait at a couple extra builds. Is it still gonna be a problem? Okay. It's let's say it continues to be a problem.

Then what do you do there? Well, perhaps you get together with your team and you start asking, do we absolutely need this feature? If yes, do we need to rewrite it? What's potentially the problem with it?

If it seems perfectly fine, then perhaps we need to make compromises elsewhere to make sure that this feature stays in the state that it's currently in. Or you could even go a step further and say, okay, are there other creative solutions for that outcome, but that we haven't thought of yet? And these conversations are surfaced earlier on in the development so that they're present and they can be thought of. It should not be, I am making a game and my goal is for it to be performant.

That shouldn't be the approach. Right?

Approach is, I'm making a game, I would like to understand what I've done and how it impacts performance, and then I can make smart decisions about how I where I wanna take my game going forward.

Right. And I think a key element of that that maybe people would miss right away is just that this is incorporated to every single build, which are then happening at least once a day, if not multiple times a day, if not with every single change list that gets submitted so that you have those metrics rather than we're about to ship. Oh, no. Now we have a performance problem. Who knows where that got introduced? It's harder to diagnose.

Exactly.

Yeah.

Yeah. And with everything, like, with how, again, how complex the systems play with each other, you know, how much is affected by content, how much is affected by the systems that are being developed. There there's so much interplay within each other that if you have something earlier on, you can see the impact of each thing.

Right.

And then you understand where you are and when you get to the phase where you're like, okay, now we need to sit down and optimize, we know these are the problems. So let's already start looking at those and then just keep going from there.

Yeah. Absolutely. I think you brought up an interesting point where I have seen studios, especially indie studios starting up and especially depending on their genre, like if they're doing a first person shooter or something competitive, they think this has to be so performant. Right?

Because everyone's, you know, this needs to run at a hundred twenty frames per second on every platform or something like that. Right? Or at least on most platforms. It needs to run that fast.

This is really important to us. And they'll start from a place of trying to optimize really early on before they even have a game per se. It's just, oh, let's see what what platform we can start with. How do we get that going?

And I'm curious, you know, you you brought up earlier, don't wait till the very end to optimize. But then you're also saying, don't try to optimize right from the start necessarily. What does that balance look like in practice?

That's very tricky question, I would say, because the balance will depend on a studio per studio basis and where the project is. I think it comes down a lot to the production planning and where the creative vision is of the project at any given time. Because from what I've seen, let's say, trend is and a lot more studios are concentrating on finding the fun, which is I think what most games are trying to do. Right?

Create a new experience for players to enjoy. So I think during this point in time, we should have performance in the back of our minds, but I think developers should really be spending the time to kind of put the game that they wanna make together. Right? And then at some point, particularly if we're making a triple a game, it's not only triple a, but I think it's particularly affects triple a because there is generally a time when you're entering production that you need to scale teams up that you're creating a lot more content.

Basically, you've got your blueprint for how you want the game to go, and then you are actually creating what you have on that blueprint. Right? And at that point, that's kind of where you you bring in all these extra developers, you're scaling things up, and it's where you really start to see how much impact that is going to have on your performance. Right?

So you kind of wanna be ready before that scale up with infrastructure in place so that when these problems start happening, you can catch them early. That's kind of like one place where you might wanna be. And then the other thing is with a system like the asset review tool that we have, which is an asset validator, you might even wanna have that earlier because you are probably trying to decide what content creation pipelines you wanna put in place. Right?

And you're deciding the budgets on any given scene. And so, I think you would only be able to, again, catch problems during production if you have a system in place earlier on because you're already creating some assets before you enter production. Right? There's already kind of scenes and art and things getting into place.

Right? And so we need to make sure that those assets are respecting whatever rules you have. And so, by having that there and then when you scale up, making sure that as part of the pipeline this tool is used, then you're able to effectively say, okay, we are either on track or we're not on track and you understand where and why, which is instead of saying, oh, I don't know what's going on, like, we're suddenly out of budget now. Need to spend time to investigate.

You don't need to. You already have it there.

It's in it's in the dashboard and Right.

Just need to get people together and solve that problem.

And so when you talk about an asset validator, is this like the validation that you can do in Unreal Engine where you can kind of code custom validators that you can run? Is this like that, or what kinds of things are you looking at?

Yeah. So Unreal has its existing validation system. And so it's just basically being able to take whatever kind of functional tests that you're you wanna run or asset validator tests that you want. Like, does it have this many triangles?

Are the shadow set up correctly? What whatever kind of rules you wanna set up for a specific asset, you can basically set those up. Alright? Those are set up easily in Unreal.

And then, from there, you're able to either run the tests as the artist is about to push something into Perforce. Right? They're like, okay, let me first put it in locally. Let me run the validator or run the rules that I need to run for this specific asset and see if it adheres or doesn't adhere.

That's one way to use it. The other way to use it is to integrate into the CICD so that it's running as part of every single build. And then similar to Goliath is all of this data is put up online. So you have the visibility again of what's the status of all the assets in the game, what has come in recently, is there any particular area that we need to focus on versus another area, and kind of follow this type of approach.

And we we found it to be to be very useful on the projects that we've applied it for. Right? And not only that, a lot of teams already have their own rules. They could either take those rules and like plug them into our existing system because they built those rules themselves in Unreal, so it plays very well with the engine.

Oh, I see.

Or maybe they already have that system set up and they don't want it, but they just want the dashboard. Right? So it's kind of like, okay, what component is missing in your particular pipeline? And let's kind of flesh that out so that you're able to, again, be more proactive and understanding of your project health.

Something that keeps coming up in a lot of these conversations for me is that even if you're a relatively small team, having someone who's at least thinking about those internal tools, even if they do other stuff, But having someone who's thinking about, yeah, not just how do we get this data, but how do we make it easy to see? How do we keep track of stuff as you're setting up your builds early on? And it seems like there's some tools coming out to make that a little easier to get started with, like Horde, if you're incorporating that into your builds, that it's able to have a database of some of this data. And then it sounds like tools like yours would also help you get started more quickly. But just having someone who's thinking about it early on seems important to me. Would you agree with that? Or am I falling into the trap of trying to optimize too early in the process?

I think there needs to be someone at least on the tech side who understands how a project could evolve to be thinking about these topics early on. It's not always the case that that type of person is there.

And that's not the only challenge we can run into. The other challenge is is that even if developers understand that this type of system could be helpful to them and their development, they don't necessarily have the resources and time to dedicate to either building that themselves or to use something that's available publicly. For me, I think it's pretty sad to hear that because every developer wants to make the best game possible and this is something that can help them and yet, the the tools are not always there For them out of the box. So, yeah. It's the it's the difficulty I think we find ourselves in these days.

Yeah. Yeah. That push pull between wanting the best stuff, but do you think the lack of resource is financial resource or mostly just the time and knowledge resource?

These days, I would probably lean more towards the financial resource. Because I think most developers are capable of building types of tools that we have, and I think because we we've spoken and we've presented this these types of tools to to many different studios and they tend to already have something in place or to be thinking about something like this or, you know, have somewhere in between what we have kind of thing.

But they can't dedicate more spending on those.

Yeah.

Like internal spending of just the the hours Exactly.

Takes to do it. Got it. Yeah.

Yeah. Yeah. Yeah. Internal spending or even to externalize it because again, we're going back to this idea of, okay, we we have we gotta find the fun, we gotta make sure that our game is, you know, on track and and budgets are are tighter these days.

So it's probably a difficult position we find ourselves in. I would like to believe and and it's already always hard to prove this, but I would like to believe that if you have a system like this in place, over time, your development will be less costly because you're not spending the time you need to optimize later and catch all the problems. Right? Right.

That's kind of the the ideal. It's always difficult to prove that because we never have a case where you're developing the same game in parallel, one has a tool and the other one doesn't. Right? Right.

So it's mostly kind of going off of like what, you know, developers are saying, like, the tool helpful to them? Are they getting the information they need? If yes, then great. We're happy with that result.

Yeah. It is it is hard when you're aiming for things actually just being on track. And I think that, yeah, the the case where you don't use it and then you end up with all of this overtime and running late and delays at the end it's like, well, yeah, but that person wasn't using your software, so you can't really get that data. That's really interesting.

Yeah. And I think you were kind of pointing to this earlier, like, gamers are much more in tune with performance these days.

There's so many videos, reviews and people are saying, oh, have got performance problems here, like, my, you know, whatever running on PC or console or all of these things. And it's interesting how the knowledge base of basically the players who we want to enjoy our games. Right? They understand much more than probably when I was growing up and playing a game.

Sure. Yeah.

I had no idea how a game was running in two d when I was a teenager. Nowadays, like, probably people in that age bracket are like, oh, yeah, this isn't performing well and it's probably speculation. It's unreal. It's the game.

It's the engine. It's I don't know. We they don't know what it is. Right? Only the developers themselves know.

Yeah. Yeah.

But still, they know they recognize there's a problem.

And we should try to to help as much as possible before people have that reaction.

Yeah. Yeah. Absolutely. As we're coming toward the end here, I wanted to ask you the question that I ask everybody, which is if you think back to that experience you talked about where you identified there's this problem with performance, right, that this company ended up way behind on everything, and you said, we wanna take what we've learned and make a better solution for it. That was obviously a long journey that had ups and downs along the way. If you could go back in time and give some advice or a tip to your past self, Is there anything that comes to mind that would have made that process easier this time around?

Yeah. I think at the time, there's there were a few things. So one, it's I would say a pretty pretty specific codevelopment learning, which would be we were specifically working on other platforms for a title. And I think the idea was that we would kind of, you know, do the porting ourselves and the main developers would just focus on the game.

I think that was a bit naive on both sides because the game was still in development. And so, whatever they did would affect the work that we had to do. And so I think earlier on, if I had the experience I have now, I would have liked to have been in the room with them and say, if we need to make this work properly, we have to understand what's coming down the pipeline, how we think it's gonna affect performance, and then let us plan that out because we don't want to have people go into overtime and we don't need to Right. Have so many more people join the project at the end.

So I think that's kind of what I would would tell myself on on that type of project, and I think it's this experience has been helpful because when I start to see other projects that may, you know, kind of follow the similar pattern, I can say, okay, let's resolve this earlier. We just gotta we just gotta hash it out and be on the same page, and then we can actually move forward and positively.

Oh, that's great. And then what about for someone who's just coming in to the industry or maybe they're just moving into a co dev type role or tools type role? Are there any tips that you would give to that person?

Yeah. I would say I think there there's two components. Right? I would say, one, if you're getting into the games industry, be ready to embrace uncertainty and also continuously experiment and iterate.

I would say from my experience, game projects are always in flux. So there are times when development's gonna have to pivot and we can't always anticipate that. But I think we can still plan for uncertainty. So it's not to say I I know that this will go wrong.

It's just to say this is probably going to take more time.

So when we plan it, let's plan for that extra time because It's so hard to do though because you won't get it in this amount of time.

We'll we'll keep it under budget. Yeah.

It it is. But yeah, I I think it's a creative, right? It's it's this kind of triangle between art, design, and engineering, and there is something that can that can break or change at any part of this triangle. And so, it's gonna it's it's gonna take time.

And we don't know what's gonna happen and we just wanna make a good game that will appear to our audience. Right? So and it can take time to get to that point. And I think it's worth to take more time to get there than it is to put all our chips in because this is where the milestone said we should be, so we should be there and let's get there.

Alright. So I think that's kinda like the uncertainty piece. And then the the next one is more around like experimentation and iteration because one of the pillars, right, is is technology, is engineering, right? And it's always progressing and I think it's giving developers more opportunities to create new experiences.

So, most recently, AI has been one of the hottest topics in this domain, but there have always been other turning points in the past which gave developers new ways to create their games. The transition from two d to three d, many new experiences came out of that, or we created the the technology, the engines, and as well consumers had the hardware to power open world type of games.

Right.

Right? So, all of a sudden you've got these new experiences. So, developers who are either looking to get into the industry, I would hope that they can have a mindset where they're curious about new technologies, including designers, engineers, artists, and try to learn what can be done with the latest tech and push those limits and iterate until they're happy with what they've created. Or or maybe even have the confidence to say, this is what I would really like to create.

I don't know if there's something like this out there. Let's try to look into it and And be there and and experiment. Right? Because that's where we will create new experiences, new games, and that excites me, and I've been playing games for many, many years.

Yeah. I love that. Yeah. I I always love it anytime a game shows me something new.

I feel like that's always what I'm looking for. And that's why I have a Steam library of, like, two thousand plus games or something like that because I I wanna try every new thing that's out there to see, like, what new things are people doing. Right? How are people innovating?

How are people telling stories in a different way?

Do you have any favorites that you've come across recently of something that was a cool new system you saw or a new kind of technology development where you just went, wow, that's really cool. I wish I'd thought of that.

If we're gonna go on to the AI topic, which it is controversial for some. Right?

Sure.

But I think there is more it comes back it comes to that experimentation for me. It's just like, okay, there is a new tech. What can we do with it? Right?

And so what I I saw recently a talk at China Joy by a developer at NetEase, and they were showing different ways that they've used AI to create new types of gameplay experiences. So one of the really cool things that I saw was they basically had an NPC that was accompanying the player on their journey in this game and they could interact with that NPC in in different ways. So they could say, hey, I would like you to spawn me a weapon, and they would spawn a weapon that they could then use. Right?

Or they could say, I'm about to enter combat. I would like you to join me and help me fight. And then That NPC would understand that.

So I think Like, they were just speaking They were just speaking.

Oh. Exactly. Okay. They were just speaking out loud Right. And this NPC was reacting to what the player was asking.

Right? And I think that's that kind of interaction, I haven't really seen that yet. And what's interesting is that, you know, it's not not just that this was the result, it's also there are so many problems that they had to deal with to get to that point. Notably, that not only does the LLM need to understand the player request just from a a fundamental point of view.

It's like, this is the action I need you to take. But also because it is in the the system was built for Chinese players and number of different accents and dialects that exist in China are very are different enough where you need to have a voice recognition system that really understands what each different player is trying to say. Right? So there are so many different things that they had to consider so that they could get to that point.

And that to me is exciting because they solved those problems or from from what I saw, you know, or they they got to a certain step that was good enough to push to actual players.

Yeah. No. That's a great point of you have this cool idea, but then to actually make it accessible to people, it needs to understand them all. I know I've run into that with even just friends trying to use, you know, Alexa or or Google or something, if they're not native English speakers and they're at my house trying to use it, they get much worse results.

And it is that, well, this sucks. Like, that's not a good experience for them. And it could be easy to forget that, I think, when you're testing out a new idea to just be like, oh, this is so cool. It works so well for me in my voice.

But then it might not work for somebody else.

So so all of these things I think are are are really interesting and AI is just pushing us to maybe think of things in different ways. And of course, I think there's also a space to say, well, you know, yeah, sure, you can do this with AI, but do you need to use AI to do it? Like, maybe you use something more traditional and you can still get the same results. So just need to ask ourselves what's the right approach to do it. And the end, like, if we create something fun, I just say we should go for it.

Awesome. Well, thank you so much, Marios. This has been a great conversation, and thank you for sharing your wisdom with all of us.

Sure. Thank you, Jace. Thanks for having me, and it's been great chatting with you.

Absolutely. Thank you so much. If you enjoy this kind of in-depth conversation with leaders in the media, gaming, and visualization world, be sure to subscribe so that you get new episodes as soon as they come out.

Subscribing and giving a review or rating is the only way that we know you enjoy this content so that we can keep making more of it. Reach out to me via email or LinkedIn with feedback, guest suggestions, or to connect if you'd like to be a guest yourself. I'm always looking for great stories and I love learning about the many ways that game and real time technologies are being used today. Links for that are in the episode description. Be sure to check out perforce dot com for information about our full p four platform based on the industry standard Perforce p four version control. Special thanks to our production team, Ella Reiswig, Emily Matlak, Kaylee Torres, Luisa Puchala and Chris Perez. I'm Jace Lindgren, and I will see you next time on In Development.