Ta walnalem sie w kwestii eve, mialem na mysli ofc pythona. Eve nie jest napisana w 100% w pythonie. Krytyczne wydajnosciowo obliczenia sa ponoc zaszyte w c albo c++, kiedys widzialem jakiegos newsa od devsow stackless python. Rzeczywiscie c# i java to podobne jezyki, ale pomiedzy np. java a c++ jest przepasc. Wyrazaj sie precyzyjniej. :>

@quasi: wyobraz sobie taka sytuacje, ze klient i serwer zarowno sprawdzaja kolizje... dzieki temu gracze nie wchodza w sciany, a cheaterzy nie zapadaja sie pod ziemie wiem ze dla ciebie to skomplikowane w uj, wkoncu jak to mozliwe by serwer i klient wykrywal kolizje... przeciez cheaterzy moga zmodyfikowac kod i wchodzic pod ziemie... ale wtedy serwer informuje ze jest to niemozliwe, i wysyla do klienta o tym informacje, jezeli gra jest shackowana i olewa takie informacje to owy osobnik stoi sobie pod ziemia i nic nie widzi, tymczasem wszyscy inni widza go jakby stal w miejscu _na_ziemi_ .

no ale rozumiem ze to zbyt skomplikowane dla twojej wyobrazni..

czyli według Ciebie klient ma sprawdzac kolizje i potem server ma sprawdzac to samo? nie uważasz, że jeśli tylko server to sprawdzi to efekt będzie identyczny?zdecydowanie
btw probowales kiedyś projektować/pisać silnik sieciowy, czy tylko tak sobie gdybasz?

Pr0 coderzy od siedmiu bolesci.

http://en.wikipedia.org/wiki/Client-side_prediction
http://en.wikipedia.org/wiki/Dead_reckoning

Wiekszosc zdarzen sprawdza sie i po stronie klienta i na serwerze, bo:
1) Trzeba zakladac ze klient jest zhackowany - wiec wszystko weryfikujemy na serwerze.
2) Trzeba sobie jakos radzic z lagiem, user nie moze czekac na reakcje serwera po kazdym nacisnieciu klawisza - wiec sprawdzamy po stronie klienta.

Client-side prediction is a networking technique used in many modern first-person shooters.

Client-side prediction refers to the process of having the client predict the results of user input before the server has acknowledged the input and updated the game state. So, instead of the client only sending control input to the server and waiting for an updated game state in return, the client also, in parallel with this, predicts the game state locally, and gives the user feedback without awaiting an updated game state from the server.

The earliest first-person shooter to use this technique was Duke Nukem 3D, released in January 1996. Later that year, it was implemented in QuakeWorld, the popular add-on to Quake. While network play was included in the original Quake game, it was optimized mainly for LAN play. Having all had high-speed home connections (a rarity at the time), Quake's designers overlooked their assumptions of high bandwidth and low ping times that made playing online frustrating for dial-up users. After a series of experiments in a long private beta, id software released QuakeWorld with a new predictive model that proved popular with both high and low latency players.

This reduces latency problems, since there no longer will be a delay between input and feedback due to network ping times. However, it also introduces a desynchronization of the client and server game states, which needs to be handled to keep the game playable. Usually, the desync is corrected when the client receives the updated game state, but as instantaneous correction would lead to "snapping", there are usually some "smoothing" algorithms involved.

Another problem, that was highlighted when Half-Life modification Team Fortress Classic was modified to use client-side prediction, is that players with higher latency will introduce inconsistencies into the game, since they are more out of sync, and thus at times can, for example, see (and fire at, and damage) players who (from their view of the game) have already moved behind a wall

Iniside mowil o algorytmach wspomagajacych prace servera? mówił. Czy ja mówiłem o tym, że w Quake'u jest także przekazywany wektor prędkości? mówiłem. Czy w tym artykule jest napisane, że klient sprawdza kolizje? nie.
Poza tym nazwa artykulu to "Client-side prediction is a networking technique used in many modern first-person shooters." so gtfo

A FPS? No tak, to oczywiscie oznacza ze techniki nie stosuje sie w zadnym innym gatunku.

btw, te algorytmy wspomagajace o ktorych mowisz też nie sa takie fajne. dla przykładu w csie jest to znane pod nazwą interp - interpolacja - jest to jakby aproksymacja funkcji, ktora najlepiej odwzorowuje zachowanie obiektu.
w polskim jezyku:
czym wiekszy interp - tym wiecej klatek jest obliczanych na komputerze klienta, a nie branych bezposrednio z ramek przesylanych przez serwer
cl_updaterate - ilosc żądanych klatek od serwera
cl_cmdrate - ilosc klatek wysylanych do serwera na sekunde
cl_rate 20000 (ilosc wysylanych danych)
cl_updaterate 101 (ilosc pobieranych klatek)
cl_cmdrate 101 (ilosc wysylanych klatek)

problem z tym polega na tym, że client sam sobie ustawia te wartości i przez to często i gęsto niszczy gre, lub inaczej mówiąc po prostu hackuje, bo ma takie słabe odświezanie danych, że innym graczom się teleportuje na ekranie. Stąd wiekszosc serverow wymaga najnizszy mozliwy interp
i taki też jest stosowany na klanowkach.

czyli według Ciebie klient ma sprawdzac kolizje i potem server ma sprawdzac to samo? nie uważasz, że jeśli tylko server to sprawdzi to efekt będzie identyczny?

Jest taka drobna roznica kiedy na serwerze jest 32 ludzi a kiedy 2000-3000.

"We want to keep the game exactly as it is," Levy assures us. "What they play now will be what you will play." There is one exception: Mechanics like levelling curve, drop rates, and instance resets will be tweaked for western audiences, as NCsoft believes there lies the gap between the two worlds of gamers. Apart from that, Blade & Soul is a Korean game, and it seems we will be playing a translated Korean game when it comes out.