Vorstellung und Demo - FawesomeEngine

Erstmal: Demodownload

Klickst du hier! (nur Windows, Anleitung für Linux unten)

Vorstellung

Die Fawesome-Engine ist eine 2D-Spielengine, die es ermöglichen soll, Spiele für viele Plattformen auf einfache Art und Weise zu erstellen. Momentan werden bereits Windows und Linux unterstützt, Unterstützung für Mac dürfte an sich auch kein Problem darstellen. Da die Engine SDL nutzt und in C++ geschrieben ist, wäre womöglich sogar ein PSP- oder Nintendo-DS-Port möglich, versprechen kann ich aber nichts ;P

Vom generellen Konzept her ist Fawesome ziemlich anders aufgebaut als der Maker. Es gibt keine Tilesets, man kann lediglich ein Tile pro Map festlegen, das dann auf der gesamten Map wiederholt wird. Darüber kann man dann beliebig viele Layer legen, die einzelne Sprites enthalten. Diese Sprites wiederum können alle animiert sein, es wird kein Unterschied gemacht zwischen Charsets, Pictures, etc. Aus diesem Grund ist Fawesome kein echter Konkurrent zum Maker, da das Mapping etc. als Konsequenz ziemlich anders verläuft und konventionelle Tilesets nicht wirklich nutzbar sein werden.

Als Scriptsprache nutzt Fawesome Tcl. Die Sprache ist gerade für Anfänger leicht zu erlernen, da sie eine sehr minimalistische Syntax aufweist. Das Spiel wird komplett über Tcl-Scripte gesteuert, wodurch sich alle Aspekte des Spiels umscripten lassen. Eine Standardlibrary für RPGs (Menü/KS/...) ist in Planung.

Ein Editor ist ebenfalls geplant, dieser wird ebenfalls in Tcl implementiert sein und als "Spiel" innerhalb der Engine laufen. Das hat den Vorteil, dass man Bugs und Fehler direkt ausbessern kann, ohne das Spiel verlassen zu müssen.

Screens der Demo

http://npshare.de/files/877c3dd8/screen1.png
Die Demo halt.
http://npshare.de/files/8909a16c/screen2.png
Beim Verschieben eines Sprites, die Wurzel ist nicht transparent, da sie ein extra Sprite ist ;)
http://npshare.de/files/1ff40334/screen3.png
Eine einfache Textbox.

Beschreibung der Demo

In der Demo kann man bereits als Held rumlaufen, mit jemandem reden (Eventhandler) und Sprites mit der Maus verschieben (so wird das auch im Editor aussehen). Der Tcl-Source liegt bei und wird dynamisch eingelesen, ihr könnt also damit bereits schön rumspielen :).

Bekannte Bugs/Probleme

- Midis funzen (momentan) nur unter Linux (wenn /etc/timidity.conf korrekt ist und ein Patchset installiert ist)
- Spiel friert teilweise für ~10s ein, wenn Fenster den Fokus verliert (Workaround: fullscreen=true in der engine.cfg ;))

Git-Repo

Für Linuxuser und Leute die sich gern den Source anschauen wollen gibt es auf http://gitorious.org/fawesome ein Git-Repo, das ihr clonen könnt. Während der Entwicklung werd ich dort natürlich auch regelmäßig reinpushen.

Zum Kompilieren müsst ihr zuerst fawesound (Sound-Library) und dann fawesome (die Engine selber) kompilieren, wenns nicht klappt einfach fragen :).

Soa das wärs dann, viel Spaß mit der Demo, Kritik ist ausdrücklich erwünscht :).

Cool, ich entwickele auch an einer Engine, vergleichbar mit dieser. Allerdings arbeite ich mit LUA als Skript-Sprache. Meine Engine läuft bis jetzt nur auf Linux.
Anders als deine, habe ich mich erstmal auf das Anzeigen von Bildern spezialisiert. (SDL_gfxPrimitives und SDL_rotozoom sind ganz nützlich :D)

Meine Engine ist auch in C++ geschrieben und läuft mit SDL.

Unter welcher Lizenz steht deine Engine? (Ups, übersehen, BSD-Lizenz)

Nutzt du SDL_TTF? (Bei mir neigt SDL_TTF immer zum Absturz, deswegen nutze ich Bitmap-Fonts.)

Was hältst du davon, wenn wir unsere Projekte zusammenschließen? (Ich würde aber lieber GPL als Lizenz haben, schon allein, weil ich eine BSD-Lizenz den kommerziellen Nutzen des Programms nicht ausschließt und der Quellcode nicht verfügbar sein muss.)

PS: Wenn ich mir deinen Quellcode anschaue, kommt mir durchaus etwas bekannt vor.

Servus niR-kun,

mit den gfxPrimitives hab ich auch schon rumgespielt, allerdings hab ichs irgendwie net vernünftig zum Laufen gebracht^^, Rotozoom ist bereits integriert inklusive Animation. Und joa, für die Fonts nutz ich SDL_TTF, hatte bisher keine Probleme damit.

Zusammenschließen, hmm warum net, den Quellcode hast aber noch net released oder^^? Die BSD-Lizenz hab ich gerade aus dem Grund gewählt, dass mans kommerziell verwenden darf, wenn jemand die Engine anpassen und verkaufen will, dann soll er das tun können (Das passiert zwar eh net, aber schaden tut das ganze auch keinem).

Gruß bgld

Zitat:

---

Zitat von bgld

Zusammenschließen, hmm warum net, den Quellcode hast aber noch net released oder^^?

---

Nö, mein Projekt ist noch zu klein (bisher 2 Quellcode-Dateien). Ob nun LUA oder TCL ist ja egal. Ich kenne LUA von Cherrys PowerPatch her. :)
Warum sollte die Engine nicht LUA und TCL als Skriptsprache verarbeiten können? :D

Zitat:

---

Zitat von bgld

Die BSD-Lizenz hab ich gerade aus dem Grund gewählt, dass mans kommerziell verwenden darf, wenn jemand die Engine anpassen und verkaufen will, dann soll er das tun können (Das passiert zwar eh net, aber schaden tut das ganze auch keinem).

---

Mein Problem mit der BSD-Lizenz ist es, dass sie nicht vorschreibt, dass man den Quellcode bereitstellen muss und dass Derivate, die aus dem Quelltext entwickelt werden, unter der gleichen Lizenz freigeben müssen. :\

An einen Editor selber habe ich nicht gedacht. Ich finde es besser, wenn die Editor-Komponente direkt in der Engine drin ist, statt einzeln zu sein.
Nach meinen Vorstellungen enthalten die Projekte die Engine nicht, sondern die Engine "shared" ist wie z.B. ein VM. Erstens erspart das Chaos mit unterschiedlichen Versionen, die gleichzeitig auf der Festplatte sind, und zweitens kann man alle Spiele dann zentral über die Engine starten. :D
Nachteil davon ist, alles in der Engine muss abwärtskompatibel sein muss, um auch ältere Spiele in der Engine zu starten.

PS: Ich kenne mich mit GIT noch nicht so aus.

Zitat:

---

Zitat von niR-kun

Nö, mein Projekt ist noch zu klein (bisher 2 Quellcode-Dateien). Ob nun LUA oder TCL ist ja egal. Ich kenne LUA von Cherrys PowerPatch her. :)
Warum sollte die Engine nicht LUA und TCL als Skriptsprache verarbeiten können? :D

---

Wärs dann net sinnvoller aus der Engine ne Library zu machen (wie z.B. Tk, das man ja nicht nur aus Tcl, sondern auch aus Python, Perl und C raus verwenden kann)? Ich weiß allerdings net, wie kompliziert solche Bindings zu programmieren sind.

Zitat:

---

Zitat von niR-kun

Mein Problem mit der BSD-Lizenz ist es, dass sie nicht vorschreibt, dass man den Quellcode bereitstellen muss und dass Derivate, die aus dem Quelltext entwickelt werden, unter der gleichen Lizenz freigeben müssen. :\

---

Joa, ich versteh deine Probleme, aber guck dir an wies in der Praxis läuft, Google nimmt GPL-Code (Linux), ändert den ab für die eigenen Bedürfnisse (sprich für Android), releast den dann und niemand fängt was damit an. Es gibt bisher keinen bekannten Fork eines Google-Projekts (afaik), einfach weil der Code nur für einen bestimmten Kontext ausgelegt ist. Bei sowas hilft die GPL nichts.

Außerdem könnte keine Firma die Engine, so wie sie ist einfach nehmen und verkaufen, da sie unseren Namen erwähnen muss und so würd sich schnell rumsprechen dass es eine kostenlose Version mit exakt denselben Features gibt. Abgesehen davon bringen viele Firmen, die BSD-Projekte geforkt haben, trotzdem ihre Verbesserungen in den BSD-lizensierten Fork ein, obwohl sie dazu rechtlich nicht verpflichtet sind.

Zitat:

---

Zitat von niR-kun

An einen Editor selber habe ich nicht gedacht. Ich finde es besser, wenn die Editor-Komponente direkt in der Engine drin ist, statt einzeln zu sein.

---

Genau das hab ich doch vor.

Zitat:

---

Zitat von niR-kun

Nach meinen Vorstellungen enthalten die Projekte die Engine nicht, sondern die Engine "shared" ist wie z.B. ein VM. Erstens erspart das Chaos mit unterschiedlichen Versionen, die gleichzeitig auf der Festplatte sind, und zweitens kann man alle Spiele dann zentral über die Engine starten. :D
Nachteil davon ist, alles in der Engine muss abwärtskompatibel sein muss, um auch ältere Spiele in der Engine zu starten.

---

Meine Engine ist auch so konzipiert, die ganzen Dateien sind momentan nur aus Faulheit zusammen XD. Wenn du die Engine in nem anderen Working Dir laufen lässt, nimmt sie auch den (vermutlich sollte ich nen Commandline-Parameter draus machen).

Zitat:

---

Zitat von niR-kun

PS: Ich kenne mich mit GIT noch nicht so aus.

---

Das Repo kannst du clonen mit git clone git://gitorious.org/fawesome/fawesome.git fawesome

Ansonsten gibts Tutorials:

http://www.kernel.org/pub/software/s...ttutorial.html
http://www.spheredev.org/wiki/Git_for_the_lazy

In fawesome und fawesound sind irgendwie keine makefiles drin. Ärgerlich, das muss man g++ die Parameter selber geben. :) Oder moment: cmake? Hmm, entweder bin ich zu blöd um cmake zu nutzen (kA welche Parameter, die ManPage ist da wenig hilfreich) oder es will nicht. :D

PS: Ich bin Ubuntu Linux x64 Nutzer, neben Win7 Prof x64, und arbeite mit Eclipse Helios mit CDT-Plugin und Ubuntu. Compiler ist G++ 4.4 oder 4.5. :D

Zitat:

---

Zitat von bgld

Wärs dann net sinnvoller aus der Engine ne Library zu machen (wie z.B. Tk, das man ja nicht nur aus Tcl, sondern auch aus Python, Perl und C raus verwenden kann)? Ich weiß allerdings net, wie kompliziert solche Bindings zu programmieren sind.

---

Nö, schon gradlinig weiter machen. Aus der Engine eine Libary zu machen wäre Schwachsinn. Eher muss die Engine über Plugins erweiterbar sein.

Ach ja, ich überlege noch, wie ich das mit den Bildern (wie Pictures im Maker) mache, ob ich das nun einfach als Array einer Struktur (getestet und geht, aber nicht sehr schön) mache, einer Liste oder als einzelne Objekte (hört sich am besten an).

Hoi,

Probiers mal mit cmake . im Verzeichnis wo fawesome/fawesound liegt. Ansonsten schmeiß ich grad meine Virtualbox an und probier da mal alles zu kompilieren (also unter Ubuntu, wegen Packages, die man installieren muss etc.)

edit: Unter Ubuntu scheint die Funktion sox_open_mem_read zu fehlen, obwohl sie im Headerfile von libsox drin ist (ich krieg genau für diese eine Funktion ne undefined reference). Irgendwie sind die Ubuntu-Maintainer was solche Libraries angeht leicht inkompetent (hatte schon ein ähnliches Prob mit SDL_Mixer, das ich davor mal benutzt hab). Du kannst ja erstmal alle Aufrufe von fawesound löschen (afaik nur zwei in audioplayer.cpp) und fawesound aus der CMakeLists.txt löschen. Dann sollte das ganze eigentlich auch kompilieren und linken.

Gruß bgld

Ich habe schon Ubuntu 10.10 RC drauf, ich habe eher das Problem, dass er timidity.h nicht findet. Denn ich habe auch kein timidity-dev-Paket in der Paketverwaltung gefunden.

Außerdem liegt tcl.h nicht direkt im Include-Ordner, sondern unter tcl/tlc.h . :D

Sollte man übrigens mit dem NPC sprechen können? Oder ist der Event-Handler kaputt? :confused:

Drückst auch die Leertaste und net Enter (momentan geht nur eine Taste, die sich in der engine.cfg verstellen lässt)?

Ansonsten gibts jetzt eine ubuntu-Branch ohne fawesound, die eignetlich unverändert kompilieren sollte (konnts aber noch net testen, da VirtualBox grad Probleme macht).

Gruß bgld

Gerade die Klasse zum Anzeigen von Bildern per Index über eine Liste endlich fertig gekriegt. juhu
Ich lade die mal hoch, kann ja mal getestet werden. Mit meinem Engine-Prototyp ging sie 100%. :D
http://npshare.de/files/d5e7eebb/SDL_pic_class.rar - NpShare wurde ja gehackt.

PS: Natürlich habe ich auf Enter gedrückt, dass es Leertaste ist, ist mir nicht eingefallen xD

Hmm, was fehlt denn noch so alles, was nicht gerade mit tcl zu tun hat? Wenn ich nicht weiß, was ich machen kann, kann ich nichts dazu beitragen. ;)

Ich hab mich entschieden eine eigene Engine zu schreiben, aber nicht mit C++, sondern mit Java um es plattform-unabhängiger zu machen.
Mit Java hab ich wegen der Uni Übung, dafür hab ich einfach zu viel schon in Java und nicht C++ geschrieben.
C++ ist bei mir schon etwas angestaubt.

Was meine auf thornEngine getaufte Engine schon hat, ist:

• mehrere Maps darstellen (und der Status der Map beleibt erhalten) und wechseln
• Scrollen der Map (falls größer als 640x480 Pixel)
• Midi (unabhängig, davon ob Timidity installiert ist, oder nicht) und wave, aiff, au usw. Wiedergabe simultan
• Bilder (png, bmp, jpg, usw.) lesen und darstellen
• Player bewegen
• globale Variablen und Switches
• Items und Spells (als Datenstruktur)
• bis zu 2 Millionen Layer mit Objekten (Bilder, NPCs, usw.) pro Map
• Textausgabe (Messages)
• Laden von Maps (als xml über SAX)
• Events und Skripting (geht größtenteils)

Was noch nicht implementiert wurde, ist:

• Kollisionsabfrage für den Layer des Spielers und der NPCs/der Spielwelt
• Speichern von Maps/Spielstände (als xml - geht schon teilweise)
• Debug-Modus für globale Variablen und Switches, usw.

Renderer? OpenGL?

Im Moment werden die Bilder mit AWT/Swing auf einen Canvas gezeichnet. Ich muss erst mal die 4 verbleibenden Sachen implementieren, bevor ich den Quellcode freigebe.

PS: Ich aktualisiere den Post von mir, wenn was neues kommt. ^^

Zitat:

---

Zitat von niR-kun

Im Moment werden die Bilder mit AWT/Swing auf einen Canvas gezeichnet

---

Hast du mal einen Leistungstest gemacht? Bilder mit Transparenzen, Animationen, große Bilder scrollen. Ich hab im Zuge eines Studienprojektes mal ein 8-Wege Movement ohne Powerrenderer (wie OpenGL) in Java gebastelt und es war scheußlich von der Performance. Palettierte 8Bit Grafiken ging super, nur Transparenzen etc. führten schnell zum Einbrechen der Performance unter AWT/Swing. Ist aber locker 2 Jahre her, k.a. was die Javaleute mittlerweile tolles in Java eingebaut haben.

250-300 Bilder (gleiches Bild zufällig auf dem Bildschirm verteilt, 200x200 Pixel groß, 24Bit Farbtiefe mit 50% Transparenz) geht locker ohne Ruckeln.
Großes Bild (4600x3400 Pixel, 24Bit Farbtiefe ohne Transparenz) scrollen geht mit unregelmäßigem, sehr leichtem Ruckeln.
Animationen, soweit wie ich es implementiert habe, geht ohne Ruckeln.

UPDATE(1): Aber du hast Recht, dass es doch besser wäre, gleich OpenGL statt AWT zu nutzen.
Da scheint es sogar schon ne ordentliche Implementierung zu geben: LWJGL (http://www.lwjgl.org/)

UPDATE(2): So, die ganze Grafik ist auf OpenGL umgestellt. Es läuft wesentlich flüssiger als mit AWT.
Ich frag mich immer noch, warum ich bei GL11.glOrtho(0, width, height, 0, -1, 1); meine ganzen Sprites um Fensterhöhe + 64 Pixel verschieben muss, damit sie sichtbar sind. Bei GL11.glOrtho(0, width, 0, height, -1, 1); rendert er es auch ohne die Verschiebung, aber auf dem Kopf stehend.
Dummer Fehler, ich hab irgendwie die Desktophöhe/-breite genommen, statt die Fensterhöhe/-breite.

PS: Minecraft nutzt sogar LWJGL. ;)

jop LWJGL is nice. Lebt man besser mit, hab ich damals auch so gelöst.

Ich hab noch keine gute Idee wie ich das mit der Kollisionsabfrage lösen soll, ohne dass das zu kompliziert wird.

Was solls denn können bzw. für welchen Zweck?

Bei Kollisionsabfragen kommt immer schnell der Begriff "pixelgenau", was je nach Anwendungszweck unbrauchbar und unnötig kompliziert ist.

Ich hatte es in meinem 2D-Movement so gemacht:
- Kollisions zwischen Figuren und Dekorationsobjekten über Kreise zu Füßen der Charaktere, inspiriert von dem sehr einfachen Prinzip der "Hitbox" wie man sie als alten Spielen kennt. Abstand Zwischen Char1-XY und Char2XY < Char1Radius+Chars2Radius = Kollision. hab das Prinzip auch mal in einem Beispielprojekt gesehn in dem es drum ging wie man tausende Sprites (explosionen etc.) gleichzeitig haben kann ohne dass die Engine an der Kollisionsberechnung zugrunde geht.
- Kollision mit der Map über einen unsichtbaren Kollisionslayer, eine 2D Grafik in der Größe der Map mit geringer Farbauflösung wobei die einzelnen Farben für "unpassierbar" und die verschiedenen Bodentypen standen. In Java kann man problemlos in Grafiken hineinmalen, Plan war es auch, dass Objekte im Raum, die nicht auf den Mapgrafiken vorhanden sind sich ihre Kollisionsumrisse in die Kollisionsmap mit hineinmalen. Die 2D Grafik als Kollisionsinformation mag etwas sonderbar wirken, ist aber im Grunde auch nicht mehr als ein pixelgenaues Raster, dass sich sehr einfach im Grafikprogramm zusammen mit den Mapgrafiken erstellen lässt. Abfrage der Kollision "Kollisionslayer<->Charaktere" erfolgte über Punktprüfung entlang des Kreisrandes der Charaktere in Bewegungsrichtung, je nach Radius der Charakterkollisionskeises reichen mitunter 8 Prüfunkte, was je Bewegung zu 4 Koordidatenberechnungen führt.

War sicherlich nicht die technisch ultimativste Lösung, besonders letzteres war eher Zuarbeit für meine Art und Weise Grafiken zu basteln, sieh diesen Post also nicht als "so ist es toll,so solltest du auch" sondern eher als kleinen Denkanstoß im Für- und Wider der Entwicklung deiner Lösung.

Deine Lösung würde mich auch mal interessieren.

Das "pixelgenau" schwirrte mir auch im Kopf herum, hab ich aber schnell wieder verworfen.

Die Annäherung einer "Hitbox" hab ich einfach java.awt.Rectangle genommen und zu dem "Objekten" auf der Karte hinzugefügt. Da gibt es die Methode boolean a.intersects(Rectangle b) (also schneiden/kreuzen).
Damit es schnell geht, hab ich die Kollisionsabfrage einfach nur auf dem Layer der Spieler-Charaktere gemacht. Sind eben nur so viele Abfragen wie es Objekte auf dem Layer gibt.

Das mit der Idee von dir mit der Kollision bei der Map hört sich gut an, so weit hab ich gar nicht gedacht. Ich muss nur überlegen, wie ich das realisieren kann.
Ich habe das auch so ähnlich verwirklicht und noch ein Partikelsystem zusammengebaut. :)