Hacker News new | comments | show | ask | jobs | submit login

I wonder what you might actually do is execute AIs on both, and send occasional snapshots of the AI state from the server to the clients.

This gives you the benefit of low-latency on the client (don't have to wait for the server to tell it what the AI is doing) but also avoids security and non-determinism worries. (Although the AI might still be non-deterministic, it probably can't diverge too much before the client receives the next snapshot from the server).

This might be more effort than it's worth, though...






> benefit of low-latency

you achieve the benefit by loosening consistency, i.e. the local ai will have to react to local events before those are acknowledged by the server to see any gain, and the server might come to different opinions because it sees a different state of the game considering multiple clients who are constantly out of sync.

That leads to warping. A rocket, to take an example of an extremely simple entity, might fly a few meters on your screen only to explode right in front of your face because the server sent a message that the flight path was blocked by an online enemy that your client didn't predict.


I don't see how this is an issue. Just imagine that client-side AI is just another player that happens to share the same CPU as the human one. From the server's POV, there's not much difference. Client inputs are client inputs, you always want to have some anti-cheating mechanism in place.



Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: