Indie-Resource.com

Hello hello,

For those that have not read my introduction I am stating a game like Travian.

I have a few ideas how I want to get this working and I thought I would run them by the more experienced members here.

I plan on having table for each user that has a field in it “events”. This will tell if that player has an event or not. At the same time an “events” table will hold info like user, event time, and event type (maybe code to execute?). This would settle events like battles and buildings leveling up. I think this page backs up this method http://buildingbrowsergames.com/2008/07 ... d-of-cron/

Meanwhile countdowns for those events would be handled on the user’s side basically using a sleep and echo.

Does this sound…sound? I am not asking anybody to write code for me...just wondering if I am going in the correct direction. Thank you all in advance.

I would not suggest having a table for each player. While it is likely that you will have a moderately sized community where it wouldn't be a problem, you always want to leave room to grow. Nothing is worse than having a sudden flood of users wanting to sign up for your game, only to realize that you will have to re-code large portions of your game to handle them. They will have found another game long before the changes could be made.

Also, maybe I am not understanding what you are proposing, but I don't understand how the "on-view" method relates to your idea. That was a method to just compare current time to last action time stored in the db instead of using crons. We would need to know more about your implementation before we could say yes or no. It is likely that the "on-view" method would not be appropriate for situations where two users are trying to act against each other in a timely manner, because you would be setting the responsibility to maintain world integrity on both players. If both players are rapidly clicking links to try to attack each other, there could be massive state conflict issues. There would have to be a ton of conflict resolution code built-in to your game that would likely negate the ease of development that "on-view" is supposed to provide. "On-view" is much more suitable for applications such as virtual pet games, in-game gardening, etc., where state conflicts are not likely to occur.

If you can tell us more about what these events are going to be, and how the gameplay will go, we could likely suggest a course of action.

I would suggest you just follow the tutorial on the link you provided until you get a good grasp on what you really want.

Because it's explanation seems completely compatible with what you need. but like jack said your question is very vague and very hard to properly give a definitive answer.

Thank you for your responses.

Maybe I can elaborate on my idea here a bit. Lets say you have 4 players. All, luckily, named player1, player2, player3, and player4.

Current time is 0000. player1 attacks player 2 and this will resolve at 0200. Player1 never logs back in. Player2 sends troops to attack Player4 and this will resolve at 0100. He does not log on for a while again. Player4 is just a bad player and only comes on every other week. Player3 attacks player one and the attack resolves at 0400.

ok I know that is a bunch of crap to read...but stay with me so I can explain this.

So a table would look something like this

PlayerIntiating------PlayerEffected------------------EventTime---------------------EventType
Player1--------------Player2----------------------------0200--------------------------Attack
Player2--------------Player4----------------------------0100--------------------------Attack
Player3--------------Player1----------------------------0400--------------------------Attack


It is now 0500 and player3 logs on.

Since neither player1, 2, or 3 log back in for a while these would go unresolved forever. But at 0300 Player3 makes an event that effects Player one. This would make it look at Player1, see that he had an event and resolve the 0200 attack. The 0200 attack effects Player2 though so it would have to resolve the attack at 0100. The results of 0100 are tallied, the troops that survived are put in Player2's village along with resources stolen. The results of 0200 are tallied ect.

For player3 this shouldn't really take too long. And when he logs on it looks like it all already took place. When player4 logs on a week from now he will have the illusion this happened in real time.

Long I know...but does that make sense?

Ok, the "on-view" method may actually work for you. Now when you say "will resolve at 0200", what lengths of time are we talking about? Are you meaning "...will resolve at:

1. 2:00pm
2. in 2 minutes
3. in 2 seconds
4. in 200 milliseconds

1 & 2 would likely work. 3 and 4 could be putting too much strain on the server, and "on-view" is likely to cause state conflicts. "on-view" can work great, and is the basis for a write-up I made on using player actions to update world states. However, if two players are jamming on buttons that both have the capability to update the combat state, this could very likely cause issues and open exploits. However, if attacks can take minutes or hours to resolve, state resolution races are unlikely to occur, but still perhaps possible without careful coding.

What happens if a 5th player is looking to attack any of the players already attacked, before any of them logs in to trigger the updating?

To him, it'd look like they're not touched at all. That, or you'd need to make "scanning" players like the 5th player would do to find his targets update the DB as well...

MAruz wrote:What happens if a 5th player is looking to attack any of the players already attacked, before any of them logs in to trigger the updating?

To him, it'd look like they're not touched at all. That, or you'd need to make "scanning" players like the 5th player would do to find his targets update the DB as well...

Yes, there would need to be a lot of contingency code written into a system like this. Real-time combat in PHP just doesn't work well. You would probably be better off learning something like Jquery and trying to do it in AJAX with all of the game logic done server-side and a real-time interface running client-side.

MAruz wrote:What happens if a 5th player is looking to attack any of the players already attacked, before any of them logs in to trigger the updating?

To him, it'd look like they're not touched at all. That, or you'd need to make "scanning" players like the 5th player would do to find his targets update the DB as well...

I have considered this. And the way I figure it there would be no need to adjust the village. All that player 5 would normally be able to see is that there is a village there that is occuppied by another player. I suppose if the village would be destroyed in the attacks this could be a problem.

Originally I was doing this whole thing in javascript having in mind that it would use ajax like jackolantern mentioned. This works great to show timers and changing resources. But I did not know how to pull and push to a server using it...php made this part easier so I switched language. I guess that I will still be using php to talk to the server?

Well, the problem with trying to have timered events in PHP is that PHP doesn't have a good way to update the player when the timer is up without refreshing, or when they are being attacked. You can use Javascript to run an estimate of what the timer should be at, but that won't always be accurate since they are not actually linked.

php is terrible to use for timed events, it has no way of truly sleeping while other things run. It instead freezes the code. Use JS. window.timeout