Hi David, On Tue, Sep 8, 2009 at 10:24 AM, David Given <[email protected]> wrote:
> > Brandon N. Wirtz wrote: > > You could build one of these... You'd go broke running it. A MUD is > always > > running.. It handles multiple threads and not only accepts requests but > > sends them to the user.. > > I actually *am* building something like one of these (using Java). > > The biggest problem I've got is that GAE has no synchronisation > mechanisms. None. There are transactions, but as they only work on > single entities they're useless. This means that it's very hard to run > game logic that needs to synchronously touch the global database. > Not true - Transactions can encompass entire entity groups. With the correct entity group configuration, you could perform updates on local areas of the map transactionally. > To work round this I've implemented my own semaphore backed by the > datastore; it's extremely nasty but does actually work. I then read the > entire game database out of a blob in a single entity into RAM, run the > game logic, write the database back again, and release the semaphore. > That is also extremely nasty but it does all actually work. (My game's > actually intended to be run on a standalone server, not GAE, but the > persistence layers are all abstracted out to let me host on GAE for > development purposes.) It'll congest rather badly but by the time > congestion becomes an issue I should have a more suitable server. > > Performance isn't bad; I'm usually getting request times of about 500ms > when the server's hot. That breaks down to: > > startup: anything from 10 to 5000ms > db load: 50ms > game logic: <50ms > build client update: 50ms (varies according to the size of the update) > db save: 100ms > > Startup time is very strange. Sometimes it's practically nil, usually > it's 100ms or so, and if the server's not hot it something takes many > seconds (together with weird warnings about failing to start the > finalisation thread). It's all out of my control --- it happens before > the app starts. > > Note that the cheapest part of the whole process is actually running the > game logic! Most of the time most requests take 0ms, as nothing will > have actually happened since the last request... > > > GAE no process can run for more than a few seconds, so you'd have to use > > some polling tricks on the client to ask what happened and have a chron > job > > run the main thread every few seconds... > > I'm running the game logic asynchronously on-demand. After all, you only > need to change things when someone's looking! This works beautifully, > but if it's been a couple of days since the last request it can take a > while; I'm planning to use a cron job to update the server every half > hour or so to avoid this. > > If you're writing a text-based game things will be both easier and > harder. Easier, in that you don't have to do all the complex database > synchronisation between the client and the server that I'm doing, and > harder, because the game logic itself will be more complex and the > client will need to poll much more frequently. (I can get away with a > poll every ten minutes or so. A MUD can't.) > > -- > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── > │ > │ "They laughed at Newton. They laughed at Einstein. Of course, they > │ also laughed at Bozo the Clown." --- Carl Sagan > > > > -- Nick Johnson, Developer Programs Engineer, App Engine --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
