Jump and Run - Unklarheiten

[TimeIsTheKey]

Hallo

Ich habe mich nach langer Zeit mal wieder ans Programmieren rangemacht und bin zurzeit an einem Jump and Run Spiel dran. Allerdings habe ich einige ungeklärte Fragen.
Bisher kann man sich in meinem "JnR"-Spiel mit einer Spielfigur bewegen und man kann springen. Allerdings läuft alles statisch ab, sprich die Physikberechnung wird nach 20 Millisekunden gemacht und die Schwerkraft wurde glaube ich noch nicht so gut umgesetzt.

Wie oft sollte die Physikberechnung gemacht werden? Ich habe nun von verschiedenen Varianten gehört. Die eine war z.B. pro Frame eine Physikberechnung zu machen (kann mir allerdings nicht vorstellen wie man dies machen soll) und die andere halt nach einer gewissen Zeit (bei mir nach 20 Millisekunden).

Dann habe ich noch eine Frage zur Schwerkraft. Ich habe das nun so gelöst, dass jedes Objekt, welches von der Schwerkraft betroffen ist, bei jedem Durchlauf um 2 Pixel nach unten gezogen wird. In der Verarbeitung baut sich der Vektor Y bei einer Bewegung um 1 ab. Bedeutet, dass es so aussieht, als würde es immer schneller runterfallen. Bei einem Sprung wird der Spieler 40 Pixel nach oben gezogen und die Schwerkraft (die 2 Pixel pro Durchlauf) regeln dann denn Sprung sozusagen. Sprünge können nur gemacht werden, wenn der Spieler irgendwo am Boden ist.
Gibt es eine bessere Methodik um das zu lösen?

Achja. Ich habe meine Vektoren (x,y) mit int gemacht. Sprich man kann sich nur x/y Pixel weit bewegen. Ich hab mich nun gefragt, ob es sinnvoller wäre, float oder double zu verwenden. Ich habe mir verschiedene Quellcodes angeschaut und ich habe die Vektoren noch nie als float definiert gesehen, aber ich glaube es wäre z.B. für die Schwerkraft sinnvoll eine Gleitkommazahl zu verwenden.

 

[Hobelhai]

Da es ja keine halben Pixel gibt, wirst Du am Ende sowieso wieder int für deine Vektoren benutzen müssen. Ob eine interne Berechnung mit float oder double den Bewegungsablauf realistischer erscheinen lässt, musst Du wohl selbst entscheiden.

 

[Quaxli]

Mein Objekte erben alle von Rectangel2D.Double und sind daher entsprechend ausgestattet. Das liegt zum einen daran, daß Rectangle2D.Double noch ein paar Nettigkeiten im Bauch hat, wie z. B. intersects() etc.
Ich würde aber auch so double Werte nehmen, da es sonst bei kleinen Bewegungsintervallen sein kann, daß sich ein Objekt gar nicht bewegt, weil ständig abgerundet wird (Und dann finde den Fehler mal.... ). Zum Zeichnen muß man nach int casten, aber im Objekt selber würde ich mit double arbeiten.

Was meinst Du mit Physikberechnung? Bildest Du die Formel für den schiefen Wurf ab oder sprechen wir von etwas Einfachen?

Einfachste Möglichkeit könnte ja z. b. in etwa so aussehen:
- Wenn die Figur springen soll, Y-Wert merken.
- Bei Y-x (x = Sprunghöhe) umschalten auf "fallen"
- Figur fällt solange, bis sie wieder Boden unter den Füßen hat

Oder halt was kompliziertes:

	@Override
	public void move(long delta) {
		
		shottime = (System.currentTimeMillis() - start)/1000;
		
		if(velo==0){
			return;
		}
		
		if(shotangle>=0){
			x = xnull + (velo*shottime * (Math.cos(shotangle)));
			y = ynull - (velo*shottime*(Math.sin(shotangle))) + (0.5 * g * shottime * shottime);
			
		}else{
			x = xnull + (velo*shottime * (Math.sin(shotangle)));
			y = ynull - (velo*shottime*(Math.cos(shotangle))) + (0.5 * g * shottime * shottime);
			
		}
	}

Beide Varianten würden aber pro Frame durchgeführt. Ich wüßte auch gar nicht, wie man das anders sinnvoll lösen soll.

 

[TimeIsTheKey]

Da es ja keine halben Pixel gibt, wirst Du am Ende sowieso wieder int für deine Vektoren benutzen müssen. Ob eine interne Berechnung mit float oder double den Bewegungsablauf realistischer erscheinen lässt, musst Du wohl selbst entscheiden.

Okay danke. ^^

Mein Objekte erben alle von Rectangel2D.Double und sind daher entsprechend ausgestattet. Das liegt zum einen daran, daß Rectangle2D.Double noch ein paar Nettigkeiten im Bauch hat, wie z. B. intersects() etc.
Ich würde aber auch so double Werte nehmen, da es sonst bei kleinen Bewegungsintervallen sein kann, daß sich ein Objekt gar nicht bewegt, weil ständig abgerundet wird (Und dann finde den Fehler mal.... ). Zum Zeichnen muß man nach int casten, aber im Objekt selber würde ich mit double arbeiten.

Was meinst Du mit Physikberechnung? Bildest Du die Formel für den schiefen Wurf ab oder sprechen wir von etwas Einfachen?

Einfachste Möglichkeit könnte ja z. b. in etwa so aussehen:
- Wenn die Figur springen soll, Y-Wert merken.
- Bei Y-x (x = Sprunghöhe) umschalten auf "fallen"
- Figur fällt solange, bis sie wieder Boden unter den Füßen hat

Oder halt was kompliziertes:

	@Override
	public void move(long delta) {
		
		shottime = (System.currentTimeMillis() - start)/1000;
		
		if(velo==0){
			return;
		}
		
		if(shotangle>=0){
			x = xnull + (velo*shottime * (Math.cos(shotangle)));
			y = ynull - (velo*shottime*(Math.sin(shotangle))) + (0.5 * g * shottime * shottime);
			
		}else{
			x = xnull + (velo*shottime * (Math.sin(shotangle)));
			y = ynull - (velo*shottime*(Math.cos(shotangle))) + (0.5 * g * shottime * shottime);
			
		}
	}

Beide Varianten würden aber pro Frame durchgeführt. Ich wüßte auch gar nicht, wie man das anders sinnvoll lösen soll.

Ich verwende auch Rectangle, aber lediglich für die Kollisionsüberprüfung (in der Hauptklasse habe ich 2, die jeweils neu abgefüllt und überprüft werden).

Ich werde double noch einbauen. ^^

Meine "Physikberechnung" ist im Moment ziemlich primitiv, weil ich kA von Physik habe. Ich meine aber mit "Physikberechnung" den Teil im Ablauf, bei dem die physischen Standorte verändert werden (sprich moveObjects() bei mir). Dieser wird bei mir eigentlich die ganze Zeit ausgeführt.
Ich hab mir mal angeschaut, wie du das in deinem Tutorial gelöst hast und werde es glaube ich einfach mal übernehmen.

 

[Cola_Colin]

Beide Varianten würden aber pro Frame durchgeführt. Ich wüßte auch gar nicht, wie man das anders sinnvoll lösen soll.

Indem man die Physikberechnung von dem Zeichnen an sich losmacht. Hat den enormen Vorteil, dass bei niedrigen wie hohen fps die Physik immer gleich bleibt.
Im kurzen tut man nichts weiter als die Physik zwischen den Frames in kleinen Schritten zu berechnen, von konstanter Länge.
Sollen 70ms Physik berechnet werden und man will einen Physik-Step pro 10ms, macht man eben 7 Durchläufe der Physikschleife mit 10ms.

Siehe: Fix Your Timestep!

@int-Vektoren:
Es empfiehlt sich intern ein eigenes Koordinatensystem zu verwenden, dass nicht in Pixeln rechnet, sondern in irgendwas anderem und dabei mindestens mit float.
Ob man dann noch double verwendet, ist wohl Geschmackssache, ich sehe da keinen Vorteil drinne.
Erst beim Zeichnen werden die Koordinaten dann in Pixel auf dem Monitor umgerechnet.

 

[Quaxli]

Indem man die Physikberechnung von dem Zeichnen an sich losmacht. Hat den enormen Vorteil, dass bei niedrigen wie hohen fps die Physik immer gleich bleibt.

Bis jetzt komm ich mir verschaukelt vor.... ???:L

Im kurzen tut man nichts weiter als die Physik zwischen den Frames in kleinen Schritten zu berechnen, von konstanter Länge.
Sollen 70ms Physik berechnet werden und man will einen Physik-Step pro 10ms, macht man eben 7 Durchläufe der Physikschleife mit 10ms.

Wir sprechen aber immer noch von einem Spiel bei dem man versucht, die FPS möglichst hoch zu halten, um flüssige Bewegunsabläufe zu erhalten, oder?

Denn was ist im Falle eines einfachen Jump 'n Run die "Physikberechnung" anderes als der Teil des GameLoops in dem das Objekt bewegt wird? Ob das jetzt nach einer komplexen physikalischen Formel erfolgt oder ein x-Parameter linear verändert wird ist dabei ja erst mal nebensächlich.

Und gerade bei Spielen weiß man im Vorhinein selten, wie lange eine Physikberechnung dauert. Woher soll ich also wissen, in wieviel Steps ich eine Bewegung aufteilen soll, wenn ich eine gleichmäßige Bewegung erzielen will. ???:L
Bleibt meiner Ansicht also nur eine Physik-Berechnung pro Frame.

Ob man die Bewegung dann anhand der Zeit des letzten Schleifendurchlaufs berechnet und/oder für den gesamten GameLoop versucht eine gleichmäßige Zeit für jeden Schleifendurchlauf zu erzielen ist dabei erstmal nebensächlich.

Das Thema FPS und Gameloop wird im Übrigen unter folgendem Link ausführlicher und etwas näher am Thema erklärt: http://fivedots.coe.psu.ac.th/~ad/jg/ch1/index.html