ZFX + Developia

Hallo,

wozu würdet ihr mir raten, wenn ich ein 2D spiel schreiben möchte?

ich hatte bereits folgende ideen:
1. ich male eine bitmap mit s/w und sage, dass die figur icht auf schwarz laufen darf ( nur wie ich das abfragen und regeln kann weiß ich noch nicht)
oder
2. ich setze zB für einen felsen ein tImage auf die oberfläche und sage, es darf nicht auf das tImage laufen sondern stoppen.

Nur so ein bsp wie es ungefähr aussehen und funktionieren soll, wäre wie bei pokemon (gameboy).
Das ganze programmiere ich mit Borland Builder C++ 2010 - vcl.

danke schon mal im vorraus!
mfg

Wenn du Bilder/Tiles/Texturen abfragen musst um deine Spiellogik anzuwenden wirst du nicht glücklich werden. Normalerweise entsprechen die Felder Datenstrukturen die zb das Bild enthalten (als Index zb), einen Wert ob der Spieler es betreten kann (oder unter welchen Bedingungen, mit Pferd nicht in Sumpf zb), und welche Bewegungskosten dabei entstehen (Straße geht schneller als Wald, Wald schneller als Gebirge).
Du solltest also solche Strukturen für deine Spielwelt anlegen und bei Nutzerinteraktion abfragen. Normalerweise wird daraus auch die grafische Repräsentation der Welt gebaut also zb mit dem Index für die Landschaftsform (Wald, Gebirge, Fluss) wird das zugehörige Bild/Tile an die betreffende Stelle gezeichnet.

also an geschwindigkeiten wollte ich nicht großartig variieren. eine feste geschwindigkeit reicht erstmal.

meintest du so etwas?

Sowas meint Despotist... vlt.
Du kannst auch jedem Feld einen Zahlenwert zuweisen.
Diese Zahlenwerte sind dann repräsentiv für die Tiles-Typen.
Was man auch machen kann, mit mehreren Layern arbeiten.
Ich glaub die Jungs die "Splatterwelten" gemacht haben, die haben das so gemacht: http://zfx.info/viewtopic.php?f=26&t=797
Kannst ja einen Blick in die Level-Dateien werfen.
Hoffe das sie nix dagegen haben :) ..

[Edit]
Oh, peinlicher Tippfehler!!
Habs korregiert...

Und noch ein Edit... "Typen" klingt so abwertend!
[/Edit]

joggel hat geschrieben: diese "Typen" die "Spalletwelten" gemacht haben

Ich denke Schrompf hat ne neue Signatur ;).

Das mit der Geschwindigkeit war nur ein Vorschlag was du alles damit machen kannst. Einfach für jedes gewünschte Feature eine Eigenschaft einbauen die dann abgefragt wird um das Verhalten zu simulieren.

DeadManWalkin hat geschrieben: meintest du so etwas?

Ich kann deine Zeichnung nicht ganz deuten. Du hast einen Datentyp der ein Feld deines Spielfeldes/Levels repräsentiert. Dieser Datentyp enthält alles was so vorkommen kann (Gegner, Türen/Portale, Schätze/Items, den Geländetyp usw) bzw Verweise darauf (Indizes, Zeiger). Dann setzt du deinen 2d-Level aus Instanzen dieses Datentyps in einem 2d Array zusammen und befüllst diese (Leveleditor, zufällig, aus Datei laden). Zum Rendern fragst du einfach die Elemente ab. Zuerst zeichnest du das Gelände, darüber dann eventuelle Items und/oder Gegner. Dabei sind deine gespeicherten Werte nur Indizes des Bildes also der Zombie ist Bild1, die Hydra Bild2 usw.. In der Spiellogik wo du auch die Eingaben des Benutzers abfragst und in Befehle umwandelst prüfst du dann entsprechend was passiert. Also wenn sich der Spieler auf ein Feld bewegt wo ein Item liegt wird es gelootet wenn er auf ein Feld mit einem Gegner geht wird der Kampf gestartet und wenn er auf ein Portal geht wird ein anderer Level geladen. Wurde das halbwegs klar? Wenn du die Abfragen über die Bilder machst wie von dir vorgeschlagen hast du eine zusätzliche Indirektion die fehleranfällig, resourcenfressend zeitaufwändig zu implementieren ist. Fazit: Du brauchst eine geeignete interne Repräsentation der Spielwelt aus der diese optisch aufgebaut wird und mit der du die Spiellogik/KI direkt betreiben kannst.

Ich hatte erst das hier gefunden, aber das bezieht sich nur auf konsolen programmierung und das habe ich nie gelernt sondern es wurde uns direkt über das gui beigebracht.

http://www.virtual-maxim.de/tilemap-1/

nur zum verständnis:

ich lege den interger fest.
int fels;

fels->top = 150; //koordinaten des objekts fels
fels->left = 230;

fels->(verzeichnis zur bitmap)

und dann? ich glaub das muss grad sehr schrecklich über kommen.. was grafik angeht, ist es für mich neuland. wir haben gelernt nur mit label, edit, buttons, imags, shapes etc zuarbeiten - das wars aber auch.

Mit normalen GUI-Elementen (Button usw) wirst du es auch hier schwer haben. Bedenke dass du vielleicht auch mal bitmaps rotieren und skalieren möchtest. Du solltest also schon eine Grafik-Engine oder wenigstens eine Grafik-Api verwenden. Ich bin kürzlich auf Unity umgestiegen und bin sehr angetan davon. Ich weiß aber nicht ob es für einen Anfänger vielleicht zu komplex ist um damit zu starten. Aber es nimmt einem viele Dinge ab um die man sich nicht mehr kümmern muss so dass man sich weitgehend auf die relevanten Spielelemente beschränken kann. Auf jeden Fall solltest du nach weiteren Tutorials oder einer Tileengine suchen.
Weiterhin speicherst du ja nicht die Bildschirmkoordinaten der Felder sondern nur ihre Position relativ zueinander (die ja implizit über die Position im 2d-Array verwaltet wird). Du berechnest die Position am Bildschirm anhand der Position der Kamera über der Map (davon ausgehend dass diese größer als der Bildschirm ist bzw scrool- und zoombar ist).

ich habe heute noch mit einem programmier lehrer meiner schule gesprochen. er fand die idee mich so auf die prüfung vorzubereiten sehr gut und gab mir den tip, mich mal in sachen 2d Kollision schlau zu machen.

was meinst du dazu?

Das musst du ganz allein entscheiden ob du es für dein Spiel/Programm/Projekt brauchst. 2d Kollision ist eher für kontinuierliche Welten gedacht (zb Actionspiele). Wenn sich bei dir alles in Feldern/Rastern abspielt ist es mMn nicht unbedingt nötig.

Auf jeden Fall musst du entscheiden was du in deinem Projekt erreichen willst und das in kleine abgeschlossene Aufgaben aufteilen. Wenn du nicht weißt was du erreichen willst wirst du auch nicht an deinem Ziel ankommen. Schau dir mal die Begriffe Pflichtenheft und Designdokument an. Also setz dir ein Ziel und überlege/recherchiere wie du es umsetzen kannst.