|
|
Post by spire on Mar 20, 2016 0:05:51 GMT
Alright, as a person who has no idea whatsoever on developing I don't know how hard or even feasible that would be. My main issue is that I play most of my hours from mobile and as I live and work in wilderness, reception is pretty lame as well as wired connection. So I lose a lot of actions due to lagging communication with the server. That is an issue from my laptop as well. So, my idea is that if a person has a stamina of 100, the server would only check with him (if online) when his stamina reaches 0 or when he clicks on replenish himself. This way he would get uninterruptible actions for 10 minutes or 60 actions. Even if he goes offline in the mean time, he would still be getting the full 60 actions and then be disconnected. If he stays online and goes fatigue, you could have a common number for everyone to be checked i.e. every 10 actions and when they hit the 24 second cap, that number could be raised to 100 to even lower communication with the server. Pros - More daily actions for all players - Less communication between server/player , aka less bandwidth, aka less cost $$. - Probably less errors during battle Cons - None I believe?  |
|
|
|
Post by wildfire2099 on Mar 20, 2016 13:22:28 GMT
I can actually think of several cons.. the biggest of which is that would basically kill chat. You can't have a conversation with someone if you only see responses every 5 or 10 minutes. It would also mess up global boosts, which would what, calculate retroactively? Kick in later (thus having you miss some amount of them every time?) I guess this might be OK as a 'lite' mode with no chat, but certainly not as the new why the game runs.
|
|
|
|
Post by L on Mar 20, 2016 16:05:56 GMT
I really like this idea. Another possibility that would reduce lag while still communicating every action would be to send the message to the server, immediately /assume/ the reply was positive, and then undo that action if the server does not reply positively.
To answer Wildfire's concerns, chat and boosts are already desynchronised from actions - I see both messages and boosts appearing while my countdown is still going.
|
|
Silesia
New Member
how to disappear completely?
Posts: 48
|
Post by Silesia on Mar 22, 2016 7:05:28 GMT
I really like this idea. Another possibility that would reduce lag while still communicating every action would be to send the message to the server, immediately /assume/ the reply was positive, and then undo that action if the server does not reply positively. To answer Wildfire's concerns, chat and boosts are already desynchronised from actions - I see both messages and boosts appearing while my countdown is still going. This would not work, as actions are initiated by the client, but calculated by the server. It's the server that checks how strong your character is and how strong the mob is, and runs some randomization to decide who wins the battle. For your suggestion to work, the server would need to initiate battles, which means it would have to keep a 6 seconds timer for every single person who's playing at any given moment. Personally I don't think this is feasible, but I'm curious to see what Vysn thinks about it. |
|
|
|
Post by L on Mar 22, 2016 11:09:11 GMT
I really like this idea. Another possibility that would reduce lag while still communicating every action would be to send the message to the server, immediately /assume/ the reply was positive, and then undo that action if the server does not reply positively. To answer Wildfire's concerns, chat and boosts are already desynchronised from actions - I see both messages and boosts appearing while my countdown is still going. This would not work, as actions are initiated by the client, but calculated by the server. It's the server that checks how strong your character is and how strong the mob is, and runs some randomization to decide who wins the battle. For your suggestion to work, the server would need to initiate battles, which means it would have to keep a 6 seconds timer for every single person who's playing at any given moment. Personally I don't think this is feasible, but I'm curious to see what Vysn thinks about it. I only meant that the client would start the next countdown as soon as the old one ends, without waiting for a reply from the server. The actual results can be shown once the server replies. |
|
Silesia
New Member
how to disappear completely?
Posts: 48
|
Post by Silesia on Mar 28, 2016 11:49:10 GMT
This would not work, as actions are initiated by the client, but calculated by the server. It's the server that checks how strong your character is and how strong the mob is, and runs some randomization to decide who wins the battle. For your suggestion to work, the server would need to initiate battles, which means it would have to keep a 6 seconds timer for every single person who's playing at any given moment. Personally I don't think this is feasible, but I'm curious to see what Vysn thinks about it. I only meant that the client would start the next countdown as soon as the old one ends, without waiting for a reply from the server. The actual results can be shown once the server replies. That doesn't solve the problem of the server having to deal with strangely timed messages. Imagine the following situation: your client sends an "attack" command with 0,5 seconds latency. Server receives it after 0,5 seconds and processes the attack. 6 seconds after the first attack, your client sends another attack command, this time with only 0,1 seconds latency. The server will now receive the attack command only 5,6 seconds after the previous attack command. What do you think the server should do with this? Should it just accept the command since it was "almost" six seconds after the previous command? That would probably be exploitable. Should it simply reject the command because it came too early? That would be even worse than the current situation. Should it delay processing it for 0,4 seconds, and tell the client to add an offset of 0,4 seconds for its next attack? That would simply not solve anything. Long story short, the command-followed-by-confirmation style of communication is probably the best way to implement Avabur's attack timers, although it's a little sensitive to latency. Sadly there's not much that can be done about that. |
|
|
|
Post by L on Mar 30, 2016 0:52:30 GMT
I only meant that the client would start the next countdown as soon as the old one ends, without waiting for a reply from the server. The actual results can be shown once the server replies. That doesn't solve the problem of the server having to deal with strangely timed messages. Imagine the following situation: your client sends an "attack" command with 0,5 seconds latency. Server receives it after 0,5 seconds and processes the attack. 6 seconds after the first attack, your client sends another attack command, this time with only 0,1 seconds latency. The server will now receive the attack command only 5,6 seconds after the previous attack command. What do you think the server should do with this? Should it just accept the command since it was "almost" six seconds after the previous command? That would probably be exploitable. Should it simply reject the command because it came too early? That would be even worse than the current situation. Should it delay processing it for 0,4 seconds, and tell the client to add an offset of 0,4 seconds for its next attack? That would simply not solve anything. Long story short, the command-followed-by-confirmation style of communication is probably the best way to implement Avabur's attack timers, although it's a little sensitive to latency. Sadly there's not much that can be done about that. No, the commands should be timestamped. Not a novel concept. |
|
Silesia
New Member
how to disappear completely?
Posts: 48
|
Post by Silesia on Mar 30, 2016 6:07:12 GMT
That doesn't solve the problem of the server having to deal with strangely timed messages. Imagine the following situation: your client sends an "attack" command with 0,5 seconds latency. Server receives it after 0,5 seconds and processes the attack. 6 seconds after the first attack, your client sends another attack command, this time with only 0,1 seconds latency. The server will now receive the attack command only 5,6 seconds after the previous attack command. What do you think the server should do with this? Should it just accept the command since it was "almost" six seconds after the previous command? That would probably be exploitable. Should it simply reject the command because it came too early? That would be even worse than the current situation. Should it delay processing it for 0,4 seconds, and tell the client to add an offset of 0,4 seconds for its next attack? That would simply not solve anything. Long story short, the command-followed-by-confirmation style of communication is probably the best way to implement Avabur's attack timers, although it's a little sensitive to latency. Sadly there's not much that can be done about that. No, the commands should be timestamped. Not a novel concept. By the client? That would be way too easy to exploit again. |
|
