Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

08.06.2009, 17:55

Was sollte meine 2D Engine können?

Konnichiwa (*ehem* oder Guten Tag!)

Nun, da ja bald Sommerferien sind, werde ich abends wohl des öfteren
ein paar Stündchen Zeit haben.
Weil ich nun schon solange mal ein kleines 2D RPG programmieren wollte,
will ich dort mal beginnen.

Also hab ich mir überlegt, mit der Engine anzufangen. Dazu werde ich
OpenGL und evt. andere Libs für die Sounds und so verwenden.

Ich weiß, dass das kein Friede-Freude-Eierkuchen wird, aber ohne Planung
läuft überhaupt nichts. Und daher wollte ich fragen, ob ihr mir bei der
Planung ein wenig unter die Arme greifen könntet.

Es ist klar, dass das ganze mit Klassen abläuft (zumindest werde ich es so
machen).

Da gibt es:

- Texturmanager
Naja, Texturen laden, löschen, hinzufügen, doppeltes laden verhindern, etc.

- Soundmanager
Siehe Texturmanager

- Timer
Zeit messen und FPS

- Physik
Kollision und evt. andere Sachen?

- Input
Maus, Tastatur

- Content
Texte auslesen und irgendwie auf dem Bildschirm bringen

- GUI
Dialogboxen, Interface, ...

- KI
Das kommt zuletzt

- Datenmanager
Speichern, laden, ...

- Framework
Standardsachen: OGL initialisieren, Fenster öffnen, Spiel updaten, Objekte
dann auf dem Bildschirm bringen, usw.

- Map
Für die ganzen Karten, also "Karte" aus txt Datei auslesen

Soweit geht meine Planung erst einmal.

Jetzt wollte ich nach Verbesserungen und Ergänzungen fragen.
Ist die Struktur einigermaßen ok, was fehlt, was sollte anders gemacht
werden?
Natürlich sind die Funktionen der Klassen in einem Dokument bei mir
ausführlicher gefasst...

Achso, öhm. evt. noch, wie der Umfang von meinem Spiel letztendlich
werden soll:

2D ist klar, tilebasiert. Story und so steht, da ich weder unter Zeitmangel
stehe, noch es ein kommerzielles Projekt wird, ich also hobbymäßig
dranarbeiten, werde ich nach Lust und Laune dran arbeiten.
Die Engine will ich coden, damit ich evt. für weitere Projekte was fertiges
da habe und auch mal verstehe, wie so etwas arbeitet.

Ich bin auch gerne bereit, mir Bücher zu kaufen.

(Schon wieder so ein langer Text... :oops: )

Lange Rede, kurzer Sinn:
Was sollte meine 2D Engine alles können?


PS:
Die Suche hat nichts ergeben und in den FAQ steht hier so etwas übrigens
auch noch nicht. ;)
MfG Shiver!

„Ideen sind nur Ausgangspunkte. Um zu wissen, was man zeichnen will, muss man zu zeichnen anfangen.“ Pablo Picasso

Ibot Development - Mein Weg zum eigenen 2D RPG

the[V]oid

Alter Hase

Beiträge: 775

Wohnort: Aachen

  • Private Nachricht senden

2

08.06.2009, 20:09

Schonmal daran gedacht, vielleicht SFML zu verwenden? Dann würdest du dir um deine Punkte Timer und Content schonmal keine Gedanken machen müssen.
<< an dieser Stelle ist eine Signatur verstorben >>

Kasenoru

Frischling

Beiträge: 79

Beruf: Softwareentwickler

  • Private Nachricht senden

3

08.06.2009, 20:13

Zitat

2D ist klar, tilebasiert. Story und so steht, da ich weder unter Zeitmangel
stehe, noch es ein kommerzielles Projekt wird, ich also hobbymäßig
dranarbeiten, werde ich nach Lust und Laune dran arbeiten.


Hmm, ich kann mir noch nicht wirklich viel darunter vorstellen.

Was für eine Art von 2D RPG schwebt dir denn vor? Was klassisches wie Final Fantasy oder Lufia mit geringer Auflösung? Oder eher ein hochauflösendes ISO RPG? Oder was ganz anderes?

Du sagst es soll was "kleines" werden, was genau schwebt dir vor?

Eine ganz entscheidene Sache hast du aber schon selbst erkannt:

Zitat

Ich weiß, dass das kein Friede-Freude-Eierkuchen wird, aber ohne Planung
läuft überhaupt nichts.


Wenn du wirklich eine saubere Planung gemacht hast, dann müsstest du eigentlich automatisch wissen was du brauchst.

Zitat

Nun, da ja bald Sommerferien sind, werde ich abends wohl des öfteren
ein paar Stündchen Zeit haben.


Ich kann dir jetzt schon garantieren, das die Sommerferien da nicht ausreichen werden. (Ich hoffe ich schätze jetzt deine Erfahrung nicht falsch ein).

Zitat

- Texturmanager
Naja, Texturen laden, löschen, hinzufügen, doppeltes laden verhindern, etc.

- Soundmanager
Siehe Texturmanager

- Timer
Zeit messen und FPS

- Physik
Kollision und evt. andere Sachen?

- Input
Maus, Tastatur

- Content
Texte auslesen und irgendwie auf dem Bildschirm bringen

- GUI
Dialogboxen, Interface, ...

- KI
Das kommt zuletzt

- Datenmanager
Speichern, laden, ...

- Framework
Standardsachen: OGL initialisieren, Fenster öffnen, Spiel updaten, Objekte
dann auf dem Bildschirm bringen, usw.

- Map
Für die ganzen Karten, also "Karte" aus txt Datei auslesen

Soweit geht meine Planung erst einmal.


Ich hoffe sehr das die Dokumente bei dir wesentlich ausführlicher gestaltet sind. Denn das was ich hier sehe sieht wie eine "Planung" aus, die innerhalb von 30 Minuten in Notepad geschrieben wurde.

Ich würde dir gerne weiterhelfen, doch dazu bräuchte ich mehr Details.

Z.b.

Zitat

- Content
Texte auslesen und irgendwie auf dem Bildschirm bringen


Was soll denn hier "irgendwie" heißen? Texte auslesen, woraus? Wofür sind die Texte? NSC Texte? Wie werden die Fonts verwaltet? Wie wird das Verhalten der NSCs bestimmt?

Ich denke du solltest dir da nochmal genauer Gedanken machen, dann wird dir klar werden, was du alles noch brauchst.

Zitat

Die Engine will ich coden, damit ich evt. für weitere Projekte was fertiges
da habe und auch mal verstehe, wie so etwas arbeitet.


Wenn du nicht weist wie eine 2D Engine arbeitet, so versuche doch erstmal eine kleine Engine für einfache 2D Spiele zu schreiben. Denn gleich eine 2D RPG Engine zu entwickeln ist in meinen Augen etwas zuviel des guten.

Mit freundlichen Grüßen

Kasenoru

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

4

08.06.2009, 20:14

Zitat

Was sollte meine 2D Engine alles können?


Du musst das anders machen: Schreib dein Spiel und entwickel die Engine dafür.

5

08.06.2009, 20:19

Ich finde die Planung nicht so gut.

Einiges ist einfach: Die KI z.B. muss haargenau auf das Spiel zugeschnitten sein, ein Bot der nur Ballern aber nie die Fahne klauen kann ist einfach unbrauchbar.
Kollision ist auch unterschiedlich. In einem Action Spiel sollte die sehr genau sein, in einem RPG muss die nur recht grob sein.

Ich würde auch z.B. glfw benutzen, da haste Timer, simples Input und Ogl initialisieren. Der Vorteil von Ogl ist doch, dass es plattformunabhängig ist, das ist die Initialisieurng aber imo nicht (weil du halt ein passendes Fenster brauchst und so). Benutzt du glfw, läuft es quasi ohne zutun auf Mac Linux und Windows, initialisierst du selber wahrscheinlich erstmal nur auf Windows, vielleicht mal auf Linux aber vielleicht nie auf Mac.

Klar, SMFL oder sonsitges kann man auch gebrauchen, aber darüber kann ich nix sagen, ich hab nur glfw benutzt und den Rest per Hand gemacht.
Ich würde halt auch erstmal so eine Art Framework mit Basis funktionen machen und das Spiel drum herum bauen. Oder aber, einfach mit dem spiel anfangen, gucken was man braucht und das jeweils möglichst universell implementieren.

Gerade als Anfänger kann man nicht alles durchblicken und durchplanen, weil die Erfahrung fehlt.
Lieber dumm fragen, als dumm bleiben!

n0_0ne

1x Contest-Sieger

  • Private Nachricht senden

6

08.06.2009, 21:23

hmmm ich hab glfw noch nie gehört, die bescheibung passt auch ziemlich genau auf die SFML ^^

Aber ich denke Jonathan hat recht, wenn du zu m ersten mal sowas machst, solltest du erstmal drauf losprogrammieren, oder vllt bei einem anderen projekt mitarbeiten. wenn du da noch nicht so viel erfahrung mit hast, wirst du wohlkaum im voraus bereits wissen, was du später alles brauchst, wie einzelne module am besten miteinander zusammen arbeiten usw.
Als ich am Anfang das SDL spiel aus dem buch erweitert hab, hab ich auch jedemenge fehler gemacht. Dann hab ich es auf die SFML portiert und die ausgebessert... mitlerweile hab ich wieder lust neu anzufangen, weil ich nicht genau wußte, was am ende so rauskommen soll, und vieles jetzt nicht so ist, wie ichs gern hätte...
Aber vielleicht ist das auch nur bei mir so, und du hast bereits erfahrung und kannst das mit genug planung und viel zeit direkt alles richtig umsetzen :D

7

09.06.2009, 18:17

Tach!

Danke erst mal für die Antworten.
Ok, ich habe mich wahrscheinlich schlecht ausgedrückt, sry dafür.
Also, wegen den Missverständnissen:
Das ist nicht meine "endgültige" Planung. Ich habe mit der Planung
angefangen, aber ich wollte euch um Hilfe zur Fortsetzung bitten, weil ich
denke, dass man bei solch einem Projekt bei der Planung nichts falsches
machen sollte.
Und wenn die Planung nicht gut ist, dann bitte ich um Verbesserungen, weil
ich nicht so ein Typ bin, der ins Forum schreibt "Macht mir die Planung für
eine Engine, die auf das Spiel ausgerichtet ist, das mir in den Gedanken schwebt".
Ich wollte wenigstens einen Ansatz zeigen.

@ the[V]oid
Für solche Sachen wie bsp. den Timer verwende ich gerne eine andere
Library, genauso für Musik. Bloß was ich halt versuchen will, selbst
mit OGL zu verwirklichen, ist das viele Grafikzeugs.

@ Kasenoru
Ok, meine Beschreibung war wirklich etwas schwammig.
Weiter als bei der Planung von oben bin ich noch nicht, nur alles etwas
ausführlicher gefasst.

Zitat

...dann wird dir klar werden, was du alles noch brauchst...

Deswegen wollte ich halt hier nachfragen.
Mir ist noch nicht klar, was die Engine im Endeffekt alles können sollte,
bzw. das, was sie können sollte, muss davor alles schwarz auf weiß
stehen.

Dass die Zeit der Sommerferien nicht reicht ist überhaupt kein Problem,
ich stehe nicht unter Zeitdruck. ;)
Ich lasse mir auch gerne 1-2 Jahre dafür Zeit (wie gesagt, der Traum
seit vielen Jahren).

Das mit den Texten habe ich mir so vorgestellt, dass sie aus einer
Datei geladen werden, oder ich halt so etwas wie ein Dialog Skript
programmiere (ich weiß nicht wo, irgendwo hab ich mal sowas gelesen...)
Für die Font wollte ich dann eine eigene Klasse schreiben.

Also zu meinen Ideen:
Ich denke Pokemon beschreibt die beste Art, wie sich der Spieler
letztendlich fortbewegen soll :lol:
http://www.youtube.com/watch?v=k_LIOS9bRcA

Die Grafik des Spiels dürfte ja keine Rolle spielen, außer 2D.
Die Story auch nicht, oder?
Aber, wo du schon einmal gefragt hast: Es soll etwas klassisches wie FF
werden. Natürlich nicht auf dem Niveau.

@ David_pb
Den Beitrag verstehe ich ein wenig zweideutig. :lol:
Meinst du erst das Spiel entwickeln und im Nachhinein die Engine oder
die Engine gezielt für mein Spiel (ich vermute letzteres)?

@ Jonathan_Klein
glfw werde ich mir auf jeden Fall anschauen!
Danke für den Tipp.

Zitat

Gerade als Anfänger kann man nicht alles durchblicken und durchplanen, weil die Erfahrung fehlt.

Derselben Meinung bin ich auch.
Ich wollte mal hören, was die "Profis" dazusagen und habe eben
nachgefragt, denn euren Rat werde ich letztlich vermutlich befolgen.

@ n0_0ne
Man kann wohl am besten aus eigenen Erfahrungen lernen. :)
Und das mit der Planung hoffe ich auch, denn ich hab schon bei einem
Teamprojekt von mir gemerkt, dass ohne Planung gar nichts läuft...
deswegen habe ich es auch so damit hehe. :lol:
(auch wenn es "ein wenig" umfangreicher war)


Ich will das Projekt auch ein wenig als Lernprozess ansehen, denn
ich kann zwar lesen was das Zeug hält, aber ohne Praxis lernt man doch
nichts.
Wie gesagt, die Zeit spielt keine Rolle, auch wenn ich erst ein einigen
Jahren fertig bin. ;) Habs mir fest vorgenommen! Und irgendwas zu lesen (Buch oder andere Quellen, Englisch ist egal), macht mir auch
nichts aus (viele wollen ja einfach ein Spiel programmieren, ohne am
besten einen (englischen) Satz zu lesen und fragen direkt nach Codes).

Danke noch mal für eure Mühe! :D

---Edit---
Sollten noch irgendwelche Fragen offen sein, bitte einfach nachfragen!
Ich verliere machmal bei meinen Texten die Übersicht, :roll: :lol:
MfG Shiver!

„Ideen sind nur Ausgangspunkte. Um zu wissen, was man zeichnen will, muss man zu zeichnen anfangen.“ Pablo Picasso

Ibot Development - Mein Weg zum eigenen 2D RPG

Kasenoru

Frischling

Beiträge: 79

Beruf: Softwareentwickler

  • Private Nachricht senden

8

10.06.2009, 01:56

Zitat

Dass die Zeit der Sommerferien nicht reicht ist überhaupt kein Problem,
ich stehe nicht unter Zeitdruck. Wink
Ich lasse mir auch gerne 1-2 Jahre dafür Zeit (wie gesagt, der Traum
seit vielen Jahren).


Das hört sich schon besser an ;)

Zitat

Und irgendwas zu lesen (Buch oder andere Quellen, Englisch ist egal), macht mir auch
nichts aus


Das will ich hoffen.

Ich habe dir hier ein paar kleine Hinweise und Informationen aufgeschrieben, wie man es machen kann. Es handelt sich hierbei aber nicht um eine perfekte Anleitung für ein 2D RPG. Ich habe hier nur ein paar kleine Sachen zusammengetragen. Die auch nicht unbedingt frei von Fehlern sind. Mit dem Thema lassen sich ganze Bücher füllen.

Die Screenshots die ich hier verwende, um bestimmte Dinge verständlicher darzustellen, stammen fast alle aus meinen alten Projekten und wurden auch nicht alle extra für diesen Thread erstellt.

Erstmal brauchst du ein Grundsystem. Je nach Portabilität und anderen Faktoren kann dieses System sehr einfach oder auch sehr komplex ausfallen.

In einem 2D RPG benötigst du natürlich Grafik. Ein passendes Grafiksystem mit OpenGL könntest du z.B. wie folgt aufbauen.

1. Fenster/Vollbild und OpenGL

Dein System sollte in der Lage sein, ein Fenster sowie einen entsprechenden OpenGL Kontext zu erstellen. Zudem sollte es auch möglich sein, das Spiel im Vollbildmodus zu spielen.

2. Pixmaps (Pixel-Maps/Grafiken/Bilder)

Dein System sollte in der Lage sein, Grafiken von der Festplatte in den
Systemspeicher zu laden. Zudem sollte es möglich sein, die geladenen Grafiken zu modifizieren.

Sehr praktisch ist es auch, wenn man "leere" Pixmaps beliebiger Größe im
Systemspeicher erzeugen kann.

3. Texturen


Damit du deine Pixmaps später überhaupt bequem mit OpenGL darstellen kannst, musst du diese zunächst in eine Textur umwandeln. Dadurch landen deine Pixmaps dann, je nach Konfiguration, im Grafikspeicher und die Grafikkarte hat einen viel schnelleren Zugriff auf diese.

4. Sprites

Um Texturen auf dem Bildschirm sichtbar zu machen, erzeugst du dir ein sogenanntes Sprite aus 2 Dreicken und legst dort die Textur drüber. Dazu gibts viele Tutorials.

Du hast damit sehr viele Freiheiten in der Gestaltung eines Sprite. Du kannst Sprites sehr leicht mit OpenGL skalieren, rotieren, blenden, uvm.

5. Planes

Planes sind Sprites, mit dem Unterschied, dass diese kein sichtbares Ende haben. Also unendlich in alle Richtungen scrollen können. Sowas wirst du oft brauchen, für ewig scrollende Hintergründe oder auch für bestimmte Kampfanimationen.

6. Tilemaps

Tilemaps werden nicht nur in 2D RPGs sondern auch in ganz anderen Genres benutzt, daher sind sie in unserem Fall ein Teil des Grundsystems.

Was eine Tilemap ist weißt du ja schon. Somit weißt du denke ich auch schon, was ein Tileset ist.

Das System sollte in der Lage sein, solche Tilemaps mit einer variablen Anzahl an Mapping-Ebenen zu erzeugen. In der Regel reichen so 2-3 Ebenen. Das kann von Map zu Map variieren.

Das Tileset beinhaltet alle Tiles/Chips die du für die Map benötigst. In deinem Map-Editor wählst du einfach die gewünschten Tiles aus und platzierst sie auf der Map.

Allerdings wäre das so alles ein wenig zu einfach. Denn wie würdest du z.b. Wasser oder Lava auf einer Map darstellen?

6.1 Animierte Tiles

Das Problem lässt sich über animierte Tiles lösen. Für diese könntest du z.B. einen extra Bereich auf dem Tileset anlegen, in welchem du z.B. je 4 Tiles als 1 animiertes Tile behandelst. Die 4 Tiles stellen dann die Animationsschritte dar.

Das System würde dann immer nur eines der 4 Tiles zeichnen und in festgelegten Zeitabschnitten das zu zeichnende Tile wechseln. Womit das ganze dann schön animiert ist.


(Link)

(Klicken zum vergrößern)

Der pinke Bereich umfasst bei diesem Tileset 3 animierte Tiles mit je 4 Animationsstufen.

6.2 Terrains/Auto-Tiles

Terrains/Auto-Tiles sind theoretisch nicht zwingend erforderlich. Nehmen einem in der Praxis aber sehr viel Arbeit ab.

Das ganze kann z.B. so aussehen:


(Link)



Woraus sich folgendes erstellen lässt:


(Link)

(Klicken zum vergrößern)

Der Algorithmus ist zwar nicht sonderlich kompliziert, aber es ist trotzdem recht "anstrengend" das ganze zu implementieren. Wobei es ganz darauf ankommt wie man es macht. Aber der Aufwand lohnt sich. Ich kann dir nur empfehlen dich damit zu befassen.

7. Fonts

Für ein 2D RPG brauchst du natürlich noch Textausgaben. Ich empfehle dir hier Bitmapfonts zu verwenden. Da du damit sehr schöne Texteffekte erzeugen kannst, sofern du alles selbst implementierst.

Eine Bitmapfont ist im Grunde nur eine Grafik, welche alle benötigten Zeichnen beinhaltet. Mit einer solchen Grafik und vorhandenen Zeichendaten(Größe und Position jedes Zeichens auf der Grafik), kannst du ganz leicht schöne Textausgaben erzeugen.

Rotationen, Skalierung, Farbverläufe, animierte Texte (z.B. tanzender Text), uvm. sind problemlos möglich.


(Link)

(Klicken zum vergrößern)

Um eine Bitmapfont zu erzeugen, kannst du dir ganz einfach einen Konverter schreiben. Das ist nicht viel Arbeit und in wenigen Stunden erledigt.

8. Z-Sorting

Auch wenn es dir jetzt noch nicht wichtig ist, so wird es dir im späteren Verlauf deines 2D RPGs immer wichtiger werden. Wie bestimmt man, welche Grafiken welche verdecken?

Dazu könntest z.b. deine Grafiken mit einer Z-Koordinate versehen. Die Grafiken werden dabei z.B. in einer Liste gespeichert und nach der Z-Koordinate sortiert. Anschließend wird die Liste durchlaufen und alle Grafiken gezeichnet.

Alternativ ließe sich sowas auch, mit kleinen Einschränkungen, über den OpenGL Z-Buffer erledigen.

9. Clipping

Es ist manchmal sehr Hilfreich, alle Zeichenoperationen auf einen ganz bestimmten Bereich(Rechteck) zu begrenzen und alles außerhalb des Bereichs abzuschneiden. Das nennt man Clipping.

Du wirst es hin und wieder mal brauchen, daher sollte das in deinem Grafiksystem nicht fehlen.

OpenGL bietet sowas z.B. über die sogenannte Scissor-Box an, sofern der Scissor-Test aktiviert wird.

10. Weiteres


Das waren jetzt nur ein paar Grundlagen für ein universelles Grafiksystem.

Neben einem Grafiksystem brauchst du natürlich noch ein Input- und Audiosystem. Aber ich denke daran wird es nicht scheitern und ich muss dazu nichts weiter sagen.

Wenn du ein solches Grundsystem hast, wird es Zeit für den RPG spezifischeren Teil.

1. UI

Für ein 2D RPG brauchst du in der Regel in irgendeiner Form eine Benutzerschnittstelle. Auch wenn UIs jetzt nicht wirklich RPG spezifisch sind habe ich sieh hier aufgezählt.

Für ein einfaches kleines 2D RPG brauchst du keine komplexe UI entwerfen. Es reichen in der Regel einfache Fenster und Auswahlmenüs.

Aber du kannst es natürlich auch komplexer mit Maussteuerung und verschiebbaren Fenstern, Textfeldern, Buttons, Radiobuttons, Checkboxen, Comboboxen, Spinboxen, Listen, uvm. gestalten.

Wichtig ist nur, den Style der Elemente in einer einzigen Quelle festzuhalten. Z.b. in einer Grafik. Eine solche Grafik kann z.B. so aussehen:


(Link)


Daraus kannst du dann deine Elemente erzeugen.


(Link)

(Klicken zum vergrößern)

Und das tolle ist, wenn du den Style ändern willst brauchst du nur die Grafikdatei kurz überarbeiten. Sogar der Spieler selbst erhält damit die Möglichkeit, das "Look and Feel" der UI seinen Wünschen anzupassen.

2. NSCs -> Nicht Spieler Charaktere

Der Spieler ist in deinem Spiel ja sicher nicht die einzige Figur auf der Map nehme ich an. Es wird sicher noch eine Menge NSCs geben. Z.b. Dorfbewohner, Ladenbesitzer, etc.

Irgendwie musst du deren Verhalten festlegen können. Die NSCs tun in der Regel nämlich ein wenig mehr als nur "Text auszugeben".

Dies lässt sich recht einfach mit einer "eigenen Skriptsprache" lösen. Natürlich keine komplexe Sprache wie Ruby oder Python.

Man kann sich das im Grunde ganz einfach machen, indem man
die Kommandos der Sprache nicht als Text schreibt, sondern in einem eigenen Editor in einer Liste oder in einem Baum hält. Per Mausklick lassen sich neue Befehle einfügen. Man schreibt diese also nicht selbst hin.


(Link)

(Klicken zum vergrößern)

Dadurch kann man sich den kompletten Parser sparen. Du speicherst für jeden Befehl der Sprache einfach nur eine ID und Parameter. Da die Sprache auch If-Else Konstrukte zulassen sollte, ist ein Indent(Einrückung) Wert für jeden Befehl von Vorteil.

Eine solche Sprache lässt sich sehr schnell interpretieren und der Interpreter fällt relativ klein aus.

In deinem Map-Editor sollte es also möglich sein, NSCs zu erzeugen und zu platzieren sowie mit Befehlen zu füttern.

Ein paar Beispiele aus meinen alten Projekten, die dir zeigen wie sowas aussehen kann.


(Link)

(Klicken zum vergrößern)


(Link)


(Klicken zum vergrößern)

Die Blauen Rechtecke stellen NSCs dar, der Code kann ganz einfach im Editor bearbeitet werden.

Der Editor muss natürlich nicht derart komplex gestaltet werden. Zu Anfang kannst du dir alles auch erstmal ganz einfach machen.

Ich rate dir aber, dich im späteren Verlauf deines Projektes mit der Entwicklung von grafischen Oberflächen vertraut zu machen.

Auch wenn du dir jetzt noch sagst "Ach ich tippe die Map-Daten einfach manuell ein!", so wird sich deine Meinung später ändern. Eigene Tools lohnen sich enorm.

3. Skriptsprachen statt C/C++

Neben den NSCs gibt es noch viele weitere Dinge die programmiert werden müssen. Z.B. das Kampfsystem, Spielmenüs, Shopsysteme, Handelsysteme, Levelsysteme, besondere Spielszenen/Animationen, uvm.

Das alles mit C/C++ zu entwerfen ist zwar problemlos möglich. Ist aber um einiges unbequemer und unflexibler als wenn man dazu eine Skriptsprache wie Ruby oder Python verwendet. Das ist zumindest meine Meinung, gibt auch Entwickler die das ganz anders sehen.

Die oben aufgezählten Dinge benötigen die Geschwindigkeit und Features von C/C++ in der Regel nicht. Auch ein direkter Zugriff auf OpenGL oder sonstige Funktionen wird nicht benötigt.

Lediglich der Zugriff auf einige Klassen des Grundsystem wie Sprite-Klassen, UI-Klassen, etc. wird benötigt. Solche Klassen lassen sich mit der C API der Skriptsprache sehr leicht für die Skriptsprache selbst zugänglich machen.

Auch der Interpreter der Skriptsprache lässt sich problemlos in das Spiel einbetten. Der Spieler muss sich also nicht erst Ruby oder Python installieren.

4. Weiteres

Es gibt da noch sehr viel mehr zu sagen. Es gibt noch sooooo viele Dinge die ich hier jetzt nicht aufgezählt habe. Mit etwas Geschick bist du in 2-3 Jahren "Ferig" :lol: Aber es kann auch länger dauern, je nachdem wie schnell du verstehst, wieviel Zeit du investierst und was du bis jetzt schon alles kannst.

Ich empfehle dir, alles in kleine Stücke aufzuteilen und somit Stück für Stück mit kleinen Testprojekten immer näher ans Ziel zu kommen.

Und wenn du es wirklich alles soweit schaffst, dass eine 2D RPG Engine + Tools vorhanden sind, fängt der "Spaß" erst richtig an :lol:

Dann kommen nämlich die eigentlichen Probleme. Wie soll die Story aussehen? Wer zeichnet eigentlich die Grafiken? Woher nehme ich Sound und Musik?

Einen Grafiker, der Grafiken in guter Qualität für dein Spiel erstellt will erstmal gefunden werden. Ich habe da bisher nur schlechte Erfahrungen gemacht.

Wie auch immer, ich hoffe ich konnte dir einen kleinen Überblick verschaffen. Viel Erfolg :)

Mit freundlichen Grüßen

Kasenoru

9

10.06.2009, 16:37

Moin!

Das ist ja eine ganz schöne Menge, echt hilfreich, vielen, vielen Dank! :)
Ist wirklich eine Menge, aber das macht nichts, was soll man denn auch erwarten. :D

Dennoch sind bei mir ein paar Fragen aufgekommen:

Zitat

...könntest du z.B. wie folgt aufbauen...

Wie würde denn der Aufbau in der "Projektmappe" aussehen?
Es ist doch sicherlich am besten, das ganze mit Klassen aufzubauen, oder? Mit dem altbewährten Schema eine .h und eine .cpp zu jeder Klasse.

Zitat

1. Fenster/Vollbild und OpenGL

Hier gehört also auch die Initialisierung von OpenGL dazu, oder?
Wie wichtig ist es, die Auflösung ändern zu können?

Zitat

2. Pixmaps
bis

Zitat

4. Sprites

Also habe ich das so richtig verstanden?

1. Grafiken in den Systemspeicher laden
2. Grafiken in Textur umwandeln (gelangen in den Grafikspeicher)
3. Sprites mithilfe von zwei Dreiecken erstellen und diese kann
man dann texturieren

Achja, was genau meinst du mit "modifizieren" bei den Pixmaps?

Zu den Tiles:
Ist es angebracht, für die komplette Tiles Sektion eine oder mehrere
Klassen anzulegen?

Also an Stichworten müsste der Grundbau des Grafiksystems folgendes können:

• OpenGL Kontext erstellen
• Vollbild oder Fenstermodus auswählen
• Auflösung ändern
• Grafiken in den Systemspeicher laden (Pixel-Maps)
• Pixel-Maps in Textur umwandeln (in Grafikspeicher)
• Sprites bestehend aus 2 Dreiecken
• Planes (Sprites ohne sichtbares Ende)
• Tilemaps (mit mehreren Ebenen)
• Animierte Tiles darstellen
• Auto Tiles
• Fonts
• Z-Sorting
• Clipping

Meinst du, ich sollte mir, bevor ich überhaupt mit der "Engine" beginne,
einige Tools selbst programmieren (z.B. einen Leveleditor)? Bzw. wieviel Zeit
sollte man darin investieren (für die Tools)?

Du hast ja schon angesprochen: Es gibt natürlich noch mehr Systeme als
das Grafiksystem.
Meinst du ich kann das Grafiksystem zuerst einmal total unabhängig programmieren
und anschließen die "Engine" nach und nach erweitern?
Das Grafiksystem wird ja sicherlich auch viel Zeit "fressen". :D

In dem Grafiksystem ist ja bisher noch keine Kollision dabei, unter was
könnte man das denn fassen? "Physik"?

Jedenfalls vielen Dank für die Hilfe! :)
MfG Shiver!

„Ideen sind nur Ausgangspunkte. Um zu wissen, was man zeichnen will, muss man zu zeichnen anfangen.“ Pablo Picasso

Ibot Development - Mein Weg zum eigenen 2D RPG

Black-Panther

Alter Hase

Beiträge: 1 443

Wohnort: Innsbruck

  • Private Nachricht senden

10

10.06.2009, 17:21

Zitat von »"Shiver"«

In dem Grafiksystem ist ja bisher noch keine Kollision dabei, unter was
könnte man das denn fassen? "Physik"?


Rudimentäre, ganz einfache Kollisionstests würd ich vielleicht als kleine inline-methode für die jeweiligen Sprites bzw allg. Objekte anbieten...

Was Physik betrifft, würd ich dir raten dich zu entscheiden... Entweder Physik ODER Grafik... beides auf einmal wird dich zu 100% überfordern. Was einfach wäre, wenn du eine fertige Physikengine unterstützen würdest (sehr gut funktioniert u.a. Box2D von Erin Catto).

Falls du selbst vor hast etwas in diese Richtung zu programmiern, was über Massenpunkt-Physik hinausgeht, dann sei dir dabei bewusst, dass du mathematisch und physikalisch ziemlich fit sein solltest, eine ordentliche Portion Geduld aufbringen musst, und dich mit numerischen (stabilisierungs) Verfahren auskennen solltest.
Für einen Anfänger alles andere als ein gutes Startprojekt (außer vielleicht du bist Physik/Mathestudent ;)).

Mein Rat: Mach in Ruhe deine Grafik-Engine und biete eine Unterstützung von zB Box2D an. Damit lassen sich schon sehr viele Sachen machen!
stillalive studios
Drone Swarm (32.000 Dronen gleichzeitig steuern!)
facebook, twitter

Werbeanzeige