Massive Universe Online

[Teekeks]

Hey Leute,

zwei Freunde (einer davon ist Bergmann89 aus dem delphi-forum, der andere heißt Akaikee) und ich hatten die Idee für ein neues Gemeinschaftsprojekt. Das ist jetzt ca. 4 Wochen her und wir haben schon einiges geplant und auch teilweise schon implementiert. Und jetzt suchen wir Verstärkung für unser Team, also wollte ich das Projekt hier mal vorstellen.

1. Projekttitel
   Massive Universe Online (MUO)
   
2. Projektbeschreibung
   Massive Universe Online soll ein Online-Clone der beliebten X-Reihe werden. Grundlegend soll es natürlich so aufgebaut sein wie X. Aber wir haben auch teilweise einige neue Ideen, die das Spielen miteinander etwas interessanter gestalten. Hier mal ein grober Überblick über unsere Ideen: Mindmap, Wirtschaft.
   Das Projekt ist in 4 Stufen eingeteilt:
   • Implementierung eines Editors zur Modellierung der Spielobjekte (Items, Schiffe, Stationen, Sektoren, ...)
   • Implementierung der Spiellogik (Client)
   • Implementierung der Spiellogik (Server)
   • Implementierung des Grafiksystems (Client)
   Zur Zeit entwickeln wir am Editor, der ist auch schon zu ca. 70% fertig gestellt.
   
3. benötigte Software
   Wir haben bis jetzt darauf geachtet, dass die genutzte Software als Freeware zur Verfügung steht. So kann jeder am Projekt mitarbeiten.
   • Entwickelt wird mit FPC/Lazarus (unter 32bit und 64bit).
   • Für die Mindmaps haben wir xMind
   • Modelle können mit jedem Editor entwickelt werden. Wir bevorzugen Blender. Die Modelle werden dann als OBJ-Datei zur Verfügung gestellt
   • Als Versionsverwaltung haben wir ein GIT bei bitbucket.org eingerichtet. Clientseitig benutzen wir SmartGit
4. Lizenz
   Über eine Lizenz haben wir uns noch keine Gedanken gemacht, weil da noch recht unerfahren sind (aber wir sind für jeden Tipp dankbar). Prinzipiell soll das Spiel als Freeware zur Verfügung gestellt werden. Wir haben aber auch über eine Art Premiumitemsystem nachgedacht, dass wir evtl später einführen wollen, um die Servermiete und dergleichen bezahlen zu können. Sollte das Projekt irgendwann Geld einbringen, dann wird der Gewinn je nach Arbeitsanteil unter den Teammitgliedern aufgeteilt.
   
5. voraussichtliche Projektdauer
   Spätestens im Sommer 2013 wollten wir eine Alpha releasen, in der die grundlegenden Funktionen implementiert sind. Diese Alpha soll dann auch zum Test auf einem Public Server laufen. Die Beta, in der dann alle Funktionen implementiert sein sollen, wollen wir Ende 2013 releasen. Das Finalrelease soll Sommer 2014 erscheinen. Dieser Zeitplan ist relativ straff, aber ich denke mit etwas Begeisterung und Motivation ist der zu schaffen
   
6. Aufgaben, benötigte Fähigkeiten der Team-Mitglieder
   Zur Zeit haben wir 2 Programmierer (Bergmann89 und mich). Der dritte im Bunde (Akaikee) kümmert sich um Modelle, Logos und den Blog bzw. die Website. Also benötigen wir noch 1-2 Entwickler. 4-5 Leute die sich um Texturen und Modelle kümmern. Die Hauptarbeit ist und bleibt das erstellen der Modelle und Texturen, deshalb sind wir für jedes Modell und für jede Textur die ihr uns zuschicken könnt dankbar. So könnt ihr auch am Projekt teilhaben, ohne ein fester Bestandteil des Teams zu werden. Natürlich wird jeder der am Projekt mitwirkt namentlich erwähnt (sofern erwünscht).
   
7. Organisation innerhalb des Teams
   Die Kommunikation im Team erfolgt hauptsächlich über Skype. Entscheidungen werden gemeinsam getroffen und vorher diskutiert. Das Schlusswort haben aber immer noch Bergmann89, Akaikee und ich.

Wichtige Informationen zum Design Ich möchte noch ein paar Worte zum Design der Modelle und der Texturen verlieren, sodass das ganze auch ein wenig einheitlich aussieht. Deshalb beschreib ich jetzt mal kurz unsere Vorstellung zu den einzelnen Rassen:

• Janaru (menschenähnlich) - Die Stationen und Schiffe dieser Rasse sollen sich etwas an der Realität orientieren (Bsp.: Spaceshuttle, Jagtflieger, ISS, ...). Die Farbe der Rasse soll weiß sein, also sollten die Modelle hier und da ein paar weiße Akzente haben.
• Tambinor (fischähnlich) - Passend zu der Rasse sollen die Modelle aussehen, wie Unterwasserstationen/-schiffe, also rund und dynamisch.
  Die Farbe der Rasse ist blau.
• Bendalir (Lavagolems) - Diese Rasse soll mächtige, klotz- oder geröllartige Modelle besitzen. Stellt euch ne Art fliegenden Stein vor ^^ Die Farbe ist natürlich rot.
• Cogadh (echsenartig) - Hier sollen die Modelle spitz, eckig und kantig sein. Wie ne Art Kaktus, oder andere Gewächse der Wüste. Farbe der Rasse ist grün.

Da jeder andere Vorstellungen hat suchen wir dringen Konzeptzeichner. Sodass alle die ein Modell bauen wollen ein einheitliches Bild haben.
Weiterhin haben wir die Modelle so konzeptioniert, dass man möglichst viele Teile des Modells in anderen Modellen wiederverwenden kann. Also achtet beim Bau der Modelle darauf, das ihr die Meshs in Gruppen zusammen fast. Damit wollen wir dann eine Art Datenbank aufbauen, wo man sich aus z.B. mehreren Antrieben einen aussuchen kann. Damit wird nicht nur der Speicherplatz optimiert, sondern es dauert auch nicht so lange die Modelle zu bauen.

Wichtige links:
Entwickler-Blog
Massive Universe Online auf Twitter


Soweit zum Projekt, ich hoffe ich konnte euch ein wenig dafür begeistern. Wenn ihr Interesse daran habt, ein Teil des Projekts zu werden, oder einfach nur eine Frage habt, dann schreibt uns eine Mail an [e-mail].
Hoffentlich bis Bald

Bergmann89, Akaikee, Teekeks.

Crosspost zum DF: http://www.delphiforum.de/viewtopic.php?t=107827
Crosspost zum lazarus Forum: http://www.lazarusforum.de/viewtopic.php?f=11&t=5498
Crosspost zum DelphiGL-Forum: http://delphigl.com/forum/viewtopic.php?f=13&t=10173
Crosspost zum Offiziellen X-Forum: http://forum.egosoft.com/viewtopic.p...733837#3733837

[BUG]

Das sieht doch schon gut aus, vor allem sehr methodisch/gut überlegt

Ein paar Sachen sind mir aber aufgefallen:

1. Schaltet man den Schatten auf Smooth, gibt es eine EControlC-Exception (siehe Anhang).
2. Die Schatten "springen" vor und zurück, obwohl sie sich insgesamt in eine Richtung zu drehen scheinen.
3. Ist es Absicht, das die Shader nur gehen, wenn man die "darüber" auch aktiviert hat?

EDIT: Ha, 1. passiert nur in der x64-Version, in der x86-Version wird alles dunkler und die Schatten verschwinden einfach.

EDIT: 2. Wird imho besser, wenn ich die Shadow-Map vergrößere.

[Bergmann89]

Hey,

erstma Danke für das Feedback.

zu 1: sehr komische Exception. Die kann ich mir bis jetzt auch noch nicht erklären. Ich werd mir das im laufe der nächsten Tage mal ansehen. Wenn's dazu was neues gibt meld ich mich hier nochma.
zu 2: das liegt an der Auflösung der ShadowMap. Umso Größer die Auflösung, desto geringer der Nebeneffekt. Wie schon im Artikel beschrieben wollen wir am Schatten noch was Neues implementieren. Das wird aber nochmal etwas aufwendiger, deshalb haben wir das erstmal weg gelassen.
zu 3: ja, das ist zur Zeit noch Absicht. Wir müssen erstmal gucken, was dort sinnvolle Kombinationen sind. Da diese Effekte am Ende in einem Shader zusammen gerechnet werden benötigen wir für jede Einstellung einen extra Shader. Das ist aber kein Problem, da unser ShaderManager schon so konzipiert ist, das er diese Shader von allein generiert. Also müssen wir da einfach ein paar Definitionen ändern, dann geht das.

€: kannst du mir noch das Log der x86 exe mit smooth Shadow anhängen? Da steht dann denke ich auch der Fehler drin. Sieht so aus als ob der Shader da nicht richtig kompiliert...

MfG Bergmann.

[BUG]

Zitat von Bergmann89:

€: kannst du mir noch das Log der x86 exe mit smooth Shadow anhängen? Da steht dann denke ich auch der Fehler drin. Sieht so aus als ob der Shader da nicht richtig kompiliert...

Hast deine Glaskugel ja gut geputzt

[Bergmann89]

Zitat von BUG:

Hast deine Glaskugel ja gut geputzt

hehe^^ Jetzt hab ich auf alle Fälle ne Zeilennummer, da kann ich mir das morgen gleich mal genauer angucken. Aber jetzt geh ich erstma penn. Ich meld mich. gn8

[Bergmann89]

Hey,

ich hoffe ich habs gefixt. Bei Shadern ist das von Grafikkarte zu Grafikkarte bisl unterschiedlich
Datei hab ich als Anhang mit hochgeladen. Die muss nach ".\MassiveUniverseOnline\data\shader".

MfG Bergmann.

[jaenicke]

Schade ist, dass das Programm sang- und klanglos abschmiert, wenn es seine Log-Datei nicht schreiben kann...

Denn logischerweise hatte es beim Ausführen keine Schreibrechte im Ordner... Dass es daran lag, hat mir aber erst der Process Monitor verraten.

Zumindest in dem Fall wäre es sinnvoll die Datei an einen günstigeren Ort zu legen oder zumindest eine Meldung anzuzeigen, dass man seine Rechte verbiegen muss.

[Bergmann89]

Hey,

das log-File ist so ziemlich das erste was erstellt wird, denn da landen eig. auch die Fehler drin. Ich finde, dass der Ordner der EXE genau der richtige Ordner für das log ist, da das Programm später auch an Leute ausgeliefert wird, die nicht so bewandert mit PCs sind, und die bei einem Fehler die log-Datei an uns schicken sollen. Wenn die erst nach %APPDATA% müssen, dann blicken die nich mehr durch Ne ordentliche Fehlermeldung wenn das Log nicht erstellt werden kann fehlt, da geb ich dir Recht. Das pack ich gleich mal auf die ToDo-Liste

MfG Bergmann.

[pustekuchen]

Das ist aber nicht wirklich toll.. Macht es doch so:

Log in %appdata%\MUO erstellen und bei der "Installation" eine Verknüpfung hinzufügen.

[BUG]

Klappt immer noch nicht.
Außerdem habe ich es geschafft eine Access-Violation zu provozieren, in dem ich mehrfach zwischen Smooth und Normal umgeschaltet habe und das Programm dann beende.

Ich würde vorschlagen, Hashes aller geladener Dateien in die Log-Datei zu packen. Da ihr sowieso Git benutzt:

• http://stackoverflow.com/questions/5...1s-without-git
• http://stackoverflow.com/questions/2...-has-this-blob

Außerdem könntet ihr darüber nachdenken, Log- und Config-Dateien (auf Wunsch des Users) über ein Tool auf euren Server zu Laden. Dann kann dem User egal sein, wo die Datei liegt und welche er genau braucht. Er klickt auf einen Button und alle nötigen Informationen werden hochgeladen, heraus kommt evtl. noch eine URL, die er in Foren und Problemberichten nutzen kann.

[jaenicke]

Zitat von Bergmann89:

Ich finde, dass der Ordner der EXE genau der richtige Ordner für das log ist, da das Programm später auch an Leute ausgeliefert wird, die nicht so bewandert mit PCs sind, und die bei einem Fehler die log-Datei an uns schicken sollen. Wenn die erst nach %APPDATA% müssen, dann blicken die nich mehr durch

Deshalb meine ich ja:
Kann die Datei nicht erstellt werden, pack sie doch einfach an den richtigen Ort. Wenn die Schreibrechte da sind, kann sie ja meinetwegen im eigenen Ordner landen, das ist bei mir eh nie der Fall.