3 ms·

I'm considering working with GAE to make a persistent browser-based game. Not serious about it yet, but maybe in another month or two. I have some doubts about

by chipsy 17y ago

I'm considering working with GAE to make a persistent browser-based game. Not serious about it yet, but maybe in another month or two. I have some doubts about staying within the CPU quotas, since I have to take on a processing load in the tick-update loop of game time, but I think I can design it to be spread out somehow.

psawaya 17y ago
I looked into this a while ago, and it seems like GAE still doesn't have a real way for the server to push to the browser (Comet). There's a ticket open for it (http://code.google.com/p/googleappengine/issues/detail?id=377 http://code.google.com/p/googleappengine/issues/detail?id=37...), and it's a feature that's "on deck" (http://code.google.com/appengine/docs/roadmap.html http://code.google.com/appengine/docs/roadmap.html), but who knows when they'll get around to implementing it. As I'm sure you know, regular polling is usually too slow for a game, and counts against your app engine HTTP request quota.
bd 17y ago
I did a very simple game on GAE in its early days and the biggest trouble were very costly writes. Basically you could forget about applications that needed to write game state to datastore in each step. Even the simplest possible writes were already triggering CPU quota warnings [1]. I didn't touch GAE recently, so maybe they already relaxed it a bit, but when it started, it was usable practically only for read-heavy applications (for which Google strongly suggested to use memcached wherever possible). Also moving larger amounts of data between your computer and GAE datastore was massive pain (e.g. backups or initial state load). You had to be very careful not to blow over your quotas, as such imports were doing a lot of writes. --- [1] For example, in early days they counted CPU use in "megacycles": * memcached based ajax request costed tens of megacycles * datastore-read based ajax request costed hundreds of megacycles * datastore-read-write ajax request costed thousands of megacycles
- grandalf 17y ago
  this has gotten much better. Also, they now let you specify what level of consistency you want, which makes writes go a lot faster if you're just putting in a bunch of data or don't need to wait to be sure it's consistent before you put in the next item.

by chipsy 17y ago

psawaya 17y ago

I looked into this a while ago, and it seems like GAE still doesn't have a real way for the server to push to the browser (Comet). There's a ticket open for it (http://code.google.com/p/googleappengine/issues/detail?id=377 http://code.google.com/p/googleappengine/issues/detail?id=37...), and it's a feature that's "on deck" (http://code.google.com/appengine/docs/roadmap.html http://code.google.com/appengine/docs/roadmap.html), but who knows when they'll get around to implementing it. As I'm sure you know, regular polling is usually too slow for a game, and counts against your app engine HTTP request quota.

bd 17y ago

I did a very simple game on GAE in its early days and the biggest trouble were very costly writes. Basically you could forget about applications that needed to write game state to datastore in each step. Even the simplest possible writes were already triggering CPU quota warnings [1]. I didn't touch GAE recently, so maybe they already relaxed it a bit, but when it started, it was usable practically only for read-heavy applications (for which Google strongly suggested to use memcached wherever possible). Also moving larger amounts of data between your computer and GAE datastore was massive pain (e.g. backups or initial state load). You had to be very careful not to blow over your quotas, as such imports were doing a lot of writes. --- [1] For example, in early days they counted CPU use in "megacycles": * memcached based ajax request costed tens of megacycles * datastore-read based ajax request costed hundreds of megacycles * datastore-read-write ajax request costed thousands of megacycles

grandalf 17y ago
this has gotten much better. Also, they now let you specify what level of consistency you want, which makes writes go a lot faster if you're just putting in a bunch of data or don't need to wait to be sure it's consistent before you put in the next item.