Hacker Newsnew | past | comments | ask | show | jobs | submit | fedorareis's commentslogin

> I use the reliable mode for sending client inputs to the server: the server needs to be able to recalculate the state of the game reliably, and it's not acceptable for some client inputs to get “lost”. This may cause a bit of latency, and a bit more work for the server, which will have to “rewind” the game a bit further if an input arrives very late, but that's the price to pay for a stable game.

Maybe I’m missing something, but wouldn’t you either want the input to drop or the rewind to not happen at some point? If my network is extremely laggy when I’m playing a multiplayer game I would expect that my attempt to hit an opponent wouldn’t still succeed 1+ seconds later when they have already moved and are no longer in a position to be hit.


Conceptually you didn't hit after they moved. You hit at the right moment in your timeframe. That is sent to the server 1 second later and you were rewarded for the hit from 1 second ago because it calculates the results based on when you made the input, not when it was received. This can even change the result of an encounter (ie rollback).


While I get what you are saying, it seems weird from the standpoint of the other player since they have been out of the engagement area for 1+ seconds. It still seems to me that you would want some sort of cap on the rollback period.


You can think its weird but it turns out to feel the best. After some maximum threshold of lag you'd just have to kick the player. That that threshold is varies with game mechanics.


It is weird, and if I’m reading this right a single player with a poor connection will trigger repeated rollbacks for everyone. It also seems to be client-authoritative? Which is just 100% illegal if you’re at all concerned about cheating. All the problems of peer-to-peer in a client/server package?

It should be:

1. Client input is either dropped or the input is applied but in an unexpected position (because when the user input occurred the client visible state was wrong)

2. On correction, client is rubber banded into the correct positions to match server state; rollback/replayed with correction if the game is deterministic

3. Server-authoritative; if it never reaches the server, the input never existed.


Client side hit detection (with server side validity confirmation) is the standard for competitive games these days. It just feels the best.

You're also fundamentally misunderstanding the design.

> 1. Client input is either dropped or the input is applied but in an unexpected position (because when the user input occurred the client visible state was wrong)

The system is built around rewarding the player for making good inputs and tracking the state in which they made those inputs. It's not as far as "all perspectives are valid" but it's close.

    - Player A moves in to make a hit.  The character starts the hit react.
    - <lag>
    - Player B see's the telegraph and makes a valid block.
    - <lag>
    - Player A receives the rollback and the character moves into the block animation instead of the hit react.  Ideally this is unnoticeable.
Cheating is handled by console DRM and root kits. Similar for Overwatch, similar for Valorant. Such is the state of the art.


Ok what happens in scenario

Player A fires at B at time 0

Player B moves at time 0, causing A to miss

Due to lag, player A receives B movement at time 3

So player A fired at a still target, and hit. Player B moved, and dodged. Rollback would apply to player A.

Does the hit register or no?

If player A receives the rollback, and now witnesses B dodge, but the hit registers anyways, then I don’t see how there can be a server validity check — from the perspective of the server, the state of the game in which A landed the hit never existed

My understanding of AAA fps games is they show the hit animation as a prediction, but it’s still up to the server whether the hit registers. Eg, if I lag in overwatch and everyone stands still, nothing I shoot lands (except by accident). When my inputs finally reach the server, reconciled and replayed on my machine, it turns out I was shooting at a wall.


The current trend is to count the hit. Its very frustrating for the shooter to make a valid hit under the crosshair and miss. Whereas the player that moved has no real obvious way to tell exactly where the player aimed. If this was a defensive move like a shield, then its up to the game mechanics to decide that sort of thing.

> If player A receives the rollback, and now witnesses B dodge

Why would they witness the dodge? They would likely see the VFX of the hit and then the target move slightly faster than they should for a frame.

> from the perspective of the server, the state of the game in which A landed the hit never existed

You can validate that player positions and visibility raycasts and such that you're verifying plausibility. You say "the state never happened on the server" but what does that even mean? You're not replicating look rotation with enough fidelity to know that and its not the job of the server to simulate "what actually happened." The point is to make a fun game so its fine to reward the player.


Found an example that you're correct: https://www.reddit.com/r/AnaMains/comments/14gsuot/whats_wit...

> You say "the state never happened on the server" but what does that even mean? You're not replicating look rotation with enough fidelity to know that and its not the job of the server to simulate "what actually happened."

The video in that post is what I was essentially talking about; the server tracks player A's attack-input, and player B's movements, and ignores the fact that the two don't at all line up. The final reconciliation of the event sequence is nonsensical -- player A is hitting player B in a manner which simply should not work. The violation of game rules / simulation state is occurring, it's just being accepted and ignored (and I don't know what, if any, verification the server is doing here, since actually doing the hit-registration check would reject this).

This is upsetting to me, but so be it.


But if they are doing accessibility they have to create alt text for the icons anyway and that needs to be translated. So the only i18n complexity left would the ltr vs rtl languages and depending on how you place the text they wouldn’t need to really change the layout to accommodate both.


As someone who's done a fair amount of frontend work, the hard part is always squeezing text into a clean UX.

The problem language is usually German, so if you have copy like "share screen", you have to find a way to fit in 12 (2x English) 'M' characters comfortably.


Why does the folder color matter? Is it just because that is what you are used to from a specific OS?

Color helps for some people but when making an accessible design you have to account for color blindness and other vision issues. Which means the icon needs enough contrast and can’t rely on just color to convey meaning, unless the icon is paired with a text label that also conveys the meaning the color was trying to convey.

So while I agree that color iconography can be extremely helpful for the average user, unless it is supplemented by other techniques it can make a product completely unusable for a subset of users


The commenter did not say yellow was important per se, or that the color yellow was the most important property of the icon.

The commenter said that adding distinct colors to icons help users tell them apart.


Folders were always yellow on Windows because people were used to Manilla folders.


In the example, the folder is recognizable as such from just its shape. The color merely makes it more recognizable (because folders are yellow on Windows — it reinforces that the icon depicts a file folder).

For accessibility reasons, you shouldn’t rely on only the color, but that doesn’t mean that color isn’t a very useful property to apply.


I don’t agree that it is obvious that it is more interesting or deep. I have played a lot of hours of Threes and it is mildly more complex because the tiles only move 1 square at a time, but in my opinion that doesn’t actually make it more interesting or deep.


My understanding is that you are correct. If the repo and all of its forks stay private then the only people that would be able to view them are people who have permissions to access those repos.


A red reset button appears in the top right of the cards after you slide the slider.


One of the best ways to affect this is to make complaints to the CFPB. They are the regulatory body that is responsible for making sure the credit bureaus aren’t harming consumers


Those types of suits generally hinge on proving malicious intent


Malicious intent is the standard for public figures. The vast majority of people in Experian’s database are not public figures.


I had a similar issue with people ignoring my availability at my previous company. I just started declining meetings. It forced people to either decide they didn’t need me in the meeting or they would reschedule it


Bing didn’t even release it in the main flow. It is a separate tab within bing like images or maps. So Google could have done a similar thing


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: