Evo Gaming #404 - Engineering Mobile Fun

Welcome to the Evolution Exchange Gaming Podcast, where we bring together technical leaders from across the gaming industry to discuss passions, challenges and ideas. The views expressed by the speakers on this podcast are their own and are not necessarily representative of their organisation. I'm your host for today's episode featuring today's guests, Lewis at Voodoo, Maxime who was pre-versely at WUGA, Boris at Voodoo and Vittely at Cádca Games. We're here to discuss engineering mobile fun. Before we delve deeper into the topic, let's work our way around the room with some introductions. I'd like to know who you are and what you do. Vittely, do you want to kick us off? Yep, yep, she'll think we'll start. Hey everyone, my name is like, as usual, it's rarely pronounced right, but Grace did in a graceful manner, so it's literally, I'm working as a game producer in Cádca Games. I previously worked different sort of studios, businesses, gaming, all mobile related, everything like from Ukrainian kids, oriented games, production to publishing and so on. So currently working as a game producer and working on a mobile title that we did with one of the publishers, it's called Threadjam, so currently in search of other ideas and again, we can continue working on, so in the ideation stage. But I guess there's pretty much it for me. Wonderful, thank you Vittely. Boris, would you like to go next? Yes, thank you very much for having me and nice to meet you everyone. My name is Boris, I'm currently a producer at Voodoo on a mobile game called Pepp Heroes, which I highly encourage you to play and download, it's a very good game, free to play of course. And before that, I worked for almost ten years at Ubisoft on triple A games, so very different ones like Assassin's Creed, Watch Dogs or Ghost Recon, which I did both on the developer and publisher side. And so in my control as a producer, I'm obviously in charge of producing everything that we release in the game, the features, the content, live-ups, game modes. And so I lead the team towards delivering all of that in a qualitative and profitable way, of course. And so basically I'm constantly aligning product vision, production constraints and player experience. Wonderful, thank you Boris. Maxine, do you want to go next? Yes, with pleasure. So hi everyone, Maxine. So number two French people here. And like Boris, actually I've been for a while, for a little moment at Ubisoft, though much less long, because my first internship and my first contact with the gaming industry was actually an internship at Ubisoft in product marketing. So yeah, but after that, basically I've been a spend to the past 12 years working in the gaming industry on free-to-play mobile games. The first half of my career, a bit less now, was focused on hardcore gaming, meaning MMORPGs and shooters, free-to-play, IOU games and smilegate. And after that, for the past seven years, I've been working in casual mobile games, first at Game Jewel and Dan Atwuga. In both cases, in my last two roles at Game Jewel and Wuga, I was ahead of product management. So meeting that I was owning the discipline of product management and working with all product managers across all products to ensure that essentially the products perform the best they can and the product managers do the best execution of product management that they can. So very fun, fun jobs. And recently at Wuga, I had the chance of both working on the existing games portfolio, namely the biggest game of them all for Wuga, June's journey, the flagship product. But I've been also working on new game concepts for Wuga, meaning that's from market research, early aviation, prototyping and going through all the gates in the validation process for several concepts there. So also very fun and also not limited to hidden objects like June's journey. We explored a lot of different genres, so that gave me quite some experience there. And I think that's it about me. Yeah, amazing. And now Lewis. Hello everybody, I'm Lewis. Yeah, I work at Boudou, I'm a senior programmer. I work on a project called Blood Jam, which is a free to play mobile game. Very fun, so free to try it out. Before that, I've been Boudou two years, two years and a half. Before that, I lived in Denmark. I worked in a company called Moistor Planet, and I was doing social multiplayer, free to play mobile and web games. Yeah, I was a tech-link there in one of the projects. I did a couple of projects. And yeah, I don't know, I have a bunch of experience and I'm happy to be here. Well, happy to have you all here as well. And now that we have established a concept to each of you, let's move on to the topic in focus. You all have a question or statement on engineering mobile fun. As usual, I'll work around the room asking each of you to pose your question and the reasons behind it. Each of you will have the opportunity to give your take on the situation. So let's start with Boris. Yes, thank you. So my question is how do we align a product, tech and art to create mobile games that are both fun and scalable from a business point of view? So yes, this is quite a broad question, but I think it's a good way to start narrowing down a bit the topic of engineering mobile fun. So I will have my answer in kind of two parts. First, what we are talking about when we say fun and scalable and then let's say a bit more how we can do that. I mean, align the team to do that. So I think to start, we need to make sure that we, the team members know what fun and scalable means for mobile. And in my opinion, that would be, so the first, the first most important thing would be a great core gameplay. I think you need an immediately satisfying game feel and feedback loop with simple interactions because we know that on mobile, the game sessions are short and so the game must be quickly and get rewording and keep players in the flow. And so I think every team member is contributing to the core gameplay feel, product, tech and art because for example, it goes through minimal input latency on the tech side, perfect animation timing, great VFX, sound effects, clear UX, haptic feedback. So everything should contribute to the core gameplay, to the game feel. And I think this is the most important component of when we say what is fun. Then depending on your game, you will very likely need also a meta and live ups for longer term progression and rewards to retain and monetize players. And obviously you need your game to perform well on the UI side so that the game can scale. You need to keep CPI as low as possible with a good market ability. You need to send the right signals to the networks with either conversion rate, retention, play time, everything. So this is basically what we should have in mind when we say what is fun and what is scalable. And so the thing is these goals, they sometimes pull in different directions. And of course the whole challenge of aligning everyone, the team members, product, marketing to optimize all of these constraints. This is what we are talking about when you say what should we do to align teams towards delivering this fun and scalable business. So how we can do that, I will share a few ideas. Obviously this would not be exhaustive and I hope you will be able to complete that. I think the first most important thing is the product vision. It needs to be very clear and understandable for everyone. The product vision, what the game is and the target audience who we expect to be playing our games. Everyone needs to know exactly what this product vision is, product, tech, design, art, QA, marketing, everyone, so that everyone goes in the same direction. It kind of sounds obvious like we always say the vision must be clear, but it's not so easily done actually in practice. Another aspect that I think is really important of course is the usage of data to guide iterations. Because data, it helps understand what players actually enjoy and do in the game rather than what you think they do based on your design intuitions. So I think data is extremely important to align everyone because you can have a great design intuition if it actually hurts your these three retention, your play time, your US spend and of course you need to change it. So data can easily close debates and help align the teams because it's a more objective and it can quickly represent the truth. And so it helps you also like build a B test, a significant one, significant ones where you can actually see clear results and that are understood by everyone in the team. It's also a great way to align on the decisions that are taken because it's quite easy for the team members to understand why a feature has been chosen or not based on the A B test result. Obviously it sounds a bit obvious but data is I think critical to achieve alignment and also you have things like segmentation where you can customize player's experience. Another very important aspect is the ability to go very fast. We know this is something very important in mobile and I think tech is extremely important in here because tech has to allow the speed. You know the competition is brutal, I mean I think it's like 1 million new mobile games in 2025. 1 million it's even crazy for me to understand that number but it means that you get copied extremely fast and so you need to be able to go fast yourself and the tech must allow for fast development and fast release of features and live-ups. And you need to be able technically to tweak your progression, your monetization, your rewards, A B test, everything like on a weekly basis and sometimes even on a day to day basis. So the tech that the engineering must allow you to do that because if not you are ending with slow decisions and this is absolutely not sustainable in our industry. And this is actually something that I find quite interesting coming from AAA development because we leverage these aspects like speed and data analysis for decisions on mobile much more than what we do on AAA games. And then there is one last thing I want to add and then I will stop talking is I think something extremely important as well is to try to give as much autonomy and ownership to team members when they have in mind what we need to do, what is the game, what is the vision. And then we have to develop the sense of ownership as much as we can. Like ideally every designer, developer artist is owner of the feature from the beginning to the post launch analysis and improvement on the feature. At least in our team this is what we try to do and I think it's really contributing to increasing the chances of success. Nice. If I can react, Bois, I'm very much aligned with your points especially I'd like to come maybe back on three of the points you mentioned where I want to share some experiences on that. So you mentioned the importance of the vision. So very 100% agree it is very important. What I would like to add is that it's not just having made a vision once and basically having it documented. It's about the education with the team about that vision and constantly re-coming back to it and validating that it's still valid and making the adjustments together with the team and informing. Because I've been in teams where basically there's a vision, it's an extremely well done document. You have the design pillars, you have all of the clear goals like what the game should be, what's the intent is, what the strategic plan is for achieving that intent. But ultimately the game evolves, some people come, some people leave the team and ultimately there are people working on the team that don't remember or I've never seen that document. So that's why what I would recommend is that when you have your documents, if you're the lead on that project, the leader of that product, to be the one that brings back the vision document, re-educate and constantly bring it up. So that's one thing that is important. The other thing that is important is a product leader to get the team aligned, especially where the product tech teams are aligned on topics where sometimes they might be confrontation between fun versus monetization, that's a cliche one, or text scalability versus speed and their discussions are on that. What is important is that everybody has this clear understanding of what the KPI goals are. That you mentioned, KPI is very important, it needs to be a common language. So that means that as a leader, you need to educate the team on why these metrics matter, they are how they are calculated so that everybody has this understanding and everybody is kind of on the same level. And then the, what is important is that you try to show people how their actions account for the different KPIs because it's obvious, it's for me as a product manager, how my actions lead to metric improvement or negative impact. However, for an artist, mine not be obvious. So sometimes I find it nice to really help the artists understand how their UI, UX change actually gave an impact to one of the metrics that they know is one of the course. So that would be the second thing that I wanted to touch. And maybe the last thing about how the teams are organized. I very much second that's, ideally you want teams that are in pods where the team feel that they own part of the product or let's say the full project if it's a small agile team working on a new hybrid, hybrid casual game. But it's very important that people feel that they have this ownership and that they are working in the pod more than in silos where they are just kind of on the, on the way, delivering things on the way, but not having clear ownership that really helps to get the alignment when you feel that you actually own what's going to be the final output. Yeah, so very much aligned with you. I just wanted to share some some additional insights there. How do you guys see it? Vitaly and Luis. Yeah, sir, I'm using to me. Yeah, I'm seconding all the points on the alignment to me like this data filter is extremely valuable, I guess for any like, I guess everyone in the team had some disputes, right? Like someone thinks that this is the best way to do that. Someone thinks it's the other way around and so on. And then you like do the test. You find the the winning set up and then you like, yeah, okay, we'll, we'll leave with that option and yeah, let's let's just try it for us. We have like even like internal sort of meme and like where we have some sort of discussion. Someone likes the green button. Someone likes the red one. Let's go with the A/B test. Let's let's let users decide what's what's right and wrong. And to me, I just wanted to maybe elaborate on the ownership side and all that for us. We kind of try to create the culture where there are owners and like decision makers for sure. So like we try to avoid chaos, but everyone can like comment, contribute to any part of the game, any part of the like an process or something like that. So while there are clear like decision makers. So for example, if it's if it's some part of UX, it's obviously up to game designer to decide. But you can contribute, you can count with the idea like that there is no like every decision should be challenged and maybe challenged this kind of, I guess this kind of leads to the question that I posted about about sort of leadership role, but yeah, it's I guess it's everyone's sort of mindset right now in the culture. Yeah. So I had to say that the three points vision data ownership, they are really key. So I took her I totally agree with that. I had a few points or I guess details that I think they're important. So in the vision parts, I also agree with what's seen in the way of yeah, you always need to be renewing this vision and I believe the vision most likely is going to change and it's going to evolve and this needs to be communicated. And I have seen several times that yeah, this communication is not as effective as it should be. And then the team believes that the goal is in the middle of the previous vision and the new vision stuff like that. And I think some some yeah, efficient communication and reinforcement needs to be applied here in order to achieve it. Yeah, in the data parts, the data is key. The more data you have, the better. And yeah, the only advice I would say is that try to find the KPIs that are most important for the success of your game, which they're not the same depending on the game that you're doing. And yeah, sometimes, yeah, some teams get lost in the basic ones. And then the ownership by super super support, I think everybody in the team should feel that it has the agency to change the course of a feature of an idea of whatever you're developing because yeah, that's how you get into even better products. I would say when you feel like you are actually contributing and you can actually improve whatever some part of the team has done on come up. So also, yeah, I just want to come back quickly on this topic of like updating the vision continuously because literally this morning I had an example. The team have been asking for more communication on the vision by our general manager. And so this morning, we had a presentation for him about the vision of the game. And it's interesting because he actually emphasized that one of two aspects where the vision did change. And I think this is the, it was great to do this as transparently to say, okay, this point it evolved this way because of the things we observed in the game. I think this is really cool. Something else that you said Maxim about the silos, I'm not sure this is extremely pretty accurate correct to say in terms of project management, but we often say we should not have silos, we should break silos. Actually, I think we need to have the right silos because some silos are actually okay. Because another way to say that is that teams must be focused on something. We should not always be working and informed about everything going on, otherwise we lose focus. So of course, we need a regular moments where we can share to everyone what we're doing. We have that in, I don't mean the forms of demo, it could be sprint reviews or anything. But I think we still need to have some focus and not have people always involved on everything, otherwise you're getting slowed down. That's a good point. You need a little mix up, if you need a good balance. Yeah, wonderful. Well, you know, Vittely, you were mentioning that it was leading on to your question. So after that great question and the great input from all of you, I'd like to pass it over to Velley. Thanks. So yeah, main question, sorry, I have to like actually rewrite that. But to me, the main question is like the sort of the power of consensus in mobile and basically any casual game development, how it works for you and so on. Because I feel that games is such like the overall industry and like the overall field is such a heat driven uniqueness driven and so on. You have to drive some, some, you have to insert something unique in any game that you work on. Everything like there should be no clones that there should be no like less of this, how to say that things that are basically derived from many other games and so on. But when we work with such a broad audience, like for example, I did some brief research and like GTA 5 did like 200 million overall like copies sold. And for example, like I don't know, Royal match, they do like what like in two months, they do 200 million installs right or something that is it's like maybe three months, they will have it, but it's just like a crazy number to reach and like for GTA 5 is like the whole lifetime and for mobile, it could be like in the sort of in the term of month or several months, right? For example, pixel flow, the recent game and yeah, how do you achieve that? How do you treat consensus basically in the decision making? Because for us is it in product or design decisions, anything, anything works here, I guess for us, we try to obviously hear everyone and try to find some middle ground. We appreciate people with diverse backgrounds and diverse interests, but sometimes it can have some sort of deviations from from norms like who I don't know, like people who love sort of niche topics, like I don't know, like I will say that, but don't judge me like Warhammer or like anything like, I don't know, extremely like chess, they may have some interesting perspective on some casual things, but usually it's like we try to sort of refine all the opinions and just find out what's in the middle ground, but sometimes middle ground is just like not the best experience that could be in the game. So how, how it's for you guys, I don't know if you if you've taken that that shot already. Yeah, so I'd be happy to to react to this one. I think it's very interesting because so as a broad manager, trying to make decisions, especially in environment when there is no consensus is like a big part of the role and it's one of the challenges of the role. And here my thinking was that we talked about you talked about a right of match, for example, I think this is an example where it looks like it's just basically another match free where they copy the lot of things from from others, but they probably was a big discussion about the vision of the game. That is actually it's kind of counter, counter consensus is that at the time where everybody was double-depping on making the meta more dense, more complex and advanced, they said, hey, we reverse that, we actually simplify everything. We make it as smooth as possible and as obvious as possible. So that was probably for them the counter consensus argument. I don't know, it was in their team back then, but probably if you'd you ask a lot of people working in Metri, that would be against the consensus. And I think first, if you look at a lot of the hits from the past, like if I think about Plash Royale, for example, back then saying, hey, when you don't play, you will get attacked. And you can only react when you play again. This was probably a very counter-consensual back then. They was a big risk. And I think if you look at the big hits, there will always be this kind of one or two or sometime more features that you think, wow, this is the unique thing that's probably breaking the consensus and they are successful because they had that. But at the same time, sometime you overlook that they still did like 80%, basically very similar to the top performers at the time. And I think the challenge is always defining your exact ratio of innovation that's run on breaking, breaking the consensus and what you actually choose to follow the consensus for. And I think usually I like some frameworks about innovation levels. I like what's Matthew Emory, a very famous PM in gaming, what he uses with basically a 70, 30 or sometimes an 80, 20 of innovation. So 80% should be things you know are safe. They are proven. You know you can count on them. You can execute fast. But then you save still 20, 30% depending on your vision, where you focus on innovation. So I think it's great to basically avoid pure imitation and get to potential majority by having these kind of big bets, these bold new ideas, but you need to be, you know, to sprinkle them. You should not think always that a great game needs to be groundbreaking everywhere because these games you never hear about them because they never find the audience. Especially for us, we are working on mobile games and especially casual games. In casual, we know that our agencies, they like their comfort zone. So they need to know already a lot of what's going on so they feel comfortable. And then you need to decide when you are going to show your unique selling point, what makes your game different from the competitors. But you need to be very careful about when you show it, how you show it. So I think it's all about that. Finding this balance and this exact timing, how you show your unique selling point and focusing very efficiently on that and not trying to be innovative everywhere. So that would be, I think, my view on this. So you just took all my ideas from my mouth. But yeah, I totally agree. I think what I wanted to add then is that basically when you're making a game and coming back and you have your vision, I think one good advice to do here is to get your priorities straight as in, okay, maybe, okay, my unique selling point of this game is the gameplay. And the gameplay has this unique mechanic that, I don't know, you do something. And then that is your priority and probably maybe this mechanic, let's imagine for this case that it's actually breaking consensus because, okay, nobody has seen it. Then it's okay. This is a decision is your priorities, your unique selling point of your product. That could mean that, I don't know, 80% of the other things that your game has, it could be part of a consensus, right, because all our users are very used to a lot of mechanics, a lot of things seen in the games. So it's okay to keep consensus in a lot of parts. And just, I would say, pick your priorities, pick your battles, where it's actually worth that your problem is going to make the difference. Yeah, I think there is at least a consensus among us about how to answer to that question. I think I'm going to probably say pretty much the same as you. You need, if you are taking only safe choices on your game, I mean, it's not going to succeed for sure. As we said before, the competition is brutal. There are so many games being released and so few of them that actually perform very well. I think it was less than 10 games in 2025 that were over $1 billion in revenue. So it's very difficult to stand out and for sure, if you take only safe bets and no radical decisions, I mean, you will very likely not stand out. So you need to do some radical choices, not only radical choices, but some of them, whether they are consensual or not. Because otherwise, you will just be doing another one of these one million games that will not stand out. Absolutely. I think that's in general, there are two things. There's the vision level and the execution. I think when you talk about execution, I think it can be good on UX, on balancing to have some consensus during the team, make sure that we all believe that this is fitting the vision we have defined. But I think at the visual level, when you define the core design pillars and what the game should be, this is where it's actually good if your game is not fully consensual, where everybody agrees like, yeah, make sense. Because that means that there's going to be some interesting discussion on why people don't agree. And sometimes that can actually help the game get better. But mostly when you vision, in general, it's not a democracy. You need to have somebody that carries that vision and fights against people who don't believe in the vision. And that's how usually unique IEDs emerge. So I think it's about balancing where you actually still seek the consensus and where actually it's totally okay because great games usually didn't get born from consensus. Yes. And on the execution part, you can actually very quickly settle any debate with the A/B test or live KPI because it's a great way also to encourage some experimentation. If you have a bit wild ideas, you can just test them sometimes. And you get your answer. If you have interesting perspectives and completely agree with everything and I just wanted to sum up that for us, it's regarding the product and features and all that. It's usually the innovation that happens in the core gameplay or somewhere near that. And when it comes to meta, live ops and all that, there are no usual things. But we try to implement and then there may be some bits of experimentation that it's completely, it's definitely rare for live ops and all this around the game features. Yeah. Well, thank you so much. And it's great to look at the other side of it, especially for people that might be going into gaming and thinking, "Oh, all these different games are stuffin to look at it from another perspective of, you know, it is challenging to be innovative and new and things like that." So, no, that's great. I'm going to pass the mic over to Lewis now for your question. Of course. Thank you very much. Yeah. So, for me, this is like a hot topic. Everybody's talking about or, yeah, or at least this is what I get. It's the hot topic. And, yeah, I just want to bring this question because, yeah, I have made my own opinions, but I'm pretty sure we can have a good blend of opinions here. And basically, yeah, I just wanted to talk about AI in development in every stage if you want to do in development. What are your thoughts if you supported or not? What do you think it shouldn't be done or are you open to everything? And it's just because, I mean, this is growing very fast, very, very fast. And, yeah, I mean, some things that you cannot do today probably next week can be done. At least be aware of where are the limits? Will you willing to put your team or stuff like that? And, yeah, for me, in this case, I mean, if I was starting a new project, I definitely would invest in infrastructure and that every developer maybe could have an autonomous agent that can just do many, many, many tasks without too much time. I understand that in mobile, I mean, these games could have seven, eight, ten years, fifteen years of development. So, legacy code, this could be very costly if you want to do a whole infrastructure of supporting that, but definitely, I was supporting to, okay, let's see what can we do here and how can we set up? So development gets faster. In my opinion, this is a game changer. This is going to make everything faster. And, yeah, I would say if I had limits for me, I mean, it's not my field and maybe this is why I don't feel comfortable about it. It's making fully art with AI. I don't know. I mean, it has, for me, it has some, yeah. So, question that I am glad that I don't have to answer them. To be honest, but I am very curious of what you think about it. And, yeah, let's chat about this. For us, and for me, especially, I guess, you're asking the question, how do you support and raise the use of AI? and for me, it's how do you not support the use of AI and all that tools? Because, yeah, it's for now, it's kind of an obsession of all the people to try some AI. I personally, I wasted countless, I guess, weeks in order to get the stable diffusion working with generating images and all that. And I guess it's kind of the, but now it's still sort of in the discovering mode and exploration mode for the whole industry and the people who work here and so on. So regarding that, I guess there is a lot of temptation to waste another week to find some AI solution or make some AI solution work. And during that week, we could have done that by hand, like effortlessly. This might be the one of the things that still like AI is not that great in certain topics. And we've all seen this flop with the Google role generation thing that everyone, basically everyone discussed on LinkedIn, right? And how it's not going to impact the gaming business and especially like tools providers, but it still happened and people lost a lot of money. But yeah, for me, I guess the biggest restriction is basically platform restriction, right? And some ethic restrictions. So you shouldn't be using like anyone, others, art, for example, to train your model or something that, but I guess in the current world, it's just unavoidable. It's just even if you do find some like Laura for stable diffusion that does copy some style, it's like most of the time it will be trained on others work. So I know it's kind of tricky topic to discuss against the ethics and all that. I know that people use that a lot. We just probably didn't even have any sort of any game that would require that. But yeah, like we use that a lot. Me personally, I use that all the time, like change, GPT and Gemini are always on the phone on the computer, everything is on everything, like process related questions, everything is done by AI and form some SOB and all that. So it's for me personally, luckily there are no restrictions because texts are not copyrighted usually. If I can continue, first I want to say that I'm quite impressed. We were able to talk around half an hour without mentioning AI, so it's, I think it's quite cool and funny. On our side, I would not say there are so much restrictions. I mean, we are quite encouraged to use it as much as we can as long as you still are the master of your own work. So for example, we use, I think it's called cursor that we integrate in Unity for developers. So developers can use it for, for example, low value tasks, like dealing with, I don't know, referencing multiple assets, things like that. But they have to understand the code that they produce, they have to be able to debug it. If they do some stuff and they don't understand, I mean, this is an issue of course. But apart from that, we are encouraged to do it. And it's also interesting because sometimes the deadlines, like the production constraints kind of forces into using that. I have an example where we had a planning of art production that was just not fitting in the timeline we wanted. So we could have of course adjusted the timeline, but we said, let's try to use AI much more than usual to try to compress the planning. And for this task, it actually worked. So you said, Luis, something about art. We cannot use it for everything, like for example, UI/UX or 3D or pixel art. It's not so effective for us at the moment, but everything from concepts to sketches or 2D distrations, it is very effective. And so for those kind of things, we are actually getting to a point where we must use it. Because if we don't, then it will have to increase back the estimates of the individual tasks and we do not want that, of course. So those are examples and then we of course use it for many other things like some UI/UX mockup, the production of creative ads, even localizations. There is no real restriction on our side, I would say. That's pretty good because it's not the case everywhere. I think it really depends if you're in a small studio or completely independent developer versus if you are in a big public company. Because in public companies where data privacy, IPs, all of the legal risk are very, very important, that makes AI move much slower. So examples being that, so with AI, the thing is that it moves so fast that every month there's the new tool of the month, the new software flavor of the month. And that's really cool for developers that can basically test all of that very fast, play around with it and then move on. But in big companies, every single tool needs to be approved legally and checks with data, privacy checks and everything to avoid leaking data onto the internet, basically, proprietary data. So that's always a big trouble and I always feel that the market's AI for AI is not mature enough so that some of the bigger public companies can really truly embrace it. That might be good, might be a good thing. I think from practical experience so far, the best use of AI at the moment is really for this mobile studios is really for asset prototyping iteration speed because the power of AI is really to allow you to create a lot of different variations, a lot of different concepts. So that then the human craft can come afterwards and basically filter and then improve and edit and fine tune. I think this is where, concretely, I've seen the best use for now is really having a junior artist create a 20 different concepts in mid-journey for in and after noon and then together with a senior artist picking what are the top two that actually are the one with actual potential and then making the final finishing touches to get to the desired quality and then you can ship. So always using kind of AI as an opilot, as an assistant but still having the human craft and Dn for validation, confirmation, fine tuning, that seemed to work pretty well. But of course again, it depends what tools your company is allowing because not every company is okay with every tool and that's pretty difficult if you move from one project to another where you might have to rebuild your own AI stack of tools you use. So yeah, for what I've seen, if I try to summarize that, I think that AI is really good at the moment in mobile developments to support on the divergent creative work phases. So many way when you try a lot of different things, you want to visually see a lot of ideas, test a lot of different things. But then the humans come in with the conversion phase when you come to picking dough when they're making the final decision. That's where I think it's still important to have humans involved in the loop. That's my view as of now, it might change in six months because maybe in six months actually you guys are not even needed. Let's see how it is. But I do hope that there will always be some craftsmanship in mobile gaming where the finishing touches are still done by us. Yeah, do you a question to all of you just from me? Do you think like do you actually trust AI to do those jobs? I know Maxine you were saying about the humans coming in and fine tuning it. But do you think you trust it to do what you want it to do? It depends which kind of test, honestly. Because AI right now is being used for art a lot and that's a big discussion in the teams always. It's a big support of engineers at the moment to help write code through cursor and GitHub Copilot, Microsoft Copilot, there's a lot of tools that can really help you code better. And then there's for everything about research, scanning data and everything. And depending on that and depending on your experience, this is where you get to do very different levels of quality, honestly. So if you are able to get the most perfect model for that specific task and you have somebody that knows what they are doing, I find it to be quite reliable. But it's still my opinion required the final review from a human at the end. But if you basically take a random model, give it a random prompt from somebody that just is trying, you will get results where the model had its innate, the output is honestly not usable. So there's still kind of an art to it on how to make it good. But hopefully with time it would anyway become easier and easier or not. Maybe actually we want to make sure I still make that it's still difficult to get AI to do exactly what you want. So that's we are still as humans involved in the process. I would say as of now, but maybe tomorrow it's already outdated. It needs iteration. I think to trust blindly, you need a bunch of iterations and maybe you get to a point that you can trust blindly. But yeah, I mean, so that's what I would say. It needs some iteration to actually train and know exactly what you're getting. So yeah, we are at the point, but maybe a new one comes already, so this is going fast. But in general, I do trust, but I am not in the state that I have an autonomous agent that it's making changes to the project. No, I mean, it needs that human validation. I mean, I wish at some point there was no human validation, but right now I think it's okay. I'm enjoying it as it is right now. And let's see what the future holds. I think that anyway, whether you trust it or not, you still have to verify the output of what you're asking the AI. And when you think about it, it's a bit like a developer or artist. I mean, a developer is doing a work. The code is reviewed by another developer, or it could be reviewed by an AI, actually. And then you are testing in the game and then a QA is testing in the game. So you have multiple layers of verifying the work, whether it's done by an AI or human. And I think whether you trust AI or not, you still need. These layers of verifications and those layers can be done by other AI or by humans. I think it's better to have at least at the moment a human as part of the verification process. But I think you still need that part. And so the trust, I mean, then it's not so important if you trust it or not, as long as you verify the output. To me, probably the closing point for the discussion, but let me know. But to me, it's like AI is basically a tool and you cannot trust, I don't know, like your coffee machine or your car or anything else. You just trust the person who does that and trust the sort of the skill to manage this tool and to work with this. So for me, I guess I don't care who wrote the code. Is it is it clothe or is it like co-pilot or anyone else? It's just like it has to work. It has to have like less bugs and then regular program does and like the less, I don't know, takes less time to make and so on and so forth. So this is it. And I guess we all had this kind of common point where we, there is still human involvement with AI and I guess there is the right thought for that that like everyone in especially in this white color jobs will turn from like doers to like basically reviewers of AI work. Like we will basically end up I guess I hope it age as well that we will end up being like reviewers of what AI wrote created. I don't know, wrote some music or anything else. We just like, we at some point will be there. But yeah, that's it. Yeah, 100% and you know, I think that AI and I think, oh, I wish I had it when I was doing my exams in school, but you can't always win I guess. But yeah, wonderful points on AI and well now last but at no means least, I'm going to pass on to Maxine. All right. So let's try to finish with the bank and hopefully a good question. So I will start with a very good premise. So if your product is already fun, like you have this very solid foundation, you have a good core core loop. That is fun. And now your challenge is that you want to scale. You want to scale the business. You want to let's say improve monetization of a time, get to a better LTV to CPI ratio. But obviously you want to do it without deteriorating the fun experience. That's in the first place made your players want to love it the game. And I find it a very interesting situation because it feels like easy that you to protect the fun and that you know you have your base and you just keep adding improvements to monetization. But very often that would be clashes between monetization decision versus fun gameplay decisions. And I am just thinking how you manage to keep fun as a key element in design decision. Even let's say when you start being on the pressure of delivering higher or poor of getting to a threshold of LTV to CPI ratio. So how do you handle that with the teams, with management to find the balance and never forget the fun even when business is knocking at the door pretty much. So that's the kind of the environment they would like to discuss. And what I would like to bring is maybe the concept that I discovered I think two years ago, which is called the trust thermocline. And I think that relates really well to this discussion. So the thermocline is basically in water. Temperatures decrease in a very interesting way. Like at the beginning decrease slowly. So the lower you get the colder it gets but it's pretty slow. And there's a moment where basically it's a cliff and then water gets very, very cold, very, very fast. And so that's basically kind of like a low, very, very curve. And somebody used that this exact shape as a way to explain that sometime. And then basically you can erode the trust of your community. So some bad decisions on your product will make that you erode a little bit the trust. But you don't lose the trust of your community and your players. It's just bits by bits to get less and less. And then there's weirdly a point where it drops and you basically completely lose the trust of your community. And it's very difficult when you're working in product and especially also in community management to understand when you are really, when it's the last drop that is too much that will make actually players leave. And sometimes it's not even something you would expect. It's not like a game breaking bug or anything. Sometimes it's just one announcement in the game that made people say, okay, this is the last time I get through that. And I think it's very interesting to always keep that in mind that every single, let's say a new monetization only feature on you push that will be potentially seen as a cash grab save from players where you objectively put more efforts sometimes into building monetization mechanics and features and events and not enough on sustaining the core of the game loop. That's at some point you will, there will be this one feature too much. That might be the one that breaks basically the all game. And so from my experience now, how do you try to foresee this kind of issues and to work with that and avoid that you get to a point where you are breaking the core loop and breaking the fun while making sometime like good decision like every A/B test will tell you, oh, with this A/B test, you improve your your R pool by 3% and here's 1.7% and so on. And you think you're going in the right direction, but there's a lot of other maybe signals that you miss on the way where you actually make the game less and less and less fun. So for me, the approach here is to a very clear kind of non-negotiable fun and fairness rules that you have established from the beginning with the team so that people know that there are something that we don't want to do even though that might be for a short term monetization really good, but something that you don't want to do because they are part of the sense of the game. Another thing is to have to protect the fun is to have fun reviews when you release a new feature and new events, especially when it's one that's more focused on monetization of users to make sure that there are a few key experience people that will review IDD maybe even from other teams so that they don't have the bias of having built that feature, but some to review and ensure that the game that this fits the game, this fits the vision, this fits the strategy and the design pillars and keeps the fun. Another element that I would like to bring that I think is important is that whenever you do an A/B test focused on monetization whether it's through a feature, a live-up event or a sale that you also have a secondary success criteria, you keep an eye on some retention engagement metrics, sometimes that for a new feature that you also take into consideration more qualitative feedback and quantitative surveys about that new feature, about these recent events so that it's not just pure monetization data that guides your decision, but also a mix of data informed but also having some qualitative feedback. And finally, maybe the last one to make sure that you keep the fun at the core is that it's in order to break the concept with the team that monetization doesn't mean it's against, but that's something that's often discussed by designers, some designers, some artists that say, "Yeah, but you want money, I want fun." But actually, sometimes the fun can be part of monetization loops and for me, the best example there that I like to reference with my teams is in Rialmatch because the entire model is built around near-miss monetization so levels where you feel you are almost winning or you just barely lost and you create this kind of pressure, a distinction and you try to monetize the tension at the moment of the highest emotional investment from the player. And that's way more fundamentally different, more powerful than having energy gaze, clear pay to progress things. And that's if you basically built your monetization around moments that are actually fun, you have a better chance of keeping the fun on the long term while also scaling the business and improving your monetization metrics. So I'm curious how you guys try to be the guardians of the fun while still scaling the business and how you manage the teams with that. And I'd like to say, Maxime, that I very much like your question because this is one of our hottest concern on a daily basis in the team. First I think, well, it's kind of obvious, but fun in mobile gaming, you can measure it, meaning that, let's say, if you have good retention and good play time, no big spikes of turn, then you probably have a fun game. So when you run your A/B test, if you look at this KPI, then you see that the play time is not affected or is increasing, you could probably be fine in terms of your game theory. It doesn't solve every problem, but I think this is one thing you have to look at. And actually, when we look at our A/B test, play time is the very first metric we look at. First, because it's the fastest representative ones, as soon as you have a few players, it starts to be representative, but also because it measures if the players are actually enjoying the game. And so A/B test, of course, is a good way to do it. And I'll give you an example of something we did. It can sound a bit weird to do an A/B test for that, but we were still afraid of touching the game field that we did. Is we did the optimization to improve the frame rate of one part of the game, so a technical goal. But the part of the game in question was the core gameplay. And we were so afraid that by doing this optimization work, we would affect the game field in any way, we would not even know what it could be that we run an A/B test on a technical feature. And thankfully, the A/B test is positive. But you see, my point is that it's so important that even for something like that, we would not take the risk of not A/B test in it. And of course, something in action is doing some reviews. When we do reviews, we tell the team that we have to focus on the game field we have to ask ourselves the question, is this feature affecting the core gameplay in any way? Because if it does, then we really have an issue. And yes, I also very much agree with what you said about the fun. It can also come not only from the core gameplay, but from monetization. No, I would like to say, progression loops and live-ups. And if we see some of the most successful games of last year, like the Forex strategy games, what is the game field actually? What is the core gameplay? The core gameplay is the whole progression loops. And so I think that this is also the proof that it's not necessarily in contradiction. But you're absolutely right that it should be a daily concern, especially for casual games that rely a lot on the core gameplay, like the example of Ragematch. Yes. Awesome. Awesome question, to you know, I just wanted to add a couple of things that I consider a trust killer. You were talking about, I mean, I think these things, if you tweak it too much, they could definitely kill the trust. Yeah, it's just a couple of things, but I just wanted to mention it. So first, like the difficulty curve. It's typically in any game, similar to the genre, that, okay, things are going to get harder, I'm going to get harder. And if you have like a wall or something, that really the people get stuck up and there's a lot of charm, yeah, probably you're going to make money at that point. That could trouble your users as well, right? So this is a very fine line of how to tweak that and it's very dangerous. So yeah, this is the typical question of money versus phone, right? Like, okay, are we really doing it too much or not? So think that one, very important. The other one also, regardless of what type of game, it's the amount of time required for daily tasks. Let's say like the average time of a user, because I think, yeah, it needs like a sweet spot. In the sense that if you have too many things to do, I don't know, this is full of meta, too many things to do. You need to, I don't know, spend two hours a day. This is maybe too much, but also if you can only have things to do for five minutes, maybe it's too little and this could make your users or get bored or they don't have the time to actually spend and do everything that it needs to be done. So yeah, the sweet spot in the time and difficulty curve, I think those two very dangerous things, but of course, this is something that we're dealing on our projects, right? So yeah, always be mindful. And as Bernie said, yeah, it'll be on your changes because you maybe don't notice, right? That, oh, we just added this new feature is super cool, but users need to have fun hour a day. You've seen that and maybe so, yeah, I just wanted to point that out. I just wanted to mention a couple of points, we were discussing the balance between fun and business. I guess we are in the business where fun is business, right? Because without fun, it's going to be like everything is like, there is no meta in the dead game, right? So it just makes them sound. There is no sense of live ox in the game that has like 5%, they want a dungeon or something like that. It's just, it's not kind of, it's the trade-off between like usually, it's trade-off between lifetime, like retention and like, with difficulty, basically in the LTV, right? That you get from the present difficulty. And yeah, it usually, from my experience, you may look at the middle numbers, like average numbers or median or something like that. But when you see some deviation, you definitely want to dig into that and see like what segment of players did you impact? Like, was it, for example, for us, is it like payers or everyone else? Because like, for example, there may be features that didn't impact payers at all. Like they are play times and everything was improved. But you see the median going down because like the biggest amount of players and non-payers. So something like that, it may sound pretty lucrative, but I guess it's kind of the, the kind of the approach that we all have. And I guess the, the, in terms of solutions, I guess, the bar from analytics, avid, testing and all that, there should be certain limitations. Like when you make a game, when you design, when you like make certain features, you have to have in mind the whole picture of where are you going to and like what's going to be the end result, what are going to be the icons on your main screen and what they mean at any point of time during the players journey. So I guess the, for us, it helped a lot to kind of like understand where we want, like every place on the screen is like intentional and where we want some things to be and when. So yeah, I guess from E currently that's, that's the only like educated guess kind of solution that you that you may have while developing. Yeah, thanks for the insights guys. They're really interesting. And I think to summarize, I just remember that there's always this sentence that is a good summary of mobile gaming. It is with good games in mobile gaming, they are able to monetize the fun and the sentence like monetizing the fun. I think it's a good guideline that everybody can have in the team because that implies that you first create the fun. That's the staple. You first need to create the fun. And then of course, the challenge is to find a good way to monetize it, but it's still step one is creating the fun and always trying to keep it and keep both the fun and the business from monetization as part of decision making. And then you can get to successful. Yeah, 100% I think it's a great way to end our lovely podcast about mobile gaming and it being fun. And you know, we've had some great questions today and you know, great answers from all of you. So happy about that. So to say before we end the podcast, I'd like to say thanks so much to all of our guests for sharing their thoughts in today's conversation. Once again, our guests on today's podcast have been Boris at Voodoo, Vittely at Kadke Games, Maxine who was previously at WUGA and Lewis at Voodoo. If you're hiring for new technical roles or looking for a new role, feel free to get in touch with us here at Evolution or if you or anyone you know would like to be featured on a future podcast, you can drop me a message too. I'm Grace Moody and you can find me on LinkedIn or visit us at evolutionjobs.com/nordics/gaming. Thanks again to all our wonderful guests and thank you so much for listening and we hope you can join us next time.