09 Jul, 2014, jakesmokes wrote in the 21st comment:
Votes: 0
I think its an interesting idea. ObjC has the notion of dispatch sources which operate on their own threads. You can use those to poll sockets for input and have them processed when received. Those could be added to a command queue and processed in turn with wait timers. I think it would a challenge to tune that, but once you did it would be pretty cool. The way my code is factored (currently), it would be easy to go either way. I could easily implement it both ways and see which works best.
I think there is something warm and fuzzy (from a game perspective) to processing input in turn (varying the order) and making sure everyone gets a shot at having a turn. But doing it the other way could be a lot more flexible. Especially, I think, when it comes to attributes affecting how much can get done in a turn. If someone had a really high dex they could move further (faster) than someone with a lower dex by modifying the way times.
I am glad I found this forum. Its good to have people to talk to about these things :-)
I think its an interesting idea. ObjC has the notion of dispatch sources which operate on their own threads. You can use those to poll sockets for input and have them processed when received. Those could be added to a command queue and processed in turn with wait timers. I think it would a challenge to tune that, but once you did it would be pretty cool.
There's no point in involving dispatch queues for this unless you want to get into multi-threading (which I don't recommend). The method that gets notified when a socket has data is the place where you can handle player input in the order it was received.
I think there is something warm and fuzzy (from a game perspective) to processing input in turn (varying the order) and making sure everyone gets a shot at having a turn.
There's simplicity in that (as in, you can rely on your prior experience designing main loops), but there are also downsides in terms of empty cycles, mini-lagging everyone on every command input, then potentially lagging everyone because one user kicked off an intensive command… In the end, your framework is a lot more suited to event-based handling, which evolved to address precisely those issues.
And you can still make sure everyone has had their turn, in an intrinsically fairer fashion. Just because the model is async doesn't mean that it is easy for someone's input to not get evaluated. As long as you equip everyone with their timers / intervals, missing a turn would be just as unlikely as in a design where you store input and handle it all in a single loop. In the old design, people can still miss a combat turn if you don't set their combat flag on (or don't add them to a list of characters in combat) due to a bug.
But doing it the other way could be a lot more flexible. Especially, I think, when it comes to attributes affecting how much can get done in a turn. If someone had a really high dex they could move further (faster) than someone with a lower dex by modifying the way times.
Right, so one of the many advantages to having individual timers is you can control / modify the length of each interval. Another advantage is that when it comes to periodic procedures / routines for entities such as mobs or items in the game, you can use the same model, and probably some of the same code.
09 Jul, 2014, jakesmokes wrote in the 23rd comment:
Votes: 0
Thanks Planzi,
The only way I know of to get notified of data on a socket is to us a Dispatch Source which in turn manages a queue (in ObjC). I'll poke around and see if I can find what you are talking about. Using a Dispatch Source wouldn't, I don't think, imply a complex thread implementation. I would just think its sole job would be to react to input and populate a command queue.
So I strongly suspect that you are overestimating the impact of the player order by degrees of magnitude.
I strongly suspect you never play pk. A simple example in Diku without using any input command whatsoever. A player start the round, does all its physical attacks, then the second one will use his. Always in that order, since they are ordered in the character list this way because they logged in that order. That means that even with two perfectly equal characters, even with the same exact dice roll, the second one is always screwed. Sorry but I think it is you who are underestimating the impact this has on pk.
Now, I will start this arguing, I expressed what I will eventually do to prevent this problem, you are free to consider this is not one.
ps: the start of the fight is also a problem in itself, as if the first player starts it, the second will be in fight once the loop will parse him, but if the second player start the fight, then all actions will be started at the next violence update loop. Parsing a loop without taking in consideration anything that happened the previous one is definitely a problem.
- I like the idea of reversing the order of players processed. That would be trivial to do and makes a lot of sense.
This gives the characters at the extreme ends of the queue two consecutive turns. That's a huge advantage.
10 Jul, 2014, quixadhal wrote in the 32nd comment:
Votes: 0
It's only an advantage if your combat system doesn't have cooldowns. Since any twitch-based combat is inherently tied to latency as the deciding factor for who wins, it's already unfair by design.
No matter if you use a loop or an event system, every action should have a set amount of time it takes to complete. If you do a roundhouse kick, it takes a certain time to physically complete the kick and be ready to do another action. If you do a jab punch, that takes less time to complete and recover from. Presumably, casting a spell also takes some non-zero amount of time… even if it's "instant".
So, unless your game loop is very slow, slower than the average time it takes to perform attacks, there won't be any consistent advantage to processing people in any particular order.
If you do NOT have cooldowns, then your system is already broken. Someone will write a bot to calculate latency and ensure that it always fires an attack at exactly the right time to be right at the top of the queue.
It's only an advantage if your combat system doesn't have cooldowns. Since any twitch-based combat is inherently tied to latency as the deciding factor for who wins, it's already unfair by design…
Exactly what I was trying to say, except better.
13 Jul, 2014, alteraeon wrote in the 34th comment:
Votes: 0
Better is the enemy of good. Perhaps you should focus on game elements that matter to a larger percentage of your userbase.
Tabletop roleplay solves this issue by using the concept of Initiative. That is, upon entry to combat, dice are rolled (usually based on a stat bonus) to determine in what order combatants take their turn. If having the first strike is really that important (such games tend to be more brutal than your average Diku half-hour-long auto-attack + cast-whatever spam) then this can become something around which players design their characters.
14 Jul, 2014, Rarva.Riendf wrote in the 36th comment:
Votes: 0
>Tabletop roleplay solves this issue by using the concept of Initiative. That is, upon entry to combat, dice are rolled (usually based on a stat bonus) to determine in what order combatants take their turn. If having the first strike is really that important (such games tend to be more brutal than your average Diku half-hour-long auto-attack + cast-whatever spam) then this can become something around which players design their characters.
That is what I plan to do :) (and this is what thaco is if I remind well) And my fights can be very short and can end in 7_8 rounds in average if both players are in offensive stance, so yeah it matters.
14 Jul, 2014, quixadhal wrote in the 37th comment:
> And my fights can be very short and can end in 7_8 rounds in average if both players are in offensive stance, so yeah it matters.
We had to deal with some of that when we added PK to a combat system that had for years been focused on PvE. The way we chose to approach it was to start morphing the skill and affects systems. Usually, the worst offenders, such as backstab for 1000hp, or bash taking people out of commission for too long, can be tuned quickly. But more interestingly, you can start thinking of ways to develop several equally viable modes of PK combat. Someone may choose to max their damage output like they always have, but could leave themselves vulnerable due to low spell resistance or high damage absorption on their opponent.
If you do have multiple equally viable combat alternatives, and common lag amelioration techniques like a command queue, the fact that two people chose "offensive stance" will not compel you to offer crutches to the one who is more lagged at the time. That is, I hope you're thinking of "initiative" as a way to develop alternative combat modes rather than as a band-aid to a combat system that revolves too much around response time.
15 Jul, 2014, Rarva.Riendf wrote in the 39th comment:
Votes: 0
>We had to deal with some of that when we added PK to a combat system that had for years been focused on PvE.
Thank you but this is already a game turned to pk. Two warriors against each other in defensive stance would indeed takes ages to kill each other…
> and common lag amelioration techniques like a command queue,
I thought I made this clear: this has NOTHING to do with lag but only with the fact that it is a turned based game. Think Dungeon and Dragon. If someone can always act the first one juste because he arrived one minute earlier, it definitely is a problem. There is a reason initiative has been invented you know.
15 Jul, 2014, Rarva.Riendf wrote in the 40th comment:
Votes: 0
Btw I find intriguing that you would consider a 7-8 round fight to the death a 'problem' as well….
I think there is something warm and fuzzy (from a game perspective) to processing input in turn (varying the order) and making sure everyone gets a shot at having a turn. But doing it the other way could be a lot more flexible. Especially, I think, when it comes to attributes affecting how much can get done in a turn. If someone had a really high dex they could move further (faster) than someone with a lower dex by modifying the way times.
I am glad I found this forum. Its good to have people to talk to about these things :-)
David