My question is to do with web games. I have never created one before and cannot find any information to how it is done on updating the players. I want to create a space game. Ive considered the tick based updates which would simply be a cron job updating all the players in x minutes, thats simple. But how does one go about doing time based updates. Example: I create a building it takes x time to build. How do i do that for say 1000 different players and different times. Do i really just have a cron job running every second checking a two columns the start and end dates of the building?
With my space game I would also want to, if i can, use js and somehow have the spaceships close to real time, where you can watch on a canvas the spaceship traveling and it gets updated every x seconds. I can get the information from the database and to the player but would it be reasonable to cron job ship updates for x many players every couple of seconds?
I have also considered web sockets, but i recently read its at the moment insecure and has been removed from some browsers....
I really want to hear from some experienced programmers on this, any links would help as well. Thanks
[web] Updating Players - Tick / Time / Realtime
You can simulate real time updates without the overhead by only actually updating the data when it's actually needed. Plenty of the information will be private to the particular player (army size, amount gold, spaceship positions etc.) and so you only need to update when the player is online. Take your building example. Assuming the building isn't visible by other players and doesn't affect them (ie. it's not defensive) then when the player logs on you can work out which buildings have completed and update accordingly. If they're online, then just have a JS countdown that triggers an update page when it ends.
then when the player logs on you can work out which buildings have completed and update accordingly.
To add to this, you will need to use timestamp's.
@ScottCreations: cron jobs every couple seconds is bad! Real bad. ;]
'...have a JS countdown that triggers an update page when it ends..'
Do NOT have anything like that unless you want your players to cheat as they please.
Do NOT have anything like that unless you want your players to cheat as they please.
@Scottscreations - Can you tell us more about the game you have in mind? Will this be played over the course of an hour or over several months? This will make a difference in the type of technology you'll require.
'..I create a building it takes x time to build. How do i do that for say 1000 different players and different times. Do i really just have a cron job running every second checking a two columns the start and end dates of the building?..'
As cagecrawler and FounderSim mentioned - if it was supposed to be something ogame'ish for 1000 people - you could possibly do with usual requests.
Compare: server time when user clicked 'build', server time now, time required to pass for the building to be ready (built)
A basic example:
1) When some user 'buys' the building -> you store the server time of when it happened in the db
2) Everytime the 'show-this-users-buildings' action is called (for example: when I decide to have a look at my 'kingdom') -> if building status not set to 'built' -> having the above you check in your db how much time has to pass until the building is built:
- If not enough time passed the page displays a nice 'SomeBuilding: will be ready in getTimeLeft()' message
- If enough passed -> update the building status to 'built' -> display it on a page as 'building was built getWhenConstructionStarted() + TimeItTakesToComplete()'
You won't have to check 1000 users every second -> each detail will be updated when needed only. If I click 'buy a building which takes 30 minutes to build', but right after I log off and never come back to the game, my user won't cause you anymore traffic on your server. Then, if someone finds my 'kingdom' after 2 years and clicks on it, the building status will update at this very moment. But the user who called it will just see an old 'kingdom' with a building bought long time ago.
You can use js/ajax for better user experience (calling an action which would GET time left for example, than displaying a countdown timer on the frontend, etc). With a bit of determination and good app design you may achieve a nice real-time gameplay effect (while you won't have to spend tons on server / traffic).
As cagecrawler and FounderSim mentioned - if it was supposed to be something ogame'ish for 1000 people - you could possibly do with usual requests.
Compare: server time when user clicked 'build', server time now, time required to pass for the building to be ready (built)
A basic example:
1) When some user 'buys' the building -> you store the server time of when it happened in the db
2) Everytime the 'show-this-users-buildings' action is called (for example: when I decide to have a look at my 'kingdom') -> if building status not set to 'built' -> having the above you check in your db how much time has to pass until the building is built:
- If not enough time passed the page displays a nice 'SomeBuilding: will be ready in getTimeLeft()' message
- If enough passed -> update the building status to 'built' -> display it on a page as 'building was built getWhenConstructionStarted() + TimeItTakesToComplete()'
You won't have to check 1000 users every second -> each detail will be updated when needed only. If I click 'buy a building which takes 30 minutes to build', but right after I log off and never come back to the game, my user won't cause you anymore traffic on your server. Then, if someone finds my 'kingdom' after 2 years and clicks on it, the building status will update at this very moment. But the user who called it will just see an old 'kingdom' with a building bought long time ago.
You can use js/ajax for better user experience (calling an action which would GET time left for example, than displaying a countdown timer on the frontend, etc). With a bit of determination and good app design you may achieve a nice real-time gameplay effect (while you won't have to spend tons on server / traffic).
Author
Sweet, thanks for the replies. I understand the timestamp idea and the ajax / javascript loading bars and stuff.
What if say user x builds building y and its 3 hrs to build. User X logs off and goes off to work. Comes home after 5 hrs but would still want to reap the benefits of building y for the 2 hrs of it being built. Would you guys run a cron job hourly to check build times? or how would this be dealt with without being inefficient. Would this just be dealt with by using some timestamps, such that. User x logs back in, it reads the time built timestamp and knows how long its been built. It then does an update timestamp and gets say a difference of z. That difference is then added to the resources....or whatever it is....
My 1000 players was a general idea. It may be more or less hard to say. I do plan on having a continuous game.
My setup would be something like
a static server for images and static content.
nginx on the front end for load balancing, if it comes to it but ready for it.
and then i plan on using JQuery / ajax / html5 and perl catalyst on the backend
for the database i want to try postgresql. I hear good things....
Thanks for the replies sorry for the delay as i was waiting for gamedev.net to get back on its feet. So awesome now.
What if say user x builds building y and its 3 hrs to build. User X logs off and goes off to work. Comes home after 5 hrs but would still want to reap the benefits of building y for the 2 hrs of it being built. Would you guys run a cron job hourly to check build times? or how would this be dealt with without being inefficient. Would this just be dealt with by using some timestamps, such that. User x logs back in, it reads the time built timestamp and knows how long its been built. It then does an update timestamp and gets say a difference of z. That difference is then added to the resources....or whatever it is....
My 1000 players was a general idea. It may be more or less hard to say. I do plan on having a continuous game.
My setup would be something like
a static server for images and static content.
nginx on the front end for load balancing, if it comes to it but ready for it.
and then i plan on using JQuery / ajax / html5 and perl catalyst on the backend
for the database i want to try postgresql. I hear good things....
Thanks for the replies sorry for the delay as i was waiting for gamedev.net to get back on its feet. So awesome now.
If you want the game to be 'real time'... ie, a player starts a building at 2:23, it takes 1 hour to complete, so you want it to finish at 3:23.... then you're going to have to go through a lot of trouble. You will need to update information for the player on each page refresh, and store the last timestamp when it was updated. Similarly, you will need to do the same if players can attack and steal resources from other players (ie, update enemy stats right before potential attack). This results in A LOT of updating, which would create a lot of bottlenecking on your server and most likely disturb gameplay. I highly recommend you avoid this approach.
The alternate, and more popular approach is to update in 15 minute to 1 hour intervals (1 hour is the most popular). This way, you can drastically reduce the number of updates your server needs to perform, and it greatly simplifies coding. For this, a Cron job is the best method.
The alternate, and more popular approach is to update in 15 minute to 1 hour intervals (1 hour is the most popular). This way, you can drastically reduce the number of updates your server needs to perform, and it greatly simplifies coding. For this, a Cron job is the best method.
You will need to update information for the player on each page refresh, and store the last timestamp when it was updated. Similarly, you will need to do the same if players can attack and steal resources from other players (ie, update enemy stats right before potential attack). This results in A LOT of updating
Hehe;) Absolutely not, what I said was about quite the opposite - updating ONLY when absolutely necessary, I'll try to reword it when I have a minute so it's less confusing. I can see cron jobbing being ok for some game scenarios / types as well
Hehe;) Absolutely not, what I said was about quite the opposite - updating ONLY when absolutely necessary, I'll try to reword it when I have a minute so it's less confusing. I can see cron jobbing being ok for some game scenarios / types as well
Virtually every page and refresh in this scenario would require a call to your update function. Consider:
Q) User begins building an item that takes 3 minutes to complete. He then either clicks refresh, or changes pages. What do you do?
A.1 Call update(); to check if the item in the queue is finished building. Failure to do this would cause # buildings to be displayed improperly.
A.2 Set a javascript timer that will call update() on completion. This can reduce the number of update() calls, but would be a serious pain to implement. I certainly wouldn't recommend this to a user asking how to use Cron jobs.
Q) A user attacks another user. What do you do?
A) First, call update() for the defenders account to make sure resources are available for the user to steal. Failure to do this would mean all players could defend perfectly by spending all their resources and then logging out. Second, call update() for the attacker to see if any buildings have been completed that would give a combat advantage.
Conclusion: The viability of 'real time' BBG progress is very low. This is why you don't see many implementations of this type of system, and why Cron is so popular.
Q) User begins building an item that takes 3 minutes to complete. He then either clicks refresh, or changes pages. What do you do?
A.1 Call update(); to check if the item in the queue is finished building. Failure to do this would cause # buildings to be displayed improperly.
A.2 Set a javascript timer that will call update() on completion. This can reduce the number of update() calls, but would be a serious pain to implement. I certainly wouldn't recommend this to a user asking how to use Cron jobs.
Q) A user attacks another user. What do you do?
A) First, call update() for the defenders account to make sure resources are available for the user to steal. Failure to do this would mean all players could defend perfectly by spending all their resources and then logging out. Second, call update() for the attacker to see if any buildings have been completed that would give a combat advantage.
Conclusion: The viability of 'real time' BBG progress is very low. This is why you don't see many implementations of this type of system, and why Cron is so popular.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
