spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Also ich hätte Interesse. Was mir erstmal an deinem Anfangsbetrag auffällt:

Wie Sacaldur würde ich Mutithreading auch erstmal weglassen, um es nicht zu komplex zu machen.
GitHub ist super, da bietet sich es an sowieso "jeden" mitmachen zu lassen. Natürlich macht es Sinn ein Kernteam zu haben, also alle die sich hier melden.
LibreOffice ist zwar gut, aber ein textbasiertes Format wäre evt. besser für Git. Markdown bietet sich eigentlich an und reicht von den Formatierungsmöglichkeiten her völlig.

Ich selbst möchte auch einige Dinge aus der Theorie ausprobieren: es wäre gut wenn ich nicht nur als Programmierer, sondern auch als Architekt arbeiten könnte. Beim ersten Forenprojekt (das ich kenne), war ein großes Problem, dass man die Arbeit nicht vernünftig verteilen konnte (oder hat). Ich würde mich dazu bereit erklären Anforderungen in ein Design umzuwandeln, natürlich nicht komplett allein, um daraus dann Spezifikationen zu erstellen die unerfahrenere Programmierer dann umsetzen können. Das macht das ganze deutlich machbarer, denke ich. Die Anforderungen selbst müssten wir natürlich auch erstmal ordentlich sortieren, da ich auch das Spiel nicht kenne.
Mit anderen Worten: ich möchte das ganze Software Engineering einmal an einem echten Projekt durchmachen. Also richtig mit Lasten-/Pflichtenheft, Architektur, Use-Cases und dazu entsprechende Unittests. Zeit hätte ich 5-10 Stunden je Woche, abhängig davon wie gut wir vorankommen und ob ich Zeit/Lust habe.

Technisch würde ich auf Linux arbeiten, genauer mit Eclipse. Um das Aufsetzen kümmer ich mich dann selbst
SFML kann ich ja später schon mal ausprobieren.

[Edit] Ach du darfst das hier als Bewerbung ansehen

Versteht das mit dem Multithreading nicht als grundlegende Kritik gegen das Projekt. Mir gings nur darum das der Ansatz (viele Objekte => gut für Multithreading) nicht der richtige Ansatz ist.

Das Konzept ist mal wieder eins der Besseren hier im Forum und hat sicherlich ne Menge Potential (das dann natürlich auch genutzt werden will). Wenn ihr es öffentlich entwickelt werde ich gerne auch mal reinschauen. Vielleicht auch um übers Multithreading zu diskutieren. Ansonsten fehlt mir leider die Zeit mich in irgendeiner Art zu verpflichten.

@Schorsch:
Und ich habe bereits eine andere Möglichkeit für die schlechte Performance genannt: eine schlechte Implementierung. Erst wenn sich in der eigenen Implementierung das gleiche Problem zeigt und der bis dahin geschriebene Code einigermaßen performant ist und keinen "Unsinn" macht, kann man nach weitere Optimierungsmöglichkeiten schauen. Multithreading kann dabei eine Option sein. Nur leider steht schon jetzt in der "Wie soll dasd Spiel aussehen"-Liste der Multithreading-Punkt.

@DeKugelschieber:
Die von dir genannten Dokumente werden aber nicht bei jeder Art von Vorgehensweise verwendet, oder zumindest nicht im gleichen Maße angefertigt. Weiterhin könnten manche Dokumente (Use-Case-Diagramme) bei Spielen bzw. Simulationen ziemlich bedeutungslos oder schwer zu schreiben sein.

Können die Dokumente aus Libre-Office denn nicht in einem textuellen Format gespeichert werden? Aber textuelle Formate wären für eine Versionsverwaltung durchaus sinnvoll, da sonst nur mit Absprachen (oder Locks, sofern unterstützt) Konflikte verhindert werden können.

Das klingt nach einem interessanten Projekt! Ich kann mich, da ich ein Anfänger bin noch nicht daran beteiligen, allerdings wünsche ich dir viel Glück und gutes Gelingen bei der Programmierung! Projekte wie dieses inspirieren mich selber tiefer in 2D Programmierung einzutauchen

Also ich muss jetzt nicht auf Teufel komm raus unbedingt genau nach Schema F aus der Industrie vorgehen.
Aber ein logisches vernünftiges Vorgehen das in die Richtung geht wäre schön.

Was denke ich auf jeden Fall Sinn macht ist eine Anforderungsanalyse die wir gemeinsam erstellen. Daraus kann man dann Use-Cases entwickeln, oder zumindest sowas ähnliches. Mir geht es ums Design und darum die Aufgaben verteilen zu können. Also eine Struktur in der ich von irgendwo Arbeit bekomme, umwandle und weiterreichen kann.
Das ist auch für die Leute die "einfach nur" programmieren einfach schön. Man kümmert sich nicht um das Gesamtkonzept und um Details sondern schreibt seinen kleinen Part. Wenns mal hackt weiß man wen man fragen kann.

Bei dem letzten Forenprojekt war einer der Gründe warum ich mich dann doch zurückgezogen habe, dass ich nicht wusste, wie ich Sinnvoll helfen kann. Wenn man den Leuten aber ein Dokument in die Hand drücken kann, wo steht was getan werden muss und dazu kein Wissen über das ganze System vorhanden sein muss, macht das auch Spaß und hat eine viel kleinere Einstiegshürde.

Also ich bin dabei

Bezüglich Dokumentation mit LibreOffice bin ich auch nicht begeistert. Das Konzept von Dokumenten als Dateien, die von PCs zu Server hin und her wandern und von vielen Benutzern, teilweise Gleichzeitig, bearbeitet werden, ist zum Scheitern verurteilt. Entweder nutzt man Lösungen wie google documents, die darauf ausgelegt sind, von mehreren Benutzern gleichzeitig bearbeitet zu werden, und immer auf dem Server bleiben, oder man richtet eine Wiki ein.

Anforderungsanalyse klingt immer so statisch. Gerade bei community Projekten macht es vermutlich Sinn das Ganze etwas agiler anzugehen. Vielleicht sowas wie Scrum aber ohne feste Sprints. Der/Die Ideengeber überlegen sich allgemein was (als nächstes) ins Spiel soll (User Stories) und das Kernteam macht daraus Aufgaben (Tasks), die in einem System gepflegt werden, so dass sich jeder daraus bedienen kann. Um das große Ziel nicht ganz aus den Augen zu lassen kann man sich z.B. mit Meilensteinen (auf Basis von Funktionsumfang, nicht Datum) Zwischenziele setzen an denen man vergleichen kann ob man noch auf dem richtigen Kurs ist.

Zitat von »DeKugelschieber«

Bei dem letzten Forenprojekt war einer der Gründe warum ich mich dann doch zurückgezogen habe, dass ich nicht wusste, wie ich Sinnvoll helfen kann. Wenn man den Leuten aber ein Dokument in die Hand drücken kann, wo steht was getan werden muss und dazu kein Wissen über das ganze System vorhanden sein muss, macht das auch Spaß und hat eine viel kleinere Einstiegshürde.

Da bin ich mal zufällig bei Brackets auf ein positives Beispiel gestoßen. Auf deren Seite gibt es neben der Erklärung wie man das Projekt baut auch eine Liste von Bugs und Features die ideal für Einsteiger geeignet sind: http://brackets.io/contribute.html

Jup ich stelle mir das auch etwas agiler vor. Das klingt jetzt so statisch aber ich bin davon ausgegangen das wir so den Workflow aufbauen können. Das zwischendurch Rückschritte gemacht werden ist denke ich normal. Wasserfallmodel funktioniert wenn überhaupt nur in der Industrie (zumindest bei uns).
Scrum klingt super, habe ich bisher auch keine Erfahrung mit, aber sicherlich ausprobierenswert.

Scrum wurde im IRC auch schon angesprochen. Wobei die Treffen dann zum Beispiel wöchentlich stattfinden könnten.

@Multithreading, Sacaldur: da hast du schon recht. Ich wollte auch nur darauf hinweisen dass es hier nicht um konkrete Planungen geht sondern nur eine Idee angesprochen wurde. Natürlich hast du recht und man sollte Probleme erst ordentlich analysieren und dann zum passenden Werkzeug greifen. Ich denke das Thema Multithreading können wir hier erst mal beiseite lassen.

Ein Wiki fände ich auch sinnvoll. Für weitere Dokumente würde sich ja möglicherweise Latex anbieten. Schwer ist es nicht damit zu arbeiten und wenn man vorher eine vernünftige Vorlage erstellt die nur gefüllt werden muss, dann sollte das recht unproblematisch sein.

Für die Aufgabenverteilung sollten wir ein System einrichten. Für welches man sich da am Ende entscheidet kann man dann ja gucken. Anstehende Aufgaben könnten dann in Meetings besprochen werden wobei ein oder zwei Leute die danach eintragen sollten. Die Aufgaben müssen dann ja nicht unbedingt fest zugewiesen werden. Da kann sich ja jeder selbst suchen was er machen möchte. Das ist an sich ja kein unübliches Vorgehen.