And even if you decide to use channels api, you won't be able to deliver messages fast for masses of users. Channels api doesn't support broadcasting, so looping through users to send messages will take time.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/5DB_p45RCYIJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Jeff
Jeff
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/vobs7E5lllYJ.
You can increase entity update limit by using MS datastore and shards. This way you can have a rate of 100/s for your logical single instance. But don't forget that MS is not reliable, neither memcache or backends. You will face a nightmare trying to make it work fast and reliable.
--
Assuming you want to create an MMORPG (see: the subject line), there's
no way in hell this will work. The persistent-world state is composed
of every player, every monster, and what they are doing at any moment.
Every time a user clicks the mouse or hits a key on the keyboard it
changes the PSW state. Every "tick" of a timer can change the PSW
state. You can't just read and write this to the datastore - the data
volumes would be insane and even if you could afford the bill, the
latency will *destroy* your user experience.
MMORPG games, in my experience, are generally implemented as an
in-memory game state that gets written to a database at intervals.
The in-memory state of a shard is very long-lived; a badly-timed
reboot of a shard usually kicks everyone off the world. You could do
this with a GAE backend but they aren't reliable enough - users get
*very* pissy about getting booted off the server in the middle of
swordfight.
Another thing is that the MMORPG games I'm familiar with have been
implemented as more-or-less single-threaded async systems. There are
a lot of good reasons to do this. Maybe you can make a different
approach work but when you're trying to squeeze tens of thousands of
active players into a single PSW you pretty quickly hit the
scalability limits of synchronous architectures.
So really, if you are serious about building an MMORPG, you do not
want to use Appengine. If you're seriously thinking about using
Appengine, I can tell you right now that 1) MMORPG games are hard to
implement and 2) you don't know enough about how to design them to
make this work. Keep researching, there's a lot of literature out
there... and a few opensource projects to learn from. Even a few
frameworks (commercial and not). They will not run on GAE.
Note that this doesn't encompass all MMO games; you could build a
simple turn-based game on GAE quite easily. But MMORPGs are a
different beast.
Jeff
--
We are the 20%
I worked on The Sims Online and Ultima X Odyssey (sadly cancelled).
Both were sharded the "boring way" - each shard was a separate
city/realm with an entirely separate set of character accounts. If a
shard was too full, it was closed to new players.
Each TSO shard (IIRC, there were 10 shards at launch) was a cluster of
20 top-of-the-line (at the time) 1U servers. Each shard was capable
of supporting 1k-2k peak simultaneous users... rather a disappointing
number for all that hardware, actually. The biggest bottleneck were
the "simulators" which actually ran code hacked out of The Sims PC
game to try to make the world a little more interesting than a chat
room (it didn't). Those poor boxes typically ran at load averages >
500, sometimes > 1000.
I know less about the UXO cluster since the core team was in Austin (I
was at EARS by then) and the product never made it to launch. We
never really found out how it would perform in the real world. It was
doubtlessly less CPU intensive than TSO but it was built with the same
ancient toolkit that EA inherited from some ill-considered acquisition
a half-decade prior. You can probably get a shudder out of most EA
Online veterans just by mentioning Aries/Voltron. At any rate, the
architecture was pretty similar so it's another "big cluster of
machines".
I didn't work directly on the game engine (just the login servers,
account management stuff, online community, etc) so I'd be talking out
of my ass if I offered advice on how to actually build one today...
except one thing: You want a garbage-collected language. C++ is a
horrid tool for the job. I don't think they ever got all the memory
leaks out of the servers... and segfaults take down a whole world. On
the other hand, Go looks like a language specifically designed for
MMORPG programming.
Jeff
everything is designed to kept in ram as much as possible. it's all
FSMs in memory.
On Wed, Dec 21, 2011 at 2:42 PM, Ikai Lan (Google) <ika...@google.com> wrote:
> Hey Jeff,
>
> Just out of curiosity, what did you shard by? Realm/region? Do the shards
> just run on gigantic machines? Does the gating factor tend to be amount of
> combat or players? I don't know if you can share any of this stuff - I just
> love hearing war stories. The game development world is one I know very
> little about.
>
> Fun fact: Alfred on the datastore team knows a TON about video game
> development. =)
>
--
Omnem crede diem tibi diluxisse supremum.
If you shrink the shard, then you have less going on.
In some games they do things like the user can only see so far so you have
hexagons and each Hex is a "shard" and the user pings all the "shards" that
it can see.
Some games have Object lists and you get updates from all the objects (kind
of like twitter, who am I subbed to at the moment)
There are lots of ways to do this, and you have to weight CPU, bandwidth,
Latency, and a number of factors.
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/WhKMhshsY30J.
Persistent world games are hard.
Jeff
--
We are the 20%
Jeff
It is very Massive Much more so than WoW and the Shards are very small, and
no Parties are allowed.
You can craft your own results, but they likely won't be included if they
aren't on WikiPedia.
Ikai Lan:
Jeff Schnitzer:
--
Actually the EVE architecture is almost exactly how I would do it.
Caching proxies serve requests for the state of visible regions. (you may be able to see 4 squares in any direction of you, so you make 25 requests to get data from each square)
Objects have a Type when you interact with an object you interact with instances that handle that interaction.
Since everything else is Read only Presentation you don’t have too many writes or reads.
The world lives in Memcache and Databases.
Where GAE would run in to issues is that Memcache isn’t going to be big enough and Datastore isn’t going to be fast enough.
Now I do have a hack to get around it, that is with in the TOS of GAE…. Multiple Versions of the same ID share Datastore, but NOT memcache. So if you said each region/hex/Square was a version, you could keep the memcaches up to date and have more than enough memcache to have a world.
So you as standing on grid 4,5 you would ask for data from 1,2 1,3 1,4 1,5 1,6 1,7 etc… 25 requests looping through as 1-1.yourapp.appspot.com to keep the world updating, If you interacted with an NPC you’d hit npc.appspot.com with their ID. And Poof everything runs as it should.
Again all http Requests will limit how latency free you are.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/O_PQrnrgegEJ.