views:

114

answers:

2

I am developing an online browser game, based on google maps, with Django backend, and I am getting close to the point where I need to make a decision on how to implement the (backend) timed events - i.e. NPC possession quantity raising (e.g. city population should grow based on some variables - city size, application speed).

The possible solutions I found are:

  • Putting the queued actions in a table and processing them along with every request.
    • Problems: huge overhead, harder to implement
  • Using cron or something similar
    • Problem: this is an external tool, and I want as little external tools as possible.

Any other solutions?

Possible Duplicate:

Web-based game in Python + Django and client browser polling

+2  A: 

Hi,

If I understand your question correct, you should look at Celery which is a distributed task queue. http://ask.github.com/celery/

Mike
This looks interesting, I'll try it.
Gabi Purcaru
+5  A: 

Running a scheduled task to perform updates in your game, at any interval, will give you a spike of heavy database use. If your game logic relies on all of those database values to be up to date at the same time (which is very likely, if you're running an interval based update), you'll have to have scheduled downtime for as long as that cronjob is running. When that time becomes longer, as your player base grows, this becomes extremely annoying.

If you're trying to reduce database overhead, you should store values with their last update time and growth rates, and only update those rows when the quantity or rate of growth changes.

For example, a stash of gold, that grows at 5 gold per minute, only updates when a player withdraws gold from it. When you need to know the current amount, it is calculated based on the last update time, the current time, the amount stored at the last update, and the rate of growth.

Data that changes over time, without requiring interaction, does not belong in the database. It belongs in the logic end of your game. When a player performs an activity you need to remember, or a calculation becomes too cumbersome to generate again, that's when you store it.

Frank Crook
+1 for pointing out maintaining time based functions that let you calculate value when you need them.
Chris Marisic
+1 for providing a better approach to the underlying issue
chrisbunney
Totally agree with you, but.As I am seeing things, my (ajax-based) app user would have his, let's say city population updated whenever he loads the city info (this may be done by him or any other player, possibly once every few seconds - I'm talking big here, because for lower sizes I wouldn't worry about overhead).The thing is, I can make a compromise and update the city population every 20 minutes, which wouldn't hurt neither the user, nor the database.I'm not trying to say you are wrong, I just need to understand this better.
Gabi Purcaru
When the population is updated, Gabi, is the growth rate changing because of something the owner or another did? If so, you update the database when that action is performed. But if the population would continue to grow at that rate, with or without the player being there, then you don't want to update the population in the database. It can be calculated on the fly when you need it. For a static growth rate, (currentPop = popFromDatabase + (rateOfGrowth * (serverTime - timeOfLastUpdate))). If it's exponential, you could write a recursive function or use some appropriate math functions.
Frank Crook
As a matter of fact, population is increased at a constant rate, and a user can "hire" people, so it decreases.The formula idea sounds very good. I think I'll use this. The current people count will be something like rate*timeSinceCityAdded-totalHired
Gabi Purcaru
Oh, and thanks for the good lesson in best practices.
Gabi Purcaru