Warum ist es schlecht, Inhalte hart zu codieren?

41

Ich weiß, dass die meisten Spiele Dialogtext in Dateien speichern, aber ich habe auch gesehen, dass einige textbasierte Spiele den Inhalt (Karte, Auswahlmöglichkeiten, mögliche Spielerbefehle, Text der Story) tatsächlich in den Spielcode programmieren.

Ich kann mir ein paar Gründe vorstellen, aber was ist der Hauptgrund, warum sogar Textspiele alles in Dateien außerhalb des Programms aufbewahren?

Die Implementierungsdetails unterscheiden sich nur geringfügig zwischen dem Speichern von Inhalten im gängigen XML-Format, dem Parsen und dem Rendern von Karten / Anzeigen von Text auf der Grundlage der aus der XML-Datei erstellten Variablen sowie dem vollständigen Verzichten auf die XML-Datei. Sie haben beide Zeichenfolgen, die auf dem Bildschirm ausgegeben werden. Ist der Unterschied nicht nur Notation?

Einige Spiele enthalten sogar Grafiken (ASCII-Grafiken?) Im Code. Ich weiß, dass dies nicht richtig ist, und ich kann ein paar Gründe erraten, warum es schlecht ist, aber ich weiß auch nicht, warum.

Es ist sehr beliebt, den größten Teil des Inhalts außerhalb des Programms zu haben. Selbst Dwarf Fortress verwendet keine tatsächlichen ASCII-Zeichen, sondern Bilder von ASCII-Zeichen, die in den Speicher geladen werden.

Ich frage in erster Linie, weil es ein bisschen wie eine PITA ist, XML-Dateien zu erstellen, zu analysieren und mit ihnen zu arbeiten. Weißt du ... im Vergleich zu der faulen Alternative, einfach jeden einzelnen Dungeon (Inhalt) zu einer eigenen Klasse zu machen.

user50286
quelle
9
Textbasierte Spiele enthalten viel Code, aber ich denke, das liegt nur an der Zeit, als sie entwickelt wurden und an der schlechten Designauswahl. Gleiches könnte für die Zwergenfestung gelten. Ich persönlich habe alle meine textbasierten Spiele genommen und den Inhalt aus der Quelle in eine Datenbank verschoben. Es hat mein Leben so viel einfacher gemacht.
Glen Swan
7
Mit Inhalten, die in der Quelle eingebettet sind, ist i18n nur sehr schwer umzusetzen.
Pllee
5
Ich bin mir nicht sicher, ob dies spezifisch für die Spieleentwicklung ist. Fragen Sie in Zukunft die Programmierer nach SE oder Stackoverflow.
MichaelHouse
13
just making every unique dungeon (content) its own class.Das hat mich nur erschaudern lassen. Die Trennung von Daten und Logik ist für mich ein so grundlegendes Prinzip, dass ich mich wundere, dass es immer noch Entwickler gibt, die dagegen verstoßen.
Lilienthal
4
Was auch immer Sie sich entscheiden, beachten Sie, dass Hardcoding-Inhalte viel mehr Sonderfälle ermöglichen. Möchten Sie, dass ein bestimmter Chef nur zwischen Mitternacht und 7 Uhr morgens (in Echtzeit) erscheint? Es ist viel einfacher, dies fest zu codieren, als eine generische Methode zu erstellen, mit der Monster nur zu bestimmten Zeiten angezeigt werden.
user253751

Antworten:

85

Dafür gibt es mehrere Gründe. Ich werde nur ein paar erwähnen:

  1. Es macht Ihren Quellcode ein Chaos. Wenn Sie viele Dialoge (Bäume) haben, besteht ein großer Teil Ihrer Codebasis nur aus Text, der nichts mit Ihrem tatsächlichen Spielcode zu tun hat.
  2. Sie müssen jedes Mal neu kompilieren, wenn Sie so viel wie ein einzelnes Zeichen ändern.
  3. Der Dialog selbst ist schwer zu navigieren. Ich stelle mir vor, der Versuch, einen ganzen Dialogbaum zu implementieren, geschweige denn mehrere, vollständig in Ihrer Quelle, wird zu einem verschachtelten Durcheinander von Spaghetti und verschachtelten ifS, switchEs und so weiter führen. Das führt dann zu fehleranfälligem Code, der schwer zu lesen und schwerer zu debuggen ist.
  4. Wenn Sie möchten, dass Leute Ihr Spiel modifizieren oder erweitern können, ist das viel einfacher, wenn sie nicht mit dem Quellcode umgehen müssen, um etwas zu ändern.
  5. Der obige Punkt ist umso wichtiger, wenn Sie in einem Team arbeiten. Sie möchten nicht, dass Ihr Schreiber sich mit dem Code anlegen muss, nur um einen Dialog zu öffnen.
  6. Das Parsen von XML- oder anderen Standarddateiformaten ist ziemlich einfach, wenn Sie vorhandene Bibliotheken verwenden. Die Kosten für die Implementierung auf diese Weise sind also sehr gering, und Sie erhalten viele Vorteile und vermeiden die oben genannten und viele weitere Probleme.
  7. Wie @MiloPrice weiter unten ausführte, ist es auch viel einfacher, das Spiel zu lokalisieren, wenn sich Ihr Text in externen Dateien befindet. Sie können eine Sprache hinzufügen, indem Sie eine Datei hinzufügen. Ihr Team kann sich um die Übersetzung kümmern, ohne die Quelle berühren zu müssen (was besonders wichtig ist, wenn Sie Leute übersetzen lassen, die nicht den gesamten Code sehen sollen - denken Sie an Freiberufler, Leute von der Community, die nicht zu deinem Team gehört etc).
Christian
quelle
10
Ich würde nicht sagen, dass es Ihren Code durcheinander bringen würde. Andernfalls kann alles, ob inhaltlich oder nicht, als Massenware angesehen werden. Sie können Inhalte wie Code in einer guten Struktur strukturieren. Aber der Rest der Punkte bleibt stark.
Glen Swan
28
Die einfache Lokalisierung / Übersetzung ist ein weiterer großer Vorteil.
Milo P
2
@Christian: Sie können ein datengesteuertes Programm haben, in dem die Daten in einem Format in das Programm eingebettet sind, in dem sie direkt verwendet werden können (z. B. in C oder C ++, große, hoffentlich constArrays mit statischer Speicherdauer). Dies erspart Ihnen den gesamten Code und die Laufzeit-Speicherkosten für das Laden / Konvertieren einer externen Datendarstellung zur Laufzeit. Selbstverständlich gelten all Ihre anderen Gründe für die Aufbewahrung externer Daten weiterhin.
R ..
2
Persönlich bevorzuge ich einen noch stärkeren Ansatz aus denselben Gründen, die hier aufgeführt sind: Verschieben Sie den größten Teil Ihres Codes auch in einer Skriptsprache. Erstellen Sie einen Kern in C / C ++, binden Sie eine Sprache wie Python oder Lua ein und exportieren Sie eine API in diese Sprache. Don't Starvefolgt diesem Ansatz und es ist eines der am besten geschriebenen Spiele, die ich gesehen habe. Zahlreiche andere Spiele in der Vergangenheit und Gegenwart tun dies ebenso wie Anwendungen (und selten Hilfsprogramme). Insgesamt würde ich sagen, dass Sie außerhalb kleiner Projekte und kleiner Versorgungsunternehmen immer von einer starken Schichtung und Trennung überzeugt sind.
Mechalynx
30

Das Einfügen von Spielinhaltsdaten in den Code bedeutet, dass Sie das Spiel selbst neu kompilieren müssen, um eine mögliche Änderung oder Iteration dieser Spielinhaltsdaten festzustellen. Das ist aus zwei Gründen schlecht:

  • Viele Sprachen, in denen Spiele geschrieben sind, haben lange Kompilierungszeiten. Insbesondere C ++ kann in dieser Hinsicht sehr schlecht sein, und C ++ ist eine sehr verbreitete Sprache für große kommerzielle Spiele. Bei Sprachen wie C # und Java ist dies weniger ein Problem, aber es ist immer noch nicht so schnell, wie Spieldaten in externen Dateien zu speichern, die während des Spielbetriebs im laufenden Betrieb neu geladen werden können, um Änderungen zu erkennen.

  • Viele Spiele werden von Teams entwickelt, die häufig aus nicht-technischen Entwicklern (Designern und Künstlern) bestehen, die Inhalte produzieren. Nicht nur technisch nicht versierte Leute möchten das Spiel nicht neu kompilieren müssen oder sich nicht mit "umständlichen Programmierwerkzeugen" befassen, um ihren Inhalt zu iterieren. Es kann auch wünschenswert sein, die Gefährdung des Quellcodes nur für die Programmierer zu minimieren (weil die weniger Leute wer Zugriff auf den Quellcode haben, desto weniger Personen können ihn aus Versehen oder nicht auslassen.

Ich denke, Sie überschätzen die Komplexität des Ladens von Daten aus Text- oder XML-Dateien. Meistens sollten Sie dazu eine Bibliothek verwenden, was das Parsen des XML / JSON / whatever erheblich vereinfacht. Ja, das Schreiben eines datengesteuerten Level-Ladesystems ist im Vorfeld etwas kostenintensiv, spart aber auf lange Sicht viel Zeit im Vergleich zu Tonnen einzigartiger Klassen zur Darstellung der einzelnen Levels.

Kleinere oder einfachere Spiele können möglicherweise weniger von der langfristigen Investition in einen datengetriebenen Ansatz profitieren. Wenn die Entwickler also keine vorhandenen Frameworks / Engines verwenden, die diesen Ansatz unterstützen, ist es möglicherweise effizienter, die Daten einfach zu codieren der Spielcode.

Es gibt natürlich eine Vielzahl von Gründen, warum ein bestimmtes Spiel seine Daten in externen Dateien ablegen kann (oder nicht). es ist nicht machbar, sie alle aufzulisten. Auf einer gewissen Ebene werden sie sich normalerweise alle auf die zusätzliche Iterationsgeschwindigkeit oder Flexibilität beschränken, die das Nicht-Neu-Erstellen-des-Spiels bieten kann.

Josh
quelle
Ich denke nicht, dass die Kompilierungszeiten wirklich so wichtig sind, aber als Entwickler streben wir immer nach "ordentlichem Code" ... dies ist ein ziemlich guter Grund, um Dinge für sich zu trennen ... Inhalt sollte Inhalt sein, nicht Code!
Krieg
4
@Wardy Kompilierzeiten sind in C ++ sehr wichtig. Ich habe mit Lösungen gearbeitet, deren Erstellung mehr als 15 Minuten in Anspruch nahm, entweder aufgrund der Größe des Projekts, der aggressiven Verwendung von Vorlagen oder sogar der Faulheit der Entwickler (einschließlich unnötiger Header). Und ich bin mir sicher, dass dies bei großen kommerziellen Spielen der Fall ist.
concept3d
1
@ concept3d: Ich wünschte, mein Projekt hätte 15 Minuten gedauert. Ein sauberer Build auf einem dedizierten Build-Server dauert ca. 50 Minuten.
Mooing Duck
Je weniger Menschen Zugang zu Quellcode haben, desto weniger Menschen leiden unter Hirnschäden, die durch C ++ verursacht werden. : P
Sarge Borsch
Ich denke, einige Leute könnten den Punkt eines Hot-Reloads übersehen haben - es interessiert niemanden, ob es 30 Sekunden dauert, das Spiel neu zu kompilieren, Künstler das Spiel nicht neu starten wollen, sie wollen eine Tastenkombination, damit sie verschiedene Animationen testen können und Texturen on the fly. In der Tat ist dies eines der Dinge, die sie am meisten wollen. Zu sehen, wie die Dinge außerhalb des Spiels aussehen, ist eine Sache, aber es zählt, sie im Spiel zu sehen.
Wolfdawn
7

Wie immer, wie immer kommt es darauf an. Aber zunächst möchte ich argumentieren, dass Hardcoding für sich genommen nicht schlecht ist.

Ich habe in einigen einfachen Spielen hartcodierten Inhalt, insbesondere Dialogtext, und die Welt ist nicht untergegangen. Wir Programmierer lieben es, Dinge zu abstrahieren, aber denken Sie daran, dass jede Abstraktionsebene, die Sie erstellen, Ihr Programm komplexer und schwieriger zu verstehen macht.

Wenn Ihr Spiel einfach genug ist, so dass Sie einige Inhalte darin fest codieren können, würde ich es der Einfachheit halber sicherlich in Betracht ziehen.

Dies skaliert jedoch nicht wirklich zu sehr. Der häufigste Grund für das Einfügen von Inhalten in externe Ressourcen ist die Vereinfachung der Teamarbeit, da sich eine Person oder ein Team auf das Schreiben des Spiels konzentrieren kann, während sich eine andere Person auf das Erstellen und Bearbeiten des Inhalts konzentrieren kann.

Es ist jedoch nicht immer ganz einfach, die Grenze zwischen Programm und Inhalt zu ziehen. Man könnte sagen, dass Texturen zu 100% inhaltlich sind; aber was ist mit prozedural erzeugten Texturen? Der Dialogtext kann zu 100% als Inhalt betrachtet werden. Aber was ist, wenn sich der Dialog in Abhängigkeit von Ihren vorherigen Aktionen ändert? Andere Elemente, von denen man annimmt, dass sie zu 100% Teil des Programms sind, wie Skripte oder Shader, könnten ebenfalls als Teil des Spielinhalts angesehen werden. Sollten sie fest codiert sein? sollten sie als externe Ressource geladen werden?

Denken Sie jedoch daran, dass für jede Art von Inhalt, die Sie in Ihrem Spiel unterstützen, ein Lade- und Interpretationscode erforderlich ist. Im Zweifelsfall empfehle ich daher generell, den Inhalt fest zu codieren und ihn nur dann an eine externe Ressource zu übertragen, wenn Sie dies tun Ich brauche diese Flexibilität wirklich (nicht, wenn du denkst, dass du sie brauchst, aber wenn du sie wirklich brauchst)

Schließlich besteht ein Vorteil des Speicherns von Daten in Ressourcendateien darin, dass Sie sie nur dann laden können, wenn Sie sie benötigen (wodurch möglicherweise die Ladezeiten des Spiels verkürzt werden), und sie entladen können, wenn Sie sie nicht mehr benötigen (wodurch Sie mehr Inhalt haben als kann in den Speicher passen). (Nitpickers 'corner: Ressourcen-DLLs könnten als externe Ressourcen angesehen werden.)

Panda-Pyjama
quelle
7
"Aber denken Sie daran, dass jede Abstraktionsebene, die Sie erstellen, Ihr Programm komplexer und schwieriger zu verstehen macht." Ich muss nicht zustimmen, Abstraktion kann ein Programm einfacher machen und sollte es auf jeden Fall verständlicher machen.
NPSF3000
1
@ NPSF3000 Abstraktionen werden Komplexität, sondern kann mehr Komplexität entfernen , als sie hinzufügen.
user253751
2
@immibis, so dass die Gesamtsumme der Komplexität eines Projektes nach einer Abstraktion der Umsetzung sollte als bisher niedriger sein.
NPSF3000
3
@ NPSF3000: Mein Punkt ist, dass Sie keine Abstraktionen erstellen sollten, nur weil Sie können. Manchmal ist das Hardcodieren von Daten einfacher, verständlicher und rundum einfacher. Meistens habe ich Spiele gesehen, die den Weg zur Softcodierung eingeschlagen haben , was ich bedauerlich finde. Denken Sie auch daran, dass das Hinzufügen von Abstraktionen immer einfacher ist als das Entfernen. Daher bin ich ein klarer Befürworter, Abstraktionen nur dann hinzuzufügen, wenn Sie sie benötigen.
Panda Pyjama
@PandaPyjama etwas zu tun, nur weil man es kann, verursacht wahrscheinlich ein Problem, unabhängig davon, um was es sich handelt. Das bedeutet nicht, dass etwas von Natur aus komplex ist, was mir ein Anliegen war. Was macht es für Sie einfacher, Abstraktionen hinzuzufügen, als sie zu entfernen? Auf den Kopf gestoßen, würde ich anders denken - spätes Hinzufügen einer Abstraktion kann bedeutendes Refactoring bedeuten, aber ich kann nicht sofort an einen Fall denken, in dem das Entfernen einer unnötigen Abstraktion komplex wäre. Der Wechsel von XML zu fest codierten Zeichenfolgen sollte trivial sein.
NPSF3000
3

Ein wichtiger Grund für das Speichern in Textdateien ist die Wiederverwendbarkeit. Wenn Sie ein Text-Game-Framework erstellen, das Ihre Karten, Dialoge und andere Ressourcen aus einer Textdatei liest, können Sie Ihr Framework für andere Spiele wiederverwenden. Über Text-Spiele hinaus bringen so große Budget-Titel wie Call of Duty jedes Jahr ein neues Spiel heraus.

Ein weiterer Grund ist die Portabilität. Sie können dieselben Dateien für Web, PC, Mac, Android usw. verwenden. Sie müssen lediglich Ihr Framework für diese verschiedenen Plattformen nachahmen, und der Großteil der Spieldaten bleibt unberührt.

Wenn Sie über textbasierte Spiele hinausgehen, bei denen ein Skript und Daten in Dateien gespeichert sind, verkürzen Sie die Neukompilierungszeiten und können eine Benutzeroberfläche erstellen, mit der Sie die Daten einfacher bearbeiten können.

Ted Wagner
quelle
1
Natürlich zwingt Sie ein Großteil des wiederverwendbaren Materials dazu, nichts "Besonderes" zu tun, außer nach den Regeln, die Sie bereits haben. Ich befürworte definitiv nicht das Hardcodieren großer Spiele, aber es ist äußerst nützlich, wenn Sie Prototypen erstellen oder experimentelle Spiele schreiben - es gibt Ihnen viel mehr Flexibilität. Es ist natürlich mit einem Preis verbunden, daher ist es normalerweise eine gute Idee, alles neu zu gestalten, sobald das Gameplay tatsächlich funktioniert. Das Gameplay ist der schwierige Teil - stellen Sie sicher, dass Sie es testen können, ohne durch die architektonische Hölle zu tauchen: D In der Regel ist es einfacher, die allgemeine Form zu finden, nachdem Sie die Betone haben.
Luaan
3

Um Änderungen zu beschleunigen, wird die Entwicklung bei größeren Produktionen tonnenweise beschleunigt.

Sie müssen nicht jedem beibringen, wie man in die Quelle einsteigt und sie bearbeitet, um einfache Änderungen vorzunehmen. Indem Sie es aus dem eigentlichen Code ziehen, haben mehr Leute die Möglichkeit, herumzuspielen, es ist einfacher herauszufinden, mit welchen Optionen Sie herumspielen können, und der gesamte Prozess der Feinabstimmung verschiedener Teile Ihres Spiels nimmt viel weniger Zeit in Anspruch. Auch Fragen und Antworten können dabei helfen.

John Cobalt
quelle
3

Ich kann nicht glauben, dass dies noch niemand erwähnt hat, aber ein großer Grund ist, die Lokalisierung VIEL einfacher zu machen. Wenn Sie Englisch, Französisch, Deutsch, Spanisch, Portugiesisch, Italienisch, Russisch, Chinesisch und jede andere Sprache unterstützen möchten, die Sie anstreben, müssen Sie für jede Sprache einen eigenen Code-Behind verwenden. Es bedeutet auch, dass Sie, wenn Sie bestimmte Inhalte entfernen müssen (lesen Sie: Zensur), Ihren Code selbst ändern müssen, um dies zu vermeiden, anstatt zu sagen: "Ersetzen Sie einfach dieses Analsuch-Minispiel durch dieses passiv-aggressive Banner, das grafisch erklärt, was vor sich geht ". Es ist auch ziemlich unfreundlich für Verbraucher, da sie wahrscheinlich das Spiel neu starten müssen, um die Sprache zu ändern, da Sie andere Bibliotheken laden müssen. Endlich,

Wenn Sie jedoch externe Ressourcen verwenden, bedeutet die Unterstützung verschiedener Sprachen nur das Laden einer anderen Ressourcendatei. Dies kann leicht durchgeführt werden, während das Spiel läuft. Dies bedeutet, dass Sie eine einzige Codebasis haben können, was die Entwicklung erheblich vereinfacht. Außerdem können Sie auf einfache Weise die Unterstützung für andere Sprachen nach dem Release hinzufügen. Schließlich können Sie dem Benutzer erlauben, die Installation bestimmter Sprachen zu deaktivieren (eine Funktion, die in Spielen nicht allzu häufig vorkommt, die aber immer noch möglich ist), um Speicherplatz und Bandbreite zu sparen.

Nzall
quelle
3

Ich denke, ein Schlüsselbegriff ist die Trennung von Bedenken .

Wenn Ihr Code den Text nicht enthält, wird der Code weniger komplex. Der Programmierer, der den Code schreibt, muss nicht über den spezifischen Text nachdenken und kann sich auf den Code konzentrieren.

Er muss nicht über Lokalisierung nachdenken. Die Person, die die Lokalisierung durchführt, muss sich nicht um den Code kümmern.

Christian
quelle
3

Ich denke, es ist zu einfach, der Typ zu sein, der nicht mehr weiß und es wärmstens zu empfehlen, eine externe Textressourcendatei zu verwenden.

Warum? Denn hier haben Sie die Wahl, die Kosten / Probleme / Vorteile jeder Lösung auszugleichen.

Wenn Sie eine externe Datei verwenden ... Nun, ich denke, die anderen Antworten erklären die Vorteile gut genug. Aber was ist mit den Kosten? Sie müssen einen gültigen Formalismus definieren, einen Interpreter erstellen, ein Dateiformat festlegen und noch schlimmer ... eine andere Anwendung erstellen - einen Editor -. Ein Problem von 0,00%, wenn Sie Mitglied eines Teams mit 50 Programmierern sind, das ein großes Projekt erstellt. Aber wenn Sie allein sind: Sie sind ins Stocken geraten.

Auch hier unterschätze ich nicht die enormen Flexibilitätsvorteile einer externen Ressource: Die datengesteuerte Programmierung scheint mir der richtige Weg für Videospiele zu sein. Vergessen wir aber nicht die Kosten.

Auf der anderen Seite ermöglicht der Text im Code ein schnelles Prototyping, weshalb er beim ersten Mal bevorzugt werden sollte. Dann wäre mein Rat, wenn das Projekt ausgereift ist, die Art der Daten zu analysieren, die zur Modellierung der Dialoge erforderlich sind (Stimmung / Verlaufszustand / ...). Dann entscheiden Sie sich irgendwann für ein Klassen- / Regel- / Dateiformat und entscheiden sich für das Original, sodass andere Personen den Code bearbeiten / vom Inhalt entkoppeln können und so weiter. ODER für ein Spiel mit einfachen Dialogen (Mario ...) halten Sie die Kosten einfach für zu hoch und halten die wenigen Zeichenfolgen / Verhaltensweisen fest.
Ihr Anruf.

(Bemerkung zur Lokalisierung: Es ist nur eine Hash-Tabelle entfernt, also ein unabhängiges und leicht lösbares Problem.)

GameAlchemist
quelle
Einige dieser Dinge sind immer noch wahr, wenn Sie den Text in den Code einfügen. Sie benötigen weiterhin ein bestimmtes Format, eine Möglichkeit zum Navigieren im Baum usw. Vor diesem Hintergrund erscheinen zusätzliche Kosten für die Implementierung einer externen Inhaltsquelle relativ gering, zumal ausgereifte Bibliotheken und Editoren zum Parsen, Schreiben, Bearbeiten und Erstellen dieser Dateien vorhanden sind. Abhängig von der Komplexität Ihrer Dialoge können Sie sogar ohne einen speziellen Editor auskommen und einfach einen Standard-Texteditor verwenden.
Christian
1
Klar: Vielleicht war ich nicht klar genug, ich meinte, dass Sie erst nach ein paar Iterationen wissen, wie Ihre Dialoge aussehen (von einer einfachen geraden Linie zu einem komplexen Baum oder einer Zustandsmaschine). In den ersten Schritten sind ein paar (einfachste) ifs + ein paar hartcodierte Strings ok imho. Wenn Sie dann Ihre Anforderungen klar vorhersehen können, treffen Sie eine Auswahl, nachdem Sie die Kosten / Nutzen der einzelnen Lösungen bewertet haben.
GameAlchemist
Ein Mittelweg, den ich für mein aktuelles Ein-Mann-Spielprojekt benutze, besteht darin, fest codierten Inhalt zu haben, der vor dem Kompilieren aus analysierten Dateien generiert wird. In vielen Fällen wäre das die schlechteste Lösung für beide Welten, aber für das, was ich brauche, ist es eigentlich ziemlich gut.
Glenatron
2

Ich denke, die Lizenzierung kann auch ein Grund sein, Inhalte nicht in den Code aufzunehmen.

Zum Beispiel,

  • Ihr Code ist möglicherweise FLOSS , aber Sie möchten Ihren Inhalt überhaupt nicht lizenzieren (möglicherweise möchten Sie Ihren Spielcode veröffentlichen, damit andere ihn zum Erstellen ähnlicher Spiele mit unterschiedlichem Inhalt verwenden können).
  • Ihr Code ist möglicherweise FLOSS, Sie möchten jedoch eine Creative Commons-Lizenz für Ihre Inhalte verwenden (da Softwarelizenzen für Inhalte nicht optimal funktionieren und umgekehrt).
  • Ihr Code ist möglicherweise urheberrechtlich geschützt , Sie verwenden jedoch weiterhin kostenlosen Inhalt
  • Ihr Code ist möglicherweise urheberrechtlich geschützt, Sie möchten jedoch Ihren eigenen Inhalt unter einer freien Lizenz veröffentlichen
unor
quelle