Problem mit Zufallszahlen und Multithreading

[Angel4585]

Hallo,

ich möchte eine kleine 2D Simulation für mein Spiel machen. Ich bin schon recht weit, aber habe jetz ein kleines Problem.
Aktuell ist es so, das jede Spielfigur ein Thread ist, was bei maximal 17(2*8 Spieler + Ball) Spielfiguren kein Problem sein sollte.
Da die Simulation nur die Darstellung für ein Fussballspiel sein soll sollte man ein Spiel mehrfach angucken können und es sollte auch jedesmal das gleiche angezeigt werden.
Ich dachte mir eigentlich en genügt wenn ich die Zufallszahlen die ich erzeuge alle aus dem selben Random objekt generiere und dieses immer mit dem gleichen Seed initialisiere.

Aber dem ist leider nicht so, der RandomSeed ist immer 100 und trotzdem sind zB die Startaufstellungen die für ne Demo zufällig generiert werden, alle unterschiedlich. Da der Zufallsgenerator noch an anderen Stellen verwendet wird frage ich lieber jetzt gleich.

Woran liegt das das was andere raus kommt und wie kann ich das Problem beheben?

 

[Der Müde Joe]

>Woran liegt das das was andere raus kommt

-->Zufallsgenerator

>und wie kann ich das Problem beheben?

--> einen deteministischen generator benutzen bzw schreiben

EDIT:
Btw: bei mir kommt immer das selbe raus bei Random(100)?
und auch in der gleicher Reihenfolge.

 

[Angel4585]

Aber wenn ich doch den Random Seed etze sollte doch genau das gleiche rauskommen, warum ist das scheinbar nicht der Fall?

Edit: Ja beim Random kommt immer das gleiche raus, aber die Spielanzeige ist jedesmal ne andere obwohl ich nur dieses eine Random-Objekt habe und verwende, habe von vornherein kein anderes verwendet und auch nach nochmaligem durchsuchen ist kein anderer zufallsgenerator mit drin.

Ich denke deswegen dass es am Zusammenspiel mit den Threads hängt

 

[Der Müde Joe]

weil die Threads nicht immer gleich rennen. einmal nimmt der Thread 2 die erste Zahl, einmal der Thread 7 etc.

>Da der Zufallsgenerator noch an anderen Stellen verwendet wird

Jedesmal ist ein anderer am nen neue Zahl holen.

 

[Angel4585]

ok, aber wie kann ich das regeln?

 

[SlaterB]

jeder Thread nimmt seinen eigenen Zufallsgenerator
oder jeder einzelne Zufallszahl-Generator-Zugriff ist einzeln synchronisiert festgelegt (wenig realistisch)

 

[Angel4585]

ok jetz hat jedes Objekt seinen eigenen zufallsgenerator der überall mit 100 initialisiert wird.
Die Spieler sind alle auf der gleichen Position dadurch aber der Spielverlauf ist dennoch ein anderer. Liegt das an Prozessorauslastung und solchen Geschichten? wie kann ich das in Griff bekommen?
Ist Multithreading für mich evtl nicht das Richtige?
Aber mit nur einem Thread isses fast nicht zu schaffen oder?

 

[Der Müde Joe]

>Die Spieler sind alle auf der gleichen Position

widerspricht

>dadurch aber der Spielverlauf ist dennoch ein anderer.

Es ist so, dass nicht alle Threads immer zur gleichen Zeit rennen. Eimal ist einer schneller einmal ein andererer. Darum auch Variationen.
Das würde ewig laufen:

		Random random = new Random(100);
		Random random2 = new Random(100);
		while(random.nextInt() == random2.nextInt()) {
			System.out.println('.');
		}

Für sowas sind glaub Executor da, hab aber noch nie was richtiges damit gemacht und schon lange nicht mehr reingeguckt drum?

 

[Angel4585]

Ich meinte die Startposition ist die gleiche, durch den Spielverlauf bewegen sich die Spieler, einer ausm team rennt zum Ball, damit ist schon sichergestellt das nichtmehr alle die gleiche position haben.. naja usw ^^

gut ich schau mal was es mit diesen Executoren auf sich hat ^^ Danke

 

[Der Müde Joe]

Eigentlich brauchst du nur 2 Threads. Den EventDispatchingThread (EDT) der malt (swing macht das) und ein Thread, welcher dir die neuen Positionene aller Spieler berechnet und den Ball, würde ich jetzt mal sagen. Somit hat sich auch das Thread Problem gelöst.

 

[Angel4585]

:lol: War sogar sehr einfach, da ich Ball und Spieler ohnehin von einer Klasse MovingPoint abgeleitet hatte welche von Thread abgeleitet war musste ich nur das extends Thread wegmachen und die run Methode durch eine Methode nextStep ersetzen welche ich dann in nem seperaten Thread immer der reihe nach aufrufe.
Danke für den Tipp jetz funktionierts

 

[0x7F800000]

jedes hinreichend komplizierte programm, das multithreading ist an sich schon ein zufallszahlengenerator, weil das, was dein Programm tut, immer davon abhängt, wie schnell der prozessor ist, und der ist nie exakt gleichschnell.


indem du alles in einem Thread ausführst, gehen übrigens vorteile von Multithread-Programmen verloren, also verstehe ich dann nicht ganz, was das ganze Unternehmen dann überhaupt sollte. Bei einem Spiel sind 17 Threads auch unsinnig: wozu sollen 17 gut sein? Das ist doch keine parallelisierte simulation auf einem superrechner mit zig tausend zusammengeschalteten prozessoren. So wie ich das mitbekommen hab, wird es bei spielen auf nicht allzuviele Threads aufgeteilt: einen für Grafik, einen für Physik, einen für KI, einen der im Hintergrund irgendwelche Objekte als für den Spieler irrelevant markiert und freigibt, bzw dazulädt. Das alles, nur um den verschiedene Prioritäten zu vergeben, und bei Szenen mit vielen Monstern und Dreiecken sich auf die Grafik und Physik zu konzentrieren, und die Ausführung der ganzen KI und Müllabfuhr-Threads auf spätere, weniger Kritische Zeitpunkte zu verschieben. Da wird definitiv nicht für jeden Monster ein Thread angelegt, das wäre ein wenig zu viel.

 

[Angel4585]

seltsam.. ich habe in dem thread der alles berechnet ein sleep(20) drin.
Wenn ich das auf sleep(10) ändere gibts einen komplett andere Spielverlauf...

Dabei wollt ich eigentlich um die Ergebnisse zu berechnen das ganze ohne das sleep durchlaufen lassen und nur zur Anzeige das sleep reinmachen

 

[didjitalist]

gibt für genau sowas die scheduler aus Executors. bzw. für swing Timer.

 

[Angel4585]

Aaaargh :x hab den Fehler gefunden :roll: Ich mach in der Berechnung an einer Stelle etwas von der Zeit abhängig, da ist klar das was anderes rauskommt wenn ich das sleep weglasse ???:L

Naja schnell geändert und jetzt gehts. Ich werde mir die Executoren aber trotzdem noch anschauen