>> All right.
Good morning guys.
>> Good morning.
>> Welcome. My name is Brendan Vanous.
I'm the Head of Developer Success for PlayFab,
now part of Microsoft as you probably heard.
I will be giving you guys a talk today on
live game operations in
PlayFab and I'll explain the concept as we go along,
but Ted kick it off.
I want to give you
an idea of some of
the changes in the market over the years.
So, this is your projection from 2000, 2001.
These are the top grossing games for those years.
And then you can see, if you look carefully at the list,
there's only one game in the entire list
that transitions from 2000 to 2001.
But if you then project forward to
the era when people born then are going to college,
2016 to 17, there's a huge difference here.
I mean, if you go back to 2000,
2001, actually, there's another aspect to it, too.
Almost all of these are either PC games
or console games of some kind.
You know, handheld, consoles of some type.
But if you look at the 2016 2017 chart,
you're looking at almost entirely mobile games.
And in fact, 70 percent
of them were the same game from year to year.
Now, there's a big reason for this.
These games don't follow the old classic pattern
of spike of usage and then drop off in long tail.
These are games that use LiveOps.
So, LiveOps is all about re-engaging your users,
getting them more excited about staying in the game,
continuing to play your game for the long term.
Some of the quotes we've heard and there's
a LiveOps booklet that we did for this year.
It contains a whole bunch of best practices
and discussions about different LiveOps.
And we talked to a lot
of folks about the industry to pull this together.
A couple of the key quotes that we got from doing
that process were from the SpaceApe and the Nexon guys.
So, the SpaceApe guys,
you can see $80 million revenue.
And they're saying anywhere from
one third to two thirds of that
is directly attributable to their LiveOps programs.
And then Nexon, of course,
the single biggest predictor of success in their games,
they feel is their live up strategy.
So, you don't need to take their word for it.
This is actual data from our servers.
So, there's two games represented here.
I'm not going to say what the first game was.
If you meet me at a party, you're
not going to get me to drink enough to tell you
what the game is because
I don't talk about things that do poorly.
The first game was a game,
they actually had a, I shouldn't say poorly,
they had an incredible launch.
They were featured on iTunes.
I think they were also featured
on GooglePlay for that matter.
So, they went up to huge numbers of users.
You can see here, they were over
two and a half million DAU when they launched.
And then, they sort of sawtooth down
the spikes on the sawtooth
pretty much represent weekend days.
So, they sawtooth down over time and it's
a classic picture of a game that launches big numbers,
fall off, long tail.
The other game though,
this one I will talk about and you guys
may have actually gone to their talk yesterday.
The other game here is
Idle Miner Tycoon from Fluffy Fairy Games.
Now, they did a talk yesterday
too on their live up strategy in
their games and what they're
doing now and going forward with PlayFab.
And if you didn't get to see it,
obviously it will be in the GDC vault later on,
so you'll always be able to watch it there.
But what they did was,
they took their concept and they did
kind of an internal game jam really and in eight weeks,
just eight weeks of development got
their game on to iTunes and GooglePlay.
And then they just iterated on it.
They didn't do anything other
than organic user acquisition.
They just iterated on the game,
worked with their community to get feedback,
kept making updates and changing.
And long about week 130,
you can see there's a little depth
there and then they start climbing.
That's where they enabled
all the LiveOps that they've been working on.
All the things that they worked with us
on and things they planned on their own.
And you can see the growth just
climbs and climbs and climbs and
it keeps going past that.
And this was a garage studio that started out in
just a few folks and
now they're doing exceptionally well.
They've launched their second game Idle Miner Tycoon and,
oh excuse me, Idle Miner Tycoon is the first one.
Idle Miner factories is the second one.
And yeah, there are
chart stretching up past is
because we're a few weeks past and
this keeps going in that direction.
And it's all down to their LiveOps.
So, what exactly is LiveOps?
And it's really, it's the changes that you
make that are designed to boost your retention,
monetization, basically just keeping your players
excited and interested in personalizing their experience.
Doing things that take
the aspects of the things that you're tracking on about
your players and how they play your game and
focusing any experiences that you
then produce on things that you believe
will appeal to those players based upon that information.
So, a lot of this is around
the cosmetic items or
user acquisition, limited time offers.
Events, sales,
things like that are good examples of LiveOps.
What's not LiveOps is actual gameplay content.
So, if you're doing like new game mode,
if you're doing new levels,
that's not really LiveOps,
but you can use
LiveOps to enhance the performance of those.
So, a good example of that might be take your demo.
You might have a number of
different ways that you want to demo the game to players.
If you're doing, this is for
a premium title in particular,
so you might do level 1, 2,
3 for some folks or you might do level 3,
4, 5 for other folks.
What you could do is you could create an AB test in
our system and then just AB test
on that to see which one gets better conversion.
If you see a definite difference
between them then obviously
just collapsed to that AB version and you're good to go.
That way everybody's using that version.
Hopefully, you get better conversion because of that.
So, what is it takes?
So, in the old days,
obviously a game was just a packaged good.
You worked with your publisher,
you get it boxed up, you shipped to the market,
you're down and you moved on to the next game.
With games as service,
what you're doing is you're shipping your game out,
but that's just like the beginning
of your journey with your players.
You're then operating the game,
you're constantly updating it, you're monitoring it,
you're taking feedback from your community
and within all of this,
the most important aspect of it is making sure
that you have the data in
order to analyze the things that you're
doing and see what successful and what's not.
This is kind of an overall map of all
of the back-end components that
you use to run your game these days.
Down at the bottom,
you've got the core game services,
things like player data, logins, guilds,
trading, in-app purchasing, all that sort of thing.
This is all stuff that we
talked about in yesterday's talk.
It's all very fundamental to your game but realistically,
all of that is kind of table stakes these days.
It's things that are important and
you don't want your team to have to bother with them.
Your team should be focused
on the actual game play differentiators.
The things that make people want to
come back to your game over and over again.
The things that make you unique.
But also around the sides of this,
you see once you've got all of these games services,
you have to have them posted somewhere,
you're going to distribute through
different channels whether there
are the different platforms,
whether they are through steam.
How you monetize your game, of course,
is going to be important and how you buy your players.
But at top, this is what we're talking about right
now is your LiveOps tools, your analytics,
everything that it flows into
this concept of managing your game for
the long term and keeping
your players interested and
hopefully maximizing your revenues.
So, the essential building blocks
for all of these then are these.
It's the BI, events, messaging, updates,
store and catalog, promotions,
customer service, and user acquisition.
I'll go through all of these in
brief but the most important one of them is the BI.
And actually, just to highlight,
we'll be talking again
tomorrow afternoon specifically about
real time events within the system and
how those works so we'll get
into more depth on that there.
But in a nutshell,
your real-time data is everything.
Every single thing that goes on in your game.
It's how are your users?
Which ad campaigns are more successful.?
It's the game tuning that you
do and how people respond to it.
Hopefully, using AB test so that you
can try different experiments with it.
See which things work better than others.
It's how you cross promote.
So, you're going to have multiple games over time.
Being able to track upon all these is using
the data to say not
just what games have they played before
and so what games do I want to advertise to them.
Obviously, not a game they played before but new ones,
but also which games are the ones that
you guys put out there are they're more interested in.
If you do both puzzle games on
RPG and somebody plays all your puzzle games,
the next time you put out a puzzle game, clearly,
you're going to want to send that ad to that player.
So, what we did was after
we created all of those fundamental services and PlayFab,
that we built onto it several years back.
It's something we call PlayStream.
So, PlayStream is every event for your game.
It doesn't matter whether it's coming from a client,
from a server, from a third-party integration.
They all flow into the same stream of data.
When I say stream data, Literally mean it.
This follows what, if you've been reading on it.
What follows the server
lists so-called model of computing,
which is a silly name because obviously there's a server.
But, the idea of the server list model is,
let's use like a shopping store example,
like Amazon or anything like that.
In the old days and old site, what you do is,
you would have a process that
where the user is like picking an item.
He picks a jacket, he says,
''Okay, add the jack to my cart.''
So, an old style systems,
the main site would say, ''Okay,
hey cart, add this, the cart would say, ''Okay,
I've added it and then you reflect that to the user.''
That's not how things work
anymore with the server list model.
You have a flow of information,
a stream, and you say, ''Okay,
let it be known that the user
has added this jacket to the cart.''
Down the stream there are consumers,
and in our case those consumers can do
a wide range of things which I'll show you here,
but in the example I'm talking about
with like a shopping cart system you say,
''Let it be known," and downstream,
there is the cart and the cart sees that event,
knows that event is relevant to it,
and uses it to put the information into the right place.
So, in our case, you can see here.
All of the core events up top things like matchmaking,
you've got buying items even just simple logins.
All of the things that are fundamental to our service.
The base APIs is that we already make
available to you have events.
You don't have to send
any events for those they already happen.
You can also generate custom events though.
In this particular example,
there's a crash log for example
so you could log information whenever
your game has an error so that you
can then track on that and do research
on what areas are more common and
help your development team to focus on them.
But, as you see, it all flows into here.
There's a visualization system in PlayFab,
that lets you then see all those events,
but then they also flow through
to the rules and you see down below.
The rules engine is where you can then have all of
these consumers taking actions
based on the events and then,
those can flow into other services
which then flow into other events,
creating that loop of information about your game,
how it's being played, how it's being used.
So, this is an example
of some of the events that you might see in the game.
The top one is a log-in event.
So, in this particular case
the player logged in, let's see.
The player is in this case,
in London, because you can see that the geo information.
The geo lookup is done by
IP address and then in the bottom case,
the event is a custom event for the game.
In this case, this particular game wants
to track whenever a player visits their store.
This is in-game store. And you can track
on custom information within
these events so you can have.
If you want it to track on player killed,
you could give the information about what X, Y,
Z position the player was at, what X, Y,
Z position the player who killed them was at,
so that you can then create heat maps for example.
The rules engine then is where you build out
these rules that take
advantage of all these events coming into the system.
So, in this case, you've got a statistic change event.
So, the statistic change comes in.
In this case, its boss is killed.
This is actually, if I can get time for it
and go quickly saying make sure you get there.
This particular rule is part of one of our demo games,
where whenever the boss event occurs we were
actually sending an email to the player.
That email contains a link,
which is a deep link back into the game.
So, it's a reward email. "Hey, congratulations.
You killed the boss. Click here to 100 gold."
So, the player gets the email. When they click the link,
it gets back to the game then they get to a 100 gold.
So, it's that flow that gets gets
pulls the player back into the game over and over again.
But, you can see in the actions chart there,
which I pulled up as a drop
down for the purposes of showing this off.
There's a lot of different things you can do.
You can also send push notifications to the player,
you can increment statistics,
grant them currencies or items.
You can even ban players if necessary.
One of my customers got
really excited when we first introduced
the system because he had long been tracking
on all the things he knew identified cheaters.
So, all he did was he built a rule set and said,
"Whenever this rule set is met, just ban the person."
Oh, and I should also highlight.
One of the ones you see on here,
''Execute Cloud Script,'' that's
probably the most powerful thing
because Cloud script is JavaScript hosted in our service,
and it will actually be offering a
C# option soon as well,
but that is custom logic,
to keep you right, relatively lightweight logic,
short lived things that you
can call from these actions and
do custom things. What's that?
>> Can I ask a question?
>> Sure. Go for it.
>> Can you set it two actions.
>> Can I do multiple actions? Oh, yeah, absolutely.
What I didn't show you actually you see
where it says, ''Add'' down on the bottom.
Yeah, you can add more actions onto a single thing.
>> So, if those actions are different to each other,
let's say if you grant a [inaudible].
Can you wait for the granting to go through?
>> Oh, you don't need to wait. So, the question is,
can you wait on one action to do the other action?
You don't really need to. When you-.
>> You don't need to but if you want
to make sure how many controls,
you don't want to tell the user, you can remove
all the minorities, you can't declare the player.
>> So, the question is about you
want to make sure that if you grant
an item to a player the players
actually got it before you tell them they've got it.
So, this is all a real time system.
I should really emphasize that all these events
are coming in as soon as they occur.
So, within a second, you got the event,
it hits the rule. All these things fire.
When the item is granted,
and you're sending a pusher or an email to the player,
it's going to take longer for the
push of the email to get to the player because
of just Internet latency
then it's can take for the item
to be granted to the player.
So yeah, you really don't need to worry about that.
But, then one of the more powerful ways you
can interact with your users is
by having user segmentation,
and being able to identify
all the ways that people play your games.
And the goal here,
one of the things that we talk about a lot
is getting to this segment of one.
Being able to have enough rich
segmentation of your players
that every single player gets
a truly customized experience.
And it's kind of a lofty goal and you know,
odds are good that you're going to have
a big enough user base that you're going to
have large groups of people who have
each classification of experience.
But, realistically, if you had a 100 different segments,
the number of permutations
that then falls into means that you really
could in some ways have
experiences that are truly
tailored to the individual user.
One of the things you see on here, because if you look
you can segment users on all kinds of
things and your point earlier about
can you do multiple things you could have five,
six, seven, 10 different filters on this.
So, your segments can be very
tightly-defined or very loosely defined either way.
But like, if I take for example
in here total value today in US dollars,
the amount of money the person spent.
For people who spend a lot of money in games,
particularly the free to play
games specifically I should say.
When they go to the store they really
don't care about your 99 cent items.
They want to see the $99 item that
contains like a million gold and a sort of doom,
and in an invisible plane or whatever.
So, being able to show them a different store,
not necessarily varying prices because,
of course, they can get you into trouble potentially.
But, talked to me afterwards,
using variable pricing as a
interstitial where you're offering
discounts works perfectly.
But, being able to offer a different store where you're
showing different items from the total list that
you have is absolutely a great technique because it's
similar to the grocery store eyeline concept,
where the grocery store puts
up the eyeline in everything they want
to really sell through a lot
because they make the most profit on it.
But in your case, you're basically offering
a different eyeline to every single customer.
Scheduled tasks that are a way
to create some logic
that you want to run across a group of users.
So, in this case, for this specific example,
we're taking the all players
in the segment of active players.
And active players, in this case, I think I defined it,
and just players who played the game within
the last two days.
And you're talking about a new event,
an upcoming event that might have been like,
we had a lot of titles do ''St.
Patrick's Days events,'' just recently obviously.
So, you're going to pre-announce these events,
let them know it's coming up so that people know, "Oh,
there's something unique happening for that title,"
and you know maybe this new costumes I can get,
anything along those lines.
You can also run a scheduled task in
addition to against a segment.
You can also run it against at
the title level itself and that's how you might enable
or disable these events
because you're running it just once the title level,
changing some title data.
So that when players log in,
they're getting new messages a day,
they're getting new information
about the configuration for the game,
and that's what gets used to
drive the actual interaction with the player.
And, as you can see, these things can also be
set to a schedule.
You can either set that to be like
hourly, daily, weekly, monthly,
or you could just set a Scrum definition
of when you want these jobs to run.
Live events then. So, obviously,
a big part of LiveOps
is driving these events for your players
because events and having these like periodic,
special periods of time where
the game is a different experience,
is something that keeps people
interested and keep them coming back.
There's a lot of
different ways you might focus on using events,
for fun, for monetization, the whole list here.
Honestly, a lot of events though are a mix of these.
A lot of them are going to be in the
bottom bullet point where it's really
you're doing it to increase the fun of
the game but you're also doing it
because you're introducing some new content.
So, some examples of that would be like these.
A lot of those screenshots by the way that I use are from
a game called Adventure
Capitalist or Adventure Communist.
These are games from Hyper Hippo,
they've been with us for
a very long time and they've been
nice enough to let us use images from their games,
and actually data from
their games when we're demoing the game,
demoing, excuse me, the service to developers.
But these are just some examples like,
having a launch day party
for your players or special day,
President's Day in this case,
St. Patric's like I said.
The Adventure Capitalist guys
have been building out and events over time where
they have more and more events
and they do these things they repeat
these events every single year and definitely,
we see spikes in their usage
every time one of these comes up.
Messaging to users.
So, there's many systems
within PlayFab to allow you to do this.
You saw that you have like pushing email notifications,
that you can do a scheduled task
to send out messages to folks.
But there's also a message of
the date type system in the service as well,
so that you can use that to
drive information about upcoming events.
So when people log in to the game,
you'll get the set of whatever the most recent message of
the date type messages
that you have in a published state,
so that players can get those and you
can present them to the users however you like.
Content, obviously we have a CDN.
We also have Title Data in the system.
So, there's basically multiple
ways in which you can deliver
new content and information about the game to the users.
So, beyond just the message of the day Title News system,
you have the ability to have files.
So, I know a lot of people are Unity developers,
you might use Unity Asset Packages
as a way to deliver new content to the games.
So you could deliver that through the CDN,
so that it gets to users as fast as possible.
But there's also Title Data,
and that's one of the most fundamental systems because
that's where you can store arbitrarily,
say JSON data or whatever format you
need that contains
configuration information for your game.
And that's where you would then adjust
that as you're doing events,
so that you have different information about
the mechanics of the game and how
they're changed based upon,
tuning the game or based upon the events that are
occurring at any given time.
We've got a complete Store System.
So in the store, you're able to define
products that are for sale to the players, the pricing.
We integrate with receipt validation
from all of the major platforms,
the entitlement systems for
the different console systems.
And then we also have in addition,
some just straight up cash purchase systems
enabled like Steam Wallet,
PayPal, et cetera, things along those lines.
But you then just define your Catalog in the game,
you can define various stores.
And a store is a view of
a subset of items within the Catalogs,
so that you can have that differentiation of,
you might have a store for
just different character classes.
The fighter has one store, the clerk has another store.
But you might have different stores, like I said,
for players who spend different volumes of money.
Somebody who's never purchased anything before,
sure, show them all the 99 cent items.
Somebody who spends a lot of money, no,
show them the expensive items
that's what they want to see.
But you can also see at the top,
as an example of the launch
party that I was talking about earlier.
During your first launch day,
maybe you want to give a half off
price to everybody for everything in your store.
So, when you show these,
this is an example of the store
screen in our Game Manager.
Everything about the game you can
configure through the Game Manager.
We try to be always API first,
so there are admin APIs if you
want to control things through your own scripting.
But the Game Manager's really handy tool
for taking care of all of your configurations.
So, in the store,
you can define the set of items that you
want to have for players and the pricing.
Stores can have different pricing, obviously,
so that you can have
the variations that you're offering to people.
And then, down at
the bottom of the whole set-up for the store,
there's the segment override system.
So, when you have user segments defined,
one of the things you can do, is you can say, "Okay,
so, if the players in this segment versus this segment,
don't show them the base store,
show them a different store."
So, that's specifically how
you would do what I was talking about,
where somebody spends a lot of money,
there are in that segment if users
spends a lot of money, great.
So, instead of showing the base store,
show the wealth store for use of
a common used term that's not
necessarily one that I like, but still.
Okay, so that's the idea of the overall system and it
looks like I actually managed to rush that enough,
that I can actually show you a little bit
of this in practice.
So let me bounce out here,
and go to my dashboard.
So you can see, this is the typical dashboard for a game.
And if I load up my demo application.
I'm going to connect and play.
There we go, so I've just logged in,
I mean, there you go, I'm in San Francisco.
Let's look at the data for that. Okay, so
there's my GPS position based upon my IP address.
And if I then go in and
actually play a round of the game.
And obviously, it's just a demo game
so it's really quick to just tell it, "Go to a level."
Boom, there's all the data that comes through with that.
There we go, I killed the boss,
so it actually sent me an email.
Let me go out to my email.
I can make this. Oh for God's sake, I'm sorry guys.
Let's do that again. Duplicate. There we go.
Have we got it now? Why is it
not showing? All right, there we go.
All right, let me just do that again.
We back out of the game. Log out.
All right, now from the top,
let's connect and play. All right, there's the log in.
The log in data showing you the GPS.
All right, I shouldn't say GPS,
geolocation based on IP, realistically.
And then if I go in and play a level, there we go.
Boom, statistics, I killed another boss,
great, I'm on a roll.
So you can see that all these events are happening in
real time as the players playing a game.
So if I then, and I hope I get the right email account,
I'm actually not sure which email account I set up for
this. It's obviously not that one.
So, if I go to here,
all right, I don't want to take up too much.
Here it is, I actually found it.
So, this is the mail that
was just sent to me that has my,
"Congratulations, you get a 100 gold coin."
So, I'm going to click the deep link URL.
"Granted a 100 gold coins to the player,
virtual currency balance changed." There you go.
So that's an example specifically of using that kind of
an operation in our system to
drive that experience for your player.
So, okay, obviously rapid
fire discussion and rapid fire demo,
I wanted to squeeze a lot of information into
a very short period of time.
We are coming up on the 11:15, so I just wanted to check.
Are there any questions at all I can answer for you guys?
I also grabbed a bunch of copies of
this from our booth to bring over.
Let me go back to my PowerPoint deck here.
Just to talk a little bit about Call to Action.
Basically, the action I
just would like to encourage you over to take.
Go to PlayFab and go ahead and create
your free account, developer.playfab.com.
It's easy to set up an account.
Creating an account automatically gets
you in the free tier,
so you can create a title,
you can start experimenting with it,
use it however you like.
And if you got any questions, we've got
a community forum that's linked
both from our developer site and from our main site.
Feel free to ask any questions there.
We're happy to get you all the info you need.
But think through in terms of your LiveOps strategy,
how you want to apply that to your games?
What things make your game unique?
What things make your game play
experiences unique for your players?
How they can be varied?
All of that, all of the things that
we've been talking about here.
Definitely, like I said,
I grabbed a few of these to hand out here.
Definitely, if you don't already have
a copy, pick up a copy of this.
This is our LiveOps
best practices guide that we put
together specifically for this conference.
We'll be putting it on our site later as well,
but we wanted to give everybody here
an opportunity to get a hold of it first.
And yeah, give us feedback
either at the booth or online, whatever.
We really want to hear from our developer community.
That is specifically how we determine what
our priorities are for the things we do going forward,
is what we're hearing from all of you.
All right, so with that, if there are no questions.
All right, great. Thanks guys.
Không có nhận xét nào:
Đăng nhận xét