SDL_Levelgestalltung Maps Bauen e.t.c.


LecramOS

Member
Joined
Feb 20, 2010
Messages
121
Age
39
Location
Pandora.
LOCATION
Pandora.
Hi... :)

Ich wollte mal fragen wie Ihr so eure Levels, für eure in C++ Programmierten Spiele, gestaltet.

Also ob Ihr "Tiles" benutzt oder jede Kollisionsabfrage einzeln schreibt. ?

Eventuell gibt es ja auch andere Möglichkeiten. Ich kenne bisher nur die Möglichkeit mit den "Tiles" und der einzeln geschriebenen Kollisionsabfrage.

Habe gehört es soll auch Leveleditoren geben. Davon möchte ich jedoch die Finger lassen, weil ich von Grund auf alles selbst erstellen möchte.

Macht es vielleicht Sinn sich selber auch erst mal einen Leveleditor zu Programmieren ?

Wie machen die erfahrenen Spieleentwickler unter Euch das so ??? :)
 
LecramOS said:
Hi... :)
Ich wollte mal fragen wie Ihr so eure Levels, für eure in C++ Programmierten Spiele, gestaltet.

da gibt es quasi "unendlich" viele möglichkeiten ;-)
Es gibt keine einzig richtigen weg der immer für alles gut ist - das ist so äähnlich wie deine frage eingangs im OOP thread, in der art "wenn ich hier *so* OOP mache, dann hab ich immre gewonnen und es kann nix mehr schiefgehen, gell?".
So funktioniert das nicht ^^
Also ob Ihr "Tiles" benutzt oder jede Kollisionsabfrage einzeln schreibt. ?

Was meinst du mit tiles vs. "einzelne kollisionsabfrage schreiben" ?

Ich könnte einniges raten, aber das lass ich mal ^^

Wobei ich gern mal auf dieses letzte substantiv eingehen möchte.
Das nervt mich nämlich ein bisschen, dass sich das in deutschland so ausgebreitet hat.
Meiner theorie nach durch halbwissende zeitschriftenschreiber (spielezeitschriften), die damals die beim C64 (und sicher manchen konsolen mit hardware tiles/scrolling + sprites support) durchaus berechtigte bezeichnung "Kollisionsabfrage" einfach für alles andere, was mit kollision zu tun hat, übernahmen: So heisst es denn für die auch heute noch beim komplexesten 3D spiel einfach "die Kollisionsabfrage in spiel xyz ist nicht so gut".
Wenn es aber wirklich eine kollisions-abfrage wäre, wie damals auf dem C64, wo man dank hardware support nur ein register abfragen musste, ob gerade ein sprite mit einem anderen oder dem hintergrund kollidiert, dann könnte in verschiedenen spielen die kollisions"abfrage" gar nicht verschieden gut oder schlecht sein, weil sie immer die gleiche wäre ^^
Sehr viel treffender wären ausdrücke wie "Kollisionsberechnung", "Kollisionserkennung", "Kollisionsfeststellung" o.ä. (englisch collision detection) - denn das muss man nämlich selbst machen, wie du scheinbar weisst (nur bin ich scheinbar einer der wenigen dem das wort auf den geist geht *g*), das kann man nicht einfach "abfragen" wie früher beim C64 ^^

Jaja. Is ja schon gut. Ich bin für's erste fertig mit mosern über unwesentliche details, aber sorry, wenn ich bei gamestar oä. mal wieder was von der "Kollisionsabfrage" lese, rollen sich mir die zehennägel auf :D
Habe gehört es soll auch Leveleditoren geben. Davon möchte ich jedoch die Finger lassen, weil ich von Grund auf alles selbst erstellen möchte.
Macht es vielleicht Sinn sich selber auch erst mal einen Leveleditor zu Programmieren ?

Klar, warum nicht. Da du dich ja in OOP üben willst - das wär doch gleich n gutes übungsprojekt ^^
Ich weiss nicht, wieviel erfahrung du ansonsten mit der programmierung hast.
Wenn du noch mit irgendwelchen C++ GUI libraries für linux oder windows, oder gar noch mit einer anderen sprache/umgebung/framework (es gibt wirklich nettere möglichkeiten der entwicklung von tools als in C++ mit altbewährten GUI toolkits) handtieren müsstest, mit denen du dich noch nicht auskennst, wäre das evtl. ein weiterer stein im weg (oder übung aus anderer perspektive. Wie man's nimmt)

Vielleicht reicht für die anfänge auch erstmal ein texteditor zum erstellen der levels.

Oder du könntest natürlich, wie in alten tagen, einfach das bisschen zeug. was du für nen einfachen tile basierten editor mit vielleicht ner handvoll einstellmöglichkeiten GUI-mäßig bräuchtest, auch selbst zeichnen, zB. in einer SDL basierten anwendung. Das habe ich früher gemacht, nach dem umstieg von DOS auf Windows programmierung, wo ich keinen nerv hatte, mich mit der grässlichen Win32 API zu schlagen: einfach nur 1 fenstre erzeugt undmir von ner grafik library nen pixel buffer dafür geben lassen, und dann meine alten DOS GUI routinen hübsch weiter verwendet, was dann in windows zwar etwas fremd aussah, aber was solls ^^
Also eine rudimentäre GUI library entwickeln für das gröbste - im spiel bräuchtest du letztendich auch irgendsoetwas, für menü's, einstellmöglichkeiten etc. Also warum nicht was mehrfachbenutzbares schaffen.

Naja,
ich schmeisse jetzt hier wild mit möglichkeiten, sorry für die überflutung ;-)
Ich weiss nicht genau um deinen stand, und wo du als nächstes hin möchtest auf deinem weg als entwickler, was dir am wichtigsten ist etc.

Wie machen die erfahrenen Spieleentwickler unter Euch das so ??? :)

Alle tools selbst zu entwickeln, wäre sicher etwas zuviel zeitwaufwand. Bei 3D spielen soetwas wie modelling + animationsprogramme selbst zu machen, bei den guten programmen, die es gibt, wäre fast schon verrückt - ausser man will sowieso unbedingt so ein programm schreiben zum spaß ^^
Damit meine ich character / object modelling & animation..
Level editoren nehme ich davon aus, denn je nach engine können die bedürftnisse da doch so speziell sein, dass allemal ein fettes plugin für eine 3rd party lösung angesagt wäre, oder eben gleich eine flexiblere komplette eigenlösung.

Was deinen tiles editor betrifft - ich kann mir schon vorstellen, dass es da generische, standard lösungen gibt, mit denen man dann levels für durchschnitts tile-basierte spiele erstellen kann, da gibt es ja nun inzwischen doch etablierte standards und die gemeinsamkeiten, oder was bei den unterschieden zwischen genres berücksichtigt werden muss, sind bekannt.
Ich kenne da aber keine beispiele.
Da ein editor für so eine art spiel aber nicht soooo irrsinnig aufwendig sein sollte, seh ich keinen grund, warum man den nicht mal selbst basteln sollte.
Der kann dann nur das, was du brauchst, und zwingt dich nicht, dinge so zu machen, wie sie für deine zwecke eher umständlich wären - etwas, das man bei sehr allgemein gehaltenen lösungen schnell mal hat.


Ich selbst entwickle tools mit C# in .NET (ja .NET, auf dem pöööhsen windoofs! nicht Mono, :p ) (es ist witzig, dass hier tux für mich die zunge herausstreckt, haaahaa! *g* )
, bin bekennender liebhaber dieser sprache/framework ^^ Java = pfui, nach meinem persönlichen geschmack ^^ Aber das wäre sicher auch noch ne gute option statt nativem C++ kram für tool dev, wobei ich mich mit aktuellen Java GUI biliotheken gar nicht auskenne und daher dazu nix sagen kann.
Ich vertrete jedenfalls die ansicht, dass da, wo es performancemäßig nicht unbedingt nötig ist, man sich nicht mehr mit sowas wie nativer C++ entwicklung herumplagen sollte.
 
Also ich gehe mal davon aus, dass du eine Kollisionserkennung für ein 2D Spiel entwickeln möchtest.
Meiner Meinung ist dafür ein Interface (C#, Java, etc) bzw. eine abstrakte Klasse (C++, etc) am besten geeignet. Diese nennen wir mal "Collidable". Diese enthält alle nötigen Daten die das Kollisionserkennungs-System (eine eigene Klasse) für die Erkennung einer Kollision benötigt. Z.B. die Position, die Größe und/oder sogar die ganze Grafik des Objekts (als 2D-Array, ...) für eine pixelgenaue Erkennung. Dein Objekt erbt von dem Interface Collidable, so dass du in der Klasse des Objekts alle Methoden des Interfaces reimplementieren musst.

Dein Kollisionserkennungs-System wird regelmäßig in der main()-Methode oder so aufgerufen. Dieses besitzt alle verfügbaren Objekte (also deine Tiles z.B.). Jetzt musst du hier alle Berechnungen um eine Kollision zu erkennen durch führen. Du überprüfst halt jedes Objekt mit jedem, ob diese sich schneiden oder berühren. Man könnte zum Beispiel anhand der Position und der Größe des Objekts/Tiles eine Boundingbox errechnen, sodass man nur 2 Boundingboxes aufeinander prüfen muss.

Vorher könnte man alle Objekte, die schonmal gar nicht in Frage kommen können, weil diese zum Beispiel außerhalb des Bildschirms liegen, aus der Abfrage entfernen.

Wenn jetzt ne Kollision statt findet, kannst du in dem Kollisionserkennungs-System einfach eine Methode des Interfaces "Collidable" aufrufen, die du ja im Objekt neu definiert hast. Das ermöglicht dir je nach Objekt eine spezielle Reaktion, wie zum Beispiel das Objekt zu löschen oder die leben herunter zu zählen.

Ich hoffe du hast verstanden wie ich das meine ;)
 
:O

Soooo viel text.

Aber recht informativ :)
Ich weiss nicht genau um deinen stand, und wo du als nächstes hin möchtest auf deinem weg als entwickler, was dir am wichtigsten ist etc.

Ich bin jetzt c.a. 4 Monate mit C beschäftigt und ungefähr 2 Monate mit C++. Aber Intensiv. Das heißt, fast jeden Tag bis spät in die Nacht.

Ich schätze mich mal so als Fortgeschrittenen Anfänger ein.

Als erstes Spiel habe ich ein einfaches Pong Spiel gemacht. Nun hört man ja fast überall, dass man erst mal ein kleines leichtes Spiel machen soll bevor man sich an größere Projekte ran wagen soll, doch ich möchte jetzt mal Nägel mit Köpfe Machen und mich an ein Rollenspiel wagen, weil das überhaupt der Grund war, der mich dazu angetrieben hat C/C++ zu lernen. Ich mache das zum Spaß. Mittlerweile würde ich es als mein Hobby nennen.

Mittlerweile sehe ich Videospiele Mario,Zelda etc. in ganz anderen Augen. Ich hätte auch früher niemals gedacht, dass da soooo viel Arbeit drinn steck. Als Kind sagt man es ja so leicht "Ich will Spiele Entwickler werden", doch hat NULL Ahnung davon, was da für unendlich viel Arbeit drin steckt.

Mir ist Mittlerweile klar, dass das was ich mir da vorgenommen habe ein Projekt wird was wohl Jahre dauern wird wenn nicht sogar ein Jahrzehnt oder Jahrzehnte.

Na ja.. Ich bleibe einfach weiter am Ball.. Irgendwann muss ja was da raus werden.
Was meinst du mit tiles vs. "einzelne kollisionsabfrage schreiben" ?

Ich meinte mit Einzelne Kollisionsabfrage :-D wenn man im Programm für jeden Gegenstand wo der Spieler anstoßen könnte einzeln eine Kollisionserkennung bastelt. Also wenn ein Vase 20x20 -ist und der Hund auf der Straße 40x20 groß ist einzelne Kollisionsfeststellungen Bauen anstatt ein Tile zu benutzen, welches 50x50 ist !?!?! :confused:??

Naaa...ja. Ich muss dazu sagen, ich habe Tiles noch nicht benutzt gehabt, weswegen ich hier ja auch die Frage ist, ob es besser(leichter, angenehmer, effizienter) wäre die Tiles zu benutzen oder die Kollisionserkennungen einzeln zu stricken OHNE Tiles, also ob ich mich überhaupt mit den Tiles beschäftigen sollte, weil ich es ja auch ohne basteln könnte :confused:: .
Also ich gehe mal davon aus, dass du eine Kollisionserkennung für ein 2D Spiel entwickeln möchtest.

Jup. Es soll ein 2D Spiel werden. Zu was anderem währe ich wohl auch noch nicht fähig und außerdem gefällt mir 2D.

So in dem Stil von Zelda 3, Secret Of Mana, Lufia u.s.w. soll das Spiel werden woran ich arbeite.
da gibt es quasi "unendlich" viele möglichkeiten ;-)
Es gibt keine einzig richtigen weg der immer für alles gut ist - das ist so äähnlich wie deine frage eingangs im OOP thread

Ja dann mal ran an den Speck. :)

Danke.
 
Also ich benutze zur zeit tiles und eine tile-basierte Kollisionserkennung. Es gibt generell zwei Möglichkeiten:
Tile-basierte oder Pixel-basierte Kollisionsabfrage

Bei ersterer ist die Berechnung einfacher, da du durch die vereinfachte Level-Architektur auch vereinfachte Algorithmen zur Berechnung der Kollisionen benutzen kannst. Nachteil ist, dass du für jedes unterschiedliche Tile (also abgesehen von dem normalen, vollen, z.B. abgeschrägte oder sogar abgerundete) einen anderen Algorithmus schreiben musst.
Die zweite Möglichkeit ist komplizierter und aufwändiger zu berechnen, da du hier die Kollisionen beispielsweise aufgrund eines speziellen Bildes (zwei Farben, eine für "Kollision", die andere für "keine Kollision") berechnest und dabei jeden Pixel betrachtest und mit einbeziehst. Der große Vorteil ist, dass diese Art der Berechnung unabhängig von dem Level ist (funktioniert für alle Arten von Tiles) und viel kompliziertere und organischere Strukturen zulässt.

Für den Anfang und für Tile-basierte 2D Spiele generell empfiehlt sich imho erstere Berechnungsart.

Dabei gibt es auch wiederum mehrere Möglichkeiten das anzugehen. Die verbreitetste scheint zu sein die Berechnung für Bewegung in x- und y-Richtung zu trennen und nacheinander und unabhängig durchzuführen. Dabei wird üblicherweise das Sprite virtuell um seine Geschwindigkeit bewegt und dann Anpassungen durchgeführt.

In Wandor habe ich noch ein System eingebaut, welches die Anpassungen nicht direkt durchführt, sondern sie in einer Liste abspeichert, die dann mit Algorithmen bearbeitet wird, um nach der Berechnung der Anpassung für jedes Tile die Gesamtanpassung zu berechnen. Das klappt in der jetzigen Implementierung ganz gut, aber für mich noch nicht zufriedenstellend, sodass ich es gerade wieder neu schreibe.

Dabei habe ich mir überlegt eventuell ein etwas anderes System zu probieren, welches einen etwas physikalischeren Hintergrund hat, bei welchem die Kollision nicht für jede Bewegungsrichtung, sondern für jede wirkende Kraft (Gravitation, Wind, Bewegung, etc.) einzeln berechnet wird. Bin dabei aber noch nicht über die Planungsphase hinausgekommen, sodass ich nicht weiß, ob es sinnvoll ist oder irgendwelche Vorteile bringt.

Generell bin ich noch auf der Suche nach gutem Lesestoff zu diesem Thema und ich denke, dass das auch auf den OP zutreffen könnte. Also wenn jemand zu diesem Thema noch was Interessantes (auch gerne in Buchform) hat, bitte posten!

foxblock out

EDIT: Gerade diesen, sehr lesenswerten, Artikel über die Entwicklung eines alten NES sidescrollers gefunden. Behandelt werden u.a. allgemeine Spiellogik (wie werden Units erzeugt, welche Eigenschaften haben sie, wie sind die Maps aufgebaut, etc.) und Kollisionserkennung, der Artikel geht dabei gut ins Detail und ist ebenfalls gut geschrieben (auf englisch).
http://games.greggman.com/game/programming_m_c__kids/
 
Bei einfachen Jump'n'Runs oder 2D Zeldas sollten Rechteckskollisionen vollkommen ausreichen. So kannst du bspw. bei deinem Char nur die Kollisionen der Füße berechnen:

terranigma-1.png


die beiden stoßen nicht zusammen, obwohl sie vom Bild her kollidieren. Pixelkollisionen wären hier nur unnötig lahm (...und selbst wenn, immer davor Rectcoll benutzen :) ) und würden eher noch zu Verhakungen führen wenn irgendeine Animationsstufe wechselt. Du speicherst einfach für jedes Object ab, wie das Kollisionsrechteck aussieht und evtl. noch wo es im Sprite liegt, dann machst du dir ne Funktion Rectcoll(int mx1, int my1, int w1, int h1, int mx2, int my2, int w2, int h2) und fertig ;)

gruß
 
Bei Tiles-Basierten RPGs brauchst du z.B. garkeine kollison. Sobald der Char versucht das nächste Feld zu betreten überprüft man im Map Array dessen höhe/ob es frei ist (Beim RPG Maker gibts z.B. 3 höhen für Objekte).
Pixelgenaue Kollision ist recht rechenaufwendig und hat den nachteil, dass du jeweils 2 Objekte Testes, also recht viel Testen musst, bzw ein recht großes "Welt-Objekt" hast (was im grunde auch nur ein Array mit den Belegten feldern ist, das eben eine Wesentlich höhere Auflösung bietet, also einfach ein Array mit belegten Tiles).
 
ich habs mal auf der psp in lua mit den farbwerten gemacht.
da gabs dann einmal die map oberfläche schön gezeichnet, darunter dann in schwarz/weiss ne map mit der man anhand der farben der verschiedenen pixel abfragen konnte ob man drüberrennen kann oder nicht und als letztes gabs noch eine für events...


so konnte ich dann die maps mit nem normalen zeichenprogramm erstellen^^
wenn interesse besteht pn an mich und dann kann ich heute abend mal nach dem code schaun
 
da gabs dann einmal die map oberfläche schön gezeichnet, darunter dann in schwarz/weiss ne map mit der man anhand der farben der verschiedenen pixel abfragen konnte ob man drüberrennen kann oder nicht und als letztes gabs noch eine für events...

...auweia. Wieviele Objekte dürfen da rumlaufen bis die FPS zu dem FPS werden?
 
Schnatterplatsch said:
da gabs dann einmal die map oberfläche schön gezeichnet, darunter dann in schwarz/weiss ne map mit der man anhand der farben der verschiedenen pixel abfragen konnte ob man drüberrennen kann oder nicht und als letztes gabs noch eine für events...

...auweia. Wieviele Objekte dürfen da rumlaufen bis die FPS zu dem FPS werden?

war ja auch nur n versuch, und ich muss sagen das es schneller lief als das mit den tiles,
kahm warscheinlich davon das ich weniger forschleifen drin hatte
 
Hui :)
Hier tut sich ja was.

Finde die Idee mit der Farbenerkennung nicht schlecht. Klingt einfach.

Ich muss mal testen und gucken worauf ich am besten anspringe. Gibt ja echt viele Möglichkeiten.

Ist das ein Spiel von dir Schnatterplatsch, wovon du das Bild eingefügt hast, wo du das mit der Kollisionserkennung erklärt hast ?

So in dem Stil möchte ich mein Spiel auch gestalten.

Bin gerade mal mit dem Intro dran. Das ist schon ein ganzes Stück Arbeit. Aber ich werde dadurch immer vertrauter mit der Animationsgestaltung, was ja nicht verkehrt ist. :yes:
 
LecramOS said:
Finde die Idee mit der Farbenerkennung nicht schlecht. Klingt einfach.
Sry aber die Idee ist eigentlich schlecht^^ Wenn du jedesmal den Farbwert von etwas abfragst, dann ist das absulute Leistungsverschwendung. Dann nimm ein 2D Array aus Boolean werten, diese abfragen geht schneller. Kannst ja am Anfang die Map in so ein Boolean Array laden, aber im Spiel immer Farbwerte abfragen ist ziemlich suboptimal.
Der "vorteil", dass du mit einem Malprogramm mappen kanst ist ja auch nur relativ. Ein Mapeditor wäre da eher sinvoll denke ich.
 
Jetzt weiß ich welches Spiel das ist wovon Schnatterplatsch ein Bild rein gestellt hat.. Es ist "Terranigma".
Habe dieses Spiel leider noch nicht gezoggt. Muss ich unbedingt nachholen. :-D

Ich muss sowieso erst mal mit dem Intro für das Spiel fertig werden,bevor ich mich richtig mit der Kollisionserkennung beschäftigen kann. Das zieht sich jetzt schon über eine Woche hin und mir kommen immer wieder neue Ideen, die man da noch einbauen kann. Ich glaube nur an der Intro Sequenz werde ich noch ein halben Monat beschäftigt sein. :-D .

Ich denke, dann werde ich eine Funktion(Schnatterplatsch vorschlag) in einer Karakter Klasse errichten für die Kollisionsberechnung und dann parallel zum Code Gimp laufen lassen mit der aktuellen Map die ich nutzen will und nehme dann von dem Bild die jeweiligen XY Werte vom Objekt(Mauer,Blumentopf,Hund,Katz,Maus...) womit der Spieler Kollidieren kann/soll und füge diese in der Funktion ein. Das klingt jetzt alles so einfach... aber wird bestimmt wieder neue Höllentore öffnen die es dann wieder zu schließen gilt . :confused::

Wird schon schief gehen.
:slap:
 
das mit den farbwerten hat sich hald so ergeben da ich versucht hab mit der funktion klar zu kommen, war nur ein übungsprogramm...
 
Back
Top