Talk:Netcode

Video games Low‑importance

This article is within the scope of WikiProject Video games, a collaborative effort to improve the coverage of video games on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Video gamesWikipedia:WikiProject Video gamesTemplate:WikiProject Video gamesvideo game articles

Low

This article has been rated as Low-importance on the project's importance scale.

Summary of Video games WikiProject open tasks:

Summary of Video games WikiProject open tasks

AfDs

Rick Jay Glen (1 participant)
Unreleased third Minecraft album (2 participants)
Kelly Metzger (4 participants)
David McGarry (3 participants)
Stumble Guys (8 participants)
Do You Like Horny Bunnies? (8 participants)
Carlos Pesina (3 participants)
Atlus USA (5 participants; relisted)
Danny Mastrogiorgio (2 participants; relisted)
Police Trainer (2 participants; relisted)
Sephiroth (20 participants; relisted)
The Boss (Metal Gear) (6 participants; relisted)
Balloon Brothers (4 participants; relisted)
Enigma Engine (4 participants; relisted)
ClanLib (8 participants; relisted)

Merge discussions

Other discussions

No major discussions

Article, definition, scope[edit]

This is going to be a difficult article to expand, clarify, and source in any meaningful way. Some of the issues with the sources used in the article as it stands that I'm hoping to clear up:

[1] is being abused. DICE never defines netcode the way the Wikipedia opening does in its article. In fact, the article from DICE explains in some ways why the term netcode as used by gamers doesn't make sense.

[2] is not being used exactly correctly. In particular, server tickrate in most engines the rate at which the server simulation is running (which is what the ref says); this does also happen to often be the same rate at which server-client communication is handled (the game loop doing this along with everything else), but the state of the whole world usually isn't sent every tick, nor is communication with every client always processed on every frame (in Source, the rate at which clients are updated is the updaterate, as the Valve wiki states)

[3] assuming the article is coming through Google Translate accurately, it's iffy. It directly contradicts the Valve wiki's definitions of things in places, conflating tickrate and "updaterate", and seems to think the only reason games have a limited tickrate is because of bandwidth considerations.

The term netcode is so so iffy. It only seems to be used by gamers when they're discuss simulation synchronization issues in networked games. There's a host of things that can fall under the netcode blanket; again, the DICE article discusses this, and DICE is very conscious to use scare quotes every time it uses the term "netcode" in release notes. I think there might be merit to this article as some sort of discussion of the gamer's understanding of netcode and the reality of it (encyclopedically, not as an editorial of course), but this is stymied by lack of decent sources. -- Consumed Crustacean (talk) 21:40, 7 September 2014 (UTC)[reply]

Based on that, largely rewritten: [4] though I'm not happy with this because of the continued difficulty in sourcing anything. -- Consumed Crustacean (talk) 00:52, 8 September 2014 (UTC)[reply]

(and it's partially WP:OR, I couldn't get full ref coverage and relied on experience and synthesis of DICE's article to fill the gaps which is bad of me, though the article is no worse in that respect than what it used to be) -- Consumed Crustacean (talk) 01:33, 8 September 2014 (UTC)[reply]

erm, what?[edit]

While the article is clearly a noble effort on someone's part, it's also hopelessly wrong. "Delay-based" networking has been obsolete for almost as long as Internet-scale networked play has existed, since QuakeWorld was released ~25 years ago. Although it's possible that some games have continued to use synced netcode since then, certainly no team with even the tiniest hint of competence in its developers has.

Rollback code is the common implementation these days, but "Standard" netcode simply applies the local user's inputs immediately and forwards them to the server, resulting in the local player having an accurate lagless application of the their own movement and a *predicted* view of their opponents. When the authoritative results of a frame's inputs have been received, the only corrections required for the local player are for cases where an external force has affected their position (knockback from enemy attacks). At the same time, any corrections required for mispredictions of other players' movements are applied (generally over a short interval of 50-100ms to minimize "warping" or "jumping"). Absent those external factors, the local prediction code can be perfectly accurate, to the extent that even complex trickjumps etc can be performed reliably even with pings in the 500+ms range, since the player's local experience remains fluid and immediately responsive to new inputs.

HTH — Preceding unsigned comment added by 71.94.17.231 (talk) 23:52, 25 November 2021 (UTC)[reply]

Rollback netcode, n.: client-side prediction as spoken by people who learned about client-side prediction from articles written by people who read the README of a library written by an author who didn't know the term client-side prediction. Note how Client-side prediction has no link to Netcode or vice versa. I think it's a cute illustration of different development worlds living side by side, making the same innovations without being aware of each other.195.50.168.194 (talk) 07:52, 21 February 2022 (UTC)[reply]

Biased[edit]

Please maintain an impartial view when editing this page. Stef1949 (talk) 21:00, 10 May 2022 (UTC)[reply]