[Music] [Music] Heat. Heat. set things up for the next panel, which is something that I think is very interesting for a lot of people. How to ship a top tier game without a top tier budget, practical tips on cost-effective live service game development. So I guess I can welcome to the stage uh Thomas Huxter from Raptor PR, Tamu Hila from Metplay, Kristoff Wegman from Photon Engine, Rick Rakula from Future Run, and Yua
Hati from Phantom Game Labs.
Hello. Hello everybody. We're very lucky today to have some grizzled veterans of the uh of the games industry. intro introverts had to be given a beer just to get up on stage today. Um, so we're going to be talking about cost-effective ways to create top tier gaming content and scale it. Um, you know, obviously cost effective is a is a subjective thing, but uh, you know, working within the resources that are available to you. Um, I'm Thomas Huxer. I'm going to be moderating. Um, I'm director at a UK based B2B PR agency for the games industry. Um, and yeah, please everybody introduce yourselves
super briefly. Hey, Demo, nice to meet you. Co-founder, chief product officer at Meta Play. My background is in in games. I had a studio called Play Raven that was acquired by ROIO. Um, I host a leadership day games conference a couple days ago, lifetime award from IGA, that sort of thing. I'm Chris. Pleasure to meet you all. I'm
founder and CTO at Exit Games, better known for our product Photon. Started the company in 2003, so 22 years ago. Um, yeah, that's it.
Hi. Hi. Uh, I'm Ricurakola, CEO of uh, Future Run Games. uh we started a couple of years ago and we're build building a multiplayer sports game at the moment and obviously using a lot of the technology that these guys represent.
And hi, my name is Yuo. Uh I'm from Fondom Game Labs. I'm a game programmer. We've been around three years now. Uh our second game Rift Busters went global last month. Uh we built that for couple of years and now we are building something new and well I'm doing a little bit of everything with the small team we have.
Awesome. Yeah. So again you know blessed to have people here who have all built something scaled something um both on
the tech side and also you know the gaming content side. So if we dive dive right into it guys um from your track record either with your you know existing in your existing role um or or previous roles what are some examples of of where you've worked within you know the resources that are available to you whether you've bootstrapped or just been very costconcious and made decisions uh that have had long-term positive ramifications and I'll open that to the the floor whoever wants to take that first.
Well, maybe I can go first. So, uh, a little bit backstory. I used to run a mobile games company called Raplight Games for 13 years. And that was my first company. So, obviously, I made a lot of mistakes there, which I tried to learn learn from, of course, for the second company that I now run. And I think starting this company, I had a very different mindset than than the previous ones. So the previously of course I started the company because I wanted to make games for living and I
had a lot of friends that were also in the gaming business and we just wanted to basically build something of our own and of course uh later on when we got funding we didn't really know you know where to spend that properly in a way that we sometimes weren't the most costconscious of course with some of the decisions. I think the biggest mistake early was hiring too early as you know I've been thinking that a lot because sometimes you hire too late but I I think I made made the mistake of hiring too early. So with the with the new company I wanted to be very costconcious of only hiring the smallest team possible which which means that we all have to wear many hats basically and uh also some of the things that we did for example was that we are not going to get any office in the early stage we the first year we only were in this small basically like a hotel room that cost like €1,000 a month uh and I think that was a good decision uh to kind of keep
the minds of the company very scrappy in the early days and also of course the personal is is always the biggest cost cost factor so but I realized that we have to hire senior guys so we couldn't go really low on the salaries but instead we can kind of limit the headcount very very uh very much so that's what we did so I think that those things just trying to keep all the things scrappy was a really big thing for the second company
I'll just maybe chip in to say that yeah it's it seems to be there's actually a topic we discussed in leaders leadership day as well that like turns out one of the learnings when you do multiple studios in a row is to realize that using money effectively is really hard. So it's actually a like a senior thing to try to go as far as possible with as as little money as possible because then it gives you the least amount of surface area to just kind of end up spending time and money on things that actually didn't matter like constraints really good thing. How much does that you know for for you and how much does uh
funding I guess change the dynamic? I mean I think you alluded there you know when you've raised some money you know potentially that might change the dynamic when compared to when you feel like every you know penny might be coming out of your pocket. I don't know how does that change the dynamic? Yeah, raising money is of course one thing I learned about raising money is I I raised like five rounds for the previous company totally like 15 million and and when you start like usually you want to want want to get the biggest street round possible or at least that's the mindset that I hear from a lot of first-time founders that okay the seed seed run needs to be big enough so we can really have like at least two years of runway three years of runway hire x amount of people but what I did for the second company was I realized I want to try to raise the least amount of money that I can so that was actually One of my pitch I said to the investor that I want to have the least amount of money possible and the whole mindset was that usually if you raise like a couple of million you get the investor expects you to get to the point of let's say a soft launch and then you start to launch more
like raise more money to actually you know do UA uh kind of like grow the game but what I what I wanted to do was to basically prove the team first and if the investor is not happy at that point that we are we don't have fast enough velocity, I will just shut down the company. And that was kind of a risk. But what that enabled is that the actual second round, the proper seed round was with a bigger bigger uh valuation than it would have been in the first. So that's kind of like a gamble, but I took it with the second company.
Awesome. Um, Yuo Kristoff, what are your your costconcious stories that you're proud of? Well, if I continue from there, well, obviously I'm not part of the founder team, so not much to say about bootstrapping, but yeah, totally agree like keeping the team as small as possible like reducing all the bureaucracy. Uh not many meetings to do and basically from maybe from tech point of view, I
would say like uh how to make things simple is coobo coding. So basically no fancy kit flow uh doing things like uh push everything to master no code reviews whatnot uh things are super simple when you are only seniors you don't have to do a lot of back and forth talking about the code you can just uh ship it code code there's the focus
Kristoff what do you think
um so yeah we are around quite a a long time. So I started Exit Games is a company name almost nobody knows probably we are more famous for Photon. So we had a first live the first 10 years we we actually built a back end. So we raised about um eight or nine million to build a product called Neutron and it was a time where everybody was using uh Nokia phone. So
there was no iPhone. There was just 90% on the planet was Nokia. And we already worked with a lot of the Finnish companies were already really shining back in the day. So there was Roio, there was Sumea which later became Digital Chocolate and it was a great time. So we um we had that idea to build a back end for mobile games um because we thought mobile phones would ultimately uh be connected and that people would play together. So the idea was uh very good. I still think it was a great idea.
Crazy talk.
Yeah, just the timing was horribly wrong. So that was maybe the biggest learning for me at that point that that's a great idea, but if if the market is not really sucking in your product, so it always felt like we had to to kind of sell the product and and go to all the conferences,
talk about it, we got projects, but it was never really taking off. So um after 10 years uh we had to sadly well fold or your investors after 10 years it's a magic number where they will ask you okay it's time to sell the company and try to make money of our investments
10 years that's that's a lot of grace to get I would
yeah so we we got along with like 8 million is a lot of money right but it's uh with a team of whatever 30 people it's not so much eventually if you're not making a lot of revenues. We had an office in San Francisco really uh full speed. Um eventually, yeah, it didn't it didn't work. So, we had to do something else and um went into M&A. Nobody wanted to buy us. Still crying a bit. Um but eventually we bought back the company and then we pivoted into um real time multiplayer. And this time it
was a good idea. It was a right timing. It was Unity was just starting to become a thing back in the days which is I think a lot of people here are benefiting uh from what Unity started with um yeah building the first free game engine. So Unreal was pretty much unaffordable for most uh companies
and so that was a timing thing and we were lucky as well to to buy a shell and a team at that point for very uh low amount of money. basically the investors were kind of suffering there um and then it eventually worked.
So that example Kristoff obviously was more of a case of of kind of timing but do any of you have an example of you know now where you still lie in bed at night and you just go oh you know that was that was a decision I took that has had you know long-term ramifications that were that were unanticipated.
So, so you mean in terms of spending money that that didn't turn out to be yeah any valuable? Um, I think we have we started to have a culture of making mistakes and and making wrong decisions. So, it's it's not a problem even to spend money. Um, but what we learned was to um to stop things that were wrong fast enough um and to change direction really quickly. It's still I think something that we are very good at. Um, one thing we had this huge success with Stumble Guys, which was kind of an accident, right? So, we could not really repeat it. So, we thought, oh, maybe it's a good idea so to invest uh or to fund game projects. So, we did that with four studios. Uh, we invested like 600 700,000 something like that. Um, and and yeah, we we didn't get any return on
investment. Was it a waste of money? I I don't think so. I think it was invested great in these teams. Um, would I do it again with different teams?
How about the rest of you guys? Any any cost costly fuckups?
Yeah, I can share one. So, one that annoys me to no end is um back in the Play Raven days, uh my own previous studio, we had an amazing team that was able to build very very high quality games, but kind of realized too late that they really only were amazing at building the game that they can see and feel. So, anything that wasn't on the build was not sort of taken into account when like balancing things or designing UIs. So, we focused a lot on the core gameplay, completely ignored the long-term retaining systems, guilds, progression, inapp purchases. We knew we
were going to build them, but they weren't in the build. So, then the game was completely not balanced. Like the first player experience is amazing, but there was no bridge to the 10th session or the one month game play or like how do you introduce these systems? So like the the learning there would have been get these systems in earlier so the team naturally just ends up polishing the game earlier. So that that took a lot of time and money to fix essentially.
I thought you were going to say hiring a B2B PR agency is your biggest anybody else what what are decisions that you maybe maybe don't regret but have learned from. Yeah, definitely. If I'll continue from that. Uh this goes back in the days in my junior n years. We were like uh this uh basically we started from school went to a company started making a new game there and like uh we were making this uh hero shooter type of game. There wasn't many of those back in the day. And we
were doing really cool stuff. We are actually using photon unity networking for a prototype and tins coins smooth. Everybody loved in the game in the internal tests. But then uh came to a decision. We were still lucky on the art side of things. No monetization but not needed little bit of polish that we could have pushed the game out. But for some reason we decided to make a decision that this is not going to be really cost efficient. We saw that with the other game that uh uh fought on uh Windows servers they were taking little bit of money and even though we didn't have a monetization what not yet in we decided that yeah we need to do things our own way and we made the whole freaking game uh again uh ECS was new in net core just came out for Linux and there were like a fancy tech that we started building we hired some expensive senior eyes to make our wishes come
true. And we did some cool stuff, but obviously it costs a lot more. Uh it took maybe a year longer and well eventually the whole game was killed because uh the team was needed for the other game because it started lacking on the money side. So well it was killed never came out and it's a really shame but
Mhm.
And you mentioned so hiring potentially too early. anything else to
yeah actually these yeah these things are tied together. So you talked about you know building technology or starting to build technology maybe too early or picking you know making something yourself that you could as well you know take as a service. I think those are related in a way that we sometimes uh on the previous company we hired a lot of people to be able to build something and then the the people of course stick with the company and they kind of bloat you and then also the projects take a lot of time. So I think in aggregate the whole the biggest kind of like cost or like
the biggest cost that you can have is building your own tech features that you don't necessarily need at the moment and especially when you have a lot of engineers in the company of course who love to build new stuff. you you kind of like end up with these situations where you have idle hands in the company sometimes and then they start their own tech projects and they kind of blow and then you know so it's very kind of like uh important to me now in this new company that we keep it small we focus on what's current lean too much into the future because of course sometimes even the investors they might pressure you that you might you have to prepare for scaling prepare for big things in the future but I think there's a risk of preparing too early and building these huge monolith technical solutions that when your game doesn't then work, you don't actually need them and you end up end up scrapping them. So those are a waste of money.
Yeah. I mean, I guess it's not too long ago, right, that you know, mobile companies were building their own game engine in order to then build a game. And now we're in an era where there are,
you know, a huge amount of tools available. um you know what should relatively early stage companies I guess look out for in terms of the tools that are available to them? What kind of pricing structures should they look for? You know is it free to start pay as you grow type models? You know how how do you make that decision at an early stage with all of the options available? Well, maybe I can start. uh with this company I was even before raising the round and even actually before gathering the team uh I had a like a game idea very clear in mind what I what I want to make with the next or do with the next company and uh one of the steps um that I took was to go through the available technology because on the previous company so I used to be a programmer that's my background so I'm kind of now also doing that 95% of the time but in the previous company when we were bigger like 30 40 people I wasn't programming anymore more. So I had a high hiatus of like five years that I didn't look at any any of the current tech. So the first thing I did when I kind of left
the company was to just take a few months off and I started to downloaded Unity again went through all the all the technical solutions that there are now. So I I did quite a bit of due diligence and when starting a new company if if you are the type of person that you can do that that helps significantly because then you know also the hires that you need to make because you know the tech stack that you're going to be using. So I think that was a very good kind of like a good thing to do.
Yeah. Yeah. And at least like what we see with the our sort of most successful neighbors, customers, whatever you call it here in Finland, like the clearly the the people making the best choices over here, um are people who have a good idea of what they're going to build, like where they're going to end up, what are they going to they can not necessarily articulate what they need, but like where what kind of problem space we're going to have millions of players, hundreds of millions of players, we're going to have, you know, inapp purchase flows, yada yada. From there, you can kind of break it down into, okay, here's
the stuff we're going to eventually need, but not day one. And then like basically say, cool, let's start with the prototype real-time tech, you know, photon in. And then like work from there into, well, then we're going to build matchmaking systems and long-term retention systems. Cool. All right. Then we're going to need this piece of tech and so on. So, kind of working backwards from actually what do you need to always prove the next step? And then yeah, it's it's cool if you have free tiers like we have, but it's actually even more essential to just get the the right tool for the job. And nobody ever throws any code away. That doesn't happen. So building on on the thing that can you can actually ship on rather than like h we'll figure it out later.
Mhm. Is there anything that that you guys look out for as a potential kind of red flag I guess in in in tool pricing structures? Is there anything you look at and go that's absolutely not the play for us?
Well, obviously you need to mention the install based fees and yeah, Unity.
Thank you. Uh other than that like uh it's really a red flag if you are not sure like what's going on. They are not transparent like where the costs come from. So like transparency definitely important in that end. Yeah, I think from my side the pri like depending on what is a good you know pricing structure for any specific service or or or middleware that you buy. I think it depends on also highly on the game that you're building. For example, if you're building a expecting to build a low LTV ad monetized game with a you know, for example, a lot of instant a lot of CCU, but you're not expecting expecting a lot of revenue per per download. Then of course, some of the even meta player photon can can be expensive solution to some of those games. But that depends solely on the how you want to monetize and kind of like what are you expecting your player base to be and sometimes you don't know that of course. But I think the most important thing um for me has been
trying to select uh technologies or or or services that I know that can scale and the companies will be around and even better if if there's a kind of like a backup solution uh for meaning meaning that if something happens to the service provider how we're going to replace that or can we get access to the source code? Can we do something ourselves if you know something goes wrong? That's that's a big part of it as well. Uh as an example, in a previous company, we were using this analytics platform that later got sold uh to a big gaming company and they stopped like on one week notice and we had been building, you know, months and months of work and and only relying on that analytic service and it shut down literally in a couple of weeks.
Yeah, let's not mention Omniata by name. Yeah, I was trying to avoid it, but yeah, maybe you said it. But but yeah, that's sometimes quite quite costly obviously and it causes a lot of frustration because then you have to rethink your stack in a in a few weeks and that's not easy. So I think one life
hack on the on the pricing stuff um I mean everything's obvious in hindsight but basically pick services that scale based on concurrence based on daily active so usage because in the beginning when you're developing you don't have any money or you don't want to spend the money then those services are basically free like we are able to give out everything we have for free that we spend tens of millions developing and then the cost goes up only when you actually have a game that's you know has a lot of players that has a business going on. Uh so that's how you derisk the beginning part of your development where you're the most kind of insecure about spending money on it. So
that's a good one.
Yeah.
Yeah. Success is never a a problem. So that's my experience. So it's a problem if you're not successful, right? And you just fear cost. So if you would be successful and not make money and you couldn't pay for example Photon, you could always come to us and we would find a solution because ultimately
success leads to revenue and everybody wins. Um I think you couldn't have that conversation with Amazon probably but with Ma Play or Photon. So you you could always meet us on conferences or pick up the phone. We we get rarely phone calls by the way. So, but um sometimes
and how does this decision making around um you know what tools to use and when differ um you know I guess dependent on monetization models kind of you know lifespan of games. I know we're obviously moving we're in an environment where we're moving towards games that ideally have a longer and evolving sort of product life cycle but how do monetization models and sort of genres come into this decision making? Well, I think Chris is right of course that you you mostly like in 95% of the cases you need to worry about the for that kind of that the game never comes out or it fails. So that's kind of it's it's a small concern of course but I I
would still of course always do the calculation which I did that you know when starting this project I calculated what would be the cost of meta play and photo both with a certain amount of DAU CCU what kind of scenarios how how much LTV would would the game need to make you know per user to sustain that and that not to be you know too much of a cost and of course uh the greediest parts of the funnel are always Apple Google at the moment. So that is that is kind of like but you can't do anything about that. But but yeah but I but I mean yeah you still have to be mindful because those accumulate you if you use a lot of services that's great because you have a save time but also those services they all accumulate to the cost of the game. So just to give you an example for example attribution services you sometimes don't look into it unless you do a lot of UA paid UA then you start to figure out oh they also take quite a bit per install. So if you are heavily relying on paid traffic, you end up uh paying the attribution cost, you
end up paying whatever server cost you have. You pay Apple and Google and you know just be mindful and calculate what is the bottom line there. So you know your LTV target by that way.
Yeah, I'll take actually a slightly different angle on the same thing like thinking of genres and so on. So we mostly deal with live service games, right? So that means um large player base, huge amount of content, you plan for like years and years of stuff in the game. And obviously you don't want to do that day one. You want to patch it in as you go. So nowadays we call it live ops and so on. So the cost of that is generally not in tech, but it's rather in your salaries, right? Like how expensive it is for you to ship that game. So then the real question is okay if we are in this these genres how can we push our own salaries down let our own our own human resource cost down by using whatever generative AI on the assets or like very clever overthe-air um like systems for templating events
and like filling the game calendar with interesting content all of that and I think that's where like actually tool choice matters even more than in premium games because that backlog is just so insanely large of stuff that you have to do. Um, which that's where we spend a lot of our time nowadays. But I think that that's it's sort of the almost the flip side of it. It's not what it costs, but like how can I how can I even afford any of it in the first place.
So, moving on, I think I I I was shocked and scandalized just before this panel to find out that most of you guys kind of work together and know each other. So, um, you know, totally totally shocked at that. Um, for for for you guys, Future Run and and Phantom Game Labs, um, what what are some of your stories, I guess, of how you've used this, you know, backend tech, Meta Play, um, you know, uh, the multiplayer uh, services cost effectively, you know, how have you found that experience? What are what are any tips that you would have?
Uh well one one thing to say for sure is uh like uh with meta play for example how we could really reduce the amount of programmers we need is that uh we can put everything to cloud so we don't need like any infra guys or whatn not because yeah again human resources tend to take a lot of money so if a service provider can help there and they have helped us there it's a it's a big plus
yeah for us uh as I mentioned earlier that at at least the kind like tool selection. So, picking the right tool for the job. Even even Phodon, you guys have different solutions for depending on what kind of game you're building. If you're building a like a super um uh kind of like uh low latency game or if you can, you know, go with some other solution if you're building a strategy game or something like that. So, so of course with all the all the service providers, I think it's even more important than the pricing is of course that do you have the like do they have the features that you need for your game and is the is it the right tool and
we've been very happy with the meta play and and and photo stack of course because that fits our game at least at this moment very well. here here.
And so it's about I guess what you're saying is it's about early decisions in you know exactly what your game's road map looks like, what functionality it's going to have uh in order to pick the right sort of tools and services in order to to implement that.
Yeah. Because it's very expensive to change, you know, for example that even we're using photon quantum. So it's a great tool, but it's also would be very hard to then move to something else. So, so we wanted to be very uh very sure from the early on that that can that fits our game. So, we actually tried I I tried fusion as well and you know some other other options but uh do some testing beforehand. I think that's very important and obviously to do that you need to have a very clear understanding of what what is the game that you're building from the get-go even if you don't have the full design document but you need to know the key features that you will need in the future.
Mhm. Actually another take on that which is like related but what we think we obviously talk about this a lot with our customers like how do how do we ship faster right um and one thing that is kind of surprising that we found is that um like we do support our customers as we sit in Slack with these people and you guys have the gaming circle as well so there a lot of times we basically ask cool um what if you know we can help you design some of your systems or give you some feedback maybe you could avoid hiring a systems engineer for example, like maybe we can fill in some of the knowledge blanks in the team and if that can drop one or two from your headc count, that's a huge save. Um, or sometimes just like help uh figure out what what are you building because nobody knows what they're building. That's a discussion, right? So maybe we can help with that. I I think you guys are doing something similar with the with the circle.
Yes, we uh we want to get developers in touch with our engineers. So um and we
came up with the idea it cannot be free because we have like a million uh subscribers. So it's very hard to to know who is serious, who is making something serious and who not. So we have a membership plan where you can basically enter and then you get access to all our key engineers. It's not like you we you get free consulting but if you ask something very interesting, if you report problems, we will help you uh right away. And what you get nowadays with with Meta Play and Photon, you get the best possible tools and you can make an amazing game with a very small team. So I think we are both very proud of especially the small teams of three, four very good engineers, but they can basically launch a game. Well, it it still takes a long time to build a proper game, right? But um yeah, it's insane. And the quality of our tools are most likely better than what you would
get in EA or even Supercell ultimately, right? Which have internal tech, but that's not very good documented. It's not a good product. And important as well from my opinion is um you you don't want to use a tool which may go out of business, right? Which is heavily funded but then is not successful quote unquote. But again ma play and us are like around since a long time. We are cash flow positive let's say and then profitable. So we will be around in 5 years and 10 years uh from now
which to an extent begs the question I guess and I know part of it comes down to you know enjoying working with the tech and pride in building it but it begs the question why are companies still deciding to build functionality like a backend themselves?
Well first of all the the the biggest problem with game development is that it's fun.
It's actually more fun to make games than ship games. Not if you've noticed.
That's true.
But yeah,
I mean it could you've got a you know you've got a background I guess in in in coding and things like that. Presumably you feel like a point of pride in in you know feeling that you've had a very strong guiding hand in the tech that that you work with.
Yeah. And I I I think for example the but just to give an example in the previous company uh we had around 40 people which about 10 were on the back end side and on the analytics side combined. So we had a 10% team just solely supporting the back end and the analytics and the new company we don't we have none. So and how is that possible is obviously using the external stuff and and you're right that building your own systems is fun. It's super fun. It's great but uh it also cost costs quite a bit. And then then um but I think it's a matter of why you ask why
some companies are still building their own stuff and it makes sense if you're a big company you know because of course even that small cost that you you know you can accumulate over time and you can and the good thing of course building your own tech that you can take it to any direction you are completely freehand to do whatever but I think that it doesn't make any sense for a smaller company to do that but after certain I've never worked into a really big company and I don't know when when does it start to make sense but obviously there's a cut off for everything that
that you need to do that.
Maybe like been thinking about this a lot, but it's the classic build versus buy argument and and really kind of boils down into right what is your competitive advantage, right? Like Supercell makes their own client engine because they can shave milliseconds off of the load times. That's competitive advantage to them against Unity, against Unreal. I'm assuming that as a smaller indie team, that's not your KPI. your KPI might be more like I want to ship this game in the first place or you know
make or make a game that nobody has made before. So like you you need to focus on that one secret source and everything else just buy it just buy it you know focus. I think many will obviously know but many won't. Um you know with Meta Play and Photon the it's very difficult to change your back end you know to experience a level of success run into uh you know scaling troubles with a blackbox backend and and and then make a change in decision. Same with you know real-time multiplayer. It's kind of got to be a quite an early decision in the journey or a very early decision in the journey. So what what kind of tips would would you Kristoff and and you Timu kind of offer to developers in terms of when to implement your tech, when to start thinking about it and and maybe also how the two kind of interact.
Uh very good question. So um of course we multiplayer is something
you don't think in a second step really, right? So multiplayer is kind of you either you build a multiplayer game or a single player game usually. Um we want to get the pain out of the way. Do you do you start with a single player prototype because you're raising money? Yeah, of course it makes sense, right? In the first step potentially, but we want to make sure that you could start with a prototype multiplayer already and just go and you don't have to run servers and and we are always there to even help. We do code reviews. We we are there for discussion. So um yeah, the quality in general, the quality of the teams, the quality of the games is going up all the time since I'm in this industry, right? And everything is extremely professional. The teams are getting smaller. Um budgets are getting tighter. Um so it's it's a lot about speed and and
success. And it's this is I I don't want to flip, right? I'm quite happy uh building the shovels for the gold diggers. It's kind of our picture, right? So, everybody need the shovels, but gold is not really uh not everybody's lucky to find that. But of course, we need the the lucky games, right? We need we need So, we are powering uh Peak, for example, which um came out of nowhere. Well, the landfall made one hit after the other, but everyone bigger than the the the previous one and without a peak, without a rainbow, without a gorilla attack, we wouldn't be able to survive. So, we desperately need these uh teams to be successful. So, we are on your team, we are not against you. So, yeah.
Yeah. So, it's kind of similar as in like it's a it's a compliment, right? But topic of today is save money. How do we do this thing on the cheap, right? So then from my point of view the cheapest thing you can possibly do is yeah pick
the tools early because it doesn't really take any extra time to develop on top of Photon or develop on top of Meta Play. It's not a slower way of making a game, but you're at you're all the time kind of in an ambient sense learning the tools on the background and then the tools maybe allow you to try stuff earlier at times like go into real-time multiplayer testing immediately or maybe my pet peeve was go for the long-term retention systems immediately persistence day one um so it's not mandatory but like you know if I if I were to now start a new gaming studio I sort of integrate everything day zero and then start prototyping around even if the prototype is going to go away because then that's going to be the cheapest fastest way to play test
get the early numbers get the sales pitch whatever is my milestone
is there an element you know Kristoff you mentioned kind of digging for gold striking gold is there a argument I
guess that using the right tech at the right time and obviously being cost effective means yes we're all still looking for hits but ultimately we may not need to strike such a other load and have more titles be sustainable um you know than have been the case in the last couple of years.
Yeah, if I would know I would probably do a studio. So we we're happy just spreading our tech and just waiting for success. It's our thing.
Awesome. I'm going to open up um to the audience if anybody has any questions. It's very hard to catch these guys any other time. today.
Make it hard something.
We've got time for one question.
What?
Bring it. Make it hard.
Say Kubernetes in the question.
Okay, if nobody has a question, I'm going to quickfire around. What's one quickfire costsaving tip that each of you would recommend to the audience
today?
Well, I can start. It's a boring one and everyone should know this, but take care of yourself and your health because there's no price tag for your health and uh if your teammates burn out what not, it's it's going to cost a lot of money losing the resources. Most important resources are yourselves.
Yeah, I would just say hire carefully.
Yeah, use free tools.
Yeah. and come ask me as in somebody's done your game before or portions of it before. Talk to your friends. We'll help you out.
Amazing.
Thank you so much,
guys. Yeah. Thank you so much.
Big round of applause for the panel.
All of you shy fins that didn't want to ask any questions, you can find them outside in the hall afterwards. [Music]
[Music]
Auto-generated captions from YouTube — names and numbers may be misheard.
Distilling the key insights…
PocketGamer.biz · 2026
Deconstructor of Fun · 2026
Comments