Spiel A hat mit Spiel B nichts zu tun -> daher kann das komplett voneinander unabhängig berechnet werden. Falls jemand WIRKLICH der Meinung ist, dass Trainer A nach 70 Minuten sagt: Upps... Team B ist am gewinnen, dann müssen wir noch höher gewinnen und offensiver spielen - nun, dann könnte man immerhin die Ligen untereinander trennen. Und wenn es übrigens wirklich so wäre, dann müsste jeweils von Minute zu Minute jedes einzelne Spiel simuliert werden, weil sonst ja bei der Simulation des 1. Spiels die Ergebnisse (und Zwischenstände) der anderen Spiele noch nicht bekannt wären.
Tja, um die Realität abzubilden, müsste man das wirklich so machen. Wenn du am letzten Spieltag gegen den Abstieg spielst und dein Konkurrent im Parallelspiel in der 80. Minute ein Tor macht, das ihn retten würde, dann würdest du aller Wahrscheinlichkeit nach offensiver spielen lassen, um deinerseits das rettende Tor zu erzielen. Es ist also schlichtweg falsch, dass Spiel A nichts mit Spiel B zu tun hat (in der Realität). Wenn also der FM das hinbekommen würde, dass er die Spiele einer Liga (Beispiel Bundesliga, Samstag, 15:30 Uhr) parallel berechnet, auf mehrere Cores verteilt: DAS wäre fett. Das hätte dann nämlich Auswirkungen auf die Taktik, die die ME sich "ausrechnet", auch gegen den menschlichen Spieler.
Warum stimmt die Aussage bzgl. GTA nicht -> dort ist alles voneinander abhängig! Wenn ich auf der Strasse stehe, dann weichen andere aus und wieder andere reagieren darauf, dass sie auch ausweichen müssen -> somit kaum Parallelität.
Fast. GTA V braucht MINDESTENS 4 Kerne, um flüssig zu laufen, was die Aussage "kaum Parallelität" ad absurdum führt. Parallelität wird also zwingend vorausgesetzt.
Quelle:
https://www.tomshardware.com/reviews/multi-core-cpu-scaling-directx-11,4768-3.htmlUm dein Beispiel zum Thema Ausweichen aufzugreifen: es gibt haufenweise Material dazu. Stichwort wäre "Multithreaded Collision Detection" oder "Multi-Core Collision Detection"*.
Hier mal ein paar Anhaltspunkte (der letzte Link ist ein "einfaches" Codebeispiel (nicht von mir)):
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.472&rep=rep1&type=pdfhttps://www.cs.cmu.edu/~mpa/ode/final_report.htmlhttp://gamma.cs.unc.edu/PCD/https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch32.htmlhttps://www.jvrb.org/past-issues/11.2014/3989https://github.com/jdiomede/ball-chamberIch würde meine Programmierkompetenz durchaus als ausreichend bezeichnen, um hier mitreden zu können. Ich hab den Kram schließlich studiert.
* für Laien stark vereinfacht:
- Core 1 simuliert die Bewegung von NPC A
- Core 2 simuliert die Bewegung von NPC B
- beide NPCs schauen periodisch, ob es eine Kollision geben könnte (ist ein Object in Sicht, wenn ja, wie weit entfernt, ...)
- hat das Objekt nur noch eine bestimmte Entfernung , leitet das den Ausweichvorgang ein. Dabei gibt es mehrere Möglichkeiten:
-- A sieht B aber B nicht A -> A weicht in eine von ihm gewählte Richtung aus (wenn möglich, hier können verschiedene Regeln zum Einsatz kommen -> physikalische, Verkehrsregeln, etc)
-- A sieht B und B sieht A
--- siehe oben, nur dass beide ausweichen. Das kann auch so aussehen, dass B nicht ausweicht, weil es A schon tut.
--- beide weichen in die gleiche Richtung aus (das führt dann zu der allseits bekannten Alltagssituation, dass man fast zusammenstößt)
-- sind höhere Geschwindigkeiten beteiligt, können sich hieraus durchaus Unfälle ergeben, wie es sie in GTA zB haufenweise zwischen NPCs gibt
Das wars jetzt aber zu dem Thema auch von mir. Ich programmiere 10 Stunden täglich auf Arbeit, da muss ich das nicht auch noch zuhause fortsetzen.