Java-Forum.org  

Zurück   Java-Forum.org > Projekte > RPGenesis > Diskussion

Projekt-Reorganisation Meldung abonnieren / ändern
issueid=69 15.05.2011 20:36
Gastredner
Projekt-Reorganisation

So, wie ihr es vermutlich bereits bemerkt habt, gab es in letzter Zeit bezüglich dieses Projekts wenig bis gar keinen Fortschritt, vom Einrichten des Web-Auftritts mal halbwegs abgesehen.
Die Gründe dafür sind vielfältig - neben meiner regulären Arbeit ist jedoch vermutlich die selbstaufgehalste Spezifikationsarbeit der Hauptgrund für diesen bedauerlichen Zustand. Um nun endlich mal voran zu kommen, wollte ich euch gerne einige Dinge mitteilen, die in den letzten Wochen und Monaten in Entscheidungsform in mir herangereift sind.

First things first - der Name.
JCupGames als Name für das Projekt war das Ergebnis guten Willens, der es allen recht machen sollte. Wie allzu oft ist diese Bemühung - so zumindest meine Sicht - an eben jenem Ziel gescheitert. Der Java-Bezug ist mit J und Cup gleich doppelt vertreten, der Name weckt zweifelhafte Analogien (ein J-Cup?) und präsentiert sich wenig griffig. Der Implementierungsname RPGenesis besitzt aus meiner Sicht keinen dieser Nachteile, weswegen JCupGames ersatzlos gegen RPGenesis ausgetauscht werden sollte.

Der Spezifikations-Albtraum.
Jaja, die Spezifikation. Ich muss gestehen, an diesem Punkt vermutlich selbst Schuld zu sein. Jedenfalls hat es sich in letzter Zeit herauskristallisiert, dass ich zum Abfassen einer vollständigen Spezifikation von RPGenesis schlicht und einfach nicht in der Lage bin. Problematisch ist daran vor allem der technische Aspekt: um RPGenesis gemäß meiner Vorstellung spezifizieren zu können, müsste ich das gesamte System bereits geplant und entworfen haben - was aber nicht der Fall ist, primär aufgrund der bereits selbstattestierten Unfähigkeit. Ein weiteres Problem, welches ich zu Beginn vollkommen unterschätzt habe: die Spezifikation tötet den Geist des Projekts. Anstatt gemeinsam ein System zu entwerfen und zu implementieren sollen die Entwickler nur als Arbeitspferde oder verlängerte Arme des Spezifikators dienen und die Spezifikation Stück für Stück anspruchslos umsetzen. Mit dem Geist eines Open-Source-Projekts ist dieser Gedanke meiner Meinung nach nur schwer zu vereinbaren, so denn überhaupt. Statt also RPGenesis komplett im Alleingang zu designen, gedenke ich das Entwicklungsmodell umzukrempeln. Irgendwann in näherer Zukunft sollte es ein (virtuelles) Treffen aller Interessierter geben, in welchem wir gemeinsam den grundlegenden Rahmen und das benötigte Minimum an Features für RPGenesis und den dazugehörigen Editor festlegen werden. Die Entwicklung der dabei festgelegten sowie eigener Features soll dann durch die individuellen Entwickler unter Absprache mit dem Maintainer des Projekts oder eines noch zu bildenden Gremiums erfolgen, welcher/welches die Gesamtentwicklung von RPGenesis überwacht.

Der Wahnsinn mit der Implementations-Neutralität.
Eigentlich auch ein Unterpunkt der Spezifikation. Meine ursprüngliche Absicht war es, mit der Spezifikation eine implementierungsneutrale Beschreibung von RPGenesis zu schaffen, welche von jedem in seiner Lieblingsprogrammiersprache implementiert werden können sollte. Dieser Plan ist letztendlich ebenso grandios gescheitert wie die Dokumentation. Obwohl in hehrer Absicht getroffen, so ist die Entscheidung für die Implementationsneutralität am Ende nur ein weiterer Sargnagel für die Spezifikation gewesen. RPGenesis ist ein Java-Projekt und dazu sollten wir stehen. Zudem vereinfacht dieser Ansatz die spätere Implementierung, da man nicht auf die Verwendung von Drittsystemen achten muss, die auch unter Nicht-JVM-Sprachen ansprechbar sind (Datenbank!). Notfalls bzw. bei entsprechendem Interesse ließe sich eine sprachneutrale Beschreibung des dann aktuellen Standes von RPGenesis immer noch erstellen.

Goodbye SourceForge.
SourceForge ist eine großartige Sache. Mittlerweile steht uns jedoch ein eigener Server zur Verfügung, welchen wir entsprechend nutzen sollten. Das Grundgerüst der Webseite steht - Forum, Bugtracker und ein eigenes SVN-Repository sollen demnächst folgen. Überlegenswert wäre auch die Verwendung einer SVN-Alternative, z. B. Mercurial. Die SourceForge-Projektseite soll jedoch definitiv nicht mehr weitergenutzt werden, inklusive des dortigen SVN-Repositorys. Die Diskussionen rund um RPGenesis sollen dann im weiteren Verlauf Stück für Stück in das eigene Forum verlegt werden.

Das Problem mit dem Bestandscode...
Steev war ja so freundlich, uns den Code seiner Easy Game Engine (EGE) als Grundlage der Implementierung von RPGenesis bereitzustellen. So sehr ich Steev und seine Arbeit schätze, so sollten wir diese Codebasis nicht verwenden. Ich respektire Steevs Arbeit an EGE und bin sicher, dass wir von ihm und seinem Werk fiel lernen können. Jedoch erscheint es mit falsch, RPGenesis auf der Grundlage von EGE aufzubauen - letztendlich würde RPGenesis damit zu einem bloßen Aufbau von EGE werden, ein Wrapper quasi. Da ich persönlich mit diesem Projekt auch das Ziel verbinde, etwas über den grundlegenden Aufbau einer Spiele-Engine zu lernen und selbst aktiv daran teilzuhaben, sehe ich die Verwendung von EGE als kontraproduktiv an. Letztendlich würden wir nur lernen, auf Basis von EGE ein RPG-Framework zu basteln, nicht mehr und nicht weniger. Zudem lässt sich RPGenesis durch diesen Schritt einfacher an unsere Wünsche und Bedürfnisse anpassen und es entfällt der Aufwand, die Sourcen von EGE bzw. die dortigen Kommentare ins Englische zu übersetzen. Ich hoffe, Steev nimmt mir diesen Schritt nicht übel und wird uns weiterhin mit Rat und Tat beistehen. Die Emanzipation von EGE sehe ich jedenfalls neben der Umstellung des Entwicklungsprozesses als zentrales Erforderniss für den erfolgreichen Verlauf des Projekts an.

Ich hoffe, ich überrumple damit nun niemanden bzw. trete niemandem damit auf den Schlips. Die derzeitige Situation des RPGenesis-Projekts ist jedenfalls untragbar, weshalb ich die oben vorgetragenen Änderungen als (teil mehr, teils weniger) dringend notwendig ansehe. Solltet ihr weitere Vorschläge oder Kommentare zu diesen Entscheidungen haben, freue ich mich auf eure Kommentare.
Details der Meldung
Meldungstyp Diskussion
Projekt RPGenesis
Kategorie System
Status Diskussion läuft
Priorität 1 - Hoch
Unbekannt
(keine)
0
0
Zugewiesen an (keine)
Stichworte Editor, Engine, Information, Organisation, Spezifikation, Team

26.07.2011 14:52
Gastredner
 
Ja.
Derzeit bin ich ein wenig im Streß und bekommen hoffentlich übernächste Woche Urlaub, damit ich mal ein wenig ausspannen kann.
Nebenbei bin ich dabei, für das eigentliche Projekthosting Redmine zu evaluieren - anders als mit Joomla kann ich damit bequem viele der wichtigen Funktionalitäten unter einen Hut und Account bringen, statt für jedes Mitglied dann einen Haufen Accounts (Forum, Bugtracker, Wiki, et cetera) anlegen zu müssen. Außerdem könnte er erneuter Serverumzug bevorstehen, welcher dann auf einen mit ein paar Arbeitskollegen geteilten Server führen würde, der von einem echten Admin betreut wird.
Antwort
28.08.2011 21:41
Neuer Benutzer
 
Hallo ihr!
Falls ihr noch Platz habt und das ganze noch etwas wird, würde ich gerne mitmachen.
Allerdings wäre es wirklich hilfreich, mal einen groben Überblick zu bekommen, denn ich vermute, die meiste Information steht in dem "Prototypen"thread, und der ist immerhin 13 Seiten lang. Wäre es vielleicht möglich, zur Übersicht über die prinzipielle Entwicklung auch eine im Hinblick auf die Implementation und die geplanten Features zu geben?
Ich hatte die Idee, dass es vielleicht möglich wäre, eine Netzwerk-Unterstützung einzufügen, allerdings weiß ich nicht, ob ich als erster die Idee hatte.
Und außerdem - Kann man sich auf der neuen Website auch registrieren oder muss das von den Admins gemacht werden?
Antwort
29.08.2011 08:26
freak_007
 
Hallo,
Du kannst eine Anfrage an den Gastredner(Projektleiter) senden um hier mitzumachen über Kontrollzentrum->Mein Netzwerk->Benutzergruppen. Die andere Frage lass ich unseren Projektleiter klären.
Antwort
30.08.2011 19:51
Gastredner
 
Mitmachen kann jeder gerne, aber die Infrastruktur steht derzeit noch nicht. Daher derzeit auch keine Registrierung auf der offiziellen Webseite.
Zu den genauen Plänen bzw. Featurelisten: ich habe eine grobe Vorstellung und suche nach einem passenden Termin, wo man sich mal zusammensetzen und das alles besprechen kann (Skype, TeamSpeak oder so). Derzeit ist es ein wenig eng, aber ab 1. September beginnt mein Studium. Dann hocke ich nicht mehr 5 Tage die Woche auf der Arbeit und muss mich darüber ärgern, dass ich seit Monaten praktisch nix mehr mache, was großartig mit Programmierung bzw. Softwareentwicklung zu tun hat, sondern habe zwischendurch auch mal ein bisschen Auszeit (bzw. FH-Streß). Dann wird es endlich wohl auch wieder voran gehen.
Alles weitere wird dann sowohl hier als auch auf der offiziellen Seite verkündet.
Antwort
19.09.2011 11:35
Neuer Benutzer
 
Hallo Leute! Irgendwie habe ich das leichte Gefühl, dass auch nach dem 1. September nichts passiert.
Ist abzusehen, dass sich das ändert? Ich finde das wirklich ein schönes Projekt, aber so wie es im Moment aussieht, klappt das ganze nicht. Insofern - Hat da noch jemand Interesse dran? Passiert irgendwas im Hintergrund oder ist das ganze eingeschlafen?
Antwort
19.09.2011 12:42
Gastredner
 
Zitat: phreakCascade
Hallo Leute! Irgendwie habe ich das leichte Gefühl, dass auch nach dem 1. September nichts passiert.
Ist abzusehen, dass sich das ändert? Ich finde das wirklich ein schönes Projekt, aber so wie es im Moment aussieht, klappt das ganze nicht. Insofern - Hat da noch jemand Interesse dran? Passiert irgendwas im Hintergrund oder ist das ganze eingeschlafen?
Ich war etwas ungenau: seit 1. September bin ich studentischer Mitarbeiter, war aber dennoch jeden Tag auf der Arbeit. Das eigentliche Studium beginnt diese Woche (letzte Woche waren Vorkurse), was dazu führt, dass ich mich in den nächsten zwei oder drei Wochen erst einmal darauf konzentrieren werde (direkt bei Studienstart Dinge zu versäumen wäre vermutlich eins der dümmsten Dinge, die ich gerade tun könnte).
Weitergehen wird es garantiert, da ich das Projekt nicht sterben lassen möchte. Es dauert aber noch ein klein wenig.
Antwort
01.04.2012 02:07
Stammbenutzer
 
Anscheinend wird das nie etwas.
(PUSH!)
Antwort
03.04.2012 21:35
Gastredner
 
Ja, der PUSH ist wohl notwendig.
In letzter Zeit war es etwas hektisch mit der Koordination FH <-> Arbeit <-> Prüfungen <-> Wohnungsrenovierung, daher bin ich nicht zu viel gekommen. Ich habe derzeit Probleme, die Entwicklungsumgebung einzurichten - SVN macht mir Probleme, und ohne Source Repo wird das ja nicht wirklich was. Ein Arbeitskollege empfiehlt git statt SVN, ich will es damit mal probieren (oder mit Mercurial, je nachdem was besser an Redmine angebunden ist). Sobald ich es in der VM ans Laufen gekriegt habe, werde ich den Server neu aufsetzen (OS ist zu alt für die angezielte Redmine-Version) und die Umgebung auch dort installieren.
In der Zwischenzeit sollte ich mir vielleicht mal die Zeit nehmen, die generellen Ideen zu RPGenesis einmal zu verschriftlichen und online zu stellen, damit diese als Diskussionsgrundlage für ein Vorgehen bzw. für die Inhalte der Meilensteine bis zur ersten Version dienen können.
Kurzer Umriss der Fähigkeiten von RPGenesis, die in einer ersten Version enthalten sein sollten:

ENGINE
  • basierend auf Software-Rendering (OpenGL erst in späterer Version?)
  • Rendering von Multilayer-Maps mit Backdrops und Overlays
  • Layer mit und ohne Tile-Unterstützung
  • Scriptlayer mit pixelgenau platzierbaren Events
  • Eventbibliothek für oftmals benötigte Events und Objekte (Türen, Truhen, Schalter, ...)
  • NPC Layer mit NPCs und deren Laufpfaden
  • Strukturierung der Maps nach inhaltlichen Gesichtspunkten (World -> Location -> Scene ?)
  • Soundwiedergabe (Hintergrundmusik, Soundeffekte)
  • Script Engine basierend auf Python
  • Kampfsystem (Details ausstehend)
  • Oberflächenbibliothek zum einfachen Zusammenbau einfacher Menüoberflächen (z. B. Status, Inventar, Gruppe, Ausrüstung, ...)
  • Datenhaltung in XML, Dateien und Datenbank (Dateien und XML für die Resourcen, DB für den Rest?)
  • Kollisionserkennung basierend auf Shadow Map

EDITOR
  • Modulare Aufteilung (besonders im Hinbliock auf spätere Lokalisierungen) basierend auf Eclipse
  • Projektverwaltung innerhalb eines Workspaces
  • Mapeditor mit Layerabhängigen Funktionen
  • Editoren für Dialoge, Skripte, Charaktere, Items, ...
  • Resource Library zur Verwaltung projektbezogener (und globaler?) Ressourcen
  • Export-Funktion zur Erstellung von Releases
Dies ist nur ein kurzer, unvollständiger Umriss, schnell heruntergeschrieben und vermutlich mit einigen Fehlern. Sämtliche enthaltenen Punkte stehen selbstverständlich zur Diskussion. Eine ausführliche Version mit Erläuterungen folgt später.
Antwort
04.04.2012 07:57
Team RPGenesis
 
Ich kann dem Vorschlag von git nur zustimmen!

Hm ein Vorschlag um das Konzept voran zutreiben, wäre es auf Google Docs (oder etherpad, ähnlichem?) zu stellen, dass mehrere Leute gleichzeitig mitarbeiten oder zumindest mitlesen und kommentieren können...?

Was für mich auch noch ein interessanter Teil wäre, ist Netzwerk (bzw. Multiplayer). Macht zwar die Engine nicht weniger komplex, aber soetwas nachträglich einzufügen war meiner Erfahrung nach bisher alles andere als angenehm.
Antwort
04.04.2012 14:53
Gesperrter Benutzer
 
Zitat:
Script Engine basierend auf Python
Gibts nen speziellen Grund für die Wahl von Python?
Antwort
04.04.2012 17:15
freak_007
 
Git ist cool. Ich verwende GitHub als Hosting Service für meine Projekte. Bei GitHub kann man ein Projekt abspalten(forken) und später eine Zusammenlegung(merge) vom Projektersteller verlangen. Jeder kann sich im Projekt ansehen wer eine Zusammenlegung verlangt und dementsprechend auch kommentieren. Natürlich kann man auch alles durch Patches auf einer Mailing Liste regeln. Natürlich wenn jemand beim Projekt mitarbeiten will kann man ihn zur Repoository vollwertigen Zugang gewähren.

Zitat:
Gibts nen speziellen Grund für die Wahl von Python?
Python ist aufgrund der Lesbarkeit und Einfachheit der Sprache gut für Einsteiger geeignet.
Zitat:
Hm ein Vorschlag um das Konzept voran zutreiben, wäre es auf Google Docs (oder etherpad, ähnlichem?) zu stellen, dass mehrere Leute gleichzeitig mitarbeiten oder zumindest mitlesen und kommentieren können...?
Ich würde mal sagen, dass eine einfache Wiki reichen würde um alle Ideen festzuhalten.
Antwort
04.04.2012 19:11
Gastredner
 
Zitat: Sonecc
Gibts nen speziellen Grund für die Wahl von Python?
Ja, ich mag Python.
Wie freak_007 bereits erwähnte verfügt Python über eine meiner Meinung nach klare Syntax, die sich teilweise deutlich an die englische Sprache anlehnt und somit hoffentlich den Einstieg ein wenig erleichtert. Ein schönes Beispiel dafür ist ein null-check. Mal zum Vergleich:
Java Code: Quelltext in neuem Fenster öffnen
  1. if (object != null) {
  2.     // ...
  3. }
Und nun in Python:
Code:
if object is not None:
	# ...
Zudem hoffe ich, dass der Zwang zur Einrückung die Lesbarkeit von Quelltexten (und somit auch den Support) erleichtert und Anfängern direkt einen halbwegs akzeptablen Einrückungsstil verpasst. Außerdem ist der Umgang mit Listen et al sehr einfach und angenehm in Python, was an einigen Stellen vielleicht ganz hilfreich sein könnte.
Besonders wichtig ist allerdings, dass mit Jython eine auf der JVM laufende, mit Java gut kooperierende Implementierung von Python existiert, die wir dann verwenden können.

Zitat: freak_007
Ich würde mal sagen, dass eine einfache Wiki reichen würde um alle Ideen festzuhalten.
Die Idee mit dem Wiki finde ich ganz gut. Die Projektverwaltungssoftware Redmine hat ein Wiki integriert, daher sollte ich diese jetzt endlich mal richtig ans Laufen bekommen.
Antwort
05.04.2012 07:40
Gesperrter Benutzer
 
Also ich stelle an die Skriptengine folgende Anforderungen:

- Leicht zu erlernende Skriptsprache
- Gute Einbindung in die Engine (z.B. WorldMap direkt ansprechbar)
- Hohe Sicherheit für den User (dazu gleich mehr)
- Einfache Einbindungsmöglichkeiten in die Engine
- Platformunabhängigkeit
- klein und leichtgewichtig

Bei Python sehe ich da einige Punkte eher skeptisch.

Vor allem aber Punkt 3 sticht mir ins Auge.
Python ist eine Hochsprache. Mit einer solchen Sprache kann sehr viel angestellt werden, was wir sicherlich nicht wollen. Ich jedenfalls würde es nicht gerne sehen, dass die Engine als Malware schleuder genutzt wird. Wie das bei Jython so aussieht weiß ich aber nicht.
Muss ich mir mal genauer ansehen.


Da die Entscheidung aber gefallen ist, lasse ich mir mal was einfallen.

Edit:

Mittels XText könnte man z.B. eine passende Skriptsprache erstellen. Das parsen und verarbeiten wäre dann schon von Haus aus dabei und die Sprache wäre gut an die Bedürfnisse der Engine anpassbar.

Nur um mal Alternativen zu bieten.
Antwort
05.04.2012 13:58
Gastredner
 
Grundsätzlich bin ich für Alternativvorschläge immer offen. Über Xtext habe ich auch schon mal nachgedacht, allerdings habe ich keine Erfahrung im Umgang damit und bin daher nicht allzu tief eingestiegen. Prinzipiell sehe ich dieselben Vorteile wie du: die Sicherheit sollte einfacher zu gewähren sein (bei Jython hätte man vielleicht über Einstellungen beim PythonInterpreter und eine SecurityManager eine gewisse Sicherheit gewähren können), die Sprache wäre komplett auf unsere Bedürfnisse anpassbar und die generierten Arbeitsmittel (Texteditor und Co) können wir dann auch direkt verwenden.
Allerdings frage ich mich, ob Jython nicht gerade durch seine Hochsprachen-Eigenschaften einen Vorteil hätte. Prinzipbedingt ist mit einer Hochsprache sehr viel mehr möglich als mit einer für bestimmte Zwecke entworfenen DSL, was den Nutzern einen kreativeren Umgang erlaubt (sofern es denn notwendig ist).
Wie gesagt, offen bin ich für alles. Wenn jemand mehr Erfahrung mit Xtext hat, wäre ich über Input dankbar. Vielleicht könnten wir auch den Versuch unternehmen, zu Beginn beides anzubieten und dann in einem (internen?) Vergleich die beste Variante zu ermitteln.
Antwort
05.04.2012 14:07
Gesperrter Benutzer
 
Also wenns mal produktiv werden sollte, würde ich mich freiwillig für den Scripting Bereich melden. Würde mich dann mal an XTEXT setzen und damit eine DSL entwerfen. Man kann dann anhand dessen ja feststellen ob es den Anforderungen entspricht oder nicht.

Insgesamt kann man ja die Scriptengine ruhig modular halten. Soweit ich das richtig im Kopf hatte sollte die Engine insgesamt ja auch auf OSGI aufsetzen, damit wäre es einfach die Scriptengines auszutauschen und zugleich immer eine gewisse Funktionalität zu gewährleisten.
Antwort
12.07.2012 18:11
Benutzer
 
ich habe noch nie an einem projekt mitgearbeitet und ich kenn mich in manchen sachen die hier genannt wurden nicht aus allerdings wage ich zu behaupten dass meine java kenntnisse ausreichen. Ausserdem lerne ich sehr schnell und gerne neue sachen dazu. Ich würde mich desshalb (falls da überhaupt noch was läuft) gerne dem projekt anschließen.
Antwort
13.07.2012 11:31
Gastredner
 
Derzeit läuft so gut wie gar nichts. Prüfungsphase kommt und auf der Arbeit war auch einiges los, da hatte ich nicht großartig Zeit und Muße, Abends auch noch viel zu schreiben. Ich werde mich in Kürze allerdings wieder dransetzen und dann endlich mal zusehen, dass auch was bei rumkommt.
Alles weitere wird man dann sehen. Da wir allerdings ein Open-Source-Projekt sind kann prinzipiell jeder mitarbeiten.
Antwort
13.07.2012 12:58
Benutzer
 
ok sag bescheid wenn wieder was läuft
Antwort
Antwort

Meldung abonnieren / ändern
Diese Meldung abonnieren