You will be fine.
The client will send a request for getting the 20 most recent pending games.
The server will return this by a response object, we call it a "game list
data object".
1- You can easily cache this response object using MemCache.
2- You can also query only for keys which is a lot cheaper.
3- You can also cache Game Entities.
Combine these three techniques to get the most out of GAE.
Note that the game list doesn't have to be perfect synchronized and up teo
date because you can always popup "Sorry this game is full, please select
another one".
Op vrijdag 24 augustus 2012 13:27:57 UTC+2 schreef Richard Watson het
volgende:
>
> How large is numPlayersMax, typically? And how big is the gameState field?
>
> On Friday, August 24, 2012 12:37:37 AM UTC+2, Mark wrote:
>>
>> Hi,
>>
>> I'm trying to see if it's feasible to write a game using app engine as
>> the backend.
>>
>> The task I'm most worried about is the discoverability of games. A user
>> can create a new game (which creates a Game object in the datastore). Then
>> other users can hit an endpoint to get a listing of open games, sorted by
>> creation date.
>>
>> Creating a new game will be a very low frequency operation, so no worries
>> there. Users polling for new open games will be much higher in frequency
>> though. Each time a user requests a listing of games, I need to go fetch a
>> page of Game objects from the datastore. Let's say a page size = 20. And
>> the Game object looks like this:
>>
>> class Game {
>> String name;
>> long timestampCreated;
>> long timestampStarted;
>> String mapName;
>> String hostUsername;
>> int numPlayersMax;
>> List<String> playerNames; // usernames of other players currently
>> joined
>> Text gameState; // game state as serialized json string
>> }
>>
>> the query would be something like:
>>
>> select Games where timestampStarted = 0
>> and playerNames.size() < numPlayersMax
>> order by timestampCreated DESC limit 20;
>>
>> First, I'm hoping it's possible to avoid loading the Text field in this
>> listings query since it's not needed for rendering yet. Still there would
>> be a fair number of fields to fetch and deserialize, and I'm afraid my
>> costs would quickly make it impractical.
>>
>> I could try keeping a list of open games in memcache, but not sure if I
>> could achieve consistency between the memcache state and the datastore
>> state of games. Will be looking into that.
>>
>> I've got a very similar game to this already published, using a single
>> jetty instance + mysql on one machine. It's starting to get too much
>> traffic now, and scaling would be a pain. App engine's scalability looks
>> great for something like this, but not sure if the # of writes and
>> inefficient reads I need to perform are a good idea.
>>
>> Any general thoughts on this would be greatly appreciated. I'm starting
>> to dig into this now and any thoughts on how you'd implement the above
>> would be great. In my already-published game (mentioned above), I ran a
>> dark test where I'd call through to a (quickly implemented) mirror of the
>> game running on app engine. It quickly ate through the daily quota!
>>
>> Thanks
>>
>>
--
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/-/Pp3U1srN43EJ.
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.
