Open-Source-Bibliotheken in der Indie-Szene

Nexus schrieb:

Warum werden Open-Source-Bibliotheken wie SDL, SFML, Irrlicht oder Ogre3D kaum für kommerzielle Spiele eingesetzt?

Spontan fallen mir 3 mögliche Gründe ein:

1. Prestige - Eine fertige Engine die für Lau angeboten wird (was auf Open Source zutrifft, trotz gewerblicher LGPL) klingt halt so, als würde man es ohne die Arbeit der anderen nicht schaffen.

2. Kenntnisse - Das was man selber programmiert, kennt und versteht man besser als das Zeugs von irgendwelchen anderen Entwicklern.

3. Urheberrecht - Auch wenn die vielen Open Source Lizenzen viel erlauben bleibt halt doch immer der juristische nachgeschmack. Die LGPL erlaubt z.B. die Verwendung als Lib, aber wenn man die Lib selbst ändert, dann muss man das wieder zur Verfügung stellen. Aber vielleicht will man das ja gar nicht, weil der Code murks ist oder man der Konkurrenz keine starke Waffe in die Hand geben will, also macht man besser alles selbst und dann kann kein Open Source Verfechter sich beschweren dass er zu kurz kommen würde.
Bei kommerziellen Lizenzen werden die Eigentümer ja entschädigt in dem sie ihren Obulus erhalten und dann ist gut, dann hat man Ruhe. Bei Open Source wird's noch in 10 Jahren Community Mitglieder geben, die hier und da etwas zu kritisieren haben und sei es nur, weil man sich weigert, eine aktuelle DLL der verwendeten Open SOurce Lib mit einem Patch nachzuliefern.

rapso schrieb:

1. die wenigsten erstellen fuer 3 verschiedene betriebssysteme, und das ist vielleicht maximal 1% vom code der api spezifisch ist. das argument hat noch keinen grossen developer bei opengl vs directx ueberredet, erst recht nicht bei 'irgendwelchen online sources'.
2. viele dieser wrapper sind minimal, ob du jetzt ein fenster ueber SDL oder direkt android erstellst, ist recht banal.

Das wird ständig behauptet, aber es stimmt nicht!

Klar, für das Fenster mag das gelten, aber wer hat schon Bock sich auch noch um die 100 verschiedenen Eingabegeräte zu kümmern?

Versuch mal dem Gamer ohne SDL einen Spezial > 10 Tasten Joystick als Eingabegerät unter Linux anzubieten.

Klar kannst du den Treiber auf Kernelebene direkt ansteuern, aber plattformneutral ist das nicht mehr und den Aufwand mußt du erstmal betreiben.
Diesen nimmt die SDL für dich ab.

Gleiches gilt für Threading und für Timingsachen, auch hier hilft die SDL ungemein.

Wenn du das alles selber machst, dann mußt du unter Linux die Posix Threads und unter Windows eben die Windoes Threads direkt verwenden.
Das bläht alles den Code auf und ist Arbeit, die man sich eigentlich sparen kann.

Die SDL hilft hier also ungemein.

Es geht also nicht nur um die < 100 Zeilen um ein Fenster aufzumachen,
sondern auch um den ganzen Rest.

Um das alles:
Threading
Input Devices
Timer
Grafik
Sound

plattformunabhägngi unter einen Hut zu bringen, müßtest du die Arbeit der SDL doppelt machen, wenn du das alles selber implementieren möchtest.

Diese Arbeit kann man sich sparen und sich um den eigentlichen Gamingcode kümmern.

Wenn für dich die Welt der Spiele natürlich bei DirectX endet, dann ist deine Meinung klar.
Hier bietet DirectX ja schon alles was du brauchst, aber das ist eben nicht plattformunabhängig.

oder dass da jemand arbeitet dessen arbeitgeber dein konkurent ist und z.b. per arbeitsvertrag sich alle rechte an jeglichem source gesichert hat den jemand zur zeit der anstellung entwickelt hat und damit von dir nach dem release license gebuehren pro kopie verlangen kann (selbst wenn du ein kostenloses spiel rausgeworfen hast) ?

In welchem Land gelten solche Gesetze, das der Code, den man in der Freizeit daheim mit eigenem Strom und Computer entwickelt, dem Arbeitgeber gehört?

wenn du dir indie spiele anschaust die erfolgreich sind, siehst du meistens dass der schwerpunkt auf etwas liegt, was so noch nie da war.

Plants vs. Zombies

Auf so ne Idee muss man erstmal kommen.
Das ist wie:

Kühlschrank gegen Wassereimer

Nexus schrieb:

Ja, bestimmt. Die Bibliotheken werden ja primär aus Langeweile über Jahre hinweg entwickelt.

Was du meinst, trifft vielleicht auf Fenster-Erstellung und direktes Zeichnen mit OpenGL/DirectX zu. Das kriegt man noch schnell mal hin. Bedenke, dass die Bibliotheken aber viel mehr enthalten, z.B. SFML: Speichern/Laden diverser Bild-, Schriftart- und Audioformate, Darstellung von Text, GLSL-Integration, Abspielen von Soundeffekten und Musik, simple Netzwerkanbindung (portable TCP/UDP-Pakete), Unicode, portable Zeitmessung. Natürlich benötigst du davon üblicherweise nicht alles.

Aber wenn du viele solche Funktionalität brauchst, musst du dir dennoch alles aus diversen Low-Level-Bibliotheken zusammensuchen. Und dann hast du x verschiedene Codestile und Lizenzen, musst alles richtig einbinden und konfigurieren, etc. Das ist viel mühsamer als eine schöne Schnittstelle mit konsistentem Design. Und du wirst beim Selbst-Schreiben auch mehr Bugs haben als eine über Jahre verwendete (und oft auch ausführlich getestete und optimierte) Bibliothek.

Genau so sehe ich das auch.

cooky451 schrieb:

SFML ist in vielen Bereichen einfach zu unflexibel. Es ist schön, dass sie ein high-level Interface anbieten wollen, aber das scheint mir leider nicht durchdacht genug ab einer gewissen Komplexität. Wenn sie die Sachen gesplittet hätten (z.B. man könnte mp3s laden und dann selbst abspielen, oder den Text selbst rendern, oder hätte mehr Auswahl was den Kontext angeht), würde das vielleicht schon ganz anders aussehen.

In der SDL sind so Sachen wie TFT Support und Bildformate laden aus der SDL in eigene Bibliotheken ausgelagert (libsdl_ttf und so zeugs)

dot

Einspruch schrieb:

Versuch mal dem Gamer ohne SDL einen Spezial > 10 Tasten Joystick als Eingabegerät unter Linux anzubieten.

Wie viele aktuelle Spiele laufen unter Linux und unterstützen dort "> 10 Tasten Joysticks"?

Einspruch schrieb:

Wenn du das alles selber machst, dann mußt du unter Linux die Posix Threads und unter Windows eben die Windoes Threads direkt verwenden.

Und? Das ist doch trivial und ich seh grad nicht, welchen Mehrwert mir SDL_Thread im Vergleich zu den rohen APIs liefern könnte. Man bedenke auch, dass Threading mittlerweile sowieso direkt in Standard C++ supported wird...

Einspruch schrieb:

Das bläht alles den Code auf und ist Arbeit, die man sich eigentlich sparen kann.

Also lieber das ganze Projekt mit unverhältnissmäßigen Abhängigkeiten würzen...

Einspruch schrieb:

Es geht also nicht nur um die < 100 Zeilen um ein Fenster aufzumachen,
sondern auch um den ganzen Rest.

Du meinst die < 100 Zeilen für

Einspruch schrieb:

Threading
Timer

Einspruch schrieb:

Input Devices

Dafür gibt es sicherlich auch unter Linux irgendwelche APIs und man muss nicht gleich auf eine riesige Library springen, von der man dann 1% benutzt...

Einspruch schrieb:

Grafik

Wenn du mit den sehr begrenzten Möglichkeiten der SDL zufrieden bist...

Einspruch schrieb:

Sound

OpenAL, fmod, ...

Einspruch schrieb:

In der SDL sind so Sachen wie TFT Support und Bildformate laden aus der SDL in eigene Bibliotheken ausgelagert (libsdl_ttf und so zeugs)

Und du kannst die Fonts und Bildformate damit auch verwenden ohne die SDL zu verwenden?

So Libraries wie SFML und SDL sind nett für Anfänger und Hobbyisten. Der Vorteil liegt aber weniger darin, dass sie einem so unglaublich viel Arbeit abnehmen, sondern eher darin, dass sie es einem ermöglichen, auch ohne tiefgehendes Wissen etwas ansehliches auf die Beine zu stellen. Und erreicht wird das, indem alles hinter einem entsprechend abstrakten Interface versteckt wird. Aber sobald die gebotene Abstraktion nicht exakt deinen Anforderungen entspricht, ist so eine Library mit einem Schlag unbrauchbar. Oder anders ausgedrückt: SDL und SFML sind super für das, wofür sie gedacht sind. Und das ist nunmal wohl, Spieleprogrammierung für Anfänger und Laien zugänglich zu machen. Jemand, der kein Anfänger oder Laie ist, wird sich dagegen dort nicht wohl fühlen...

Nexus

cooky451 schrieb:

Was heißt hier optimiert? Wüsste nicht was man beim Fenster erstellen sonderlich optimieren sollte.

Dann ist ja gut, dass ich noch genügend andere Beispiele genannt habe

cooky451 schrieb:

Aber ansonsten vertrete ich eher die Ansicht, dass man sehr sparsam mit externen Abhängigkeiten umgehen sollte.

Diese Aussage basiert wieder auf einer falschen Annahme -- "wenn ich keine High-Level-Bibliothek nehme, habe ich keine Abhängigkeiten". Das stimmt eben nicht! Du kommst um Abhängigkeiten nicht herum, wenn du etwas mehr als die trivialen Dinge benötigst. Im Gegenteil hast du dann viel mehr Abhängigkeiten, weil du all die Low-Level-Bibliotheken wie libjpeg, libpng, libsndfile, Freetype, OpenAL, WinSock, etc. einzeln einbinden musst.

cooky451 schrieb:

So viele Features hat SFML dann auch nicht, als dass ich da groß experimentieren könnte.

Ich habe ja schon gesagt, dass es nicht nur um SFML geht. Du kannst dir also echt nicht vorstellen, dass man durch eine High-Level-Bibliothek (Open-Source oder nicht) schneller ans Ziel kommt? Selbst wenn einzelne Dinge nicht ideal sind, bekommt man so sehr schnell eine Vorstellung der Machbarkeit und möglicher Implementierungsprobleme. Wenn man dann sieht, dass man einen komplett anderen Weg einschlagen muss, verliert man viel weniger Zeit als bei selbstgeschriebenem Code.

cooky451 schrieb:

[JPEG] Noch nie benutzt, keine Ahnung wie komplex das ist.

Schau mal hier. Viele der genannten Funktionalitäten sind ähnlich komplex, nicht ohne Grund gibt es jeweils spezialisierte Bibliotheken.

dot

Nexus schrieb:

cooky451 schrieb:

Aber ansonsten vertrete ich eher die Ansicht, dass man sehr sparsam mit externen Abhängigkeiten umgehen sollte.

Diese Aussage basiert wieder auf einer falschen Annahme -- "wenn ich keine High-Level-Bibliothek nehme, habe ich keine Abhängigkeiten". Das stimmt eben nicht! Du kommst um Abhängigkeiten nicht herum, wenn du etwas mehr als die trivialen Dinge benötigst. Im Gegenteil hast du dann viel mehr Abhängigkeiten, weil du all die Low-Level-Bibliotheken wie libjpeg, libpng, libsndfile, Freetype, OpenAL, WinSock, etc. einzeln einbinden musst.

Viele kleine Abhängigkeiten haben imo mehrere Vorteile. Insbesondere bekomm ich genau das, was ich brauch und nicht mehr, ich kann einzelne Komponenten nach Lust und Laune separat austauschen und updaten, niemand zwingt mir eine bestimmte High-Level-Abstraktion auf, ...

Abgesehen davon, hast du diese Abhängigkeiten so oder so, oder was glaubst du, macht deine High-Level-Bibliothek unter der Haube?

cooky451 schrieb:

So viele Features hat SFML dann auch nicht, als dass ich da groß experimentieren könnte.

Ich habe ja schon gesagt, dass es nicht nur um SFML geht. Du kannst dir also echt nicht vorstellen, dass man durch eine High-Level-Bibliothek (Open-Source oder nicht) schneller ans Ziel kommt? Selbst wenn einzelne Dinge nicht ideal sind, bekommt man so sehr schnell eine Vorstellung der Machbarkeit und möglicher Implementierungsprobleme. Wenn man dann sieht, dass man einen komplett anderen Weg einschlagen muss, verliert man viel weniger Zeit als bei selbstgeschriebenem Code.[/quote]
Schnell ans Ziel ist aber nicht das einzige, was zählt. Insbesondere in einem professionellen Umfeld, ist z.B. Qualität wohl auch nicht ganz unwichtig...

Nexus

dot schrieb:

Viele kleine Abhängigkeiten haben imo mehrere Vorteile.

Da bin ich völlig mit dir einverstanden. Ich wollte nur sagen, dass man um gewisse Abhängigkeiten nicht herumkommt, auch wenn man vieles selbst schreibt

dot schrieb:

Abgesehen davon, hast du diese Abhängigkeiten so oder so, oder was glaubst du, macht deine High-Level-Bibliothek unter der Haube?

Ja, man hat sie noch und muss evtl. deren DLL mitliefern. Je nachdem sind sie aber auch gut wegabstrahiert, sodass man sie nicht alle einzeln linken muss und weniger Konfigurationsaufwand (gerade im Bezug auf Portabilität) hat.

dot schrieb:

Schnell ans Ziel ist aber nicht das einzige, was zählt. Insbesondere in einem professionellen Umfeld, ist z.B. Qualität wohl auch nicht ganz unwichtig...

Das ist klar, ich bezog mich aufs Prototyping. Wenn man bereits viel Erfahrung hat und der einzuschlagende Weg schon im Voraus weitgehend bekannt ist, hat das natürlich weniger Relevanz.

rapso

Einspruch schrieb:

rapso schrieb:

1. die wenigsten erstellen fuer 3 verschiedene betriebssysteme, und das ist vielleicht maximal 1% vom code der api spezifisch ist. das argument hat noch keinen grossen developer bei opengl vs directx ueberredet, erst recht nicht bei 'irgendwelchen online sources'.
2. viele dieser wrapper sind minimal, ob du jetzt ein fenster ueber SDL oder direkt android erstellst, ist recht banal.

Das wird ständig behauptet, aber es stimmt nicht!

Klar, für das Fenster mag das gelten, aber wer hat schon Bock sich auch noch um die 100 verschiedenen Eingabegeräte zu kümmern?

ich unterstuetze neben touchscreen, das sony xperia play pad, archos pad,hama creedroid und Ouya pad. ist das alles bei SDL dabei?

ich arbeite auch an meinem kleinen Oculus support, fuer wann ist das bei SDL geplant?

Versuch mal dem Gamer ohne SDL einen Spezial > 10 Tasten Joystick als Eingabegerät unter Linux anzubieten.Klar kannst du den Treiber auf Kernelebene direkt ansteuern, aber plattformneutral ist das nicht mehr und den Aufwand mußt du erstmal betreiben. Diesen nimmt die SDL für dich ab.

klingt ja gravierend, welches spiel hast du nochmal gemacht das joystick support hatte und auf mehreren platformen vertrieben wurde?
theoretisch hast du recht, praktisch: einspruch abgelehnt.

Gleiches gilt für Threading und für Timingsachen, auch hier hilft die SDL ungemein. Wenn du das alles selber machst, dann mußt du unter Linux die Posix Threads und unter Windows eben die Windoes Threads direkt verwenden.
Das bläht alles den Code auf und ist Arbeit, die man sich eigentlich sparen kann.

1. kannst du eine der posix libs unter windows nutzen
2. ist das threading bei mir in 3 kleinen klassen was platformspezifisch ist. task/job system etc. was cross platform ist hat sicherlich schon 10mal soviel code als thread erstellen, priority setzen, mutex, semaphore erstellen, locken.
3. wuerde ich da lieber boost nehmen als SDL, sieht irgendwie sauberer aus.

Es geht also nicht nur um die < 100 Zeilen um ein Fenster aufzumachen,
sondern auch um den ganzen Rest.

der ganze rest ist sicherlich <1% vom spiel und den schreibt man eh sauber gewrapped, da wohl niemand direkt auf einer externen api arbeiten wuerde.

Um das alles:
Threading
Input Devices
Timer
Grafik
Sound

plattformunabhägngi unter einen Hut zu bringen, müßtest du die Arbeit der SDL doppelt machen, wenn du das alles selber implementieren möchtest.

ich kenne ehrlichgesagt niemanden der raw drauf arbeitet, man schreibt sich also eh einen wrapper. den vorteil den man dann hat ist, dass auf neuen platformen fuer die es SDL nicht gibt, man eben nur seinen kleinen wrapper fuer diese platform portiert z.b. hatte ich so ein spiel in einer woche von iOS auf psp portiert. was machst du in dem fall? selbst die SDL auf neue platformen portieren? warten bis es die SDL dafuer gibt?

Diese Arbeit kann man sich sparen und sich um den eigentlichen Gamingcode kümmern.

diese arbeit hat man eh immer weil man seinen wrapper schreibt, ob man die platform api wrappt oder einen wrapper, die arbeit ist da, falls man es sauber und portabel haben will.

Wenn für dich die Welt der Spiele natürlich bei DirectX endet, dann ist deine Meinung klar.
Hier bietet DirectX ja schon alles was du brauchst, aber das ist eben nicht plattformunabhängig.

meine platformen sind:
-pc (linux,osx,windows)
-tablet/phones (iOS,Android,Bada,Blackberry,WP8)
-konsolen (DS,PSP,PSVita,PS3,X360)
(-ehemalige platformen waren noch gba,gamecube,ps2)

davon hat die SDL folgende unterstuetzt als ich die platformen verwenden wollte
-pc
kein android&NDS (ist erst seit nem jahr drinnen glaube ich), kein iOS, PSP, WP8, GBA, GC, PS2, PSV, X360, PS3
einfach nur OpenGL (ES und EGL) und dazu OpengSL ES und du hast schon mehr abgedeckt fuer video/audio als SDL bei den relevanten platformen kann (nichts persoenliches gegen die dreamcast, GP32, Solaris, BeOS, usw. zielgruppe )

wenn du dir indie spiele anschaust die erfolgreich sind, siehst du meistens dass der schwerpunkt auf etwas liegt, was so noch nie da war.

Plants vs. Zombies

Auf so ne Idee muss man erstmal kommen.
Das ist wie:

Kühlschrank gegen Wassereimer

es kommt oft nicht auf die idee an, sondern auf die realisierung. aber stimmt schon, das setting ist schon gut/spassig

von rapso zensiert

B4ndit

zensiert von rapso

rapso

tut mir leid jungs, aber rechtliche sachen darf ich hier echt nicht behandeln, hab der fairheit halber auch meinen text zensiert. sorry. ihr koennt mich gerne deswegen anmotzen ;), aber forumsvorgaben aufgrund von gesetzen

rapso schrieb:

tut mir leid jungs, aber rechtliche sachen darf ich hier echt nicht behandeln, hab der fairheit halber auch meinen text zensiert. sorry. ihr koennt mich gerne deswegen anmotzen ;), aber forumsvorgaben aufgrund von gesetzen

Du weißt aber schon, dass man anonymisierte Fallbetrachtungen immer durchdiskutieren darf, das erlauben auch Gesetzte.

Wenn du also schreibst:
Der Chef von Herr A sagt Herr A, dass er in seiner Freizeit nicht programmieren darf und wenn er es doch macht, dann gehört der Code der Firma von Chef.

Dann darf ich sagen:
*
Ich bin der Meinung das dies rechtlich nicht zulässig ist, weil....
*

Juristisch ist das keine Rechtsberatung, deswegen ist es gesetzlich erlaubt.

Eine Rechtsberatung wäre wenn ich z.B. schreiben würde:

Hey Leute, ich habe hier ein Problem mit meinem Nachbar, weil....
was soll ich tun?

und du dann schreibst
*
Stell ihm ne Unterlassungsklage und mache dies und jenes.
*

Das dürftest du dann nicht, weil der Fall konkret ist, in diesem Fall könntest du lediglich auf einen Anwalt verweisen.

Also, es ist immer nicht alles so heiß gekocht, wie der juristische Laie immer glaubt.

Rechtsfälle dürfen, wenn sie anonymsiert sind, durchaus durchgesprochen werden.
Siehe auch, wie das andere Foren lösen (unter dem Link "was ist erlaubt" dürfte das wesentliche stehen):
http://www.recht.de/phpbb/viewtopic.php?f=13&t=111060

Viel schlimmer, ein echtes Problem in eurem C++ Forum sind da eher eure nennung von Produktnamen und Personen. Sowie die Anwesenheit von Links auf diverse Seiten, inkl. Youtube.

In dem Rechtsforum ist folgendes nie erlaubt:
- Links auf Youtube und sonstige dubiose Quellen.
- Nennung von Produktnamen und Hersteller, diese müssen alle anonymisiert werden. Anstatt Microsoft kann man also schreiben, Softwarefirma aus Redmond.
- Angabne von realemn Namen. Das mit eurem Jürge Wolf, der hier öfters vorkommt, inkl. dem Aufruf seine Bücher nicht zu kaufen ist schon hart an der Grenze des erlaubten.

Also, wenn ihr echte Rechtsproblemen aus dem Weg gehen wollt, dann solltet ihr erstmal an den obigen Fällen ansetzen.

Das was hier geschrieben wurde war okay und es gab keinen Bedarf das zu zensieren.

B4ndit

rapso schrieb:

tut mir leid jungs, aber rechtliche sachen darf ich hier echt nicht behandeln, hab der fairheit halber auch meinen text zensiert. sorry. ihr koennt mich gerne deswegen anmotzen ;), aber forumsvorgaben aufgrund von gesetzen

Ist vollkommen in Ordnung. Auch wenn Einspruch meint dass dies unbedenklich ist, so würde ich als Forenbetreiber auch lieber auf Nummer sicher gehen.

cooky451

Nexus schrieb:

Ich habe ja schon gesagt, dass es nicht nur um SFML geht. Du kannst dir also echt nicht vorstellen, dass man durch eine High-Level-Bibliothek (Open-Source oder nicht) schneller ans Ziel kommt? Selbst wenn einzelne Dinge nicht ideal sind, bekommt man so sehr schnell eine Vorstellung der Machbarkeit und möglicher Implementierungsprobleme. Wenn man dann sieht, dass man einen komplett anderen Weg einschlagen muss, verliert man viel weniger Zeit als bei selbstgeschriebenem Code.

Klar kann ich mir das vorstellen, aber eine solche Bibliothek ist mir für Spielekram nicht bekannt.