Ist so etwas irreparabel oder hat Dice die Möglichkeit das zu verbessern ?
behebbar isses sicher. aber sinnvoll behebbar? wieviele objekte fliegen auf soner map rum? stühle, kisten, tische... kA. unzählige dinger.
so, jetz gehn wir mal von den "großen" geschichten ran: du als client legst irgendwo minen, die position wird dem server bekannt gegeben welcher sie an alle anderen weitergibt, die auch mitspielen. da reicht ne simple x|y koordinate, da der boden ja überall der gleiche is (sein sollte ^^). fährt jetz einer drüber, machts rumms (pos_tank == pos_mine) und es entsteht nen bombentrichter. so, um diesen gehts mir grad. das verändert die landschaft und es wäre blöde, wenn das nur für den minen auslöser (also clientseitig) wäre. der nächste legt minen in den trichter, der server empfängt die x|y koords und bastelt es (da der den trichter nich "kennt") auf die z-koordinate (höhe) "seiner" map. für andere wären die minen jetz also gut sichtbar auf der ebenen fläche, während man selbst sie eigentlich in nem bombentrichter versteckelt hatte.
man muss das also auch mit dem server kommunizieren. hier reicht auch ne simple x|y koord wieder. der server nimmt die, erstellt mit einem gegebenen algorythmus (den der server und jeder client hat) an der angegebenen x|y koord nun den trichter (mittels dieses algorythmusses) und sended die "trichter koords" auch allen anderen clienten - die dann auch wieder "ihre" trichter mit dem selben algorythmus erzeugen. ausrichtung, tiefe usw bestimmt der algorythmus un der is überall gleich - also is auch das loch am ende überall gleich. und alles was man brauchte, waren 2 koordinaten einmalig an jeden senden.
bei so häussern das gleiche. welcher part vom haus wurde grad zerstört? da wird meinetwegen ne objeckt-id übermittelt (zur identifikation des hauses oder was auch immer) und dazu der "index" des zerstörten teils. dann erfolgt wieder das selbe spielchen wie beim bombentrichter und alle haben den selben stand der dinge.
hier kommt erstmalig ein wenig der netcode ins spiel, denn den kann man hier schon mehr oder weniger effizient gestalten. der weg vom clienten der das ereignis auslöste hin zum server und dann zu allen anderen clienten ist "lang". wie lang kann man uU beeinflussen. zum bsp schlägt die rakete bei mir auf dem bildschirm im haus ein - mein spiel sendet dem server die daten, flitzt durch router und leitungen mit lichtgeschwindigkeit irgendwie zum server und braucht dabei 20ms oder so. in der zeit hat mein rechner schon die zerstörung berechnet und führt die animation aus. nun erhält der server die daten und berechnet seinersetis den kram (er kann ja auf die animation verzichten, er braucht die zerstörung an und für sich nur registrieren und vermerken. gut, er muss noch nen timer starten (die trümmer fallen 2 sekunden ausm 2. stock meinetwegen) und nach ablauf dessen prüfen, ob unterhalb der einschlagstelle jemeand zum erschlagen bereit steht ^^ so, jedenfalls hat der server nun seinerseits berechnet und schickt die daten los an all die anderen klients, wo die wand noch immer existiert ^^
gut, das mal als erste "skizze" eines solchen möglichen vorgangs. was könnte man verbessern? man könnte zum bsp optimieren, dass der server erst die daten losschickt an all die anderen und DANN die berechnung startet. zudem könnte man es etwas "fairer" gestalten, indem nich ein client als auslöser fungiert, sondern der server. in dem falle schießt der client die rpg aufs haus ab. nun weis der server, aha, der hat das ding in der richtung abgeballert und wird früher oder später eh den einschlag bemerken ^^ dann schickt er diese info an alle anderen UND den "auslöser" client zurück und startet seine berechnungen. somit haben ALLE clienten die selben vorraussetzungen (ping abhängigkeiten mal aussen vorgelassen ^^
ebenso kann man das schon beim abschuss so machen. man klickt, der server wird benachrichtigt, registriert den start der rpg und informiert den clienten wieder - welcher jetz erst seine rpg abfeuert. genauso sehen alle anderen im selben moment, das er die abgefeuert hat un ned erst zeitversetzt. das das in bf3 so gemacht wird, kann man zum bsp bei lag erkennen. man drückt ab un ne sekunde später fliegt dann auch endlich ma die rpg los ^^
ok, nun zurück zu all den stühlen, tischen und vorallem kisten, welche als deckung dienen könnten. reicht hier ne einfache positionsangabe? bei "unförmigen" objeckten spätestens nich mehr. is die kiste hochkant oder flach aufm boden? macht schon nen unterschied. auch die orientierung (33° nach links gedreht usw) müsste man registrieren. hinzukommt eben die fülle an diesen dingern und man müsste nich nur einmal die daten senden, sondern laufend (ne hauswand sprengt man einmal ab, dann wars das fürn rest der runde - auch der bombentrichter hinterlässt nen bleibenden eindruck. die kisten? die werden laufend verschoben ^^). man hätte also mehr daten zu senden, die anzahl der auslöseobjeckte ist groß (wobei man sich hier noch streiten könnte, ob der unterschied ins gewicht fällt) und man muss "laufend" die daten senden um alles synchron zu halten - un das spiel neigt eh schon zum laggen. noch mehr komunikations-"overhead" wäre nich unbedingt das beste.
also wie gesagt: machbar wär das mit sicherheit, nur obs ein brauchbares ergebnis liefern würde... kA. aber auch hier könnte man versuchen eine "alibi-synchronisation" zu schaffen. der server weiss schließlich genau wie alle clients, wo sich was befindet. wenn er nun einen spieler registriert, der eine kiste bewegt, dann könnte er die "verschiebungsberechnungen" des client rechners "nachempfinden". genauso haben alle anderen clienten diese daten früher oder später und könnten das selbe tun. nur scheinbar spielt hier entweder ne zufallsberechnung ne rolle (ich tret dagegen und mit 30% warscheinlichkeit geht das ding mehr nach rechts als eigentlich gedacht un beim server tritt die warscheinlichkeit ein - bei mir ned -> andre positionen) oder es wird völlig vernachlässigt.
zweiteres würd mich ned wundern oder eben nen mix aus beidem. das resultat is natürlich mist wie man gesehen hat.