Open-Source-Bibliotheken in der Indie-Szene
-
Warum werden Open-Source-Bibliotheken wie SDL, SFML, Irrlicht oder Ogre3D kaum für kommerzielle Spiele eingesetzt? Verweist jetzt bitte nicht auf irgendwelche Wikipedia-Listen, im Grossen und Ganzen betrachtet ist der Anteil dieser Bibliotheken doch eher gering.
Selbst wenn man nur Indie-Games betrachtet, basteln sich viele Entwickler eine eigene Engine oder verwenden gleich Komplettpakete wie Unity. Warum Komplettpakete verwendet werden, ist ja verständlich. Aber wieso werden teilweise jedes Mal wieder aufs Neue Abstraktionen für OpenGL und DirectX geschrieben? Zum einen spielt wohl die Grafikkartenentwicklung eine Rolle, relativ wichtig ist mittlerweile Portabilität auf Android und iOS. Dennoch sind viele Spiele auf den Computer ausgelegt, wobei die drei grossen Betriebssysteme von den oben genannten Bibliotheken abgedeckt werden. Könnte man in diesen Fällen nicht grosse Teile aus existierenden Projekten wiederverwenden? Ich sehe halt nicht ganz ein, dass es wirtschaftlich ist, jeweils das Rad neu zu erfinden.
Z.B. Torchlight, das Ogre3D verwendet, beweist ja sehr schön, dass Open-Source-Bibliotheken zumindest für Indie-Games sehr wohl mithalten können. Natürlich muss je nach Gameplay einiges an Physik, KI etc. neu implementiert werden, aber die vorhandene Basisfunktionalität wie 2D/3D-Grafik, Audio, Fenster- und Eventhandling scheint für sehr viele Fälle auszureichen.
-
Ich als Hobbyprogrammierer kann dir vielleicht antworten.
Ich programmiere, weil es mir Spaß macht. Nur deswegen.
Ich habe keinen Stress und alle Zeit, die ich brauche.
Aktuell versuche ich gerade auszuprobieren, wieweit ich nur mit der Standardbibliothek, der WinAPI und OpenGL komme. Einfach weil es Spaß macht.
Mir ist klar, dass ich damit das Rad neu erfinde, aber es macht mir halt Spaß.
Und wenn irgendwann da mal was tolles heraus kommt, gut, vielleicht verkaufe ich es. Vielleicht nicht. Mal gucken.
-
Ich bin auch so ein Hobbyprogrammierer und auch ich arbeite mit dem nackten OpenGL einfach um es zu verstehen. Ich werkel sogar an einen reinen Software-Renderer, also mache ich das was OpenGL und die Grafikkarte in Punkto 3D macht auch noch selbst in Software. Und auch hier mache ich dies weil ich wissen will wie es funktioniert und es vor allem auch selbst implementieren.
Es macht einen Riesenunterschied über etwas tu lesen wie was funktioniert oder dies dann tatsächlich auch umzusetzen. Da merkt man erst ob man ein Thema wirklich verstanden hat.
Das kosten alles unheimlich viel Zeit und auch Nerven weil es nur in ganz kleinen Schritten vorangeht, denn die Mathematik dahinter will auch verstanden werden. Aber das Gefühl dass du hast wenn du es wirklich zu 100% selbst gemacht und verstanden hast ist total super und das als Nichtakademiker.
Das kannst du ein wenige mit einem Heimwerker vergleichen dem macht es auch Spaß Sachen selbst du bauen anstatt einfach Fabriksachen einzukaufen und hinzustellen auch wenn das meist viel günstiger und einfacher ist.
Kurz, weil es Spaß macht und ich mein Leben so eingerichtet habe, dass ich unheimlich viel Zeit für mein Hobby habe, dafür aber wenig Geld. Aber nix ist so kostbar wie Lebenszeit, besonders die jungen Jahre.
-
Nexus schrieb:
Warum werden Open-Source-Bibliotheken wie SDL, SFML, Irrlicht oder Ogre3D kaum für kommerzielle Spiele eingesetzt? Verweist jetzt bitte nicht auf irgendwelche Wikipedia-Listen, im Grossen und Ganzen betrachtet ist der Anteil dieser Bibliotheken doch eher gering.
SDL/SFML sind ja eher high-level wrapper von APIs mit ein paar utilities, die meisten werden dennoch ihren wrapper haben, man hat am ende also
CustomWrapper(OpenSourceWrapper(Api()));
was nicht soviel sinn macht.bei den open source engines ist hingegen nichts weshalb man sie nutzen sollte. zu sagen dass man das rad nicht neu erfinden soll ist in dem fall wie zu sagen dass nicht jeder von einem hausaufgang zum baecker gehen sollte, da reicht es einen plan aufzustellen wer an welchem tag geht und der besorgt dann fuer alle die broetchen, ist viel oekonomischer und logischer.
Unity, UDK usw. bieten was, da hast du solide features, alles gut integriert, gute tools. open source sind hingegen oft "es hat alles was es spass gemacht hat zu implementieren, alles was annoying ist, das musst du trotzdem selber machen". das siehst du schon daran wie leute arbeiten wenn sie mit den open source tools anfangen vs professionelle tools. open source ist meistens: zieh den source, versuch zu compilieren, zieh alle dependancies, versuch nochmal, schau wie du mal eine camera setzt, ah, keine und alle physics engines, wie integriert man die, oh falsche physics engine version vs opensource-engine version, ah, nur ein wochenende und es steht alles. pro-engines: _editor_ aufmachen, samples laden, coole sache, mal ein paar values tweaken (visuell oder ai oder music..), ah, sowas beeinflusst das, hmm wie stelle ich jetzt xyz an, oh cool, dafuer gibt es ein tutorial gleich in der docu, coole sache, ....sogar alte quake engines sind da besser, weil es eben ein solides ding ist, von surface shader bis editor.
Selbst wenn man nur Indie-Games betrachtet, basteln sich viele Entwickler eine eigene Engine oder verwenden gleich Komplettpakete wie Unity. Warum Komplettpakete verwendet werden, ist ja verständlich. Aber wieso werden teilweise jedes Mal wieder aufs Neue Abstraktionen für OpenGL und DirectX geschrieben?
woher hast du diese info? ich kenne keinen indie der es jedesmal neu schreibt, eigentlich sind indies sehr effizient indem sie alles moegliche wiederverwenden, wenn schon nicht mittels gutem design und abstraktion, dann wenigstens mit Copy&Paste. wenn du dir die indies anschaust die mehrere spiele pro jahr erstellen, sehen die auch sehr aenlich aus, das gameplay wird geaendert, die assets, der rest bleibt. siehe z.B. http://www.orangepixel.net
ich waere wirklich neugierig auf deine quellen wo erfolgreiche indies immer alles neu geschrieben haben.
Zum einen spielt wohl die Grafikkartenentwicklung eine Rolle, relativ wichtig ist mittlerweile Portabilität auf Android und iOS. Dennoch sind viele Spiele auf den Computer ausgelegt, wobei die drei grossen Betriebssysteme von den oben genannten Bibliotheken abgedeckt werden. Könnte man in diesen Fällen nicht grosse Teile aus existierenden Projekten wiederverwenden? Ich sehe halt nicht ganz ein, dass es wirtschaftlich ist, jeweils das Rad neu zu erfinden.
die zumeist bloatet libs haben zumeist kaum support fuer mobile platformen und wenn, schleppen sie alles mit was die anderen platformen brauchen die du nicht brauchst.
simples beispiel ist initialisierung vom device bzw aufloesung+monitor. auf konsolen und mobile devices fragst du ab was sache ist, setzt was du immer setzt, fertig. auf PC musst du erst listen was denn da ist, du musst den leuten menues geben in denen sie es auswaehlen und aendern koennen, du musst sonder cases wie stereo-3d rendering, multi-monitor pipapo mit in der api verwurschteln.
ich finde es 10mal einfacher einen device wrapper zu haben der auf iOS,Android,Bada laeuft.Z.B. Torchlight, das Ogre3D verwendet, beweist ja sehr schön, dass Open-Source-Bibliotheken zumindest für Indie-Games sehr wohl mithalten können. Natürlich muss je nach Gameplay einiges an Physik, KI etc. neu implementiert werden, aber die vorhandene Basisfunktionalität wie 2D/3D-Grafik, Audio, Fenster- und Eventhandling scheint für sehr viele Fälle auszureichen.
aber es kommt eben nicht auf die basis funktionen an, basis funktionen sind wie scheinwerfer am wagen, wenn alle hersteller so oekonomisch waeren sich auf eine art davon zu einigen, haettest du sowas von wenig vorteile. was du brauchst ist ein weg content aus tools in die engine zu bekommen, einen editor (torch light hat einen eigenen afaik), du brauchst eine integration alle benoetigten features wie du schon sagtest, wie KI, PHysik etc. das ist es was arbeit macht, nicht die eine woche um die basis funktionalitaet aufzusetzen die ogree3d macht und du dann mit dem einarbeiten und debuggen in ogre3d hinein wieder verschwendest.
Ich habe erst letztens mit einem kumpel geredet der so 'pony hof' spiele macht und wechseln alle paar projekte die engines, aus kostengruenden natuerlich open source gratis dinger. er meinte dass man damit erst total schnell loslegt, aber dann in einer welt gefangen ist die man nicht erschaffen hat. zu dem zeitpunkt dann dinge umzuschreiben die eine schluesselfunktionalitaet der engine sind, ohne nebenwirkungen absehen zu koennen, ist aus zeitgruenden zu riskant, du sitzt in der suppe und darfst sie ausbaden. bei ogre3d hat er uebers animationssystem gemeckert und er lachte darueber dass manche dinge nur per xml oder so editierbar waren, da er der einzige coder war, konnte er nicht die zeit aufbringen es zu automatisieren, also haben artist/designer jedesmal wenn sie in einem tool was gemacht haben und exportierten um es dann in ogre zu bekommen, alle vertices per hand umeditieren muessen (ich glaube es war was mit vertex weights).wenn man die open source engines schon kennt, kann man es nutzen, das ist vermutlich so wie dass man die programmiersprache nutzt die man am besten kann, wenn auch sie fuer den anwendungsbereich nicht das beste ist, weil es mit einer neuen sprache eventuell dennoch suboptimal laufen wuerde.
bis auf preis, sehe ich nichts was open source engine so gut machen wuerden dass man auf unity verzichten wuerde und sag nicht 'du hast den source', denn bei einer guten engine wie unity kannst du alles noetige fuer ein spiel anstellen ohne sourcen zu haben (bzw koenntest du wenn die license es erlauben wuerde).
-
Danke für den wirklich interessanten Einblick in die Realität.
-
Nathan und Lichtweite, wie schon angetönt sind bei kommerziellen Projekten eben andere Kriterien wichtig als bei Hobbyprojekten. Normalerweise lohnt es sich nicht, alles aus Wissensdurst oder Experimentierfreude von Grund auf zu entwickeln
rapso, vielen Dank für die ausführliche Erklärung!
rapso schrieb:
SDL/SFML sind ja eher high-level wrapper von APIs mit ein paar utilities, die meisten werden dennoch ihren wrapper haben, man hat am ende also
CustomWrapper(OpenSourceWrapper(Api()));
was nicht soviel sinn macht.Warum machen mehrere Abstraktionsebenen keinen Sinn? Man muss natürlich den CustomWrapper nicht genau wie die Open-Source-API aufbauen, sondern auf einer höheren Abstraktionsebene. Wenn man z.B. mit den Features und der Portabilität von SFML zufrieden ist, warum sollte man das Gleiche nochmals in OpenGL, OpenAL, diversen spezifischen Bibliotheken und 3 verschiedenen Betriebssystem-APIs nachprogrammieren?
rapso schrieb:
woher hast du diese info? ich kenne keinen indie der es jedesmal neu schreibt
Ich meinte weniger bei jedem neuen Spiel desselben Studios, sondern bei jedem Studio (natürlich kann man nicht den Code anderer Studios verwenden, aber eben existierende freie oder kommerzielle Engines).
Wenn ich richtig informiert bin, wurde für Super Meat Boy eine Engine geschrieben (->). Bei Vessel ist von einer "custom built engine" die Rede, es ist allerdings nicht klar, ob diese nur Physik, KI und Audio betrifft, oder auch Grafik (->). Fez wurde mit XNA entwickelt (->). Bei Dustforce wird auch von einer Engine gesprochen (->). World Of Goo verwendete SDL und weitere Open-Source-Bibliotheken (->). Sind zumindest ein paar Indie-Games, die ich gerade kenne...
rapso schrieb:
bis auf preis, sehe ich nichts was open source engine so gut machen wuerden dass man auf unity verzichten wuerde
Ja, war wie gesagt mehr im Vergleich zu "selbst schreiben" als "Komplett-Engine verwenden" gedacht. Das Problem mit Open-Source-Libraries ist neben fehlender Finanzierung/Manpower wohl auch gerade die kleine Verbreitung im professionellen Umfeld, was sich wiederum negativ auf die Entwicklung auswirkt.
Wie sieht das üblicherweise aus, wird bei fertigen Engines wie Unity überhaupt noch C++ verwendet? Die Skripts sind ja vor allem auf C# ausgelegt.
-
Nexus schrieb:
Nathan und Lichtweite, wie schon angetönt sind bei kommerziellen Projekten eben andere Kriterien wichtig als bei Hobbyprojekten. Normalerweise lohnt es sich nicht, alles aus Wissensdurst oder Experimentierfreude von Grund auf zu entwickeln
Ach so, ich dachte mit Indieszene meinst du soetwas.
Bei Minecraft z.B. bezweifele ich, dass Notch das Spiel von Anfang an verkaufen wollte. Ich denke, er hat eher aus Spaß angefangen.
Du redest von professioneller Indieszene, ok, dann war das ein Missverständnis.
-
Nexus schrieb:
rapso schrieb:
SDL/SFML sind ja eher high-level wrapper von APIs mit ein paar utilities, die meisten werden dennoch ihren wrapper haben, man hat am ende also
CustomWrapper(OpenSourceWrapper(Api()));
was nicht soviel sinn macht.Warum machen mehrere Abstraktionsebenen keinen Sinn? Man muss natürlich den CustomWrapper nicht genau wie die Open-Source-API aufbauen, sondern auf einer höheren Abstraktionsebene. Wenn man z.B. mit den Features und der Portabilität von SFML zufrieden ist, warum sollte man das Gleiche nochmals in OpenGL, OpenAL, diversen spezifischen Bibliotheken und 3 verschiedenen Betriebssystem-APIs nachprogrammieren?
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.
3. du limitierst dich zu dem was so ein wrapper kann, wenn er es nicht kann, feature request an den feature tracker und hoffen dass es mal jemand macht oder du musst es selbst irgendwie einhacken.
4. wieso gibt es nicht nur einen einzigen, sondern alle zeitlang erfindet jemand yet another lib with a different name that already exists?
5. kannst du deine hand ins feuer legen, dass in einem open source projekt alles mit rechten dingen abgeht, dass da niemand mitarbeitet der sourcen kopiert hat mit z.b. GPL sodass dein fast fertiges PS3 spiel ploetzlich nicht released werden kann. 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) ?rapso schrieb:
woher hast du diese info? ich kenne keinen indie der es jedesmal neu schreibt
Ich meinte weniger bei jedem neuen Spiel desselben Studios, sondern bei jedem Studio (natürlich kann man nicht den Code anderer Studios verwenden, aber eben existierende freie oder kommerzielle Engines).
da kommt punkt 4. auf, wenn nichtmal die open source leute sich auf eine open source engine einigen koennen, sondern immer wieder das rad neu erfinden, wieso sollte da ein indie studio nicht eigene tools entwickeln statt open source? etwas eigenes zu haben worueber du alles weisst und dir bei der implementierung ein eigenes design gedacht hast, kann viele vorteile haben. z.B. fragt mal sony ploetzlich bei dir an, ob du dein indie spiel nicht auf PSN bringen moechtest, wie lange wird das dauern... jetzt musst du ueberlegen "bekomme ich das open source tool portiert? oder schmeisse ich es raus und bastel alles nach? hm, was wird wohl wie lange dauern, noch nie gedanken darueber gemacht"...gibt es SDL fuer ouya? (ich weiss es nicht, vermute aber mal nicht), falls nicht, wer macht sich jetzt die arbeit damit...
und nichts ist schlimmer am markt, als einer zu sein der es genau so macht wie alle anderen, du brauchst was, was du sehr gut kannst. Unity,UDK,CryEngineFree sind grundverschieden in allem was du dir rauspickst, das ist bewust so. wenn du dir indie spiele anschaust die erfolgreich sind, siehst du meistens dass der schwerpunkt auf etwas liegt, was so noch nie da war. "Flower" hat unmengen an grass rendering, little big planet hat eine sehr flexible stabile engine (kannst also 'noobs' mit der engine machen lassen was du willst und es funktioniert einfach). world of goo, super meat boy, rez... das worauf es dort ankommt ist mit viel zeit entwickelt worden, das was open source dazuliefern wuerde, waeren die 'basics' und viele features die du nie nutzen wirst, was dich aber einarbeitungszeit kostet und damit es nutzbar gemacht wird, musst du es am ende dennoch 'anpassen'.Wenn ich richtig informiert bin, wurde für Super Meat Boy eine Engine geschrieben (->). Bei Vessel ist von einer "custom built engine" die Rede, es ist allerdings nicht klar, ob diese nur Physik, KI und Audio betrifft, oder auch Grafik (->). Fez wurde mit XNA entwickelt (->). Bei Dustforce wird auch von einer Engine gesprochen (->). World Of Goo verwendete SDL und weitere Open-Source-Bibliotheken (->). Sind zumindest ein paar Indie-Games, die ich gerade kenne...
und ich bin mir sicher die verwenden ihre engines oder teile davon immer weiter. sowas wie Box2D ist echt nuetzlich und gut, kleines module (nicht ein bloated uber-monster), solide, einfache api. das wird in sehr sehr vielen spielen verwendet (z.b. angry birds).
rapso schrieb:
bis auf preis, sehe ich nichts was open source engine so gut machen wuerden dass man auf unity verzichten wuerde
Ja, war wie gesagt mehr im Vergleich zu "selbst schreiben" als "Komplett-Engine verwenden" gedacht. Das Problem mit Open-Source-Libraries ist neben fehlender Finanzierung/Manpower wohl auch gerade die kleine Verbreitung im professionellen Umfeld, was sich wiederum negativ auf die Entwicklung auswirkt.
und gerade da sehe ich keinen vorteil in open source. willst du eine engine, licensier eine, da bekommst du auch den source. auf der anderen seite, einige open source dinge, die gut sind, z.b. Qt, kosten dich dann dennoch geld. Open source sollte nicht mit 'kostenlos' verwechselt werden, there is no free lunch, irgendwie zahlst du am ende dennoch (meistens, gibt ja ausnahmen wie box2d).
Wie sieht das üblicherweise aus, wird bei fertigen Engines wie Unity überhaupt noch C++ verwendet? Die Skripts sind ja vor allem auf C# ausgelegt.
wenn du die engine licensierst, kannst du mit c++ arbeiten soweit ich weiss. die meisten grossen spiele werden meines wissens nach so gemacht, auch auf konsolen wo es bald unity gibt willst du vermutlich nicht c# nutzen.
ich programmiere gerade mit c# fuer die vita, das ist echt grausam langsam, der gc kann dich umbrigen, weshalb du noch deinen eigenen garbage collector mittels free-lists brauchst und einfach eine simple OOP klassensamlung fuer path finding (was kein problem auf iOS/Android mit c++ ist) auf primitive arrays umzuschreiben, hat 3x performance gebracht bei mir. dieselbe erfahrung hatte ich damals mit java auf android gehabt.
wenn du dir die psm foren dazu anschaust, meckern alle ueber die performance, sogar die c# fans koennen das nicht leugnen. das ist wieder: there is no free lunch.
-
tl;dr: Die genannten OpenSource-Projekte sparen vielleicht ein Wochenende, maximal eine Woche. Das ist kaum relevant wenn man 3-6 Monate an einem Spiel sitzt. Dafür handelt man sich aber nicht die ganzen Nachteile ein. (Man muss sich erst einlernen, Code anderer Leute debuggen, ist weniger flexibel, ...)
-
Ich bin mit vielem einverstanden, und sehe auch, dass Neu-Schreiben einige Vorteile hat. Es hängt wohl damit zusammen, wie lange man an seinem Indie entwickelt, und wie gut man die benötigten Features im Voraus abschätzen kann. Was ich aber auch glaube, ist dass gewisse Open-Source-Bibliotheken schlicht zu unbekannt sind oder schon nur deswegen nicht verwendet werden, "weil man das als professioneller Spieleentwickler nicht macht". Genauso wie jeder professionelle Musiker einen Mac haben muss :p
Ich werde mich im Folgenden daher vor allem auf kontroverse Punkte beziehen. Ausserdem werde ich SFML als Beispiel bringen, da ich diese Bibliothek am besten kenne.
rapso schrieb:
4. wieso gibt es nicht nur einen einzigen, sondern alle zeitlang erfindet jemand yet another lib with a different name that already exists?
Hast du schon mal SDL mit SFML verglichen? Da liegen Welten dazwischen. Alleine schon weil SFML eine äusserst saubere C++-API hat, sehr leicht zu benutzen und massiv schneller ist. Sowas wie SFML gabs zuvor nicht.
rapso schrieb:
5. kannst du deine hand ins feuer legen, dass in einem open source projekt alles mit rechten dingen abgeht
Nein, aber das kannst du bei einem Closed-Source-Projekt noch viel weniger. Wer garantiert dir, dass nirgends Code kopiert wurde? Wenn niemand den Code sieht, kann sowas viel eher unbemerkt bleiben.
rapso schrieb:
sowas wie Box2D ist echt nuetzlich und gut, kleines module (nicht ein bloated uber-monster), solide, einfache api.
Schau dir mal SFML an. Eine der am saubersten designten C++-Bibliotheken überhaupt. Schön leichtgewichtig und modular, du kannst auch nur einzelne Teile davon linken. Und du kannst es problemlos mit eigenem OpenGL-Code kombinieren. Oder gleich das ganze Rendering über OpenGL/DirectX lösen und nur andere Features verwenden.
SFML ist eben noch nicht so verbreitet, weil es vergleichsweise jung ist. Aber die Community ist stark am Wachsen, sehr viele Leute wechseln auch von SDL oder Allegro.
cooky451 schrieb:
tl;dr: Die genannten OpenSource-Projekte sparen vielleicht ein Wochenende, maximal eine Woche.
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.
-
SFML gibt dir wenig Kontrolle darüber, wie genau der GL Context erzeugt wird, Dinge wie Enumeration verfügbarer Hardware etc. sind überhaupt nicht abgedeckt, für professionelle Anwendungen aber durchaus nicht unwesentlich, wenn du das willst, heißt es erstmal, die SFML in ihren Grundfesten ganz ordentlich umschreiben und wenn du da dann anfängst, kannst du dir das auch gleich selber bauen...
-
Wenn ich die Antworten hier richtig verstanden habe, dann nutzen die Leute deswegen so wenig bis gar keine OpenSource-Libs weil sie dadurch Zeit und damit Geld verlieren. Viel Geld für einen kommerzielle Engine auszugeben ist anscheinend billiger als sich in andere Libs einzuarbeiten und diese anzupassen. Nix ist so teuer wie Arbeitszeit.
Als Beispiel nehme ich mal Photoshop, dafür 1000,-EUR auf den Tisch zu blättern ist viel billiger als mit einem kostenlosen oder günstigen Programm täglich einen schlechteren Workflow zu haben, da dass dann bis jedem Auftrag Geld kostet, da man nicht so gut vorankommt und dadurch weniger schafft.
Geld auszugeben kann viel Geld sparen.
-
Nexus schrieb:
Bedenke, dass die Bibliotheken aber viel mehr enthalten, z.B. SFML: Speichern/Laden diverser Bild-,
10 Minuten auf Wikipedia für .bmp und .tga - und wenn man seinen Kram eh packt, bekommt man .png quasi gratis dazu.
Nexus schrieb:
Schriftart-
Das ist nett, aber bekomme ich den Kram dann auch in meine Shader rein oder muss ich SFML das zeichnen lassen?
Nexus schrieb:
und Audioformate,
Kann ich das Abspielen von Sound dann in meine eigene Job-Queue integrieren, oder erstellt SFML da eigenständig irgendwelche Threads? Kann ich steuern ob SFML z.B. WASAPI nutzt?
Nexus schrieb:
simple Netzwerkanbindung (portable TCP/UDP-Pakete)
Kann das mit boost::asio mithalten, oder ist das eher ein mini-C++-Wrapper um ganz normale Berkeley Sockets?
Nexus schrieb:
Unicode
Ich wusste gar nicht dass man mit SFML auch Textbearbeitung machen kann. Oder ist damit gemeint dass man Unicode Text zeichnen kann? Nun ja, noch mal 30 Minuten gespart. Das summiert sich ja wirklich.
Nexus schrieb:
portable Zeitmessung.
Du meinst std::steady_clock/std::high_resolution_clock?
Nexus schrieb:
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.
Es sei denn ich schreibe es einfach selbst.
Nexus schrieb:
Und du wirst beim Selbst-Schreiben auch mehr Bugs haben als eine über Jahre verwendete (und oft auch ausführlich getestete und optimierte) Bibliothek.
Da habe ich leider gegenteilige Erfahrungen gemacht.
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.
-
Okay, ich sehe, was ihr meint. SFML ist tatsächlich nicht so stark erweiterbar, da es die Philosophie hat, simpel zu sein und die wichtigsten Fälle abzudecken.
Aber es scheint mir doch reichlich naiv zu glauben, dass man über Jahre entwickelte Funktionalität jeweils in kurzer Zeit selbst nachbauen könnte, noch dazu optimiert und mit weniger Bugs. Das klingt einfach nicht realistisch, zumal die Bibliotheks-Entwickler oft selbst jahrelang als professionelle Entwickler gearbeitet haben und dadurch recht viel Erfahrung mitbringen. Ich sehe auch nicht, wieso die gleichen Leute, die im C++-Forum jeweils "erfinde das Rad nicht neu" predigen, hier gegen ihre eigenen Prinzipien verstossen, obwohl die Argumente dieselben sind.
Zudem gibts nicht nur schwarz und weiss: Man kann für gewisse Features Bibliotheken benutzen und mit eigener Funktionalität ergänzen. Man muss sich eben überlegen, wie lange man zur Anwendung der Bibliothek benötigt. Bei sauber designten High-Level-APIs kann die Einarbeitung durchaus nur wenige Stunden erfordern, was normalerweise in starkem Gegensatz zum Selbst-Schreiben steht. Ausserdem sind High-Level-Bibliotheken super geeignet für Prototyping. Man kann mit verschiedenen Features experimentieren. Falls man sich dann doch für eine eigene Implementierung entscheidet, verliert man immer noch weniger Zeit, als wenn man alle experimentellen Ansätze selbst implementiert hätte.
cooky451 schrieb:
Es sei denn ich schreibe es einfach selbst.
Du verschätzt dich gerade gewaltig, du kannst niemals alles selbst schreiben. BMP liegt ja noch drin, aber bei JPEG lohnt sich der Aufwand längst nicht mehr. Schriftarten sind ebenfalls recht komplex (nicht unbedingt das Dateiformat, aber die richtige Darstellung). Gleiches gilt für Audio, Video, Unicode, und so ziemlich alles, was ein bisschen komplexer ist. Du musst nicht SFML benutzen, es gibt genügend andere Bibliotheken. Für Sockets scheinst du ja auch Boost.Asio (eine Open-Source-Bibliothek) zu verwenden.
cooky451 schrieb:
Du meinst std::steady_clock/std::high_resolution_clock?
Ah, du meinst die mit der Millisekundenauflösung in Visual C++? :p
So ein Bug reicht, um hochauflösende Uhren in C++11 unbrauchbar zu machen, sodass man für Portabilität doch wieder auf externe Bibliotheken ausweichen muss.
-
Wenn hier einer im Forum sagt, dass sich das Rad nicht neu erfinden nicht lohnt, dann hörst du darauf?
-
Nexus schrieb:
Aber es scheint mir doch reichlich naiv zu glauben, dass man über Jahre entwickelte Funktionalität jeweils in kurzer Zeit selbst nachbauen könnte, noch dazu optimiert und mit weniger Bugs.
Was heißt hier optimiert? Wüsste nicht was man beim Fenster erstellen sonderlich optimieren sollte. Und wenn ich eh eine eigene Job-Queue schreiben muss, dann ist es natürlich effizienter wenn ich die Sounds dort integrieren kann. Gleiches Argument gilt auch für Schriften etc.
Nexus schrieb:
Ich sehe auch nicht, wieso die gleichen Leute, die im C++-Forum jeweils "erfinde das Rad nicht neu" predigen, hier gegen ihre eigenen Prinzipien verstossen, obwohl die Argumente dieselben sind.
Ich predige das sicher nicht. Ich empfehle vielleicht offensichtlichen Anfängern sich mal SFML anzugucken, einfach weil die Wahrscheinlichkeit ziemlich hoch ist, dass die keine Sonderwünsche haben was die Schrift oder Threads angeht etc.
Aber ansonsten vertrete ich eher die Ansicht, dass man sehr sparsam mit externen Abhängigkeiten umgehen sollte. (Jeder der mal versucht hat einige GPL-Projekte zu kompilieren, wird das zu schätzen wissen.
)Nexus schrieb:
Ausserdem sind High-Level-Bibliotheken super geeignet für Prototyping. Man kann mit verschiedenen Features experimentieren. Falls man sich dann doch für eine eigene Implementierung entscheidet, verliert man immer noch weniger Zeit, als wenn man alle experimentellen Ansätze selbst implementiert hätte.
So viele Features hat SFML dann auch nicht, als dass ich da groß experimentieren könnte.
cooky451 schrieb:
JPEG
Noch nie benutzt, keine Ahnung wie komplex das ist.
cooky451 schrieb:
Für Sockets scheinst du ja auch Boost.Asio (eine Open-Source-Bibliothek) zu verwenden.
Aber auch nur weil ich das Interface quasi genau so aufbauen würde. Das trifft aber leider auf ausgesprochen wenig Bibliotheken zu. Und selbst asio nervt mich, weil es an boost::system hängt.
-
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
Soundplattformunabhä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)
