Xaby hat geschrieben:Komplettes Jump'n'Run ohne Springen ...
Bräucht Denk anstoss für ein Array... (3.30)
-
Fluid Byte
- Beiträge: 3110
- Registriert: 27.09.2006 22:06
- Wohnort: Berlin, Mitte
Windows 10 Pro, 64-Bit / Outtakes | Derek
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
Wenn ausser Belustigung auch was Kreatives in euren beiden Antworten gestanden hätte würd ich nix sagen, aber bitte unterlasst derartige Antworten ohne gleichtzeitig Fördernd zu sein in diesem Thread, SPam sorgt zu abweichungen im Thema auch wenns amüsant sein kann 
Nichts schührt Hass wie die Warheit
PB Version - 3.30
PB Version - 3.30
Ich hatte es ja gestern schon fertig programmiert, also das 2,5 Dingli,
was du gern gehabt hättest.
Würde sogar mit der Demo von PureBasic 4.x laufen.
Die Frage ist nur, ob du etwas vorgesetzt haben möchtest, oder
lieber deinen eigenen Kopf gebrauchen magst.
Deine Array-Konstruktionen sind mir schleierhaft.
Ein zweidimensionales Array ist
Wenn das Feld
Lautet, kannst du da 10 Steine breit und 10 Steine hoch ohne Probleme
unterbringen. Ich dachte, du hast selbst schon 2D-Spiele
mit Draufsicht und von der Seite gemacht. Jedes Feld ist ein Stein
in deinem Spiel.
Und wenn du das ganze nun in einem 2,5-Spiel mit 3 Dimensionen
haben möchtest, haste eine Ebene mehr.
Stell dir dein 2D-Spiel einfach in mehreren Schichten vor.
Also entweder die Draufsicht öfter über einander oder die Seitenansicht
öfter nebeneinander.
Dein Array könnte also lauten:
Nun hast du 10 Schichten mit je 10 x 10 2D Leveln.
Jede Zahl, also jeder Wert deines Arrays kann doch so definiert sein,
dass er die Eigenschaft des Feldes enthält.
Wenn das Feld "0" ist, kann man beispielsweise hindurchgehen.
Steht eine 1 drin, ist es eine rote Wand. Steht ne 2 drin, ist es ein grüner Stein.
Bei einer 3 ist es ein Strauch, bei einer 4 eine Kiste mit Gold ...
Du fragst dann allle Felder ab mit einer dreifach verschachtelten
Zählerschleife und zeichnest das so
was du gern gehabt hättest.
Würde sogar mit der Demo von PureBasic 4.x laufen.
Die Frage ist nur, ob du etwas vorgesetzt haben möchtest, oder
lieber deinen eigenen Kopf gebrauchen magst.
Deine Array-Konstruktionen sind mir schleierhaft.
Ein zweidimensionales Array ist
Code: Alles auswählen
Dim Welt (xBausteineMax, yBausteineMax)
Code: Alles auswählen
Dim Welt (9,9)
unterbringen. Ich dachte, du hast selbst schon 2D-Spiele
mit Draufsicht und von der Seite gemacht. Jedes Feld ist ein Stein
in deinem Spiel.
Und wenn du das ganze nun in einem 2,5-Spiel mit 3 Dimensionen
haben möchtest, haste eine Ebene mehr.
Stell dir dein 2D-Spiel einfach in mehreren Schichten vor.
Also entweder die Draufsicht öfter über einander oder die Seitenansicht
öfter nebeneinander.
Dein Array könnte also lauten:
Code: Alles auswählen
Dim (9,9,9)
Jede Zahl, also jeder Wert deines Arrays kann doch so definiert sein,
dass er die Eigenschaft des Feldes enthält.
Wenn das Feld "0" ist, kann man beispielsweise hindurchgehen.
Steht eine 1 drin, ist es eine rote Wand. Steht ne 2 drin, ist es ein grüner Stein.
Bei einer 3 ist es ein Strauch, bei einer 4 eine Kiste mit Gold ...
Du fragst dann allle Felder ab mit einer dreifach verschachtelten
Zählerschleife und zeichnest das so
Kinder an die Macht http://scratch.mit.edu/
Es gibt halt leider ein großes Problem bei diesem Thema: Es geht um Isometrie und das kann unter Umständen übelst komplex werden. Da weiß man gar nicht wo man mit Erklären anfangen soll, weil wir auch nicht wissen, was Du schon alles begriffen hast.
Im wesentlichen hängt's auch erstmal davon ab, was Du genau vorhast. Soll die Welt trotzdem nur Flach sein (also Boden und eine einzige "Schicht" für Mauern usw.), oder soll das vollständig dreidimensional sein? Für letzteres kann ich schon verstehen, daß Du an ein dreidimensionales Array denkst - das Problem ist nur, daß der Speicherverbrauch ins unermeßliche steigt. Daher gibt's auch hier wieder unterschiedliche Vorgehensweisen: entweder machst Du die Maps nicht allzu riesig (z.B. wie bei Head over Heels), oder Du machst eine große Map mit großen Höhenunterschieden, wo es aber dennoch nie "Stockwerke" geben kann (z.B. wie bei Gyroscope oder auch bei Doom (nur daß das nicht isometrisch ist)), oder Du machst eine feste Stockwerkhöhe (also mehrere Array-Schichten in bestimmten Abständen), oder Du machst eine Map, die aus einzelnen "Flächen" besteht, die frei angeordnet werden können aber auch immer nur aus einem "flachen" Array bestehen, ODER Du machst alles komplett dreidimensional, speicherst aber nicht in Form von Arrays sondern in Form von Objekten.
Hat alles seine Vor- und Nachteile und ist wie gesagt übelst komplex. Isometrie sieht leider nur auf den ersten Blick einfach aus. Vielleicht solltest Du nochmal näher beschreiben, welche Features Du tatsächlich unterstützen möchtest, dann kann ich Dir evtl. nochmal ein paar Tips geben.
Im wesentlichen hängt's auch erstmal davon ab, was Du genau vorhast. Soll die Welt trotzdem nur Flach sein (also Boden und eine einzige "Schicht" für Mauern usw.), oder soll das vollständig dreidimensional sein? Für letzteres kann ich schon verstehen, daß Du an ein dreidimensionales Array denkst - das Problem ist nur, daß der Speicherverbrauch ins unermeßliche steigt. Daher gibt's auch hier wieder unterschiedliche Vorgehensweisen: entweder machst Du die Maps nicht allzu riesig (z.B. wie bei Head over Heels), oder Du machst eine große Map mit großen Höhenunterschieden, wo es aber dennoch nie "Stockwerke" geben kann (z.B. wie bei Gyroscope oder auch bei Doom (nur daß das nicht isometrisch ist)), oder Du machst eine feste Stockwerkhöhe (also mehrere Array-Schichten in bestimmten Abständen), oder Du machst eine Map, die aus einzelnen "Flächen" besteht, die frei angeordnet werden können aber auch immer nur aus einem "flachen" Array bestehen, ODER Du machst alles komplett dreidimensional, speicherst aber nicht in Form von Arrays sondern in Form von Objekten.
Hat alles seine Vor- und Nachteile und ist wie gesagt übelst komplex. Isometrie sieht leider nur auf den ersten Blick einfach aus. Vielleicht solltest Du nochmal näher beschreiben, welche Features Du tatsächlich unterstützen möchtest, dann kann ich Dir evtl. nochmal ein paar Tips geben.
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
@ZeHa und übelst komplex
Lass ihn doch ne Welt machen, die 256 x 256 Steine breit ist und eventuell 10 Steine hoch.
~ 2,70 MByte, wenn er pro Array einen Longint verwendet.
Meine Welt im Beispiel ist 10 x 10 x 10 groß.
Wobei der grüne Boden bei 3 liegt, so dass man noch einen Keller bauen kann.
Man könnte ja auch immer wieder nachladen.
Wenn er natürlich plötzlich an einer Stelle etwas benötigt, was höher ist als
7 Kästchen, wird es schwer. Vielleicht ist da ne Kombination aus beidem
die Lösung.
Also zum Beispiel Vögel und Flugzeuge werden als Objekte platziert und
die Welt selbst in dem festen Array.
Speicher dürfte da noch nicht das Problem sein.
256 x 256 ~ 65.536, also 64 KByte
Wenn er das als Longints hat, halt das vierfache.
Und das pro Ebene. wenn so eine Welt 10 MB im Speicher verbraucht,
ist das noch kein Hinternis.
800 x 600 Pixel Auflösung und 32 x 32 große Tile,
würde er eine Welt von ca. 10 Bildschirmseiten mit voll bekommen nebeneinander.
und 13 übereinander.
Sind also auch schon 130 Bildschirmseiten.
Die muss er erstmal in einem Editor zusammenbasteln.
Man könnte auch, wie du schon sagst, eine Terrain-Ebene machen
und eine Objektebene. So dass man in einer Ebene des Arrays
die Höhenunterschiede und Texturen kodiert und
in einer darüber liegenden Ebene die möglichen Objekte wie
Stäucher, Kisten, Tische ... etc.
Lass ihn doch ne Welt machen, die 256 x 256 Steine breit ist und eventuell 10 Steine hoch.
~ 2,70 MByte, wenn er pro Array einen Longint verwendet.
Meine Welt im Beispiel ist 10 x 10 x 10 groß.
Wobei der grüne Boden bei 3 liegt, so dass man noch einen Keller bauen kann.
Man könnte ja auch immer wieder nachladen.
Wenn er natürlich plötzlich an einer Stelle etwas benötigt, was höher ist als
7 Kästchen, wird es schwer. Vielleicht ist da ne Kombination aus beidem
die Lösung.
Also zum Beispiel Vögel und Flugzeuge werden als Objekte platziert und
die Welt selbst in dem festen Array.
Speicher dürfte da noch nicht das Problem sein.
256 x 256 ~ 65.536, also 64 KByte
Wenn er das als Longints hat, halt das vierfache.
Und das pro Ebene. wenn so eine Welt 10 MB im Speicher verbraucht,
ist das noch kein Hinternis.
800 x 600 Pixel Auflösung und 32 x 32 große Tile,
würde er eine Welt von ca. 10 Bildschirmseiten mit voll bekommen nebeneinander.
und 13 übereinander.
Sind also auch schon 130 Bildschirmseiten.
Die muss er erstmal in einem Editor zusammenbasteln.
Man könnte auch, wie du schon sagst, eine Terrain-Ebene machen
und eine Objektebene. So dass man in einer Ebene des Arrays
die Höhenunterschiede und Texturen kodiert und
in einer darüber liegenden Ebene die möglichen Objekte wie
Stäucher, Kisten, Tische ... etc.
Kinder an die Macht http://scratch.mit.edu/
Jo sorry hatte da was verwechselt.
Nicht der Speicher ist das Problem, sondern die Sortierung. Denn wenn Du die Objekte zeichnest, mußt Du sie alle gescheit sortieren, und dazu wollte ich damals den Z-Buffer der Grafikkarte nutzen (der aber i.d.R. nur 32 Bit hat).
Wie er das dann unter PB macht ist wieder die andere Frage. Aber Sortierung ist essentiell, es sei denn, die Figuren bewegen sich immer blockweise. Bewegen sie sich aber frei übers Gelände, wird's schwierig.
Ich habe eigentlich auch vor, meine Engine mal weiter zu machen (sofern ich mal Zeit finde), und dann mach ich es eh komplett anders, nämlich 3D mit OpenGL, aber mit orthogonaler Projektion. Somit brauch ich mich um das ganze Sortierzeug nicht zu kümmern.
Nicht der Speicher ist das Problem, sondern die Sortierung. Denn wenn Du die Objekte zeichnest, mußt Du sie alle gescheit sortieren, und dazu wollte ich damals den Z-Buffer der Grafikkarte nutzen (der aber i.d.R. nur 32 Bit hat).
Wie er das dann unter PB macht ist wieder die andere Frage. Aber Sortierung ist essentiell, es sei denn, die Figuren bewegen sich immer blockweise. Bewegen sie sich aber frei übers Gelände, wird's schwierig.
Ich habe eigentlich auch vor, meine Engine mal weiter zu machen (sofern ich mal Zeit finde), und dann mach ich es eh komplett anders, nämlich 3D mit OpenGL, aber mit orthogonaler Projektion. Somit brauch ich mich um das ganze Sortierzeug nicht zu kümmern.
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
Die Sortierung bleibt:
von hinten nach vorn und von unten nach oben muss es dargestellt werden.
Einheiten können nur dort hin, wo keine Gegenstände sind.
Oder die Blöcke sind halt kleiner als die Einheiten.
Man muss die Blöcke ja nicht als solche Erkennen.
Wenn ein Grasbüschel zum Beispiel einen Block hoch und einen Block tief und breit ist,
und die Einheit selbst hat Beine, die 3 Blöcke hoch sind und davon zwei stück,
und wenn die Beine noch einen Block auseinander sind, dann würde der
Grasbüchel immer richtig vor oder hinter dem Bein angezeigt werden.
Oder er kann halt auf Gras drauf treten, dann ist es entweder
vor der Einheit, hinter der Einheit oder die Einheit tritt drauf.
Dann müsste er sich aber überlegen wie er die Einheitensteuerung
übernimmt. Wenn Wände und Sträucher nur dort sein können,
wo Einheiten nicht hinkommen, es sei denn, es ist etwas zum Einsammeln,
dann könnte man die Einheiten samt der Welt in einem Array verwalten.
von hinten nach vorn und von unten nach oben muss es dargestellt werden.
Einheiten können nur dort hin, wo keine Gegenstände sind.
Oder die Blöcke sind halt kleiner als die Einheiten.
Man muss die Blöcke ja nicht als solche Erkennen.
Wenn ein Grasbüschel zum Beispiel einen Block hoch und einen Block tief und breit ist,
und die Einheit selbst hat Beine, die 3 Blöcke hoch sind und davon zwei stück,
und wenn die Beine noch einen Block auseinander sind, dann würde der
Grasbüchel immer richtig vor oder hinter dem Bein angezeigt werden.
Oder er kann halt auf Gras drauf treten, dann ist es entweder
vor der Einheit, hinter der Einheit oder die Einheit tritt drauf.
Dann müsste er sich aber überlegen wie er die Einheitensteuerung
übernimmt. Wenn Wände und Sträucher nur dort sein können,
wo Einheiten nicht hinkommen, es sei denn, es ist etwas zum Einsammeln,
dann könnte man die Einheiten samt der Welt in einem Array verwalten.
Kinder an die Macht http://scratch.mit.edu/
WIE sortiert wird, ist kein Problem. Aber es MUSS sortiert werden, und das auch noch schnell. Es geht nicht blockweise, es geht pixelweise, denn wenn die Figuren sich frei bewegen können, dann gibt es übelste Überlappungen, wenn Du nicht pixelweise sortierst.
Und um pixelweise zu sortieren, brauchst Du entsprechend viel "Raum", sprich, Du brauchst eine Möglichkeit, die ganzen Positionen voneinander zu unterscheiden. Und dazu brauchst Du große Zahlen.
Es ist tatsächlich nicht alles so einfach wie man denkt. Iso ist ein Pain in the Ass.
Und bevor wir hier weiter drüber diskutieren, würde ich erst gerne von Dir wissen, ob Du das alles schon durch hast, oder ob Du grad nur am "denken" bist, denn gedacht habe ich damals auch, und dann implementiert, und dann gemerkt, daß das denken alleine nicht ausreicht, weil man leider nicht weit genug denkt.
Und um pixelweise zu sortieren, brauchst Du entsprechend viel "Raum", sprich, Du brauchst eine Möglichkeit, die ganzen Positionen voneinander zu unterscheiden. Und dazu brauchst Du große Zahlen.
Es ist tatsächlich nicht alles so einfach wie man denkt. Iso ist ein Pain in the Ass.
Und bevor wir hier weiter drüber diskutieren, würde ich erst gerne von Dir wissen, ob Du das alles schon durch hast, oder ob Du grad nur am "denken" bist, denn gedacht habe ich damals auch, und dann implementiert, und dann gemerkt, daß das denken alleine nicht ausreicht, weil man leider nicht weit genug denkt.
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
