In recent years, there’s been considerable discourse about the game industry’s challenges. However, according to today's guest, Jiten Dajee, one core element has been missing from the conversation: the root technical causes underlying many of today’s business woes. After all, game tech shapes the way games are developed and managed, which in turn drives business outcomes.
Jiten, General Partner at Rendered VC, joins host Aaron Bush to discuss how the state of game tech is holding developers back, how many managers fail to solve systemic issues, interesting trends across global development teams, and how all of this shapes the way he invests. We also hit where future game tech breakthroughs may come from and areas adjacent to gaming that are worth keeping an eye on.
We’d also like to thank AWS for Games for making this episode possible. AWS for Games aligns purpose-built game development capabilities — including AWS services like Amazon GameLift as well as solutions from AWS Partners — to help game developers build, run, and grow their games. For more information, visit https://aws.amazon.com/gametech/
This transcript is machine-generated, and we apologize for any errors.
Aaron: Hi everyone, and welcome to the Naavik Gaming Podcast. I'm your host, Aaron Bush, and I'm really excited about today's episode. As you've probably noticed, our podcast is super focused on the business of video games, especially when it comes to figuring out what's next.
However, business is a reflection of all sorts of underlying trends and products and technologies. And sometimes, like when it comes to figuring out why the games industry is facing widespread challenges, it's helpful to dig a layer deeper. and suss out more technical root causes and solutions. And that's what this episode today is all about.
I'm joined today by Jiten Dajee, General Partner at Rendered VC. And we're going to dive into how technology and game tech specifically has shaped and continues to shape how game companies work and what might be holding them back in some cases. So, it should be a fascinating conversation. And Jiten, welcome to the pod.
Jiten: Thanks so much for having me.
Aaron: Yeah. So this is going to be a really interesting conversation, but before we dive into the weeds I think it would be great just for you to share some quick background. So to start, could you give our audience a quick taste of what you were up to before Rendered VC?
Jiten: Yeah. My, I come from a consulting background. I started a practice at Deloitte US on 3D graphics. So we did all the strategy work for the major 3D software players, but the technical work for their customers too. So we implemented game pipelines, but also VFX pipelines and more and more outside of games as well, thinking unity and unreal engine to automotive aerospace bashing companies, a lot of outside sectors using real time 3D.
Aaron: Nice. And I know you've been pretty on top of just new technology in general. I don't know if you want me mentioning this, but I did listen to your TED talk as part of the preparation for this podcast, which was about, virtual reality and such years ago. So really excited to dig into all sorts of technical elements with you today.
But, final question before we really dig in, what drove you to start Rendered VC? What was that two, three years ago now?
Jiten: Yeah, two years ago, we've worked with game companies and non-game companies, and there were two trends that really stood out. One, game tech was aggressively being used outside of games, but that opened our eyes to the second trend, which was There was a very clear difference between how software teams worked outside of games and how they worked in games.
And the tech world in games felt like we were closer to the 90s compared to how other software orgs worked. So that's what we've noticed. And that gap became very apparent That there was both organizational processes that needed to change within the games world, but there was also a technical gap around what was needed for the specific cases of game developments.
And so that's what led us to start our investing journey to try and target that gap.
Aaron: Awesome. As I alluded to in the intro over the past couple of years, there's been a ton of discussion about games industry challenges, launch failures, budgets soaring faster than sales. The bloated content, treadmills, layoffs, you name it.
And usually the framing from the media and the companies themselves centers on business or economic reasons. And a lot of times that's fair. Apple's ATT policies. The COVID boom boss, your interest rate phenomena, like all of these things are real and impactful. However, you also think that there are deeper underlying technical reasons for why these overarching challenges in the games industry we're seeing exist.
So we'll dig. Into more depth and peel back the onion here. But could you to kick us off, just elaborate on your thesis here? How would you frame that for us?
Jiten: Yeah, a useful way to frame it is. Every software company has a dynamic where development performance shapes business performance.
You want to ship a good product, you win your customers. You provide a consistent, stable product experience. You keep your customers. You keep your product relevant amid competition. You prevent it from leaving. Games are software products too, and gameplay and IP are in the driver's seat, but development performance still shapes business performance.
And this has become especially clear with live service games. To bring this to life, imagine a stick figure. You have the head, which is the executive management team, the GMs, the EPs. You have the body, which is the studio staff, dev teams, testers, artists, and then the likes of the technology that the whole studio stands on.
So the stick figure has been walking its whole life. It takes years to develop a game, they have a walking pace, and then management decides they want to try live service games because why not? The money's great. So the head leans forward to run and then the body follows the head because the body then says, let's build a production cadence of every few months, every few weeks, the body leans forward, but the legs never learned how to run.
And so the head leans forward, the body leans forward, but the legs can't keep up and the stick figure falls over. So the industry headlines are observations of stick figures falling over and explaining, wow, running must be hard. But failing to acknowledge that the head and the body are moving before the legs are ready to run.
Aaron: Yeah, that makes sense. And a lot of times, when management teams, they set expectations, they set financial guidance. Sometimes maybe they're getting a bit ahead of themselves and strategy before all of the details have been sorted out. And it makes a lot of sense that, in these cases, there, there would be, many more details than, you Meets the eye that you would see in press releases.
That, is more like internal warfare or like internal at least dissatisfaction in terms of like how decisions are being made. And we can get to more of the human element later, but maybe could you expand more on like, why are live services? The best example here, maybe in like today's gaming environment of like, why this is a widespread issue and like what that actually, how it manifests itself in these, these companies.
Jiten: With most game problems get swept under the rug because there's the ability to throw people at the problem and make them sleep under their desks before launching their crunch time and stuff, so much stuff gets swept under the rug, but. Games were built to ship once, it was a boxed software product, and when they start to ship every single week or every single month, every small problem is felt over and over.
It's like a grain of sand in the shoe, you're not going to feel it if you just stand up and try the shoes on, but once you start running a marathon in them, you're going to get blisters pretty fast. And that's the dynamic that live services had about bringing the inefficiencies and gap and game technology really front of minds to everyone who works in the industry.
Aaron: And as with any technology and any business, the technology we use. In turn shapes how we work. So clearly in the games industry, the game tech people use shapes, their development, it shapes their production processes. And so, Jiten, based on the state of game tech and games today, what are those issues that are popping up, whether it is with live services or elsewhere, could you be specific.
Jiten: Let's nail some technical principles first. And once those make sense, the correlation will become a lot more clear. So let's take a couple of technical topics. One's code architectures. So in code architectures, the first paradigm is it's called monolithic architectures. A monolithic architecture looks, imagine a skyscraper.
Every floor is built on top of the other floor. It's. Every floor depends on the floor before it, and that's what we call tightly coupled architectures. There's dependencies where one file structure relates to another file structure, and it's easy to get started. It's simple enough when you know that you're done after 20 floors.
But if you need to change something on the 10th floor, you can't just take that floor out and put it back in. You have to change something on the 10th floor and then verify or rebuild all the floors after it. Because they're all connected. So that's a monolithic code architecture. On the other end, you have microservices like more of a neighborhood.
Instead of 20 floors, you have 20 houses. And the data moves between each house, and if I need to change house number 10, that's quite easy, because it's not connected to the other 19 houses. So it's a spectrum. There's not one or the other. There's varying levels of how the architecture goes from tightly coupled to loosely coupled, but architecture impacts performance.
Because most games sit towards the model at the camp. Again, you ship the game once you didn't need to worry about it afterwards. You want it to maximize performance for the limited compute on a box and keep things simple when you started development. These tightly coupled game projects, they can be 500 gigabytes in terms of a game build, and you have all these developers working on the same project, and when they're done making changes, it needs to be tested.
So there is a process called compiling where the game engine produces a build that operations teams then take to the testers, and they give that feedback back to the developers who then make their change. But this monolithic code base has everything so tightly coupled with dependencies. So the entire code base needs to be recompiled, not just the stuff we changed.
So across 500 gigabytes, that could take 5 or 15 hours on a AAA before a build is ready to test. So I don't want to test after every change and wait 14 hours after every mining change. I'd bundle 20 changes together before we do a 14 hour build cycle to test. So now that means, I'm going to wait two weeks before I'm ready to test to get all the changes together to then get the build up to test.
So now I'm only testing every two weeks and I'm not driving enough testing and bug catching into my development cycle. So the choice of architecture. Shapes a long waterfall process with handoffs between siloed teams, development, handoff, preparation of build handoff, testing handoff, continued developments, and that's how architecture.
Shapes a very linear waterfall handoff driven process, which is very different than if you use a different architecture that you see in SAS companies, agile development can ban these types of practices. So that's architecture. It's a complicated one. Coding principles is a bit easier in a game that ships once the priority is to get the game out the door.
And so since you don't have to worry about touching the game code after it ships, devs take shortcuts, they make messy fixes to keep the project moving. Instead of planning meticulous code and robust documentation. So going back to the skyscraper example, there's a ton of duct tape that gets used to hold that thing up.
But if I now have to add 10 stories, and the guy who built floor 5 left or got laid off, we don't know where he put all the duct tape. He never wrote the instructions. So now we have to go back and re inspect everything before we can create a safe plan to build because of the dependency problem as well that compounds over from the architecture.
Sure. So it's pretty, it's all interconnected about how these tech foundations, architectures, code principles, they start to form tech debt problems. They shape a studio's development processes. The usual tech choices end up with waterfall processes, handoff silo teams, limited testing, slow production speed and long term stability issues.
And that's as much of a nutshell as I think we can put it into.
Aaron: Yeah, no, that's really well explained for how nuanced it is in reality. You're only as flexible and as efficient as your underlying architecture is. And as you say, it's easy for over, over time, especially when you're under time constraints to that tech debt loads up and just makes it even harder in the future.
To improve on top of it, unless you make some radical changes so I guess, where are the biggest changes still needed on the tech side? If you look at all of those problems and, like, how you think about fixing them what does good do? Look like these days. How do you start moving towards good?
Jiten: Yeah. So we did a study of more than 500 global studios to investigate developer efficiency. And first of all, there's no standard framework. For developer efficiency, it like that topic itself isn't well understood and is an underlived issue. So we borrowed Dora's the Dora framework from Google. It measures things like how accurate your planning is, your lead time, the time it takes from design to ship or the rework rates.
So the game industry average. Piety accuracy, for example, is 3%, 3 percent of the time they're accurate to their estimates and their lead time is three or more months. A modern software company has more than 80 percent accuracy and less than a 42 hour lead time. So that's what we're dealing with. It's night and day.
Now, mobile and MMOs are typically in the top quartile. They look so much better. 33 percent planning accuracy, two month lead times, but the best in class games are platforms like League or Roblox that have 75 percent or more accuracy and ship multiple services a day. What do they do differently?
Loosely coupled architectures, a focus on modularity automation, and DevOps maturity. Basically, the more you break something apart, the more complex the system becomes. So the more systems you have to have in place to manage the complexity. And then DevOps is a framework of operating and technology.
You have to implement the right human processes. The funny thing is that this is normal stuff for the software industry. It's cutting edge practice in games. Now, a huge word of caution because there's no single best way to make a game because there's no single type of game. Different games need different tech and good, I would say looks like a decision making framework and strategic thinking that helps technology meet the business requirements of the game.
And there are trade offs to every technical decision and the stuff we talked about might not make sense for every studio. If the game has a go to market that's highly dependent on live services. Like a free to play live service game, loose coupling and modularity are key to build scalability and the agility needed to perform as a business.
But there's still a lot of AAA single player games that this might not make sense for.
Aaron: And a couple of quick follow up questions on this. The inefficiency is not, executing on timelines in the games industry compared to the modern software industry, how much of that do you think is a function of the games industry, just being more of an art form and more of a sense of like figuring it out as you go.
Sometimes you got to take a step back to take two steps forward or go in a different direction which is maybe different from, just coding software as a service, versus the. Like the actual underlying technology itself is more of the limiting factor. Like, how do you think through the balance of issues there?
Jiten: Yeah. Yeah. So there's definitely enough technology and enough explorers, technological paradigms, like architectures and whatnot that can meet the needs of what games need to be doing today. I think it's more an underlying issue of the willingness to explore new ways of doing things and management teams giving their teams the Time, a mandate, a culture of change, budget and schedule flexibility to make mistakes, trying something new.
It's also a huge issue with AAA is trying to play it safe, pulling IP franchises, which then told technical debt from the start. So I think the best way to approach it is you have to leave enough room for creativity, as you said. But you have to understand that if your business is going to depend on a certain function working, you have to address that function working.
Actually my, my friend, Ben Ribeley, who was over VP of opposite Jagex, he said it best in the talk, he gave it a recent conference. It's about shifting left. It's a strategy of how do you shift left your problems? How do you find your problems and encounter them early, assess your project, do risk based assessments in order to make the understanding of, okay, I'm We think that this creative is fairly locked down.
This decision makes sense. We're going to move forward with it. There's limited ability for it to change. Now let's go ahead and do a refactor, pay down the tech debt before we move forward. I think blindly charging forth makes sense when you have a finish line that you know exists, but when there's no finish line and you have to operate consistently, your strategic planning process has to meet that.
And yeah, and you don't want to stifle creativity by pre imposing what the end state looks like. But you do want to reassess your risk profile and what your go to market tolerance is and develop against that as you move forward in the whole project.
Aaron: Yeah, that makes sense to me. And one final question on this research report — is it possible for the, like our listeners to, to see that is that published anywhere?
Jiten: Yeah. We published it with Griffin actually back in January or something like that. It's out there on the web open for downloads. It's quite dense. I think section three is mostly related to what we were talking about today.
But I encourage anyone to go take a look at the framework and the data that we present.
Aaron: Okay, cool. Yeah, definitely go check it out. I want to check that out in more detail too. But okay let's step, step back again. We've been talking a lot about Just technical challenges, but obviously technology does not exist in a vacuum.
There's also like a human elements at play. There's human management as at play. You're when you're giving the stick figure example, you're talking about Human management as the head. And at the end of the day, what people do with technology and companies is still a result of how teams are structured and managed and how decisions get made in terms of R and D, what's a prioritize or not and.
Technology and otherwise. So I'm guessing that if tech and production changed so much, some management practices probably will need to change too. Would you agree, or how would you frame the human management elements of this and more?
Jiten: Absolutely. Change. Is so hard and it takes time.
And I think this is where management teams are failing rather spectacularly because managing such a drastic change across people, process and technology takes top down support to foster a culture of change, not muzzling developers that say that they need to work differently. It takes support for budget, time and training.
It takes org structure changes. infrastructure budget. Again, when you start to break apart a code architecture into more components, You have to invest in automation and management services across that. That takes time and effort, and it takes time and effort to also break apart your team structure because now developers aren't working all on the same project.
They're working on individual components that they're responsible for their own development operating in ships. Production schedules lengthens, you have to pay technical debt down across a project rather than when something goes wrong. You want to be proactive rather than reactive. That takes a top down focus on going through that process and supporting the people processing technology shifts that happen over a multi year period.
Ends. It would be almost impossible and it would definitely be too much to bite off all at once to say, okay, let's jump from point A to point B, but let's just test automation. As an example, if a game company wants to start moving in this direction, I would not recommend and saying, let's do it all at once.
But a management team can say, look for the next title. We don't think we're ready to jump into a live service free to play, but let's at least start to test out some of the principles that would be needed to succeed if we did do a live service free to play. Let's start building test automation into our company, into how we ship games, into how we run our dev processes.
And if that's successful across a limited number of test scenarios, we feel more comfortable for doing a full rollout of test automation across more test scenarios on our next game, which would be needed to be able to achieve the velocity needed for a two or three week. Release cadence management teams need to be driving strategic decision making that helps the teams change, not waiting for the teams to figure it out themselves without properly resourcing them.
Or in the case of technical debt, you have engines that stretch back a decade. Plus layoffs and outsourcing are incredibly detrimental to the tribal knowledge of how that proprietary code base that was built 10 years ago works. Yep. And. This is where management, good management, strategic thinking, recognizing that interplay between developer efficiency and business KPIs is absolutely essential.
Aaron: Yeah. So what's the underlying people problem here then? Are the managers not seeing the issues? Are they ignoring them or most leaders of these companies, they are pretty smart people, right? Like they got into those roles for A reason. So is it structural reasons holding them back that we need to dissect more?
Like what's like the real root problem that like needs to get better to enact change here.
Jiten: So the problem is systemic. They're right. There's so many cascading impacts of how an architecture shapes, build time, shape testing shapes QA drives player experience drives.
LTV and our current attention. So because the problem is so systemic, but orgs are very siloed, very few people are looking and seeing the cross org systemic nature of the problem. And so there's barely ever one person that looks across beyond their own domain or beyond their own org to see how the impact affects the whole org and the whole motion of the team.
So that's a pretty structural and slight element. And also most. I think in our survey, more than 80 percent of the people that work in games never worked outside of games. A lot of these problems, they're just numb to it. That's how white is here. And they've never seen, Oh, what does software development look outside the industry over at roadblocks?
Actually, before they went through the hyperscaling motion, they brought on board some folks, some backend engineers from Google. And then when they had to hyperscale during COVID, they said, you're trying to do what with this. And Roblox did the painful transformation of going over to a microservices architecture and it's how they've been able to stay relevant and capture so much player value over this long of a time.
So managers Also are very set in their ways and comfortable in their ways. Most people who work for them are collecting a paycheck. Why change? Why do more work? So this then flips over to top management's culture of change, culture of achieving more rather than culture of top down pressure to ship on time, minimize budgets and cuts are around the corner.
So you can quickly see how the ability to change and the freedom to explore a new method of working that introduces a bit more risk into a project. That topic is very hard to approach. And then top managers rarely know how to shape strategy around that to manage it effectively. So you end up right back where you started on. Let's just do it the old way.
Aaron: And I think the Roblox example is a great one. And obviously that's an incredibly complex platform with probably a lot of tech debt and a lot of places. But as you were saying, especially in certain ways, they made good, hard decisions that probably were painful but set them up for, another magnitude tier of success in the future.
Not to put you on the spot, but are there a couple other examples around the games industry that you would point to of teams that have done a good job working together? through this. I think grounding it in a couple of examples would be interesting.
Jiten: Riot is a great example to look at. So Nick Titley and Alistair Bond did a great write up about Riot's backend.
It was a monolithic architecture when it started, but as League built out more functionality to keep players engaged, like crafting, the store, challenges, unlocks, and they started to serve a million, then tens of millions, then over a hundred million now. Yeah, they needed to evolve to be able to quickly and nimbly deliver a new player value across a number of geographic locations.
And in those different locations that partners were partners managed the shard, they had to introduce even more complexity to manage. So they did a huge shift to break apart their monolith into a microservice architecture, which is great at first. They built out more than 15, 000 services, but then they realized that their QA and load testing environments weren't built to support that scale.
So they did the transformation. Then they realized that again, it was a cascading series of effects of how interconnected everything can be. So they needed to invest in more infrastructure and a novel environment architecture to redefine how the whole product worked. It's phenomenal work that they did, but they made the trial by fire transition into being able to operate in a modern and effective sense.
And going back to the benchmarking we did before, that's why these companies perform like modern software companies, because they're architected. And they have the systems and processes and automation and control systems. To perform like a software company because they're operating a software product in the market with high uptime and new value being added every day.
And that's critical.
Aaron: Yep. That makes a lot of sense.
Jiten: It might be interesting to contrast that. So you have this successful platform moving and then you have something like war zone, which has 3000 developers working on it. But what's interesting is. Their dev cycles can get up to a year plus from designing a feature to shipping from designing that feature to shipping it.
So they run multiple teams that are staggered so that players feel like releases are happening much faster than they really are, because they're just doubling down to their problem to hide it by staggering teams. So the cases of updates is faster than the actual development processes. And so that's how bloat happens.
That's how. What we call sub linear efficiency scaling happens. Long term tech development on inefficient tech drives something called sub linear efficiency with developers. Let's say you have ten developers, and in production, all ten are working on new gameplay features. After one year and several releases, three developers are needed to start dealing with all that duct tape, and all the new bugs.
So all these seven are working on new gameplay value for the player. So you hire three more devs. Now you have 13 devs. Year 2, several more releases. Now 7 devs are needed to refactor and banish dependencies, so you hire 4 more and still have 10 working on new player value. So now it takes 17 developers to give the same developer velocity you had at launch.
These technical factors drive sublinear efficiency scaling, which drives team size bloat, bloat drives OpEx drives profitability, and that drives share price. Ubisoft is a great example of that blow in the article you wrote too. Like when you look at teams that have this incredible blow, it impacts share price.
And I think that's the final link that's needed for this to become prioritized for executive management. Because if this impacts share price, it's a problem worth looking at.
Aaron: Yeah. And not every brand, not every IP is Call of Duty, right? And can get away with it because they have a super loyal, massive audience that's gonna, pay them year after year.
And it's probably, when we see the rising discrepancy between how costs across the industry for AAA games have just risen so much faster than revenue can catch up. I have a feeling that Much of what you're describing is a kind of a root cause for some of this. All right let's step back to live services again for a moment.
To me, it seems like there's a pretty clear industry wide pullback going on with live service games right now. Teams like PlayStation, maybe like the most obvious example are significantly pulling back. And I guess to go. To your example from earlier about the stick figure, this is a perfect example of, the PlayStation management, the head moving forward faster than the body could, it stumbles, and then the organization has to, pull itself up and reset its priorities.
And so we've seen, this team cut multiple live service projects. We recently saw Concord launch and become a massive flop. And it's not just PlayStation 2. We're seeing, many of the unexpected breakout hits right now be more boxed products again. And sometimes not even from, these large publishers.
But, are you seeing a similar trend with live services too right now? And if so, to what extent is that problem related to all of these things that we've been talking about so far?
Jiten: Yeah. The trend is definitely there, and I think the problem still stems from the same place. You can't put a game into a business model.
So AAAs want to play it safe. They take franchise IP, put it into a business model. So Halo, they've been running the BAM engine since before 2000, and been upgrading it for every single Halo game, and that's fine. It's had a very consistent look and feel. But then with Halo Infinite, you try to take BAM, which is a sci fi FPS engine, And turn it into a open world live service, free to play game.
That's going to cause trouble. And that's why he went through such difficulty in having to refactor the band mentioned to space a slip space. Yeah. So most games will have a regular update cadence in some way, shape or form. Age of empires too, as a regular update cadence, but the go to market that depends on it, like a free to play FPS, I think that's going to regress to be one type of strategy instead of being the kind of end all be all industry norm.
And absolutely young, small teams with less to lose can try new things and they have an incentive to try new things versus large to establish triple A's. With again, franchise IP and consistent look and feel and a game engine they're using from 10 years ago. They have an incentive not to try new things.
So these younger, smaller teams can make a game and form a business model around it, which I think is fundamentally better than taking a business model and putting a game into it.
Aaron: Okay. Yeah, that makes a lot of sense. So I want to talk about investing and apply All of that you've said to just better understand, like, how you think about it through the lens of an investor. But before we do that, is there anything else that you want to hit on related to, these industry wide technical challenges before we dive in?
Jiten: Yeah, it's been interesting to talk with a number of strategy officer or their teams. And the CSO function has typically been one of looking at content strategy, geo expansion. But under the new market conditions is a lot of pressure to investigate production, efficiency, production sustainable production, but I think they're starting to encounter the same issue of no one person contains all the answer easy to present a format.
It's something that is very systemic sitting across a lot of silos. I think there's now an effort to understand how development shapes business impacts. And I would want to point to, I want to point to some logic that plays out rather simply. It's the tech determines your scalability, your stability, your speed, which is going to shape your dev performance.
That's a game's dev performance shapes a game scope, whether you can deliver on time within budget, what your update cadence is going to look like, the patch failure rates that you experienced, the recovery times you're going to have, and those shape your player experience. And your player experience is fundamentally what drives LTV retention and ARPU, your business KPIs.
That train of thought is where I think focus needs to be driven towards. Is tech, dev performance, player experience. This is KPIs.
Aaron: Got it. Okay. Let's shift gears and talk about investing. And I guess the first big question here is just how does this thesis, this view you have on the market manifest itself in the way that you invest?
Oh, what are you specifically looking for or specifically avoiding? And that maybe shapes like how you invest in the games industry in a unique way.
Jiten: We like to say that we want to invest not in incrementally better tech, but fundamentally different tech. We think that young teams that can run circles around incumbent teams.
We'll have the advantage in coming to market with products that are interesting, differentiated, and try to capture unmet player needs and do so with agility and velocity. So the problem with fundamentally better tech is that the customer needs to change how they work and change is hard. So we talked about this with the triple A's, especially triple A's.
They need a lot of change management support. And that means that the companies we invest in need to have a go to market based around customer success, not sales, because you're not selling to this customer for them to buy licenses on day one and then expect them to be successful. They don't, they've spent their entire lives actually not using your technology.
You have to help them be successful with it. So that year two year three, they're better customers than they were on year one. And that's a very different go to market mentality than anybody in honestly, the whole 3d industry has ever had, which comes from a world of 9, 000 , licenses for a 3d TCC tool.
Double A's are better customers, but have a slower revenue ramp. And honestly, this is where VCs have been making it rather difficult because fund dot fund sizes in this. In this market, they're getting so big in the space and there's a lot of generalist mega funds flooding in, which is throwing return expectations and revenue wrap expectations out of whack.
They're not allowing tech to target the right customers, double A's and who have a time to market of 2 years and smaller ACVs. They're putting pressure to go out the triple A's. We want to invest in teams that understand that go to market reality very well, and want to bring fundamentally different tech that could help enable teams to outperform incumbents.
I think that is our mentality. When we look at companies, we do some content to a minority of our portfolio, but the majority is around the tool they needed to help enable that.
Aaron: Yeah. Could you give a couple of examples of like companies that you've seen or that you've invested in that have fit that mold?
Jiten: I have two darlings that we'll talk about. Once we talked earlier, how building a microservice architecture, especially for our backend can introduce a lot of complexity, a lot of additional investment needed in systems. And that's why teams like riot had to shift from one to the other, because it made sense to launch through the monolith and then they needed to scale.
And change their tech stack. That used to be the case that you had to either decide to overinvest, but not know if your game project would succeed or under invest, but struggle. If you succeed it, it's damped. If you do, damned, if you don't get uses. Companies like pragma exist. They've done the hard work.
They've built a microservice backend product that you can take and run with without having to do the work yourself. That's a huge boon that helps you de risk your project, but also enable scale. And the other would be model AI. Test automation. Is every game company in five years is going to be using test automation in some way, shape or form.
It's not an option. There's a really good talk, a GDC talk given by Robert Masela a couple of years back, but on one title, almost all game titles bugs, the number of known bugs climb until launch, because you know that you're tracking bugs, but you don't have time to fix all of them because your dev cycles are so spread out apart, and you only catch bugs after the development has been released.
So I think on this chart, there were 6000 bugs that they had to quash before launch. Then they had Sea of Thieves. Which had a very strong test automation framework where they never experienced more than 200 known bugs at a time because test automation can test a game, a developer's work before it gets submitted to a build before the build reaches the testers.
And I don't know if he knows, by the way, but bugs become exponentially more expensive over time, the longer they live by the time you catch a bug after you've released a patch is 640 times more expensive. Yes. That if you caught it with the developer made the mistake. So driving test automation as early as possible around what the developer does before it infects the rest of the game project is absolutely essential to keep game costs low and efficiency high.
But that means developers have to learn how to test their own code. And today there's a whole notion of just tossing that over the fence to operations to get the testers. So I think pragma has done a good job making themselves well known and saying, look, we're here and we're ready to support your project.
Model AI is something that almost every game company wants, but they need to start realizing how much effort it takes from the customer side as well to actually go about building building success with a tool like test automation. But test automation is an absolute stepping stone to DevOps, which is a crucial part of achieving efficiency in the market.
Aaron: Yeah, and I think we actually have interviewed both of those teams on our podcast before. We talked to Pragma a decent while back, but I think Modal AI, we had even just a pretty recent podcast From May about AI powered quality assurance. So if you're listening and are interested more in the, these topics, just, type in the companies and Naavik and you should and you should see more in depth conversations there.
I guess to, to follow up on this quickly, like on the technical. side of gaming, like with infrastructure, dev tools where do you foresee the largest investment opportunities and outcomes will come from in, in the future related to all of this?
Jiten: Yeah this is going back to that fundamentally difference.
That we're looking for. So we're still looking for technical breakthroughs before companies can even be formed. Like polygons are very expensive way to represent 3d structures with materials and light calculations. And I truly believe that there is a better way to represent 3d data in space than polygons.
We're seeing gaseous splats and nerfs come around and they're exciting, but with 2d imagery, you had pixels and raster graphics. And a 4k image can still be a couple of megabytes of 4k video can be tens if not a hundred gigabytes. And the reason why we have tools like Figma and Canva that live on the cloud that allow graphics editing to become so easy is because of vector graphics.
The representation of an image as a series of math rather than the color code and XYZ of what are RBG of pixels on a grid. Polygons are expensive. I think there's Developing around how to represent 3D differently in a cheaper way, and that might have implications around how much compute budget we have on boxes or whether or not cloud gaming can truly be cloud.
C is tough as well. And between monolithic architecture, C code, and polygons being expensive, anyone that's talking about cloud today in the 3D space is really just taking it A program that's running locally and tossing it on a virtual machine, slapping it and saying, great, this is cloud. It's not cloud.
We're very far away from being cloud native. And I think that as the core underlying technology of 3d graphics can change, we'll see more cloud native. Technology come to market. We're not even really tapping into that. And from there, we're in some really exciting territory.
Aaron: How does AI play into all of this?
It's the topic of. Conversation. It's, we're at like the top of the hype cycle for, AI everything. As someone who's like actually deeply in the weeds of the technologies and the technology processes that, all of these companies, big and small are running through, like from what you can tell.
And, based on how you're thinking about investing, like what here is actually real and exciting right now versus. doesn't actually interest you that much.
Jiten: I have a crosshair on my back, which different way I turn on the topics, so I'll stop to bite my teeth, or grip my teeth and say my answer.
The tech is great. The use cases I think have been very overrated. In almost every case, it's just an incremental change. Game art, accelerating game art. Sure, but you're still doing it with the same old function of polygons and traditional 3D. There's some interesting stuff coming around with neural rendering.
But for the most part, what we've seen is just incremental changes to dialogue, art, crafting, stuff like that open world. I'm more interested in AI's use in the graphics pipeline to replace how heavy processing is. Faster paced inferencing might be a viable alternative to brute force processing everything in a scene.
Also, AI as a user in 3D simulations, I don't know. It's not that popular knowledge, but for example, one of our projects we worked on was AI For a car company building a private data center to run Unreal Engine in the, in their private cloud over and over to create training scenarios for self driving vehicle programs.
Because if you need to train a car, how to drive in London, you can recreate London. But then if you have to train it, how to drive in the Ray, you can't just wait for a rainy day to happen. So we're creating parameters and the scaling of this went from a couple hundred, couple thousand, 15, 000, 20, 000, 100, 000.
Now it has more concurrent players playing 24 seven than any game in the world because you had AI becoming the user of a 3d simulation and Unreal Engine. So I think there's a very exciting horizon there that's, again, fundamentally different, not just an incremental change on a feature.
Aaron: And do you think that there's room for AI or, is it realistic at all to think about it playing a meaningful role and, speeding up, some of, like, how these teams solve their tech debt?
Or, work to build more efficient infrastructure some of these like big bottlenecks that you've been talking about, maybe it'll take time for, the, for it to not be iterative and to be transformative in some new way. But even if it is iterative, is it still, worth thinking about right now?
Like how exciting is that?
Jiten: 100%. Even the issue of duct tape goes away really fast when you have AI simply generating documentation as a developer goes along. And that can help so many endemic issues about developers, leaving the company or decade plus games looking back and saying, what on earth was this bit of middleware that someone did a quick hack on?
Now if there's easy and available access to documentation and tracing back all the dependencies around that, it's a huge boom. And. There's some interesting discussion on whether or not that will lead to less developer discipline. Because AI can handle a lot of that workload for them, rather than more discipline needed, which is the current day situation for creating those types of developer norms.
But I think either way you look at it, it has a lot of potential. It still comes back down to management creating a coherent strategy of how they manage that change in that process to bring that into the fold. And how they create a culture of change. So people are open to the idea of using it. And then we can start to see the practical applications and they'll absolutely be great outcomes for the industry around just these basic steps.
Aaron: One last investing related question before we begin to wrap up I know you think of yourself more as a 3d graphics investor, not even necessarily like a pure games industry investor. And so this means that you're also thinking about areas that are adjacent. Two games, and I'm just curious really quickly what has that been?
What are those adjacent areas? And is there, we talked earlier about the games industry being a bit insular sometimes, not paying attention to everything else that's going on. With these areas that you're focused on, is there anything of note that the games industry should be paying attention to?
Jiten: Yeah. Yeah. 3D graphics itself has been built around the constraints of, finite compute power on a box, everything runs locally. And so if that changes, it has implications for games and outside, but outside of games already enterprise growth of 3d as something has been something that's been very clearly felt.
There's been a couple of companies that were sleepy 10 year companies that were doing less than 10 million in revenue, and they've all broken a hundred million. There's been around a five X growth of the use of 3d outside of games in the past five years, all consistently as businesses have digitized or virtualized their workflows.
So the enterprise growth of 3d and especially 3d as a gym for AI to either create data for AI to use in the synthetic data use or to train with reinforcement learning autonomous systems. Are extremely exciting. And there's a lot of cross pollination now that's happening. People that work in games are being picked up by Nike, Adidas uh, LVMH.
These guys needs people with game studio experience to create pipelines that are fundamentally game studio pipelines to create virtual imagery of their products. Even Ikea and target are going down the way and VFX has been a huge crossover and there's some great work in the industry being done around the notion of how to more effectively create products and offerings.
And across media play using IP, where the same shared pipeline to develop a game, those assets can go straight into creating animations, whether long form or short form. So I do think it's a very great blurred boundary. I think it's a lot of cross pollination outside of the games industry and from investing at a core tech level, as well as watching the applications and use cases expand.
And finally, the talent starts to cross pollinate. I think 3D is finally becoming an investable asset class. And I really credit the games industry for being the incubator and the nexus of it, and hopefully the distributor of it as well.
Aaron: Yeah, no, that's super fascinating. I'm far less in the weeds on all things 3D than you are, but even things like NVIDIA's Omniverse, and like the idea of the digital twins uh computer reality that mimics the real world and, all of the things that you can do with that, it's just so fascinating and fascinating.
And I can't wait to see where all of this goes. Two final, very quick wrap up questions for you. One outside of, everything we talked about today and your. Your technical games industry, investing focus, like what else is going on in gaming, are you excited about, maybe like a, on a lighter note, like what games or other are you make you happy right now?
Jiten: I'm loving Remnant too. My friend Curtis told me about it and I looked at it and I said, I don't know if I have the energy for another souls-like. Elden ring, I loved Elden ring, but it took something out of me to get through that. But Remnant 2 is amazing. I love the dark tower vibes it gives. It's very closely mirroring Stephen King's works.
And there's something very interesting about that gameplay. I'm sure we'll be seeing a lot more co-op PvE third party shooters with Hell Divers 2 and Space Marine 2 also paving a lot of that way in the genre, but I played my way through those. I think Remnant 2 has really struck a chord with me.
Aaron: Interesting. I'll have to check it out. I didn't realize there was that Stephen King dark tower connection of sorts to you. So that's cool. And then finally, Jiten, if anyone wants to reach out to you or, to rendered VC in general where should they go? Yeah.
Jiten: LinkedIn is always fun or email.
It's pretty easy - [email protected]. I'm pretty open and I do love making sure that good people have good outcomes in this industry. And I don't need much of an incentive to try and see more of that. So very happy to take any inbounds and. Give value back to an industry that gives me great Friday, Saturday nights on the Xbox.
Aaron: That's awesome. Let's go ahead and wrap up here. Jiten this conversation has been a real pleasure. I've learned a lot from you today and I hope everyone listening has as well. And to all of our listeners, thank you, as always, for tuning in and we'll see you next time.
If you enjoyed today's episode, whether on YouTube or your favorite podcast app, make sure to like, subscribe, comment, or give a five-star review. And if you wanna reach out or provide feedback, shoot us a note at [email protected] or find us on Twitter and LinkedIn. Plus, if you wanna learn more about what Naavik has to offer, make sure to check out our website www.naavik.co there. You can sign up for the number one games industry newsletter, Naavik Digest, or contact us to learn about our wide-ranging consulting and advisory services.
Again, that is www.naavik.co. Thanks for listening and we'll catch you in the next episode.
