Größe und Position der Spielergrafik in RPG

[Rubiko]

Hi nochma,
und schonmal Entschuldigung im vorraus falls ihr hierfür auch wieder einen Code wollt... warum auch immer, hab da auch keinen

Sorry wegen den ganzen Fragen aber zurzeit bin ich eben wieder aktiv am coden, war im letzten Jahr ja eher nicht so...

Is' ne ganz klassische Frage:
Welche Größe von Spielergrafiken benutzt man in RPGs und wo setzt man sie hin? Liegen diese Grafiken auch in der Tilegröße vor (z.B 32x32) oder sind sie kleiner und werden nur in die Mitte der Tiles gesetzt?

Beispielgrafik:


Wie schneide ich diese Bilder jetzt am besten aus und benutze sie?

[Kaeru Gaman]

normaerweise genügt es, die figuren in tilegröße zu clippen.
möglichst viel transparentes weglassen muss man nur, wenn man nanosekunden schinden muss.

so ne grafik wie in deinem beispiel würde man als ein sprite einladen und
dann clippen je nachdem welche richtung und welche animationsphase.

[Zaphod]

Eigentlich kann man die Fragen alle mit einem einzigen Satz beantworten:

"So wie du willst."

Es gibt nämlich keine ISO Norm

Es ist genauso legitim die Sprites so groß zu machen wie ein Feld oder sie kleiner zu machen und in die Mitte zu setzen.


Kleiner Tipp zum Kreativen Prozess: Nimm dir ein Grafikprogramm wie Gimp und bastel dir eine Typische Ansicht aus dem Spiel wie du es dir vorstellst.
Dabei kannst du leichter und schneller herumexperimentieren, Sprite Größen verändern, Screenauflösungen Ausprobieren und über Effekte Nachdenken.
Das basteln per Hand gibt dir darüber hinaus Einblicke und Tieferes Verständnis wie die Algorithmen aussehen müssen um deine Szene zu generieren.

[Xaby]

Fang erstmal mit einem Sprite an.

Ganz ohne Animation und ohne Transparenz.

So wie in meinem "Ball und Fahrstuhl"-Beispiel.

Später kann man dann bei bestimmten Aktionen das Aussehen des Sprites verändern.

Eine Animation ist später auch ganz einfach.
Du hast einen Sprite, den du als Helden nimmst.
Und verändert er die Richtung, lässt du das Sprite so, aber du änderst den Inhalt des Sprites.

So kannst du Spielsteuerung und Funktion von Spieldesign trennen.

Ideal wäre es schon, wenn deine Bildchen immer die selbe Größe später haben. Was du da nimmst, ist dir überlassen.

Später wird es nur interessant, wenn du zum Beispiel bestimmte Collisionsabfragen machst, die unter Umständen von dem Aussehen deines Bildes abhängen ...
Aber solche Abfragen kann man auch weglassen bzw. nimmst du sie nur für Dinge, wo du immer genau weißt, wie etwas aussieht.

Schau dir ruhig das mit dem Ball mal an und ersetz einfach mal den Ball mit einer deiner Grafiken.
http://www.purebasic.fr/german/viewtopic.php?t=13946

(ich weiß, ist kein RPG, aber am Ende ist es das gleiche, hängt halt vom Bild ab, ob man von der Seite oder von oben kuckt. Und ob es Schwerkraft oder Wind von der Seite ist ...)

[Rubiko]

Genau darum geht es mir Xaby, ich experimentiere gerade herum mit der Kollision und da ist das wichtig...


(blau nicht begehbar, grastile begehbar)

Hab ich hier ne volle 32x32 Grafik und überprüfe die Kollision mit den Koordinaten im Array muss ich mich ja GENAU in der Mitte befinden um durchzukommen, obwohl es von der Grafik her dann aussieht als passe ich
durch...

Kurze andere Frage:
Die GrafikX Koordinate geht ja immer von der oberen linken Ecke des Sprites aus, wär es nicht besser die Mitte der Spielfigur zu berechnen und von dort aus auf Kollision zu prüfen?

und.. danke für eure Antworten

Grüße,
Rubiko

[Kaeru Gaman]

> Die GrafikX Koordinate geht ja immer von der oberen linken Ecke des Sprites aus, wär es nicht besser die Mitte der Spielfigur zu berechnen und von dort aus auf Kollision zu prüfen?

jup.
...aber so sehr wichtig ist das nicht bei nem labyrinth-rpg.
bei nem jump'n'run ist das wichtiger, weil es dort wesentlich vereinfacht.


> Hab ich hier ne volle 32x32 Grafik und überprüfe die Kollision mit den Koordinaten im Array muss ich mich ja GENAU in der Mitte befinden um durchzukommen

na, dann überprüfe nicht auf SpielerX sondern SpielerX+8 (links),
und nicht auf SpielerX+32 sondern SpielerX + 24 (rechts)

das hat doch nur mit deiner rechnung zu tun, nicht mit deiner darstellung.

[Rubiko]

hm... im Moment überprüfe ich im Map Array welches Tile rechts, links, über und unter dem Spieler ist, und ob es begehbar ist..

also bei der Abfrage

Code: Alles auswählen

ColR = Map(PlayerX32+1, PlayerY32)

If KeyboardPushed(#PB_Key_Right) And MyTiles(ColR)\walkable = 1
  ...
Endif

Heißt, ich kann nur gucken was sich genau 32 Pixel recht vom Spieler befindet, also reine Abfrage im Map Array

Wie soll ich denn pixelgenau auf Kollisionen überprüfen?
Habs nicht ausprobiert aber man kann ja schon von vornerein sagen, dass

Code: Alles auswählen

ColR = PlayerX + 8

nicht funktionieren würde, da es mir nicht das Tile zurückliefert, sondern lediglich den Wert

Also wie genau meinste das mit den +8 und +24?

[Zaphod]

Du weist ja aber, dass ein Tile immer 32*32 Pixel groß ist, kannst die Pixelgenaue Kollision auch mit einem Stellvertreter Sprite durchführen... außerdem, wenn du weist was im array an der Stelle steht, weißt du doch auch für welches Sprite das steht. Die Nötige Postition kannst du dann auch leicht aus den Array Koordinaten errechnen.

Aber mal eine Kurze zwischenfrage: Willst du denn überhaupt, dass die Spielfiguren sich pixelfrei Bewegen können oder sollen sie sich schon immer von Feld zu Feld bewegen, nur mit weichen übergängen? Wenn du letzteres willst, dann brauchst du gar keine so komplexen Kollisionsabfragen.

[Rubiko]

Was genau meinst du mit "Stellvertreter Sprite"?

Das Errechnen wäre natürlich einfach, man müsste nur wieder die Daten im Map Array * 32 nehmen und dann hätte man X und Y, nur weiß ich jetzt nicht direkt wie mir diese Daten dann weiterhelfen

Aber mal eine Kurze zwischenfrage: Willst du denn überhaupt, dass die Spielfiguren sich pixelfrei Bewegen können oder sollen sie sich schon immer von Feld zu Feld bewegen, nur mit weichen übergängen? Wenn du letzteres willst, dann brauchst du gar keine so komplexen Kollisionsabfragen.

Ja, der weiche Übergang von Tile zu Tile wäre schon viel einfacher, aber pixelfrei hätte ich lieber.
Kurze Frage: Würde sich dafür die Bounding Box Kollision eignen? Da hatte Kaeru auch extra ein paar Routinen dafür gepostet...

[Kaeru Gaman]

uffa...

nee, da musst du komplett umkonzipieren...

also, PlayerX32 ist bei dir wohl die Tile auf der sich der player befindet.
aber damit rechnest du ja nur mit 32er schritten, dann kannst du strenggenommen auch nur 32er schritte gehen (animierte sequenzen eben)
und keine pixelweise schritte.

...oder ist das lediglich eine umgerechnete koordinate vom feinen PlayerX?


also, zur veranschaulichung:


PlayerX und PlayerY sind die koordinaten deines PlayerSprites.
dich interessiert jetzt aber fürs spiel nicht wirklich, welches Tile unter diesem punkt ist, sondern
a) für nach links gehen interessiert es, welches Tile unter PlayerX+7 ist.
wenn dort ein unbegehbares grad anfängt, kann er nicht weiter nach links.
b) für nach rechts gehen das gleiche für PlayerX+24
c) für nach oben gehen für PlayerY+4
d) für nach unten für PlayerY+30

und natürlich dementsprechend auch einen bereich, damit ecken richtig funktionieren.

> Würde sich dafür die Bounding Box Kollision eignen?
eine ableitung davon ja.

> die Pixelgenaue Kollision auch mit einem Stellvertreter Sprite durchführen...
ja nee, bitte keine spritecollision.
dies ist ein koordinaten-problem, kein pixelgrafix problem