Frage zu GAMEPLAY - "Kameraposition"

[Mezimo]

Hallo,

ich weiß nicht unter "was" ich genau suchen soll, deswegen frag ich das direkt mal hier vllt. hat jmd. eine simple Lösung.

Ich möchte in Lazarus auf der z.B. Form1, dass wenn sich das Bild bewegt, sich die "Perspektive/Kamera/Sicht" mit bewegt.

D.h. das Bild bleibt für mich in der Form1 immer im Zentrum und haut nicht aus der Form1 ab weil die height z.B. zu klein ist.

Quasi wie für ein Spiel mit einer größeren Welt ohne das man immer rechts oder unten Scrollen müsste.

z.B. die Form1 ist 640 x 480. Die "Welt" aber z.B. 10000 x 10000.
Wie bleibt meine "Sicht" auf einen Punkt fixiert?

Anders ausgedrückt. Wie bewege ich mich mit? (2D Spiel)

Danke für alle Antworten im Vorraus!

[Medium]

Wie hast du dein Spielfeld denn aktuell realisiert? Davon hängt im Wesentlichen ab wie man es angehen könnte. (Bei einem (echten) 2D-Game von Perspektive und Kamera zu sprechen verwirrt ungemein. Diese Begriffe gibt es im 3D-Bereich als wohl definierte und feststehende Begriffe, die bei (reinem) 2D nicht anwendbar sind. Streich die besser gleich wieder in deinem Kopf in diesem Zusammenhang, das erspart dir sicherlich künftige Missverständnisse.)

[Mezimo]

Alles klar. Habs halt nur so umschrieben damits verstanden wird.

Also ich hab noch nicht damit angefangen aber will grundsätzlich gerne wissen wie man sowas umsetzen könnte.

[Medium]

Ja, das ist das Problem: Es war schon ziemlich missverständlich. Zumindest für jemanden, der mit der Materie zu tun hat

So ganz grundsätzlich: Zeichne immer nur das auf dein Formular, was man gerade auch wirklich sieht. Um das zu ermitteln muss man mindestens die Rahmen (Bounding-Boxes) seiner Spielelemente kennen, sowie deren Position, und das Zentrum der aktuellen Ansicht auf die Gesamtkarte. Mit diesen Infos (und der Größe deiner Anzeige sowie ggf. Zoomfaktor) kannst du bestimmen, was überhaupt zu sehen sein wird, wenn du es zeichnest. Dann musst du nur noch all deine Objektkoordinaten negativ um die Verschiebung "Fenstermitte -> Ansichtsmitte" transformieren (sowie ggf. um den Zoomfaktor skalieren), und dann zeichnen.

Nochwas: "Gameplay" entspricht im Deutschen in etwa "Spielerlebnisgüte" oder "Spielbarkeit". Fehlt mir auch grad ein wenig der Bezug

[Mezimo]

Okey, dann nochmal danke für die Antwort.
Ich kanns mir in etwa Vorstellen wie es gemeint ist.

[Medium]

Man kann vermutlich besser was dazu sagen, wenn du schon mal einen gewissen Ansatz hast, an dem man werkeln kann. Versuch dich nur gleich von Anfang an von der (weit verbreiteten) Vorstellung zu lösen, dass ein 2D-Spiel am besten aus 5000 TImages bestehen sollte . "Richtig" ginge man es so an, dass man zunächst eine Basisklasse hat, die erstmal alles an Eigenschaften kapselt, die ein "Ding" im Spiel haben muss. Etwa sowas

Delphi-Quellcode:

type
  TGameEntitiy = class(TObject)
  private
    ....
  public
    property Position: TVector;
    property Rotation: Single;
    property BoundingBox: TBoundingBox; // = record von 4 TVectors, ähnlich TRect
    property IsSolid: Boolean;
    property Sprite: TBitmap;
    property LocallyRotatedSprite: TBitmap;
  end;

Davon lassen sich dann alle weiteren Entitätstypen ableiten, und haben gleich alles was für Spiellogik und Anzeige nötig ist huckepack. Zum Zeichnen riecht dann nachher quasi schon sowas:

Delphi-Quellcode:

procedure TDisplayForm.Paint;
var
  entity: TGameEntity;
begin
  ClearCanvas;
  DrawBackground;
  foreach entity in AllGameEntities do
  if entity.IsVisibleInRect(DisplayForm.ClientRect) then
    entity.DrawRotatedAndCentered({to} DisplayForm.Canvas, {at center} FormCenter);
end;

Alles natürlich Pseudomethoden ohne Ausformulierung, da die ja eben ganz maßgeblich dann von dem Spiel und den sonstigen Gegebenheiten abhängen. Aber das wäre ein sehr vereinfachtes, ganz allgemeines Gerüst.