Real-time game without Timer?

[Sébastien Tromp]

Hello,

I am currently building a web-based game, and my typical scenario is as follows:

- Player A sends a command to the server. This command is supposed to be fired after n seconds

- Once the n seconds are passed, the server execute the command, and notifies all the player of the game of what has happened. While this command is waiting to be executed, players can send other commands to the queue, which will then be executed in due time.

The issue I have here is the "once n seconds have passed". From what I see:

- Creating a Timer to execute after n seconds is not possible within GAE

- Tasks Queues seem to fit my need. I could  even use the etaMillis to get around the FIFO nature of queues. My concern here is with the delay after which a task sent to a queue becomes available for processing. The Pull Queues Documentation  clearly says that "may be a short delay before tasks recently added using add() become available via leaseTasks()", but there is no such warning on Push Queues.

Would you have a recommendation as to what to use? Is this kind of "real-time" requirement even achievable with GAE?

Thanks for any hint,

-- 

Sébastien Tromp

[Tim Hoffman]

Hi

You probably want to have a look at a resident backend. 

http://code.google.com/appengine/docs/python/config/backends.html#Types_of_Backends

 These could provide the facilities you need to maintain 

a continuous game state and establish an in game time. It could then Pull tasks

or get messages direct from the datastore.

Rgds

T

[Sébastien Tromp]

Thanks for the pointer. I read the documentation on back-end, and it looks like an alternative to handling the tasks in the App Engine standard application, but still keeping the task queue to provide a timer-like feature. Is that correct?

The pros of a backend would indeed be the ability to store more in-memory information to maintain the game state. The only limitation I am seeing now is the current impossibility to use the same channel between front-end and back-end. Which would mean, once my task has been processed, that I need to find a way to communicate the change in the game state to all the other players. Is there a way to do this?

Thanks again for your help :)

-- 

Sébastien Tromp

--
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/-/lFgRyRBonNYJ.
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.

[Tim Hoffman]

Hi Sébastien

Off the top of my head

The resident backend could maintain its own wall clock time, and sit in a busy loop checking for actions to perform via memcache.

It could then put updates back into memcache, the front ends can be keeping an eye on the gamestate updates in memcache (tasks maybe, or  the backend could signal front ends via xmpp)

Just some thoughts.

T

 

[Sébastien Tromp]

Hi Tim,

Thanks for your hindsight. I think I'll first try and play with tasks queues and see how it goes, and then study how to integrate a backend later on when I'm more familiar with all of this.

Thanks again :)

-- 

Sébastien Tromp

--

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/-/1Ln8GBqXiucJ.

[Sébastien Tromp]

Hi again,

I have it working ok for now, not using a backend at the moment (still waiting to see whether I really have the need for it).

However, the countdownMillis() or etaMillis() look rather unreliable (I had tasks that waited for around 100s before being executed, while the countdown was around 10s). The queue is hardly full (at most 5-6 tasks in it, none of which requires heavy processing).

Is there a way using appengine to have a more reliable execution of delayed events? 

Thanks,

-- 

Sébastien Tromp

2011/8/10 Sébastien Tromp <sebasti...@gmail.com>

[Sébastien Tromp]

Precision: in local environment, everything is fine. I have a small difference (around 30 ms) between the time at which the task executes and the time it is supposed to execute.

When deployed on GAE, the differences are usually around 10-15s, sometimes up to a minute and a half.

2011/8/17 Sébastien Tromp <sebasti...@gmail.com>

[Robert Kluin]

No, there is no way to make it more precise. There will always be
some delay and variation. Think of the eta / countdown as a 'polite
request' to execute the task around that time.

If you need precision, Tim's backend suggestion may be your best bet.
There are probably other solutions using cron as well.

Robert

2011/8/17 Sébastien Tromp <sebasti...@gmail.com>:

[Sébastien Tromp]

Cron's granularity is too high (I need precision of the order of the 1/10th second), and would fire too many useless tasks.

I'll have a look as to what I could do with a backend then.

Thanks for your answer,

-- 

Sébastien Tromp

[Robert Kluin]

I was actually thinking more about firing a long-running cron every 5
minutes to do what ever processing you need. However, I still think
backends are probably a better choice.

2011/8/17 Sébastien Tromp <sebasti...@gmail.com>:

[Sébastien Tromp]

If I understand correctly, in both cases I need to retrieve all the objects that are in my cache, extract the ones that need to be processed "soon", and process them. 

Using a backend or a cron changes the environment in which this process executes, but not the process itself. And in this case, a backend seems indeed more suited to this.

Is that what you had in mind?

-- 

Sébastien Tromp

[Robert Kluin]

Yeah, exactly. There are several other variations on the same theme
too. If you were to use long-running tasks or cron-jobs for this you
might need some type of locks or guards in case two run at the same
time. A backend should simplify the process quite a bit since a
process can run for a very long time (24 hours) and you can crank up
the memory; the downside is that backends extremely expensive and they
won't be able to scale as wide as a task-based method.

Robert

2011/8/17 Sébastien Tromp <sebasti...@gmail.com>:

[Sébastien Tromp]

On Wed, Aug 17, 2011 at 11:16 PM, Robert Kluin <robert...@gmail.com> wrote:
>
> Yeah, exactly.  There are several other variations on the same theme
> too.  If you were to use long-running tasks or cron-jobs for this you
> might need some type of locks or guards in case two run at the same
> time.  A backend should simplify the process quite a bit since a
> process can run for a very long time (24 hours) and you can crank up
> the memory; the downside is that backends extremely expensive and they
> won't be able to scale as wide as a task-based method.

Thanks a lot for all your help.
I'll first validate the concept using Crons. It will allow me to test
everything with no or little cost in a first time. And given that the
application is for now in a prototype phase with little traffic, I
think the risk of locking is rather low.
If this go well, I'll look into using a backend, and how to handle
communication between backend and frontend (Tim suggested XMPP, but
from what I saw in the documentation it is not possible to directly
communicate with the frontend).