Game Design! ? (◄ █ ►)

Got a specific question or suggestion on the game? You ask, the developers answer.

Moderator: SolC Development Leads

User avatar
1DVD4D2UDK
Posts: 2655
Joined: 08 Nov 2012, 00:10
Location: Pioneer, CA
Contact:

Re: Game Design! ? (◄ █ ►)

Post by 1DVD4D2UDK » 05 Mar 2015, 07:24

MadMax1998 wrote:Count me out; I'm too busy finishing the UDK side of our game. Not sure that we should race ahead and show stuff from the next game before finishing the first. You guys be the judge!
I took the new podcast mention to mean, showing an updated version of PG as it looks now - before the final tweaks prior to it's release, but I guess any show & tell would also mean time away from the overall development schedule.

But, if it were put to a vote - I think I'd still lean towards a small S&T Progress Update! :D
After closing your browser, it'll be with you - in back of your mind
waiting to inspire you, by what you've seen, heard, or read today
1DVD, 1DVD4D2UDK, 1DVD-DCLXVI, 1DeViLiShDuDe, @uToPLaY
http://descent-to-udk.deviantart.com http://1devilishdude.deviantart.com

User avatar
1DVD4D2UDK
Posts: 2655
Joined: 08 Nov 2012, 00:10
Location: Pioneer, CA
Contact:

Re: Game Design! ? (◄ █ ►)

Post by 1DVD4D2UDK » 02 Jun 2015, 17:19

I'm curious to know if it's even possible to average player input,
and still have a responsive and interesting game to play? :?: :roll:

To make a game that will undoubtedly be played from anywhere
in the world, with some sort of averaging algorithm between the
players - maybe with a kind of ping compensator, for all fairness.

Since anyone with a monster machine and a business LAN could
very easily dominate the matches with seemingly lighting reflex
response times, if they logged into it from the same city/state.☺
After closing your browser, it'll be with you - in back of your mind
waiting to inspire you, by what you've seen, heard, or read today
1DVD, 1DVD4D2UDK, 1DVD-DCLXVI, 1DeViLiShDuDe, @uToPLaY
http://descent-to-udk.deviantart.com http://1devilishdude.deviantart.com

Sylvester_Ink
Posts: 41
Joined: 13 Mar 2015, 17:12

Re: Game Design! ? (◄ █ ►)

Post by Sylvester_Ink » 03 Jun 2015, 07:40

Drakona made a good point in one of her posts about peer-to-peer gameplay being the most ideal for competitive play. It tends to be fair, since the players share the connection quality with each other. However, the further the distance between the two players, the more ideal a centralized server becomes. At that point, 2 players with good connections will always have a better game using a server than using p2p. Granted there will be a very slight advantage to the player with lower ping, but in a spammy game like Descent, the advantage is generally negligible for players with decent connections. (ie below 100 or so.)

The best network algorithms I've seen in an fps are probably in Warsow, which is VERY fast-paced and twitchy, relying more on good ping than Descent would. (I've seen American and European players play against each other with 200+ ping, and somehow manage to have good games.) The code is open-source, so it's probably worth taking a look.

The upcoming fps, Reflex, also seems to have pretty darn good netcode, but I couldn't say more, since it's closed-source. I'm sure some players have posted brainstorm concepts for netcode on their forums during development, if you're willing to look.

I'm assuming, of course, that the standard UE4 netcode won't be used in the final release.

User avatar
Halogene
Posts: 57
Joined: 18 Apr 2013, 09:47

Re: Game Design! ? (◄ █ ►)

Post by Halogene » 03 Jun 2015, 09:55

For good netcode you can also check Xonotic (a FPS of similar pace to Warsow, also open source). Personally, I have perceived Xonotic's netcode to be even more accurate, or at least its behavior appeals more to me - but note that my opinion may be biased since I'm part of Xonotic's extended team. Also no intent to rate Warsow negatively in any way, it is a great game!

LotharBot
Posts: 44
Joined: 18 Mar 2015, 23:13

Re: Game Design! ? (◄ █ ►)

Post by LotharBot » 03 Jun 2015, 17:49

Sylvester_Ink wrote:2 players with good connections will always have a better game using a server than using p2p. Granted there will be a very slight advantage to the player with lower ping, but in a spammy game like Descent, the advantage is generally negligible
Ping advantage is very noticeable. In D3, every 10ms ping advantage was worth about 2.5% efficiency for me -- which means, in a standard-rules ladder match (play to 20, win by 2), a 20 ms advantage can easily make the difference between winning and losing (20-18 is 52.6% efficiency; 18-20 is 47.4% efficiency, a difference of 5.2%).

In D1, Rebirth used a server-based model (still allowing client-side dodging, but packets were routed through the game host) whereas Retro restored a pure p2p model. It was a lot of work to put it in, but it improved the game drastically -- even between me and Drakona (our computers are less than 25 feet apart.)

In a game like Descent, which is more about movement/dodging than about aiming, client-side dodging is as important as trichording. Minimizing the number of extra hops between players is a high priority. I'm not aware of any netcode model that comes close to matching the performance of p2p for the behaviors most important to Descent.

Sylvester_Ink
Posts: 41
Joined: 13 Mar 2015, 17:12

Re: Game Design! ? (◄ █ ►)

Post by Sylvester_Ink » 04 Jun 2015, 06:13

LotharBot wrote:
Sylvester_Ink wrote:2 players with good connections will always have a better game using a server than using p2p. Granted there will be a very slight advantage to the player with lower ping, but in a spammy game like Descent, the advantage is generally negligible
Ping advantage is very noticeable. In D3, every 10ms ping advantage was worth about 2.5% efficiency for me -- which means, in a standard-rules ladder match (play to 20, win by 2), a 20 ms advantage can easily make the difference between winning and losing (20-18 is 52.6% efficiency; 18-20 is 47.4% efficiency, a difference of 5.2%).

In D1, Rebirth used a server-based model (still allowing client-side dodging, but packets were routed through the game host) whereas Retro restored a pure p2p model. It was a lot of work to put it in, but it improved the game drastically -- even between me and Drakona (our computers are less than 25 feet apart.)

In a game like Descent, which is more about movement/dodging than about aiming, client-side dodging is as important as trichording. Minimizing the number of extra hops between players is a high priority. I'm not aware of any netcode model that comes close to matching the performance of p2p for the behaviors most important to Descent.
The netcode for D3 was pretty darn bad though. It's probably not the best place to look for an example of how you'd want client/server Descent netcode to work.

That's why I suggested Warsow's netcode, as Warsow is focused just as much on movement as Descent. Common 1v1 speeds reach around 250% of the default, players can instantly change directions at any speed, and there are a couple of insta-hit weapons that have to be taken into account.

Halogene suggested Xonotic, and although the initial release had problematic netcode in comparison to its predecessor, Nexuiz, I believe that's been cleaned up by now. However, Xonotic's combat and movement is smoother and more flowing than Warsow's, so I think the latter would better suit the Descent style. (Of course, I could be wrong. No reason not to take the best elements from both.)

Either way, good netcode will be a necessity whether you're using p2p or client/server. And believe me, with good netcode and a ping below 100ms, a 20ms difference should have absolutely no effect on the player, especially not for any fps. (Games based on frame precision, like many fighting games, would possibly have a problem depending on the framelock, but that's a whole different arena of netcode programming.) Remember that average human reaction time is about 200ms, with 150ms being right around the fastest human response. If you get a ping of about half that, it means the round trip for the data should fall below the noticeable rate for human players. Furthermore, you need to give the player instant response on their own part, in order to make the ping nearly invisible to them. The trick is to balance the player's instantaneous response with their interactions with remote opponents, which is where stuff like prediction comes into play. Different games need to use different types of prediction, with a game like Counterstrike focusing on optimizing aim and shooting, while games like Warsow, Xonotic, and Descent focus on movement.

The truth is that while p2p will always be superior over the shorter distance, once you start to get to the higher pings, there are less netcode tricks you can pull that will mitigate the issue. It's also important to note that higher ping becomes less noticeable for human players as long as it's constant. The player can adapt to the ping pretty quickly if it's not too extreme. The nice thing about the client/server method is that a good server can normalize ping spikes from one player and make it invisible to the other. The end result is that even the player with the spikes doesn't notice it.

Also, because Descent has very few insta-hit weapons, and only some weapons with a relatively quick travel speed, a client/server model has an even larger amount of room to work with normalizing ping. (Actually, since the gauss is a spammy weapon, it's not that difficult to work with either.) As such, Descent netcode will certainly be easier to work with than even games like Warsow and Xonotic.

Now I haven't taken a close look at Retro's p2p netcode, nor have I tried it myself (haven't played in the time that Retro was introduced, and since I just finished moving, I'm still trying to find the time to jump back in and see how garbage I've gotten over the years), so perhaps the game plays just fine up to a point. But I guarantee that after that point, client/server will be superior.

To give an example (using totally bs numbers that I pulled out of thin air):
At 0-50 ping, p2p would be transparent and the ideal way to play.
At 51-100 ping, p2p would become noticeably harder to deal with, especially if it's not consistent.
But 40-100 ping, client/server would perform as well as p2p at lower pings, and better at higher pings.
At 100+ ping, p2p would become unplayable competitively, whereas client/server could potentially be competitive at 150, possibly even 200. (But nobody wants 200.)

Of course, this doesn't mean we should drop p2p as an option. It may turn out to be just fine after all. But don't discount a client/server model with good netcode (rather than D3 netcode). This is where players experimenting will certainly help.

User avatar
1DVD4D2UDK
Posts: 2655
Joined: 08 Nov 2012, 00:10
Location: Pioneer, CA
Contact:

Re: Game Design! ? (◄ █ ►)

Post by 1DVD4D2UDK » 04 Jun 2015, 06:44

Thanks a lot guys, it's good to know that this game will have some heavy duty brain power behind the scenes too - while I'm pretty sure Max has already been through a few hoops checking out the best options, to make each clients gameplay experience as close to the next guys as possible to make the best game that could possibly be made with the UDK.
LotharBot wrote:Ping advantage is very noticeable. In D3, every 10ms ping advantage was worth about 2.5% efficiency for me -- which means, in a standard- rules ladder match (play to 20, win by 2), a 20 ms advantage can easily make the difference between winning and losing (20-18 is 52.6% efficiency; 18-20 is 47.4% efficiency, a difference of 5.2%).
Those are some interesting specs there, might have a look at the UDK server logs myself! :)

Part of the reason I'm trying to get more info on this is, I found out from an old admin buddy of mine MJCSD - that steam already has a type of limiting system in place, where only similar machines can log into specific servers with like machines. And in essence limiting the players you can play with, so having the ability to run external servers is easily going to be a plus! :D
While back when we were running UT2K4 servers, both of us usually suffered from less than adequate connection speeds - which was a blessing and a curse at the same time, because he was able to use the high ping to his advantage with leading shots etc. And I had a hard time adjusting to playing that way, and usually ended up getting frustrated at not being able to! :|
Sylvester_Ink wrote: The nice thing about the client/server method is that a good server can normalize ping spikes from one player and make it invisible to the other. The end result is that even the player with the spikes doesn't notice it.
This is basically what I was getting at! :D
After closing your browser, it'll be with you - in back of your mind
waiting to inspire you, by what you've seen, heard, or read today
1DVD, 1DVD4D2UDK, 1DVD-DCLXVI, 1DeViLiShDuDe, @uToPLaY
http://descent-to-udk.deviantart.com http://1devilishdude.deviantart.com

LotharBot
Posts: 44
Joined: 18 Mar 2015, 23:13

Re: Game Design! ? (◄ █ ►)

Post by LotharBot » 04 Jun 2015, 15:20

Sylvester_Ink wrote:believe me, with good netcode and a ping below 100ms, a 20ms difference should have absolutely no effect on the player.... Remember that average human reaction time is about 200ms, with 150ms being right around the fastest human response. If you get a ping of about half that, it means the round trip for the data should fall below the noticeable rate for human players.
That's not how it works. In fact, it's somewhat the opposite.

When you add together the travel time of shots plus ping, and compare those to human reaction plus ship responsiveness, if A < B the shots will hit and if B < A the player can dodge. That means that even a ping of 20 ms is noticeable, because it makes the difference between "I barely dodged" and "that barely hit". Even if you're not working with D3-style terribad netcode.

Yesterday I was playing a D1 game where the host had set the packet rate to 10 pps instead of the typical 30 pps. This means it was an average of 100ms between positional updates instead of 33ms between updates. I noticed it was easier to dodge and harder to hit people -- because there was a longer delay between when I started dodging and when my opponent could see the effects of my dodge, and vice versa. A change of 67ms completely changed the dynamics of the game.

I'm not sure what you think the advantage is of having a server in the middle. It just means more hops -- which means more delays, and ultimately more lag effects. That's a bad thing, not a good thing.

Sylvester_Ink
Posts: 41
Joined: 13 Mar 2015, 17:12

Re: Game Design! ? (◄ █ ►)

Post by Sylvester_Ink » 05 Jun 2015, 05:36

LotharBot wrote:That's not how it works. In fact, it's somewhat the opposite.

When you add together the travel time of shots plus ping, and compare those to human reaction plus ship responsiveness, if A < B the shots will hit and if B < A the player can dodge. That means that even a ping of 20 ms is noticeable, because it makes the difference between "I barely dodged" and "that barely hit". Even if you're not working with D3-style terribad netcode.

Yesterday I was playing a D1 game where the host had set the packet rate to 10 pps instead of the typical 30 pps. This means it was an average of 100ms between positional updates instead of 33ms between updates. I noticed it was easier to dodge and harder to hit people -- because there was a longer delay between when I started dodging and when my opponent could see the effects of my dodge, and vice versa. A change of 67ms completely changed the dynamics of the game.

I'm not sure what you think the advantage is of having a server in the middle. It just means more hops -- which means more delays, and ultimately more lag effects. That's a bad thing, not a good thing.
Well, if you don't have any sort of antilag, then you're absolutely correct. But with good netcode, the small ping difference doesn't really matter.

I did manage to find a bit about Reflex's netcode as posted by the developers, and it seems to be quite similar to how Warsow (and I would assume, Xonotic) does it:
http://www.reddit.com/r/truegaming/comm ... s_netcode/
(The main post gives a bit of background, but the meat of the concept is in the link to the developer's post, which gives the details about how Reflex does it.)

Basically, for any of your own actions, the response should be instantaneous. The actions of your opponent between receiving packets from the server are extrapolated, so they are smooth between packets. Extrapolation may be incorrect, but for smaller timeframes (say, 20ms), they are fairly negligible. The server, meanwhile, ensures that the player positions and actions for the current tick are always correct using backwards reconciliation, so that each packet that's sent out to the players is up to date. The combined use of extrapolation and BR ensures smooth and accurate gameplay, while minimizing the downsides of each method. (ie incorrect prediction and peeking.) Warsow allows you to disable client-side extrapolation, which can help at a higher ping, at the cost of making the game more choppy.

This method is pretty darn good, but it won't solve all problems. The devs do limit the amount of time in which these methods are applied, to prevent errors, so higher pings will start to see the effects of lag. But again, it will provide you with a wider playable ping range than p2p will.

As for the number of hops, that's really inconsequential. The number of hops between me and Google is somewhere around 13 at 48ms, whereas some lousy Warsow server in Russia gets 11 hops for 278ms. All that matters is the ping between the client and the server, which on average will be quicker than client to client. (Due to more reliable, industrial connections.) Antilag methods more than make up for the middle-man.

LotharBot
Posts: 44
Joined: 18 Mar 2015, 23:13

Re: Game Design! ? (◄ █ ►)

Post by LotharBot » 05 Jun 2015, 17:13

Sylvester_Ink wrote:with good netcode, the small ping difference doesn't really matter
No matter how good your netcode, lag will always matter.
Extrapolation may be incorrect, but for smaller timeframes (say, 20ms), they are fairly negligible
"Fairly" negligible... but not entirely. The little things matter.
All that matters is the ping between the client and the server, which on average will be quicker than client to client
The sum of both clients' pings to the server matter. "Anti-lag methods" don't actually eliminate lag, they just move the effects away from symmetric (with WYSYWIG on the client end) to slightly asymmetric.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests