verrückte Ideen für einen Editor

[BlueShark]

Ich programmiere gerade an einem kleinen Spiel und muss leider mit den üblichen Schwierigkeiten kämpfen. Das schwierigste ist meiner Meinung nach Leute zu finden, die mit einem arbeiten wollen. Als nächstes kommt dann das Kommunikationsproblem. Es ist zwar gut, dass man Hilfsmittel, wie zum Beispiel SVN, zur Hand hat. Jedoch ist es immer gut, wenn die Mitglieder auch mal miteinander reden könnten, meiner Meinung nach sehr wichtig für die Qualität und Effiktivität. Lange Rede, gar kein Sinn. Warum sollte man nicht einfach SVN mit einem Editor verbinden und am besten gleich noch einen Chat oder sogar eine Konferenzschaltung mit dazu? Man könnte einen SVN Server als Basis nehmen, der Editor hat dann Zugriff auf alle Dateien, und durch Locks könnten mehrere Leute zur selben Zeit am Spiel arbeiten. Je nachdem, wie mächtig dann dieser Editor ist könnte man sogar das Skripting oder noch mehr von mehreren Leuten bearbeiten lassen. Wenn man Zugriffsrechte einfügt kann man sicherlich verhindern, dass jemand das Projekt korupieren könnte.

Was meint ihr dazu?

Mfg
BS

[Richard Schubert]

Visual Studio 2010 Team Suite arbeit in diese Richtung. Für Eclipse gibt es auch diverse Plugins die sowas ermöglichen. Die Zukunft sieht ganz klar so aus, da Kommunikation und viele Aspekte des Extreme Programming immer mehr Platz in der Softwareindustrie bekommen. Daher brauchen wir nur warten bis dieser Editor kommt :)

[Aramis]

Das wäre supertoll. Nahezu ebenso toll wäre ein Editor, der Syntaxfehler auch für C++ wirklich zielsicher on-the-fly erkennen und highlighten kann, Tippfehler halbwegs intelligent korrigiert und gleichzeitig auch noch angenehm performant ist.

[dowhilefor]

Üargh das möcht ich ungerne ... Vielleicht bin ich da altmodisch, aber ich habs nicht gerne wenn Programme mehr können als sie eigentlich sollen. Klar sowas wie SVN Sollte eine IDE können, aber chatten?
Mich stört schon das ich 3(!!!) unterschiedliche Chat Programme habe Steam, Skype und Pidgin ... bald brauch ich noch ein Profil für Visual Studio 2012? Nene, Schuster bleib bei deinen Leisten ... Ich sehe da keinen Vorteil drin. Was spricht gegen AnkhSVN/Tortoise, Trac und Skype?

[SPech]

Gerade im täglichen arbeiten mit vielen Entwicklern an einem Projekt möchte ich mein Visual Studio Team System nicht mehr missen.
Alle wichtigen Sachen sind in dem Tool integriert
- Code Verwaltung
- Teamroom für Dokumente
- Statistiken und Reports
- Dropzones mit automatischen Builds
- Nahtlose Integration mit Word, Excel, Visio, Enterprise Architect, ...
- Mit den Power Tools auch noch Zugang aus Visual Studio auf die Kontakte im Office Communicator und Outlook

[BlueShark]

Ähem, ich will ja die Diskurssion nicht unterbrechen aber eigentlich habe ich eher an einen Level-Editor gedacht. :roll: Sorry, vielleicht hab ich hier einige Leute auf die falsche Schiene gebracht.

Mfg
BS

[Lord Delvin]

Also wenn du die Idee ernst meinst, dann würd ich in das Spiel n Video/Voice chat implementieren. Zumindest Voicechat mit OpenAL ist nicht sooo schwierig. Und dann sollte man irgendwie in der Lage sein im Spiel einen Modeswitch durchzuführen, der alle Spieler in den Editor Mode versetzt, damit man einen "Fehler" den man grad gefunden hat gemeinsam beheben kann. Ich würd aber kein svn verwenden, sondern einfach fortlaufende nummern. Vor allem wenns tatsächlich Spieler machen, dann wirst du bei moderater nutzung des features größere probleme mit merges von änderungen bekommen, also ist so ein Darwinlike ansatz für die "Versionsverwaltung" denk ich besser. Es wird dann einfach gespielt, was am besten erscheint.
Vielleicht sollte man noch Spieler als Besitzer einer Map eintragen können, denen man die Änderung schickt und die dann aus allen änderungen die Spieler vorschlagen eine bessere Map machen können.
Setzt natürlich ein sehr modulares Format vorraus.

EDIT: Mir ist unklar, wie ich in Quellcode mehr zusammen editieren kann, als atm mit svn, git, ... . Ich mein wenn ich grad was ändere und jemand anderes ändert grad was, dann baut das doch tendenziell eher nie. Und ich würd schon ganz gerne wissen, ob ich irgendwo vergessen hab weiterzuschreiben, mich vertippt hab, ...

[BlueShark]

Nun ja, ich habe gedacht, dass man das anders machen sollte. Gerade wenn mehrere Leute an einem Projekt arbeiten wollen hat man eine Vielzahl an Dateien, die man organisieren muss. Ich würde das einfach in verschiedene Kategorien einordnen.

Hier nur mal eine Idee:

• -3D-Modelle
  -Texturen
  -Audio
  -Skripts
  -Videos
  -Maps

Hier wären natürlich noch Subkategorien für Animation, Lightmaps, Heightmaps, usw sinnvoll. Nun sind mir 2 Sachen eingefallen, wie man dem Dateihorror entgegenwirken könnte. Zuerst einmal sollte es einen Admin geben, der Zugriffsrechte verteilen kann. Zum Beispiel sollte ein Skript-Schreiber keinen Schreib-Zugriff bekommen außer bei den Skript-Dateien, damit nicht aus Versehen etwas gelöscht wird oder so, was ja doch schnell passieren kann. Des weiteren müsste man Dateien "locken" können, sprich wenn ich gerade am Modell mit der ID 23 arbeite, können andere dieses Modell zur Zeit nicht bearbeiten. Dennoch sollte alle anderen Leute einen Lese-Zugriff auf das Modell haben, damit sie damit arbeiten können.

Des weiteren würde ich vorschlagen, dass man die Materialien in 2 Gruppen gliedern kann. Einmal Materialien, die schon bearbeitet wurden und als fertig angesehen werden und einmal die Materialien, die bearbeitet werden, also wohl noch oft geändert werden.

Sinnvoll wäre es, alle Materialien in einer Datei zu speichern. Zusätzlich bräuchte man dann Features, die einem die Verwaltung erleichtern. Zum Beispiel, dass man alle Dateien komprimieren kann um Speicherplatz zu sparen. Dazu liefert man dann noch eine Library, damit man leicht über ein Interface auf die Datei zugreifen kann. Oder man schreibt ein paar Funktionen, die prüfen, ob wirklich alle Dateien benötigt werden, die man in den Materialsammlung hat.

Den Voice Chat würde ich sogar noch unterteilen, sodass es möglich ist, dass sich 2 Map-Designer in einen extra Raum abkapseln können um ungestört arbeiten zu können.

Wie gesagt, ich hatte echt viel Zeit darüber nachzudenken und mir ist auch viel eingefallen, wie man das umsetzen könnte. Ich persönlich würde wxWidgets für die Gui nehmen, da ist außerdem nee ganze Menge drinnen, was einem das Netzwerkprogrammieren erleichtert. Delvin hat OpenAL für den VoiceChat vorgeschlagen, weil das damit wohl recht einfach zu implementieren ist. Die Grafik, könnte jedoch ein Problem werden. Cool wäre es natürlich, wenn jeder seine eigene Grafik-Engine anstöpseln könnte, jedoch hab ich mir darüber nicht wirklich Gedanken gemacht, letzten Endes wäre das wohl ziemlich viel Aufwand.

Ich persönlich würde einfach DirectX3D für die Grafik verwenden. Aber vielleicht habt ihr da eine bessere Idee.
Aber naja, genug von meiner Seite, was sagt ihr dazu?

Mfg
BS

[Aramis]

Nun, von der Grundidee sicherlich cool, aber warum das Rad neu erfinden? Ganz ehrlich, das gibt's doch schon alles.

Den Voice Chat würde ich sogar noch unterteilen, sodass es möglich ist, dass sich 2 Map-Designer in einen extra Raum abkapseln können um ungestört arbeiten zu können.

Teamspeak/Skype. Bei den meisten Spielen nutzt auch (fast) niemand den integrierten Voicechat. Einfach weil es über darauf spezialisierte Anwendungen um ein Vielfaches bequemer ist.

Hier wären natürlich noch Subkategorien für Animation, Lightmaps, Heightmaps, usw sinnvoll. Nun sind mir 2 Sachen eingefallen, wie man dem Dateihorror entgegenwirken könnte. Zuerst einmal sollte es einen Admin geben, der Zugriffsrechte verteilen kann. Zum Beispiel sollte ein Skript-Schreiber keinen Schreib-Zugriff bekommen außer bei den Skript-Dateien, damit nicht aus Versehen etwas gelöscht wird oder so, was ja doch schnell passieren kann.

Naja, Subversion. Wenn es bei großen Datensätzen nicht so elendiglich lahm wäre, wäre auch Mercurial eine gute Sache.
Zugegebenermaßen, SVN/HG auf der Kommandozeile ist eigentlich eine Zumutung für Nichtprogrammierer. Aber wozu gibt's TotoiseSVN/TortoiseHG? Ein intuitiveres Interface kann ich mir kaum vorstellen. Außer du integrierst die entsprechende Funktionalität gleich in deinen Editor. Vielleicht ist das vom Arbeitsaufwand her eine gangbare Lösung, wäre dann AnkhSVN nicht unähnlich.

Des weiteren müsste man Dateien "locken" können, sprich wenn ich gerade am Modell mit der ID 23 arbeite, können andere dieses Modell zur Zeit nicht bearbeiten. Dennoch sollte alle anderen Leute einen Lese-Zugriff auf das Modell haben, damit sie damit arbeiten können

Naja, Modelle werden ja an sich in Max/Blender/Maja/WasAuchImmer erstellt, und eher von einer Person. Dann in den Editor importiert und in ein Engine-eigenes Format gesichert, mit dem dann alle anderen bis zur nächsten Modellrevision arbeiten können.

Des weiteren würde ich vorschlagen, dass man die Materialien in 2 Gruppen gliedern kann. Einmal Materialien, die schon bearbeitet wurden und als fertig angesehen werden und einmal die Materialien, die bearbeitet werden, also wohl noch oft geändert werden.

Hm ... ich sehe da den Kontext nicht so ganz. Ein 'Material' ist für mich ein (XML-)File, das ich beim Import eines Modells in meine Content-Pipeline automatisch erstelle und eigentlich kaum mehr nachbessere. Die Engine lädt diese Materialbeschreibung und generiert passende Shader dazu.

Alex

[Seraph]

Ich bin mir nicht sicher, aber ich denke BlueShark meint nicht nur die Nutzung von SVN fuer Ressourcen, sondern auch das gemeinsame Arbeiten an Ressourcen. Beispielsweise ein Modeller, Leveleditor, ... mit dem mehrere Personen gleichzeitig arbeiten koennen, wo die einzelnen Schritte also online uebertragen und somit abgeglichen werden. Wichtig waere dabei wohl vor allem die Kommunikation (muss wie Aramis schon sagte nicht in der Applikation selbst vorhanden sein) und das Einbauen praeventiver Massnahmen um das zeitgleiche Editieren von sich ueberschneidenden Bereichen zu verhindern.

[BlueShark]

Zuerst einmal muss ich mich hier entschuldigen, da ich mich wohl nicht klar genug ausgedrückt habe.

Nun, von der Grundidee sicherlich cool, aber warum das Rad neu erfinden? Ganz ehrlich, das gibt's doch schon alles.

Du hast natürlich recht, diese einzelnen Komponenten wie Skype, TeamSpeak, SVN, Maya, usw. gibt es alle schon längst. Meine Idee ist ja nun nichts anderes als diese Komponenten in einer Applikation zu vereinen, wobei ich denke, dass man gewisse Programme außen vor lassen sollte, wie zum Beispiel ein 3D-Modeller, Programme mit denen man Texturen und Audio-Dateien erzeugt. Dafür gibt es sehr spezialisierte Software und es würde einfach keinen Sinn machen diese in einem Editor unterzubringen.

Jedoch finde ich, dass man die Dateiverwaltung, das Zusammenarbeiten und die Kommunikation mithilfe eines Programmes zu erleichtern. Ich werfe hier einfach mal meine Meinung rein. SVN ist meiner Meinung nach ganz net, doch ich denke, dass es an einigen Stellen zu viel bietet und an anderen Stellen Mängel aufweist, letzten Endes ein sehr praktisches Programm. Nun Teamspeak oder Skype, nun ja, ich bevorzuge Teamspeak, da Skype viel mehr Leistung von meiner Leitung frisst. Dazu kommt der Editor meiner Wahl, sei es nun CodeBlocks, ein Leveleditor, Gimp oder Audacity. Letzten Endes habe ich einen ganzen Haufen an Programmen, die ich bei jeder Arbeitsphase starten muss. Und ja, Toirtoise SVN hat ein sehr gutes grafisches Interface, doch meiner Meinung nach zu viele Features, die man während der Spieleentwicklung nicht braucht.

Doch nun stellen sich für mich einige Fragen:

• 1)Ermöglichen mir diese Programme mit anderen Leuten gleichzeitig an einem Outdoor Level für einen Shooter zu arbeiten?
  2)Wird mir letzten Endes eine Datei geliefert, in der alle vom Spiel benötigen Dateien vorhanden sind(Maps, Texturen, Audio-Files, Video-Files, Skript-Dateien, usw.)?
  3)Bekomme ich eine Library zur Hand, mit deren Hilfe ich diese Datei einfach auslesen kann?

Die Idee ist, dass man nicht mit anderen Leuten gleichzeitig an einem 3D-Modell oder einer Textur bastelt, das sind DInge, die man allein macht, sondern Levels zusammenbauen, Events mithilfe von Skripten einfügen, usw. .

Ich wüsste nicht, dass die normalen Programme, die man zur Hand hat, dies könnten. Und das ist genau der Grund warum ich es hier anspreche. Ich tappe in der Hinsicht im Dunkeln und vertraue auf das Wissen der Communitymitglieder. Wie gesagt, ich fände solch ein Programm unglaublich praktisch, vor allem, da ich nicht gerne mehrere Programme parallel benutze, ich bevorzuge es, wenn ein Programm mehrere Funktionalitäten kapselt.

Mfg
BS

[Richard Schubert]

Das Problem wird sein, dass das einen ganz bestimmten Leveleditor voraussetzt, der auch mit deiner Engine/Content Pipeline kompatibel sein muss. So hat der Unreal Editor 3 eine integrierte Versionsverwaltung, um SVN/P4/Alienbrain zu unterstützen. Andere Engines bieten die Möglichkeit gemeinsames Editieren von einem Level im Netzwerk. Aber solche Dinge sind alles Speziallösungen, welche auf die jeweilige Engine/Editorumgebung angepasst sein müssen. Vielleicht will der eine die Benutzer der Windows Domäne verwenden um im EditorChat einen Account zu haben, andere wollen vielleicht ICQ verwenden, andere wieder ganz was anderes.

In dieser Richtung könnte ich mir Frameworks vorstellen, die sowas vereinfachen, aber eine eierlegende Wollmilchkomplettlösung wirds wohl eher nicht geben.

[BlueShark]

Das Problem wird sein, dass das einen ganz bestimmten Leveleditor voraussetzt, der auch mit deiner Engine/Content Pipeline kompatibel sein muss.

Naja, warum drehen wir den Spieß nicht einfach um und sagen, dass die Engine/Content Pipeline mit dem Leveleditor kompatibel sein muss. ;) Wäre auch eine Möglichkeit das Ganze zu sehen.

Vielleicht will der eine die Benutzer der Windows Domäne verwenden um im EditorChat einen Account zu haben, andere wollen vielleicht ICQ verwenden, andere wieder ganz was anderes.

Ich weiß nicht ganz, warum man für solch einen Editor einen Account bräuchte. Aber selbst wen dem so ist könnte man das sicherlich gut über ein PlugIn-System regeln. Dann muss man eben beim erstmaligen Start des Editors den jeweiligen PlugIn für seinen Favoriten auswählen. Ich persönlich würde nicht von den Benutzern verlangen einen Account zu erstellen, nicht für einen Editor.

Außerdem, warum sollte man die selbe Engine wie der Editor verwenden? Letzten Endes will man mit dem Editor ja nur die Daten für sein Spiel aufbereiten. Man kann ja selbst eine Engine basteln, die dann die vom Editor erstellten Dateien liest, und eine 3D-Engine, die den ganzen Kram dann rendert. Niemand zwingt einen ja dazu nicht die eigenen Komponenten zu verwenden. Außerdem könnte man selbst seine eigene 3D-Engine in den Editor stöpseln, wenn der Editor ein Interface für diese vorgibt. Daraus ergibt sich zwangsläufig, dass man den Editor sehr flexibel programmieren müsste, aber warum nicht? Letzten Endes spielen wir das ja nur im Gedanken durch.

In dieser Richtung könnte ich mir Frameworks vorstellen, die sowas vereinfachen, aber eine eierlegende Wollmilchkomplettlösung wirds wohl eher nicht geben.

Das Gesagte müsste doch eigentlich genau in diese Richtung gehen. Würde ich jedenfalls sagen, vlt. liege ich aber auch daneben. :lol:

Mfg
BS

[Schrompf]

Außerdem, warum sollte man die selbe Engine wie der Editor verwenden? Letzten Endes will man mit dem Editor ja nur die Daten für sein Spiel aufbereiten. Man kann ja selbst eine Engine basteln, die dann die vom Editor erstellten Dateien liest, und eine 3D-Engine, die den ganzen Kram dann rendert. Niemand zwingt einen ja dazu nicht die eigenen Komponenten zu verwenden.

Öhm... was? Welche Komponenten willst Du denn sonst zum Rendern nehmen denn die selbe Engine? Ganz am Ende werden mit dem Editor ja auch die selben Daten bearbeitet, die im Spiel nachher präsentiert werden sollen. Demzufolge würde, wenn Du tatsächlich zwei Engines schreiben wölltest, die zweite Engine am Ende auch der ersten verblüffend ähnlich aussehen.

Die gemeinsame Nutzung der Engine für Spiel und Editor ist nicht ganz auf den Bäumen gewachsen...

[BlueShark]

Öhm... was? Welche Komponenten willst Du denn sonst zum Rendern nehmen denn die selbe Engine? Ganz am Ende werden mit dem Editor ja auch die selben Daten bearbeitet, die im Spiel nachher präsentiert werden sollen. Demzufolge würde, wenn Du tatsächlich zwei Engines schreiben wölltest, die zweite Engine am Ende auch der ersten verblüffend ähnlich aussehen.

Also ich hab für meine 3D-Engine ein Interface geschrieben, dazu gibt es dlls, einmal für DirectX9 und OpenGL, die Funktion Draw() macht in beiden Fällen das selbe, die Umsetzung ist jedoch verschieden. Es ist also gar nicht nötig, dass die Editorengine die selbe sein muss, oder zumindestens sehr ähnlich, wie die, die man in seinem Spiel verwendet. Nehmen wir einfach ein Beispiel:

Ich bearabeite im Editor ein Level, eine kleines Dorf zum Beispiel. Nun habe ich, sagen wir 10 Modelle für die Häuser und dazu nochmal 100 Texturen für alles, das Ganze ist dann in einem BSP-Tree verpackt. Nun speicher ich das ganze in einer Datei, wo dann folgendes steht:

• 1)die 10 Modelle
  2)die 100 Texturen
  3)Position und Orientierungsrichtung der Häuser
  4)der BSP-Tree

Wie man hier sieht, sind die Daten nicht 3D-Engine abhängig, soll heißen dass jede beliebige 3D-Engine in der Lage sein müsste dies Daten zu verarbeiten. Die Daten müssten beim Laden in das Engine freundliche Format gebracht werden, aber das war es dann auch schon. Das Problem wird jedoch sein, dass das ein extrem simples Beispiel ist. Schließlich will man in seinem Editor mehr machen als nur Level auf Polygonbasis zu kreieren, sondern auch Skripten können. Und das wäre nur ein Punkt, dazu kommt noch sehr viel mehr.

Aber mal so ganz am Rande, was spricht dagegen, dass man für sein Spiel die 3D-Engine des Editors verwendet? Dann könnte man zwar die eigene Engine nicht benutzen aber könnte sich dann follends auf wichtigere Sachen konzentrieren. Und wenn man die Engine in Quellcode-Form verfügbar macht ist man ja trotzdem noch in der Lage Änderungen vorzunehmen. Wäre natürlich kein wirklicher Lerneffekt mehr vorhanden, da man ja nichts selbst programmiert hat.

Mfg
BS

[Schrompf]

Also ich hab für meine 3D-Engine ein Interface geschrieben, dazu gibt es dlls, einmal für DirectX9 und OpenGL, die Funktion Draw() macht in beiden Fällen das selbe, die Umsetzung ist jedoch verschieden. Es ist also gar nicht nötig, dass die Editorengine die selbe sein muss, oder zumindestens sehr ähnlich, wie die, die man in seinem Spiel verwendet.

Das ist nach meinem Verständnis keine Engine, sondern bestenfalls ein API-Wrapper. Der ist im besten Fall tatsächlich austauschbar, da hast Du Recht.

Ich bearabeite im Editor ein Level, eine kleines Dorf zum Beispiel. Nun habe ich, sagen wir 10 Modelle für die Häuser und dazu nochmal 100 Texturen für alles, das Ganze ist dann in einem BSP-Tree verpackt. Nun speicher ich das ganze in einer Datei, wo dann folgendes steht:
Wie man hier sieht, sind die Daten nicht 3D-Engine abhängig, soll heißen dass jede beliebige 3D-Engine in der Lage sein müsste dies Daten zu verarbeiten.

Da gehen die Meinungen auseinander. Ein BSP-Tree z.B. ist schon eine reichlich spezifische Organisationsstruktur für statische Geometrie, und noch dazu eine, die vor 5 Jahren den Zenit ihrer Nützlichkeit überschritten hat und seitdem mehr Performance kostet, als sie bringt. Für's Rendern. Für Kollisionstest z.b. wäre wieder eine andere Beschleunigungsstruktur nötig.

Die Daten müssten beim Laden in das Engine freundliche Format gebracht werden, aber das war es dann auch schon.

Naja, das kann ordentlich Rechenzeit brauchen, das sollte man nach Möglichkeit bereits vorher getan haben... z.B. in einem Editor :-) Bei uns zählen zur Vorab-Aufbereitung zum Beispiel Kollisionsmesh-Vorkompilierung, Bewuchsverteilung, LOD-Berechnung, statische Spiegelungen, globale Konsistenzprüfungen und nicht zuletzt die Umgebungslicht-Berechnung dazu - allein letztere braucht mehrere Stunden für eine mittelgroße Welt.

Das Problem wird jedoch sein, dass das ein extrem simples Beispiel ist. Schließlich will man in seinem Editor mehr machen als nur Level auf Polygonbasis zu kreieren, sondern auch Skripten können. Und das wäre nur ein Punkt, dazu kommt noch sehr viel mehr.

Ja, mir fällt da zum Beispiel die Ausleuchtung ein: der Leveldesigner verteilt und konfiguriert Lichtquellen, um bestimmte Stimmungen in bestimmten Bereichen des Levels zu erreichen. Das z.B. schreit geradezu danach, im Editor die selbe Engine zu nehmen wie im Spiel, damit der Designer das Endergebnis sofort sieht. Gleichzeitig ist aber z.B. die ganze Render-Pipeline mit Beleuchtungsmodell und Lichtorganisation eine meiner Meinung nach sehr individuelle Geschichte, für die sich nicht so einfach eine wiederverwendbare Schnittstelle finden lassen dürfte.

Aber mal so ganz am Rande, was spricht dagegen, dass man für sein Spiel die 3D-Engine des Editors verwendet?

Nichts, das ist ja der Standardweg. Bzw. andersrum: man benutzt die Spielengine auch für den Editor. Im Spiel muss es ja gut aussehen, und im Editor muss es möglichst wie im Spiel aussehen, damit die Designer nicht blind arbeiten müssen.

Was ich aber an der Idee für das problematischste halte, sind die Konflikte, die bei der gemeinsamen Bearbeitung ganz automatisch entstehen. Die gängigen Versionsverwaltungen lösen das auf Textzeilen- oder Byte-Ebene. In einem komplexen Szeneneditor würde man dagegen eine Lösung benötigen, die sehr viel mehr Wissen von den zu bearbeitenden Datensätzen benötigt.. ein Merge für ein Model sieht z.B. ganz anders aus als ein Merge für Objektplatzierungen oder eins für Physik-Geometrie. Hier könnte man wahrscheinlich erstmal auf Basis einer kleinsten Einheit (z.B. einem Szenegraph-Node) arbeiten und alle Änderungen verschiedener Leute, die die selbe kleinste Einheit betreffen, dem Nutzer zur Auflösung hinhalten. Das "Mergen" wäre dann eine Übertragung aller Fern-Änderungen auf die lokale Arbeitskopie, solange die betroffenen Einheiten nicht auch lokal verändert wurden. Und die Konfliktauflösung würde sich auf "Schau's Dir an, so sieht Deine aus, so die geänderte aus dem Repos. Welche willst Du?" beschränken.

Geht natürlich nicht für die ganzen globalen Daten wie Wesen-Vorlagen, Gegenstände, Skripts, Tag/Nacht-Einstellungen, Quests, Dialoge, Story, usw... aber es wäre ein Anfang.

Bye, Thomas

[BlueShark]

Hallo und Entschuldigung, dass ich mich erst jetzt wieder melde^^.

Die Daten müssten beim Laden in das Engine freundliche Format gebracht werden, aber das war es dann auch schon.

Naja, das kann ordentlich Rechenzeit brauchen, das sollte man nach Möglichkeit bereits vorher getan haben... z.B. in einem Editor :-) Bei uns zählen zur Vorab-Aufbereitung zum Beispiel Kollisionsmesh-Vorkompilierung, Bewuchsverteilung, LOD-Berechnung, statische Spiegelungen, globale Konsistenzprüfungen und nicht zuletzt die Umgebungslicht-Berechnung dazu - allein letztere braucht mehrere Stunden für eine mittelgroße Welt.

Aber könnte man diese Dinge nicht verallgemeinern? Sozusagen als Option für den Editor aktivierbar machen? Vielleicht kann man diese Vorabberechnungen in ein allgemeines Format bringen.

Da gehen die Meinungen auseinander. Ein BSP-Tree z.B. ist schon eine reichlich spezifische Organisationsstruktur für statische Geometrie, und noch dazu eine, die vor 5 Jahren den Zenit ihrer Nützlichkeit überschritten hat und seitdem mehr Performance kostet, als sie bringt. Für's Rendern. Für Kollisionstest z.b. wäre wieder eine andere Beschleunigungsstruktur nötig.

Muss ja nicht unbedingt ein BSP-Tree sein. Assimp liefert ja zum Beispiel nen Szenegraph oder???(Wage mich jedenfalls irgendwo sowas in der Richtung gelesen zu haben, bin mir aber nicht ganz sicher)

In einem komplexen Szeneneditor würde man dagegen eine Lösung benötigen, die sehr viel mehr Wissen von den zu bearbeitenden Datensätzen benötigt.. ein Merge für ein Model sieht z.B. ganz anders aus als ein Merge für Objektplatzierungen oder eins für Physik-Geometrie. Hier könnte man wahrscheinlich erstmal auf Basis einer kleinsten Einheit (z.B. einem Szenegraph-Node) arbeiten und alle Änderungen verschiedener Leute, die die selbe kleinste Einheit betreffen, dem Nutzer zur Auflösung hinhalten. Das "Mergen" wäre dann eine Übertragung aller Fern-Änderungen auf die lokale Arbeitskopie, solange die betroffenen Einheiten nicht auch lokal verändert wurden. Und die Konfliktauflösung würde sich auf "Schau's Dir an, so sieht Deine aus, so die geänderte aus dem Repos. Welche willst Du?" beschränken.

Ich würde in diesem Fall auch nicht unbedingt an ein "Merge" denken, wie wir es bei SVN haben. Ich habe mir eigentlich folgendes gedacht:

Wir haben in unserem Editor ja einen Haufen Kleinigkeiten, die wir für den Bau eines Levels brauchen.(Modelle, Texturen, Skripts, usw) Nun dachte ich, dass, wenn man einen Teil bearbeiten möchte, dieser Arbeitsbereich vor Zugriffen geschützt wird. Andere Benutzer können dann diesen Bereich nicht bearbeiten aber die Änderungen sehen. Nachdem die Blockkade wieder aufgehoben wird, wird dann dieser neue Bereich für alle anderen Benutzer zugreifbar.

Bei einem Modell läuft es ähnlich, das Modell wird geschützt, trotzdem kann es im Editor platziert werden, und kann nur von einem bearbeitet werden. Selbst beim Skripting könnte man das einführen.

Ja, mir fällt da zum Beispiel die Ausleuchtung ein: der Leveldesigner verteilt und konfiguriert Lichtquellen, um bestimmte Stimmungen in bestimmten Bereichen des Levels zu erreichen. Das z.B. schreit geradezu danach, im Editor die selbe Engine zu nehmen wie im Spiel, damit der Designer das Endergebnis sofort sieht. Gleichzeitig ist aber z.B. die ganze Render-Pipeline mit Beleuchtungsmodell und Lichtorganisation eine meiner Meinung nach sehr individuelle Geschichte, für die sich nicht so einfach eine wiederverwendbare Schnittstelle finden lassen dürfte.

Jepp, gerade Schnittstellen zu finden ist hier glaube ich das Hauptproblem, oder vielmehr das einzige Problem.

Aber mal so ganz am Rande, was spricht dagegen, dass man für sein Spiel die 3D-Engine des Editors verwendet?

Nichts, das ist ja der Standardweg. Bzw. andersrum: man benutzt die Spielengine auch für den Editor. Im Spiel muss es ja gut aussehen, und im Editor muss es möglichst wie im Spiel aussehen, damit die Designer nicht blind arbeiten müssen.

Ich meine aber genau das, eine frei verfügbare Engine, zu der man einen Editor mit dazugeliefert bekommt und "nur" noch alles zusammenbasteln muss. Und selbst Shader könnte man über den Editor bauen. Es ist dann natürlich keine Eierlegende Wollmilchsau, aber es würde die Arbeit der Leute sicherlich erleichtern, weil man sich dann wirklich nur noch um die Entwicklung und nicht oder nur noch wenig um die Verwaltung kümmern muss.

Mfg
BS

[Zudomon]

Ich finde einen Editor, der im Netzwerk/Internet arbeitet, gut. Das ganze steht schon seit Jahren auf meiner ToDo-Liste. Gedacht hatte ich mir das auch wie BlueShark, das man Bereiche sichert, und die dann bearbeiten kann. Das ganze mit Account-Verwaltung und Zugriffsrechten.
Um sich mit den Datensätzen nicht ins Gehege zu kommen, sollte man statt Namen und Dateien lieber auf GUIDs und Kataloge setzen. Ein wahnsinniger Vorteil ist, wenn man das ganze soweit realisiert hat, dass man auch Berechnungen direkt im Cluster auslagern kann, um so z.B. die Lightmaps zu berechnen.

Zu dem Thema fällt mir auch noch Second Live ein. Das ist ja quasi ein gigantischer Netzwerk-Editor.

Gruß
Zudo

[Lord Delvin]

Warum nimmst du nicht nen ganz normalen Editor und itegrierst SVN? Dann müsstest du dein zu editierendes Objekt halt dynamisch in mehrere Files unterteilen können, aber so schlimm ist das doch nicht, oder?

[Zudomon]

Meinst du mich?

Falls ja:
Den Editor bau ich ja eh selbst und versuche, da wirklich die komplette Kontent-Pipeline drin zu halten.
Was eine Engine angeht, gehören einzelne Dateien für mich eher der Vergangenheit an. Es geht darum, Informationen abzulegen und zu laden, darum sollte sich die Engine kümmern und nicht der User. Die Idee dazu kam mir durch folgende Problemstellung: Man nehme zwei Entwickler, die sich ein eigenes Level bauen und jeweils zufälligerweise eine Textur ein bringen, die den gleichen Pfad und Namen hat. Wenn man nun die beide Levels in das Engineverzeichnis kopiert, dann überschreibt die eine Textur die andere. Um solche Dinge zu vermeiden bin ich dazu übergangen, grundlegend für jedes Objekt GUIDs zu benutzen. So ist es unwahrscheinlich, dass da jemals Konflikte auftreten.

Bzgl. des SVN: Man könnte mal schauen, wenn man im Netzwerk arbeitet, ob es nicht auch möglich ist, dass beide zur selben Zeit am gleichen Objekt rumarbeiten. Dazu würde mir dann folgendes einfallen: Alles was auf ein Objekt angewendet wird, sind modulare Operationen. Man behält sich, zumindest für eine gewisse Zeit die Basis. Beide Clients besitzen diese, sie ist also Synchronisiert. Nun werden die modularen Operationen darauf angewendet, wie ein Modifikatorstack. Durch einen Zeitstempel lässt sich einfach sagen, wann welche Operation durchgeführt wird. So sollten keine Konflikte oder Inkonsistenzen entstehen.