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 :-)

David
09 Jul, 2014, plamzi wrote in the 22nd comment:
Votes: 0
jakesmokes said:
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.

jakesmokes said:
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.

jakesmokes said:
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.

David
09 Jul, 2014, Odoth wrote in the 24th comment:
Votes: 0
Why does everybody call him planzi instead of plamzi?
09 Jul, 2014, jakesmokes wrote in the 25th comment:
Votes: 0
Cuz I'm a moron looking at the page on retina display with max resolution and I am old and wear glasses. Bad combination sorry plamzi :-)
10 Jul, 2014, plamzi wrote in the 26th comment:
Votes: 0
jakesmokes said:
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 guess it's time to ask what exactly you're using for your networking. Is it not CFSocket?

https://developer.apple.com/library/mac/...
10 Jul, 2014, quixadhal wrote in the 27th comment:
Votes: 0
Odoth said:
Why does everybody call him planzi instead of plamzi?


Poor font rendering. :)
10 Jul, 2014, Davion wrote in the 28th comment:
Votes: 0
quixadhal said:
Odoth said:
Why does everybody call him planzi instead of plamzi?


Poor font rendering. :)

Man, I thought it was his name outside of MB or something! It happened so frequently, (and mostly by you, you pedantic!) that I took it as a norm.
10 Jul, 2014, plamzi wrote in the 29th comment:
Votes: 0
Davion said:
quixadhal said:
Odoth said:
Why does everybody call him planzi instead of plamzi?


Poor font rendering. :)

Man, I thought it was his name outside of MB or something! It happened so frequently, (and mostly by you, you pedantic!) that I took it as a norm.


It can't be the font. I'm also frequently known as plazmi.
10 Jul, 2014, Rarva.Riendf wrote in the 30th comment:
Votes: 0
plamzi said:
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.
10 Jul, 2014, hippitydippity wrote in the 31st comment:
Votes: 0
jakesmokes said:
- 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.
10 Jul, 2014, plamzi wrote in the 33rd comment:
Votes: 0
hippitydippity said:
jakesmokes said:
- 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.


How so?


quixadhal said:
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.

Alter Aeon MUD
http://www.alteraeon.com
14 Jul, 2014, Kaz wrote in the 35th comment:
Votes: 0
Make it a feature.

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:
Votes: 0
Kaz said:
your average Diku half-hour-long auto-attack + cast-whatever spam


Maybe YOUR Diku… mine doesn't suffer from number bloat, so there are no players running around with 50K hit points. ;)
14 Jul, 2014, plamzi wrote in the 38th comment:
Votes: 0
Rarva.Riendf said:
>
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….
20.0/40