spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Toa«

Hab gelesen ihr verwendet Pivotal Tracker. Benutzt ihr einen öffentlichen Account und kann man den einsehen?

Ja ist öffentlich: hier (Ich hoffe es ist okay, dass ich das hier poste...)

Zitat von »Toa«

Konkret beispielsweise ein Statemanager für Zustände. Landet eine solche Aufgabe bei euch als Coding Task in euer Userstorie oder wie erfasst ihr sowas?

Naja wir haben hier nichts verrücktes gemacht und die Tasks sind auch nicht bis ins letzte Detail beschrieben. Der Feinschliff lief dann oft über IRC - wie bei so manchem ist Kommunikation sehr zentral - wo durch es dann möglich war, gute und schlechte Ideen abzuschätzen und in die richtige Richtung zu steuern. Dies setzt natürlich aber auch etwas Erfahrung voraus, sonst weiss man ja nicht was gut und was schlecht ist.
Ganz praktisch hat die Story 3.3 mit der Grundstruktur zu tun (wie gesagt nichts weltbewegendes):

Zitat

[3.3] As a developer, I need a basic system and architecture that defines how rendering is performed.

Create a basic rendering architecture which can unite the different types of renderable elements.

Zitat von »Toa«

Positiv ist mir auch aufgefallen, das ihr Ergebnisse der Meetings festhaltet.

Zja, wenn immer nur die Hälfte anwesend sind, braucht es schon eine Art Protokoll, wobei da Pivotal auch schon ein guter Beitrag leistet.

Zitat von »Toa«

Bin überrascht von der Plannung. Bisher dachte ich das Projekt sei unorganisiert und hab es immer überlesen.

Management ist das A und O in der Teamarbeit und es ist auch dort, wo die meisten Community/Team Projekte scheitern. Meiner Meinung nach wäre hier innert kürze nichts mehr gegangen, hätte nicht BlueCobold das Projekt in die Hand genommen und klar eine Richtung angegeben. Demokratie etc. ist gut, aber es gilt ja auch: "Zu viele Köche verderben den Brei."

Zitat von »Toa«

Sichert ihr auch die Qualität eures Projektes (Hab etwas von Code Reviews gelesen und auch ein UML artiges Diagramm in GoogleDrive gesehen).

Die Reviews sind leider wie oben genannt zu wenig und ich müsste mich persönlich einmal daran setzten und alles durch gehen...
Das Diagramm war zum grössten Teil für mich, damit ich einen gewissen Überblick erhielt. Leider ist es bereits sehr alt, was jedoch auch wiederspiegelt, dass ich nicht mehr jede Verbindungen verstehe (z.B. die ganzen Animations Sachen...).

Zitat von »BlueCobold«

Im Moment sieht es so aus, dass es jede Menge Code gibt, zu dem bisher niemand ein Review getätigt hat.

Ich versuche mich mal daran zu setzten in den nächsten paar Tagen... Es gibt einfach noch so viele andere interessante Dinge zu tun.

Zitat von »BlueCobold«

Das Engagement, bzw. die Eigeninitiative sieht momentan meiner Meinung nach also eher dürftig aus.

Obwohl du wahrscheinlich mich nicht eingeschlossen hast, so muss ich mich doch auch etwas dort platzieren, da mir die Motivation etwas verloren ging, da ich die Übersicht etwas verlor..

Zitat von »BlueCobold«

Mit ~3 aktiven Leuten lässt sich dies auch nicht mehr so ganz als Community-Projekt beschreiben.

Vielleicht hat die Spieleprogrammierer Community ja nur 3 Members.

Zitat von »Toa«

Ich interessiere mich für eure Formulierung der Userstories, aber auch wie ihr alles aufsplittet. Ich habe persönlich oft das Problem das ich etwas für einen Sprint programmieren muss, das sich aber nicht aus Sicht des Users darstellen lässt. Konkret beispielsweise ein Statemanager für Zustände.

Das ist genau genommen auch keine User-Story im eigentlichen Sinn, aber notwendiges Chore. Ich habe bei den Stories immer versucht die Sicht entweder eines Level-Designers oder eines Spielers zu erfassen, da beides mehr oder minder User darstellen, auch wenn sie ganz klar andere Ansichten auf das Projekt haben. Ein Statemanager ist jetzt auch eigentlich nichts, was man zwingend braucht. Das kann man sicher auch anders lösen und daher hätte ich sowas ungern als Story definiert.

Zitat von »Toa«

Landet eine solche Aufgabe bei euch als Coding Task in euer Userstorie oder wie erfasst ihr sowas?

Nun, man sollte versuchen das komplett außen vor zu lassen. Man will ein gewisses Feature oder Verhalten und die Entwickler sollten sich dann absprechen, wie sie das am besten umsetzen. Wenn dabei ein Statemanager sinnvoll ist, dann sollte dieser gebaut werden. Aber nur als Mittel zum Zweck, nicht als eigentliche Aufgabe der Story. So zumindest die Theorie. Ich habe allerdings auch ein paar Chores eingestellt, die ganz klar auf strukturelle Mittel wie Rendering und Ressourcen-Management abgezielt haben, da gerade am Anfang eines neuen Projekts und bei eher Team-unerfahrenen Leuten eine klare Architektur-Richtung wichtig war.

Zitat von »Toa«

Positiv ist mir auch aufgefallen, das ihr Ergebnisse der Meetings festhaltet.

Na ja, seitdem wir Pivotal verwenden und außer den Stories in den Meetings eigentlich nichts mehr wirklich besprochen wird, werden auch keine Ergebnisse mehr festgehalten.

Zitat von »Toa«

Bin überrascht von der Plannung. Bisher dachte ich das Projekt sei unorganisiert und hab es immer überlesen.

Nun, am Anfang hatte sich Sacaldur ja bemüht da provisorisch die Leitung zu übernehmen, wobei da leider die ersten Meetings nicht viel rausgekommen ist, weswegen ich da etwas straffer durchgegriffen habe mit einer Ziel-Vorgabe des Spieltyps und der User-Stories, sowie Richtlinien für Programmierung (siehe http://code.google.com/p/spieleprogrammierer-forenprojekt/ - Team Charta, Syntax Regeln und Code Conventions). Allerdings ist die Mitarbeit ziemlich schnell eingebrochen und fast alle wirklich großen Sachen blieben auf eXpl0it3r hängen, wodurch das Projekt stark gebremst wurde. Als Folge daraus und meiner eigenen Ambition genau dieses Spiel zum Leben zu erwecken, habe ich selbst noch einiges programmiert, damit ich gewisse Animationen und Freiheiten im Level-Design umsetzen konnte - was ich eigentlich nicht geplant hatte.

Zitat von »Toa«

Sichert ihr auch die Qualität eures Projektes (Hab etwas von Code Reviews gelesen und auch ein UML artiges Diagramm in GoogleDrive gesehen).

Jein. eXpl0it3r hat ein grobes Diagramm gepflegt und wir führen notwendige Refactorings und Code-Reviews durch, sowie Absprachen im IRC, wie sich eine Story am besten technisch umsetzen ließe (ohne im Overkill zu landen natürlich). Es sind allerdings keine automatischen Tests oder Unit-Tests vorgesehen, weil ich denke, dass diese zwar sehr gute Hilfsmittel, aber auch große Motivationskiller sind. Wenn das Projekt etwas gerade nicht gebrauchen kann, sind es Motivationskiller.

Zitat von »eXpl0it3r«

Zitat von »BlueCobold«

Im Moment sieht es so aus, dass es jede Menge Code gibt, zu dem bisher niemand ein Review getätigt hat.

Ich versuche mich mal daran zu setzten in den nächsten paar Tagen... Es gibt einfach noch so viele andere interessante Dinge zu tun.

Das war eigentlich nicht die Intention meiner Aussage. Ich will nicht, dass am Ende nur noch Du, Koschi und ich da dran sitzen, dann können wir's auch lassen. Es sind ja doch einige abgesprungen ohne es offiziell zu sagen, einige mit Ankündigung, einige haben sich als "vorübergehend inaktiv" gemeldet und... na ja. Es wäre halt ein komplett anderes Projekt als ursprünglich gedacht.

Na das klingt nach keiner Rosigen Zukunft für das Spiel

Was mich bisher abgehalten hat mitzumachen ist, dass man nicht weiß - ich hab es zumindest bisher nicht auf Anhieb gefunden - was eigentlich gemacht wird. Gibt es einen Thread mit einer zentralen Stelle, wo alle Sachen zusammenlaufen? Links zu google-code, tracker und drive documents? Es ist damit relativ schwierig einen Überblick zu behalten.

Ich klaube mir grad so alles zusammen und schau mir das ganze mal an. Lust habe ich schon seit Idee des Projekts, gerade mit euch zusammenzuarbeiten!

Zitat von »TrommlBomml«

Was mich bisher abgehalten hat mitzumachen ist, dass man nicht weiß - ich hab es zumindest bisher nicht auf Anhieb gefunden - was eigentlich gemacht wird. Gibt es einen Thread mit einer zentralen Stelle, wo alle Sachen zusammenlaufen? Links zu google-code, tracker und drive documents? Es ist damit relativ schwierig einen Überblick zu behalten.

Nicht wirklich, aber ich hatte da aus Spass am Anfang mal schnell eine "Seite" gemacht: http://sppro.my-gate.net/

Eine offizielle Zusammenfassung dessen, wohin die Reise eigentlich geht und was so dazu gehört, die gibt es maximal in Pivotal, eher aber in meinem Kopf. Ich war schlicht zu faul daraus ein eigenes Konzept-Dokument zu erstellen. Die Links an sich sind aber nicht so viele, nur eben nicht alle wirklich hilfreich in Bezug auf: "Was wird eigentlich gemacht?".
Die Frage selbst lässt sich schon spalten in die technische und die fachliche Seite. Geht es darum, was wir an Code so bauen und wie das sich alles aufbaut oder dahin, wie im Detail das Spiel später mal aussehen soll? Ersteres ist immer eine agile Entscheidung von Sprint zu Sprint. Letzteres ist nur grob in meinem Kopf und ergibt sich mehr oder minder aus den jeweils aktuellen Level-Entwürfen und diversen Brainstorming-Ergebnissen, die nur Stichpunktartig in den ersten Google-Docs zu finden sind, sowie in meinem Kopf.

Ich finde das erstmal super, dass du die Vision hast. Letztendlich ist es meiner Erfahrung nach eh besser, wenn einer die Vision hat. Was mich natürlich interessiert, ist beides: fachlich und technisch.

Was denke ich auch dazu geführt hat, dass viele ab gesprungen sind: Es ist schon ordentlich Architektur in dem Spiel, die ein Anfänger kaum verstehen wird. Dieser hätte in diesem Spielumfang vielleicht 3-4 Klassen und eine Main-Funktion - mit entsprechenden Folgen logischerweise . Das überblickt einfach nicht jeder und zuzugeben, dass man Dinge nicht versteht und sich eingestehen muss, dass man es nicht so einfach umsetzen kann, ist schon für manche nicht so einfach.

Jup. Ein Projekt stellen sich viele eben doch ganz anders vor. In jeder Hinsicht.

Zitat von »TrommlBomml«

Was denke ich auch dazu geführt hat, dass viele ab gesprungen sind: Es ist schon ordentlich Architektur in dem Spiel, die ein Anfänger kaum verstehen wird.

Ich gebe zu das war auch einer der Gründe, warum ich in letzter Zeit inaktiv war. Ich hab das ganze zwar im Groben wohl verstanden, aber irgentwie doch die Motivation verloren.
Ich will mich aber auch noch nicht komplett vom Projekt verabschieden, vielleicht bekomme ich ja nochmal Lust daran und kann ein paar leichtere Aufgaben übernehmen.

Aber auch noch mal Respekt für den Einsatz von BlueCobold. Wenn er sich nicht um die Leitung gekümmert hätte, wäre das Projekt vermutlich schon wieder vergessen.

Zitat von »michi_95«

Ich gebe zu das war auch einer der Gründe, warum ich in letzter Zeit inaktiv war. Ich hab das ganze zwar im Groben wohl verstanden, aber irgentwie doch die Motivation verloren.

Das ist etwas, was man in einem grösseren Team lernen muss damit umzugehen. Man kann ein anständig grosses Projekt kaum komplett Verstehen und gutes Design ist da sehr wichtig, damit man das auch nicht muss. Man kann dann irgendwie abgeschottet an etwas bauen, was man versteht und das fügt sich dann ins Gesamtbild ein.

Das ist das, was Anfänger wohl am meisten von diesem Projekt lernen können (die Designentscheidungen, Erfahrung etc. von BlueCobold sind natürlich auch ein Pluspunkt, aber das sind Sachen, die mit der Zeit und viel Entwicklung kommen). Meine Empfehlung für die, die die Motivation verloren haben: Bleibt dran. Quält euch halt durch, aber so zu arbeiten gehört sehr wahrscheinlich irgendwann zu eurem Alltag, wenn ihr als Entwickler arbeitet. Es hat auch seine schönen Seite, wenn man einfach mal denken kann: "ich muss das nicht verstehen/mir den Kopf darüber zerbrechen. Das macht jemand anders"