Heyho,

ich möchte hiermit mein neuestes Projekt vorstellen: Die Frostshard Engine.
Da ich gerne eine Art Blog über größere Projekte führe, möchte ich diesen Thread nicht nur als Vorstellung nutzen, sondern auch als Entwicklungsthread.
Nach und nach werden hier immer neue Bereiche auftauchen, je nachdem wie Weit die Entwicklung voranschreitet.
Da die Engine, wie bereits erwähnt, noch in Entwicklung ist, freue ich mich jederzeit über sinnvolle Kritik.
Auch über mögliche neue Features würde ich mich freuen.

Negativbeispiel:

die tilemap ist voll scheiße und du kannst gar nicht programmieren

Positivbeispiel:

Ich finde das System der Tilemap nicht schön gelöst, da unter die Nummerierung der Tiles sehr unübersichtlich ist. Außerdem gibt es bei den Textboxen einen Fehler, welche das Spiel bzw. die Engine crashen lässt. Dieser taucht auf, wenn [hier Ursache einfügen].

Außerdem würde ich es gut finden, wenn es eine Art Shopsystem geben würde, bei dem der Spieler seine Gegenstände kaufen und verkaufen kann.

Nun möchte ich noch kurz zu mir kommen:
Ich hatte bereits in einem Zeitraum von 4 Wochen eine kleine 2D RPG Engine geschrieben, da es eine Projektarbeit für die Schule war. Auch diese wurde in C++ geschrieben.
Nun möchte ich aber jegliche Fehler, welche vorhanden waren, nicht wiederholen und die Engine als Langzeitprojekt in meiner Freizeit programmieren.
Da ich nebenbei noch arbeiten gehe, könnt ihr nicht erwarten, dass ich wöchentlich oder gar täglich neue Updates bringen werde.
Dazu fällt mir ein prima Sprichwort ein: It's done, when it's done.

Nun aber näheres zur Engine an sich.

[HR][/HR]
[Logo folgt, wenn sich jemand daran versuchen möchte, einfach eine PN schreiben]

Die Frostshard Engine soll eine voll funktionstüchtige Engine werden, welche zum Erstellen von 2D Rollenspielen in C++ genutzt werden kann.
Zur einfacheren Entwicklung wird die Bibliothek SFML 2.1 genutzt.
Zur Engine gehört ebenfalls ein Editor, der sogenannte "Frostshard Mapper", mit welchem man u.a. die gesamten Karten des Spieles erstellen kann.
Das gesamte Projekt ist Open Source, allerdings werde ich das Projekt erst hochladen, wenn ich schon einige Grundbausteine fertig programmiert habe. Sonst bringt es weder mir, noch euch etwas.
Nun komme ich aber mal zu den derzeitigen und geplanten Features.

Legende:

• Fertig - Dieser Teil ist vorraussichtlich fertig programmiert.
  
• In Entwicklung - Dieser Teil ist gerade in Entwicklung
  
• Folgt - Dieser Teil wird aufjedenfall in die Engine aufgenommen, jedoch wurde die Entwicklung und Planung noch nicht gestartet.
  
• Geplant - Über diesen Teil wurde bereits nachgedacht, aber ist weder in Entwicklung, noch fertig programmiert, noch ist festgelegt, dass dieser überhaupt in die Engine aufgenommen wird.
  
• Ausgeschlossen - Dieser Teil wird vorraussichtlich nicht in die Engine aufgenommen.
  

Die genannten Features, welche ausreichend geplant oder bereits in Entwicklung sind, werden weiter unten detailliert erklärt.

Frostshard Engine:
[SPOILER2]Tilemaps
Kollisionen
Eventsystem
Textboxen
Spieler
Interface (z.B. Menü bei ESC)
Itemsystem
Inventarsystem
Händler/Shops
Kampfsystem
NPCs
LUA-Engine für Events
[/SPOILER2]

Frostshard Mapper:
[SPOILER2]Tilebasiertes Mappen der Tilemaps (als Beispiel könnte man den RPG Maker nehmen)
Kollisionsmapping
Events setzen
NPCs setzen
LUA-Programmierung der Events direkt im Mapper
[/SPOILER2]

Nun möchte ich zu den Features kommen, welche bereits ausreichend geplant oder bereits in Entwicklung sind.

[HR][/HR]
Tilemaps:

[SPOILER2]Um eine Tilemap zu verstehen, muss man erstmal wissen, was ein Tileset ist.
Dies ist zum Beispiel ein Tileset, welches jedoch noch keine richtigen Grafiken besitzt:


Wie man klar erkennen kann, ist ein Tileset in immer gleichgroße Quadrate aufgeteilt, in diesem Fall besitzt ein Tile eine Größe von 32x32 Pixeln.
Auf diesem Bild sind also genau 8 Tiles.
Und genau aus solchen entsteht eine Tilemap.
Eine Tilemap ist also eine Grafik, welche aus vielen kleinen Grafikstückchen zusammengesetzt wird.
Mit diesem Tileset könnte also eine Tilemap im fertigen Fenster wie folgt aussehen:



Klar erkennbar ist, das einige Tiles mehrmals benutzt wurden wie z.B. das Tile mit der Nummer 1.
Und genau das ist der Sinn eines Tilesets: Mit nur einer Grafik, können mehrere Landschaften entstehen.
Diese Methode war z.B. sehr wichtig für ältere Rollenspiele wie Secret of Mana. Da die alten Kassetten des Super Nintendos nicht viel Platz bieten konnten, wurde so (nach damaligen Entwicklungsstand) unmengen an Speicherplatz gespart.
Und genau auf dieses System baut die Frostshard Engine auf.
Nicht nur die User mit einer schlechten Internetleitung werden sich darüber freuen.

Es ist geplant, dass diese Tilemaps in einem .XML-Dateiformat gespeichert werden.
Dies ermöglicht eine leichte und schnelle Programmierung, welche die Ladezeiten gering halten sollte und dennoch komplett anpassungsfähig ist.
Eine Tilemap wird als gespeicherte Datei vorraussichtlich so aussehen (Die Einrückung wird vom Forum leider nicht übernommen):
[SPOILER2]
<Map>
<Config>
<Tileset>tileset.png</Tileset>
<TileSize>32</TileSize>
<Width>2</Width>
<Height>2</Height>
</Config>
<MapData>
<Tile Row="0" Column="0">0</Tile>
<Tile Row="0" Column="1">0</Tile>
<Tile Row="1" Column="0">1</Tile>
<Tile Row="1" Column="1">4</Tile>
</MapData>
<CollisionData>
<Collision Row="0" Column="0">0</Collision>
<Collision Row="0" Column="1">0</Collision>
<Collision Row="1" Column="0">1</Collision>
<Collision Row="1" Column="1">1</Collision>
</CollisionData>
</Map>
[/SPOILER2]

Diese Tilemap kann sowohl von der Engine als auch vom Mapper geladen und benutzt werden.
[/SPOILER2]

[HR][/HR]
Kollision:

[SPOILER2]Eine Kollision entsteht, wenn der Spieler ein Tile betreten möchte, welches er aber nicht betreten kann.
Dies wäre im Falle eines 2D Rollenspieles also z.B. eine Mauer. Es wäre ja auch totaler Blödsinn, wenn der Spieler durch alles durchlaufen könnte, oder?
Ein Kollisionssystem verhindert also, dass ein Spieler nicht durch jedes beliebige Tile durchlaufen kann.

Die Kollision ist eng mit der Tilemap verbunden.
Jede Tilemap hat ihre eigene Kollision.
In der Frostshard Engine hat nicht jedes eigene Tile eines Tilesets eine Kollision, sondern jede Tilemap kann das gleiche Tileset mit anderen Kollisionsdaten haben. Dies ist vorallem nützlich, wenn man Geheimwege o.ä. einbauen möchte.
Die Kollision wird in der jeweiligen Tilemap-Datei gespeichert.
Um das Beispiel von Oben noch einmal aufzugreifen:
[SPOILER2]
<CollisionData>
<Collision Row="0" Column="0">0</Collision>
<Collision Row="0" Column="1">1</Collision>
<Collision Row="1" Column="0">1</Collision>
<Collision Row="1" Column="1">0</Collision>
</CollisionData>
[/SPOILER2]

Mit diesen Kollisionsdaten ergibt sich folgende Kollision:

[TABLE="class: grid, width: 10"]
[TR]
[TD]Keine Kollision[/TD]
[TD]Kollision[/TD]
[/TR]
[TR]
[TD]Kollision[/TD]
[TD]Keine Kollision[/TD]
[/TR]
[/TABLE]

Jede 0 steht also für keine Kollision und jede 1 steht für eine Kollision.

Das Kollisionsmapping im Frostshard Mapper wird vorraussichtlich wie folgt aussehen:



Beim Kollisionsmapping hat man seine Tilemap vor sich.
Wenn man nun mit dem Kollisionstool auf ein Tile klickt, bekommt dieses Tile eine halbdurchsichtige lilane Ebene. Diese halbdurchsichtige lilane Ebene markiert Tiles, durch welche der Spieler im Endeffekt nicht durchlaufen kann. Die halbdurchsichtige lilane Ebene wird natürlich im Spiel oder außerhalb des Kollisionstool im Frostshard Mapper nicht sichbar sein.[/SPOILER2]

[HR][/HR]
Changelogs

0.0.1 Changelog:

Versionen
- Ich werde die Versionen nicht besonders unterteilen.
Wenn es sich um kleine Neuerung oder Bugfixxes handelt, wird die Version z.B. 0.0.2 heißen und nicht 0.2.0.
0.2.0 wäre z.B. eine Version, in der etwas größeres hinzugefügt wurde, wie z.B. ein Eventsystem oder ein Shopsystem oder sowas.
1.0.0 wird die erste große Version sein, in der alle wichtigen Dinge enthalten sind. Maps, Kollision, Events, Steuerung und sowas.

Maps
- Laden der Maps aus einer .XML-Datei funktioniert schnell und ohne Probleme.
- Ich habe mich dazu entschieden, die Kollision mit in die Mapklasse zu nehmen, da jede Map ihre eigene Kollision hat und nicht die einer anderen.

Hier mal ein kleines Beispiel, wie ich eine momentan verschiedene Maps aufrufen kann.

Quellcode

1. TileMap *map;
2. map = TileMap::getInstance();
4. if(!map->load("map.xml"))
5. {
6. // Wenn alle benötigten Dateien gefunden, wird die map.xml angezeigt.
7. // Ansonsten kann man hier festlegen, was passiert, wenn die Map nicht geladen werden konnte.
8. return -1;
9. }
11. // Hier wechseln wir die aktuelle angezeigte Map zur map2.xml
12. if(!map->load("map2.xml"))
13. {
14. // Siehe oben
15. return -1;
16. }

Alles anzeigen

Events
- Nach einigen Überlegungen habe ich mich dazu entschlossen, ein LUA-System für Events einzubauen.

Allgemein
- Die Engine wird wohl eher eine Art RPG Maker werden. Zumindest möchte ich in Zukunft darauf hinarbeiten.
Deswegen ist auch mein Entschluss auf ein LUA-System für Events gefallen.

[HR][/HR]

Wie bereits erwähnt, freue ich mich über sinnvolle Kritik und weitere gewünschte Features.
Da MMORPG-Core das einzige Forum ist, wo ich eigentlich noch aktiv bin, wird dieser Beitrag auch erstmal nur hier erscheinen, M-Core exklusiv sozusagen.
Ohne meine ausdrückliche Erlaubnis darf dieser Beitrag nicht in anderen Foren geposted werden, wogegen eine Verlinkung zu diesem Thread auf M-Core erlaubt ist.

Ich hoffe, dass es hier doch den einen oder anderen interessieren wird.
Vielleicht verleite ich ja sogar jemanden dazu, C++ zu lernen - Ich versuche nämlich die Engine so anfängerfreundlich wie möglich zu kommentieren. Gleichzeitig lernt man auch noch den Umgang mit der Bibliothek SFML, welcher aus meiner Sicht ebenfalls sehr leicht zu bedienen ist.
Aber selbst ohne Programmierung wird das ein oder andere mit der Engine möglich sein.
Wer weiß, vielleicht läuft es am Ende ja sogar auf eine Art RPG Maker aus? :-)

Ich freue mich aufjedenfall über eure Meinungen und hoffe auf rege Diskussionen und reges Interesse!

~Kaev

ulle;324250 schrieb:

Freue mich auf das was da kommt. Leider kann ich mit C++ nichts anfangen, da ich eine Plattformübergreifende Programmier Sprache suche. Wobei ich jetzt schon weiß das es nicht Java sein wird ;)

C++ ist Plattformübergreifend, genau wie SFML.
Kommt halt immer nur auf die Programmierung und Einstellung an. :P
Als GUI nimmt man dann halt QT oder sowas.
Da ich aber viel zu faul bin und zu wenig Erfahrung mit Linux habe, wird die Engine wohl nur unter Windoof laufen.

Tenshi:
Viele Teile der Engine nehmen ja schon die meiste Programmierung ab.
Maps, Items und co. werden alle in XML sein.
Für Events werde ich vermutlich eine LUA Engine einbinden, wobei ich in diesem Bereich noch keine Erfahrung habe.
Aber Befehle wie Player.MoveUp(1) wird es schon geben, da ist dann nichtmal so viel Programmiererfahrung nötig. Nur halt für kompliziertere Dinge. :)

Delinquenz;324256 schrieb:

Sofern du die Source rausrückst (LGPL) kann man sich das selbst bauen.


Dein Einwand ist garnicht so unberechtigt. Wenn man systemnah programmieren möchte, ist man bei Mac mit Objective-C richtig. Einer Sprache, die mir verwirrter als Perl erscheint. C++ wird halt auf dem Mac nicht so gut supportet, wie auf Linux und Windows. Die Linux API und die WinAPI sind beide in C geschrieben, C++' Vorgänger. In C++ kannst du auch reines C nutzen, deshalb ist das prima. Aber die MacOS API ist afaik primär in Objective-C geschrieben. Einer Sprache, die bis auf Applegeräten, keine Sau mehr nutzt.


Ich find Python echt super, aber ich bin mir nicht sicher, wie flüssig das Ganze in Python laufen würde. Afaik gibt es allerdings auch ein Python SFML-Binding.

Das Projekt wird hundertprozentig Open Source. Wer Lust hat, kann es sich dann für Linux umbasteln.. :P

Du liegst richtig, es gibt SFML auch für Python. Finden kann man diese hier: Python bindings for SFML &mdash; pySFML 1.3.0 documentation
Allerdings basiert diese (noch) auf SFML 2. Da afaik nichts wirklich Großes in SFML 2.1 neu ist, dürfte es keine großen Probleme geben, den Code 1:1 nach Python zu übertragen. Ob es in der Pythonversion neue oder sogar weniger Bugs gibt, kann ich allerdings nicht sagen.

EDIT: Bis auf einige Bugfixes und Verbesserungen ist in SFML 2.1 nichts neu.
SFML bietet sogar MAC-Unterstützung. :P

Ich finde es aufjedenfall schon super, dass doch etwas Interesse gezeigt wird. Ich hätte mit einem einzigen Post ala "Coole Sache" o.ä. gerechnet.
Wenn die Engine weit genug ist, werde ich ein Wiki aufsetzen und auch einige Tutorials verfassen, damit der Anfang leichter fällt.

Nur weil du eine neue Sprache lernst, wirst du deine geliebte Websprache schon nicht verlieren.
Ich habe über die Jahre auch mehrere Sprachen getestet und teilweise gelernt und kann die immernoch. :)

Der Fokus liegt aber auf der Engine, nicht auf den Tutorials. Keine Engine = Keine Tutorials. :P
Außerdem werden die Tutorials explizit für die Engine sein und nicht unbedingt für C++ oder SFML selber. Aber mal sehen was die Zukunft bringen wird, vielleicht kommt da ja doch mal irgendwas von meiner Seite.

Ich werde mich heute vermutlich mit den Maps an sich beschäftigen. Sobald eine kleine Testmap steht, die geladen und gespeichert werden kann, wird die Mappingfunktion im Mapper angegangen. Ich glaubs zwar nicht, aber vielleicht werde ich ja heute sogar damit schon fertig. :)

Ich werde für den Mapper ebenfalls SFML nehmen. Da brauch ich nicht extra Qt oder GTK nehmen. :P

Ich werd mir da schon was überlegen, mach dir keine Sorge. ;)

Da ich die letzten Tage nicht so viel Zeit hatte, großartig weiter zu machen, gibt es den ersten kleinen Changelog:

0.0.1 Changelog:

Versionen
- Ich werde die Versionen nicht besonders unterteilen.
Wenn es sich um kleine Neuerung oder Bugfixxes handelt, wird die Version z.B. 0.0.2 heißen und nicht 0.2.0.
0.2.0 wäre z.B. eine Version, in der etwas größeres hinzugefügt wurde, wie z.B. ein Eventsystem oder ein Shopsystem oder sowas.
1.0.0 wird die erste große Version sein, in der alle wichtigen Dinge enthalten sind. Maps, Kollision, Events, Steuerung und sowas.

Maps
- Laden der Maps aus einer .XML-Datei funktioniert schnell und ohne Probleme.
- Ich habe mich dazu entschieden, die Kollision mit in die Mapklasse zu nehmen, da jede Map ihre eigene Kollision hat und nicht die einer anderen.

Hier mal ein kleines Beispiel, wie ich eine momentan verschiedene Maps aufrufen kann.

Quellcode

1. TileMap *map;
2. map = TileMap::getInstance();
4. if(!map->load("map.xml"))
5. {
6. // Wenn alle benötigten Dateien gefunden, wird die map.xml angezeigt.
7. // Ansonsten kann man hier festlegen, was passiert, wenn die Map nicht geladen werden konnte.
8. return -1;
9. }
11. // Hier wechseln wir die aktuelle angezeigte Map zur map2.xml
12. if(!map->load("map2.xml"))
13. {
14. // Siehe oben
15. return -1;
16. }

Alles anzeigen

Events
- Nach einigen Überlegungen habe ich mich dazu entschlossen, ein LUA-System für Events einzubauen.

Allgemein
- Die Engine wird wohl eher eine Art RPG Maker werden. Zumindest möchte ich in Zukunft darauf hinarbeiten.
Deswegen ist auch mein Entschluss auf ein LUA-System für Events gefallen.

felix;324372 schrieb:

Wenn ich das richtig verstehe wird die Map sofort angezeigt sobald map->load aufgerufen (und erfolgreich ausgeführt) wurde. Nehmen wir mal einen Dungeon als Beispiel, welcher höchstwarhscheinlich verschiedene Ebenen - und somit auch Maps besitzt. Wäre es nicht besser das anzeigen der Map in eine andere Funktion auszulagern, sodass Maps die quasi unter einer Map liegen bereits beim betreten der "Hauptmap" während des Spielens vorgeladen werden können?

Just my two cents

Guter Vorschlag, wäre möglich, aber da im Normalfall keine Maps mit 100000x100000 Tiles geladen werden, wird dies nicht nötig sein. Die angezeigte Map, wird aus den einzelnen Tiles zu einer neuen Grafik "zusammengebaut" und diese wird im Anschluss ausgegeben. Ich werde demnächst eine ziemlich große Map erstellen und schauen, wie lang diese zum Laden braucht. Wenn dies zu lange dauert, werde ich darüber nachdenken, ansonsten ist es nicht notwendig.
Außer du hast natürlich andere Argumente, die mich überzeugen.

EDIT: Außerdem, woher soll die Engine wissen, welche Map als nächstes betreten wird?
Es sollen auf keinen Fall alle Maps auf einmal geladen werden.
Und eine extra Angabe in der Mapdatei ist auch nicht so die perfekte Lösung, finde ich.
Wenn dir dazu etwas einfällt, lass es mich wissen.

EDIT2:
Ich habs mal getestet, eine Tilemap mit 100x100 Tiles (10000 Tiles!) braucht bei meiner Hardware etwa 19 Sekunden. Das ist doch etwas lange. Ich werde mir doch noch etwas einfallen lassen.

EDIT3: Ich werde das ganze nochmal neu schreiben und auf eine Art "Datenbank" setzen, die alle Daten beinhalten wird. Das heißt, ich werde alle Dinge, die benötigt werden, bereits am Anfang laden und dafür einen Ladescreen einblenden. Dann sollte es zu keinen "längeren" Ladezeiten während des Spielens kommen.