Wann ein Schwert schmieden?
-
Rechenleistung ist relativ, dein Schmied zum Beispiel könnte so funktionieen das er ausgeblendet wird und erstmal garnichtsmehr tut weil seine arbeitsstelle zu weit weg ist, nachdem du näher kommst und er seine arbeit wieder aufnimmt könnte er einfach die vergangene Zeit errechnen und prüfen was er in der Zeit geschaft hätte, nehmen wir an er schmiedet die ganze Zeit nur, dann hätte er 3h egschmeidet und würde einfach errechnen wieviel er ind er Zeit Geschaft hat.
-
-.-'
manno.
Ich hab mich so doll auf eine Lösung konzentriert, das mir dieser Einfall von dir gar nicht in den Kopf kam.klar. Ist doch logisch eigentlich. Selbst bei größeren Handelssystemen die mehr oder weniger zufällig laufen, könnte man das ja so machen.
thx
vg
-
Dann musst du aber auch beachten, dass Interaktionen im Dorf nicht von der Zeitverzerrung beeinflusst werden. Um bei deinem Beispiel zu bleiben: Was, wenn vorgesehen ist, dass jemand anders sich ein Schwert abholt? Der müsste dann auch einberechnet werden.
Jetzt könnte man denken: "Berechnen wir den auch, wenn ich ankomme." So einfach ist es aber nicht, was wäre, wenn dieser Jemand sich mit dem Spieler getroffen hätte? Oder mit jemand anderem interagiert, der gerade im Moment "aktiv" ist? Je komplexer das System wird, desto mehr wirken sich künstliche Verzögerungen aus.
-
Viele Spiele verwenden vereinfachte Modelle für Dinge die gerade nicht sichtbar sind. (Ich meine Berechnungs-Modelle, nicht Modell im Sinn von 3D-Objekt/Model/Mesh/...)
Bei X² war es z.B. so... wenn man Stationen zu knapp neben anderen Stationen gebaut hat, dann durfte man den eigenen (automatisierten) Schiffen nicht beim Landen zusehen. War man im gleichen Sektor (oder guckte per Remote-Camera zu), crashten die Schiffe beim Landeanflug munter in die umliegenden Stationen (und waren dann natürlich hübsch kaputt). Guckte man nicht zu, wurde ein einfacheres Modell verwendet, und die Schiffe konnten heil landen.
Ansich ist es kein Fehler solche vereinfachten Modelle zu verwenden, solange man irgendwie sicherstellen kann, dass die vereinfachte Simulation inetwa dasselbe Ergebnis hat, wie die komplexere Simulation die man macht, wenn die Objekte sichtbar sind.
Der Fehler bei X² war nicht dass ein vereinfachtes Modell verwendet wurde, um Objekte anderen in Sektoren zu simulieren, die man gerade nicht beobachtet.
Der Fehler war bloss, dass der Check, der bestimmt ob es möglich ist eine Station an einem gewissen Punkt zu bauen, zu "grosszügig" war. Hätte man diesen Check "verschärft", hätte man nie Stationen so knapp neben anderen Stationen bauen können, dass irgendein Schiff beim Landeanflug irgendwo gegenfliegen hätte können. Dann hätte es auch keinen so wichtigen Unterschied mehr zwischen dem vereinfachten Modell, und dem "ich sehe zu" Modell gegeben.EDIT: man könnte natürlich genauso sagen der "Autopilot" war zu dumm. Oder die vereinfachte Simulation zu dumm zu erkenne, dass der Autopilot hier Schiffe craschen wird. Der Fehler war natürlich aus all dem.
-
Aber das erfodert doch Massen an Rechenleistung oder ni?
1. du hast zehntausende objekte, tausende werden noch gerendert, einige sind animiert, dynamisch, haben materialeigenschaften. nebenbei musst du shader durch die gegend schieben usw. das ganze laeuft mit hoffentlich 60fps, also 16.6ms fuer all das.
nun die logik. nicht jeder grasshalm den du zeichnest denkt. du hast in wirtschaftspielen/weltsimulationen eventuel soviele 'denkende' elemente wie du in der umgebung objekte zum rendern siehst. die menge ist also nicht so dramatisch wie es fuer dich auf anhieb klingt. du wirst eher ein speicherproblem bekommen wenn du zuviele davon hast. dein pc schafft es locker in ner sekunde ein paar mal durch den ganzen speicher zu gehen. du kannst garnicht genug logikobjekte haben (im normalfall)2. mit welcher framerate muessen die geupdated werden? sicher sind keine 16ms als zeitscheibe noetig, oder welcher schmied macht 60schwerter/s? faellt dir auf wenn er 0.5s laenger braucht? faellt dir 5s auf wenn er kilometer von dir entfernt ist?
3. genau wie beim rendern gibt es auch bei der logik LOD. wenn du in der naehe bist, dann entscheidet der schmied sich neue kohle zu kaufen und geht los. die wegfindung sucht den weg, die kinematik steuert die fuesse damit sie sich einigermassen an den boden anpassen usw.
bist du ewig weit ausserhalb der sichtweite, weiss der schmied anhand der luftlinie, er braucht strecke/laufgeschwindigkeit und wird sogar fuer diese zeit aus der logik simulation herausgehalten.zusammengefasst:
-du hast viel mehr rechenleistung bei viel weniger komplexen berechnungen
-du hast viel mehr zeit pro "logikframe" und selbst wenn es mal doppelt so lange dauert, faellt es niemandem auf
-die simulation der welt kann in vielerlei hinsicht sehr approximiert werden ohne dass jemand das wirklich feststellen kann und muss nur in der naehe genauer simuliert werden und das auch nur um die darstellung zu fuettern.
-
Dann musst du aber auch beachten, dass Interaktionen im Dorf nicht von der Zeitverzerrung beeinflusst werden. Um bei deinem Beispiel zu bleiben: Was, wenn vorgesehen ist, dass jemand anders sich ein Schwert abholt? Der müsste dann auch einberechnet werden.
Ist auch kein Problem:
Man gibt dem Schmied 2 Counter. Einer berechnet wieviel er geschmied hat.
(Dies macht man nach der vergangenen Zeit wenn man dort ankommt)Der 2. Counter wird immer dann erhöht, wenn jemand ein Schwert abholt.
(Dann ist der Schmied bei diesem Spieler ja aktiv zu sehen und bekommt soweiso Rechenzeit ab.)Hinterer einfach berechnen wieviele Schwerter er hergestellt haben kann (mit der vergangenen Zeit) Minus die Abgeholten.
-
Das würde ja auch bei Netzwerkt sogar funktionieren (Bin jetzt nur von Einzelspieler ausgegangen).
Ist vielleicht etwas Schwer zu programmieren, aber wozu gibts Klassen ^^.
-
Andreas XXL schrieb:
Der 2. Counter wird immer dann erhöht, wenn jemand ein Schwert abholt.
(Dann ist der Schmied bei diesem Spieler ja aktiv zu sehen und bekommt soweiso Rechenzeit ab.)Eben, aber was ist, wenn derjenige, der das Schwert abholt, auch inaktiv ist? Ich habe mich auf den Ansatz bezogen, nach dem Ereignisse in der Nähe des Spielers in Echtzeit passieren, während weiter entfernte, momentan irrelevante Geschehnisse, pausiert werden.
Es ist nun mal so, dass man bei künstlichen Eingriffen in den Zeitablauf der Welt die Kausalität nicht mehr gewährleisten kann - vor allem wenn voneinander abhängige Dinge unterschiedliche Zeiten haben.
Wie rapso sagte, kann das approximiert werden. Wenn die einzelnen Systeme (z.B. Dorf) weitgehend autonom sind und in eine "Zeitzone" gehören (d.h. entweder alle pausiert oder alle aktiv sind), ist der Effekt auch vernachlässigbar. Aber grundsätzlich sollte man die Auswirkungen im Hinterkopf behalten, besonders wenn die Systeme komplexer werden.
-
das problem mit den zeitblasen ist auch dass es schwer ist abzusehen welche seiteneffekte die abschaltung von systemen verursacht. das ist dann code design welches gamedesign entscheidungen manipuliert und mit diesem dann im einklang sein muss.
was passiert z.b. wenn man den schmied im eigenen dorf umbringt und nun die leute in das andere gehen wollen um dort ihr schwert zu kaufen, wird dann jeder am rande der zeitblase festfrieren? wird der schmied im anderen dorf temporaer reaktiviert damit die eigenen einwohner nicht fuer immer verschollen bleiben? wird er pruefen, ob der kohlehaendler noch am leben ist bevor er ein schwert aushaendigt? wird der kohlehaendler etwas verkaufen, obwohl du schon seit tagen jeden der aus der kohlemine kommt abmurkst um das nachbardorf "auszuhungern"? wird der dorf's ritter jemals versuchen dich davon abzuhalten wenn er zZ so weit weg ist dass er im "AI schlafmodus" ist?
am ende ist das rausfinden welche objekte nicht einschlafen duerfen weil von ihnen ganz indirekte aber wichtige ablaeufe abhaengen sehr aufwendig, diese dependancy chain erforschen oft wissenschaftler im echten leben.
natuerlich kann man das sehr gut fuer abgeschottete oekosysteme machen wie z.b. bei simcity die nachbarstaedte die man nie sehen wird, aber einen teil der simulation abzuschalten finde ich relativ schwer.
-
Ich denk mal, das kann man mit einer guten Architektur "leicht" lösen.
Wenn man ein Subsystem als bus für Dörfer einsetzt (Datentransfer) und jedes Dorf, Stadt, etc mit diesem Bus verbindet und die berechnungen seperat laufen lässt, so denke ich das da was möglich wär.
Dazu andere Subsystem (Wie bei SimCity die Nachbarstädte) einbinden, die ein mangel von kohle ausgleichen,,,
Natürlich kann man das hier nicht komplett für jeden einzelfall niederschreiben.Und eine Architektur auf diesem Nievau wär zu hoch für mich.
Von daher kam ja der eine Vorschlag. Einfach abschalten, was nicht in der nähe passiert.
