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. 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
