necessitates having a platform with low friction. We work hard on the product side of this business to make sure that we've got all the right tools in place, the right interfaces, that we run it in the background. I mentioned before about taking away complexity.
Te job for the 2PP platform is to make it easy to use and a fast to develop platform. If you're a studio looking for the right platform to go with, you care about rates and the price of course, so it's important, but actually, there's no point having a percentage less revenue share to pay if your game is going to be two months late and if it's going to take your client side engineering team three months to make it work with the backend. Tat percentage goes away fast if you're not getting content live, so our job is to build that and make it as easy as possible for the studios.
What are those friction points you typically come across?
It's about building the game engines the right way and making sure the engines we're building perform exactly as expected. 10-15 years ago, game math was relatively straightforward. But now, with this explosion of different mechanisms, whether it's crash games, slots that take the Megaways-type of pattern, cascading symbols, game math gets complex. Having a team at the backend who can read and understand game maths and build the engine right is important and it's a real skill to have, born of experience. Tat's one of the key areas of friction. Te other is the operational day-to-day experience, ensuring the test servers are available and exposing the right backend to be used with the game client integration. It's all those pieces that go on in that cycle.
Fincore offers two variants of these 2PP partnerships - game engine services and full build. Could you just talk me through that process?
Yeah, let me first pick up on those two different models you touched on. Te most common model that we work with our partners on such as IWG, Red Desert and Azure entails building out the game engine whilst they work on the game client. Tey build the frontend and then both are integrated together. However, as you touched on, do have a service as well where we offer the complete build.
So, we'll typically take the game math and the frontend spec, take some Photoshop and graphics files, and we'll build the frontend. Honestly, we prefer the first model where we build the game engine because if you're a studio the player experience is critical to your success. You want your game to be perfect. Tat means you want to sit there and refine the speed of animation a hundred times, tweak colours and change sizing by minute amounts.
We believe that's what studios bring to the party - real finesse and focus on the player experience. Studios should passionately want to own that
74
game client. Although we do both sides, we'll typically work on the first one or two games with the full building, and they'll transition into owning more of the client experience. We care about building a great client as well, but no one is ever going to get their vision across as much as the person whose vision it is.
And how easy is it for studios to exit a 2PP partnership? Because there have been some horror stories of companies who can't exit technically because they're too beholden to who they've partnered with. Tat was at the heart of our decision around the source code licensing. Exactly that situation you outline we saw happening. It's always going to be difficult to a degree when you build on a platform and invest your time in having that platform as the core of your business to try and move away from it, hence the licensing piece so you can take it with you. It goes two ways as well. With my 2PP platform hat on, I'd say that if you invest time with the studio and they build a great business, to see them just suddenly move away is tough.
So, I understand why platforms put in protections, perhaps commitments to have the games available over a longer period or have
Te most common model that we work with our partners on such as IWG, Red Desert and Azure entails building out the game engine whilst they work on the game client. Tey build the frontend and then both are integrated together.
access to the revenue if the game store moves. Because you are investing your own time and business in making this partnership work. But it can be hard for studios to move away, and I guess you need to look at the small print. Make sure you understand what you're getting into.
And if you have a long-term aspiration to own your own platform with a clear path of getting there from early on, understand that untangling yourself is not a quick process. It can take a long time. Sometimes you see an exec saying that our strategy is to move away and own everything ourselves, not appreciating the fact that untangling the commercial and technical complexity is not a small job and it can take a lot of your bandwidth away from running your day-to-day business.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84 |
Page 85 |
Page 86 |
Page 87 |
Page 88 |
Page 89 |
Page 90 |
Page 91 |
Page 92 |
Page 93 |
Page 94 |
Page 95 |
Page 96 |
Page 97 |
Page 98 |
Page 99 |
Page 100 |
Page 101 |
Page 102 |
Page 103 |
Page 104 |
Page 105 |
Page 106 |
Page 107 |
Page 108 |
Page 109 |
Page 110 |
Page 111 |
Page 112 |
Page 113 |
Page 114 |
Page 115 |
Page 116
