Using PlayerIO to Scale Your Online Multiplayer Game, Part 1

Oliver from PlayerIO talks about their service for developers, part 1

You can download the podcast here…
http://www.indiegamepod.com/podcasts/playerio-part1-interview.mp3

Or listen to it here…

Show Notes:
Interviewer: Hey, what’s up? Welcome to the Indie Game Development Podcast Show. How about you introduce yourself?

Oliver: Oh, hi. OK. I’m Oliver. I work at PlayerIO, which is a service for game developers. We do sort of the back end platform for games as a sort of Cloud service.

Interviewer: OK. And so, what inspired you to do that?

Oliver: PlayerIO is really a spin-off of our other project which is Nonoba.com which is an older thing we started a couple of years back where we tried to spin up a company in the intersection between game players and game developers. We saw that there was a lot of stuff happening with Flash games, and we sort of wanted to provide tools for developers to make better games and then also provide a better place for these games to be played.

So, we made Nonoba.com as a portal where you both have… It’s both a Flash portal, like you have congregate or addicting games or these other portals. But it also has a lot of tools for the game developers to make games that are integrated into that community. One of the tools we built there was… We built a bunch of stuff. We built a multiplayer service where it’s basically hosted where you build your multiplayer game using SDK locally. And then you host both the client side and the service side to us, and we scale it out over a gaming cluster. And we built a payment service and some other services there.

Sort of what happened though was people were coming, saying, “This is really great. We really love what you’re doing here. We really don’t want to use it because it’s so simple, but it’s tied into this whole Nonoba community brand experience. And we just need it for our companion game, or we need it for something that’s completely wide playable. We’re building a complete end destination, and we want to completely control the user experience. We don’t want to join your brand in there. We just want to pay you for the tools.

Since we were getting enough of these requests, we sort of figured out that, hey, maybe that’s a good idea to actually do that. So, that’s what PlayerIO is. It’s basically the tools from Nonoba.com Version 2 of that, spin out and extract it so they stand on themselves and that you can take them and put the parts you need into your games. The big one we have right now is the multiplayer service, but we’re going to be adding more, of course.

Interviewer: So, the multiplayer service is pretty much Real Time multiplayer for Flash games, or is it for any client? Are you focused on Flash games or other types of ?

Oliver: There’s nothing in the platform that prevents you from using it from anything else, but we have a very, very strong focus on Flash games right now, the reason being we sort of think that in order to be successful you have to focus yourself. And if we’re just all over the place trying to get game developers from all different walks of life into it we would sort of have a harder issue.

We are planning on coming out with… There’s the back end service, and there’s a client library that connects to that. The one we have right now is for Flash, but we are planning on having more for different environments.

Interviewer: What’s the benefit of using your service over, say, SmartFox server or Electro-Server?

Oliver: So, the benefit would be ease of use. That’s one thing. You basically download this package. You get a really, really nice development server that shows you who’s talking, what they’re talking about. You can rent out debug visualizations in terms of just a simple console or show images that you generate live. So, there’s a really, really nice development experience, and when you’re done with that you just take the results that the service side code and you just upload that to our service.

The really nice thing is from that point on, you really don’t have to think about it. You will just know that it will run, and if you have five users it will work. If you have a million users, it will work. It just scales out over that, so you don’t really need to think about scaling. Scaling is a really big thing here; ease of use and not having to worry about the fact whether you have it on one server or 10 servers.

Interviewer: Do you have to pay? You know, like these other servers, you have to pay a huge upfront fee. How does the pricing structure work for you guys?

Oliver: So, currently we have a free model where it’s divided into a free package which would be more than enough for all the Flash games that are out there. We think it’s really generous.

And then there’s plans that are divided into what we think are going to be target customers. So, I should point out that right now we’re still in Beta so we’re not charging anything which we will start charging once we go out of Beta. We have a starting point which is $99 a month and then there’s one in between and then there’s one for Enterprise customers who want support and SNAs and want to have unlimited scaling and stuff. So, there’s different limits on it. You can check them out. All the pricing is on PlayerIO.com/pricing.

Interviewer: So, it’s Play.IO, right? Is it?

Oliver: It’s Player.IO.

Interviewer: OK. Player.IO. Great. And you know, the thing about scaling though is…

Oliver: Player input, output…

Interviewer: OK. So, what about scaling though, everyone says that their service will scale. How do people know that your thing can scale to a million? Are you talking about a million concurrents or what exactly?

Oliver: Yeah. I was talking about a million concurrent.

Interviewer: OK.

Oliver: Of course, we don’t have a million concurrent on that right now. We don’t have the servers spun up for that, but sort of what’s in it is that we monitor load and we can see what’s happening across the cluster and what’s being popular. The way that the service is structured and the way that the API interface that you get as a developer allows us to know that if we see load spiking, then we just add more servers. We can basically spin up game servers as we need them.

Interviewer: OK.

Oliver: So, the whole idea is that we just start more servers as we need them, and then the whole system takes care of distributing across it.

Interviewer: So, you’ve abstracted all the balancing and all that other stuff.

Oliver: Yeah, yeah, exactly. The interface you have as a developer is basically hurry for a list of rooms that match a given criteria, and you can join them or you can create them. Since the unit of work here is really a game room, then our task is just distributing these game rooms across our cluster.

Interviewer: Great. Do you allow enough complexity with your interface so that people can have sophisticated games? Or is this mainly aimed at developing games for the casual players? What’s the target audience that you feel that your API would be able to service in terms of players?

Oliver: This is sort of Version 2 of the API. We’ve had Version 1 on Nonoba for, I think, one and a half or two years now, and it works really well for everything basically. We have 306 multiplayer games on Nonoba, and that’s everything from simple turn-based games to Real Time, live, running around shooting each other up multiplayer games. It really depends on what you want to do. We’ve sort of built it for speed so, for instance, the protocol is a custom binary one, and we try to really, really squeeze as much as we can out of every bit. We’re not sending HTML back and forth over the wire. We’ve done lots of shooting to network ? to be sure we can handle Real Time traffic. You can build anything on top of it.

Interviewer: OK. And, you know, do you guys…

Oliver: It’s not like we have limits and you can only have two people sending turn-based games, you know.

Interviewer: Speaking of turn-based games though, there’s this movement where a lot of players are now actually into asynchronous games. You look at these social games, and a lot of them don’t have Real Time services. They’re more asynchronous. So, what’s really the benefit of doing Real Time when some of the biggest games in the world now are just asynchronous with their friends? And is that a service that you guys also offer?

Oliver: I don’t think you should look at it as an either/or type situation. There’s genres of games. There’s first person shooters, and there’s Real Time strategy games. One might like one. One might like the other ones. Multiplayer games like live action games are really, really fun for when you find somebody that you know and you like to play with, or you have good matching and stuff. That’s why really the asynchronous games are probably what you were just talking about, the Facebook games.

Interviewer: Yeah.

Oliver: They’re sort of in a neat middle place where they’re half a single player game because a lot of them you are just basically playing with yourself, but they’re also half or maybe less about what the other people are doing, just knowing that you’re not wasting time playing with yourself. There’s also other people who are playing.

And I do want to point out that one of the big games on Facebook is actually single poker ? which is a live multiplayer game. So, I think it’s just a matter of what type of game you want to build. One of the strong features about us is that we’re building our service in terms of sort of vertical features, one of them being the multiplayer feature. The next big one we’re going to come out with is a positioned API which basically allows storing for data without having to think about, you know, what happens if I have lots of users.

Interviewer: So, basically you’re going to provide the database that will have unlimited scaling for gaming. Is that what you’re trying to do?

Oliver: That’s the idea.

Interviewer: You know, the thing is that’s–how is that going to be any better or different than something like Apagin ? or a service like RightScale.

Oliver: Well, I’m trying to find a good comparison. Let’s say, if you’re comparing SmartForks to us, for instance.

Interviewer: Yeah.

Oliver: Then, that’s sort of the same as comparing the persistent things with somebody else. Our focus is games, only games. You could build a ? on top of it, or some other stuff like that. But, we don’t support video and just audio chats, that sort of thing. We just support games, and we’re tuned for games which means that the whole way the API is structured and the way that you build it and the development server works, it’s just made for the game development experience.

Interviewer: Sure.

Oliver: So…

Interviewer: OK, go ahead, go ahead.

Oliver: I’m not sure I had more.

Interviewer: No, that’s fine. What I was going to ask is from your persistent API are you going to use SQL or no SQL or how are you going to be able to scale?

Oliver: It’s a bit too early for us to talk about it, but it won’t be SQL. It will be some sort of API that we think is appropriate and then we’ll take it into Beta and we already have some developers working on it. And then, based on the feedback we’ll go back and refine it so we’ll have something that works for what people are doing in games.

Interviewer: OK.

Oliver: So, in games you’re not doing OLTP type transaction management and all this sort of stuff. You just want, you know, to load some objects and shave them back.

Interviewer: OK. Great. I think that’s a good stopping point. We’ll continue with the second part of this in a bit. Thank you. Thanks a lot.

Oliver: OK.