spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

@Flux: Nein. Nur weil es nur 2 Projektmitarbeiter gibt, heisst es nicht, das zwei Rollen wegfallen. Es darf jemand auch mehrere Rollen haben. Es spricht zum Beispiel nichts dagegen, dass einer ScrumMaster und Team und der andere Product Owner und Team als Rolle hat. Der Vorteil von Verteilt Product Owner und Scrum Master hat den Vorteil der Gegenseitigen konsultation, sehe ich zumindest so. Ansonsten spricht auch nichts dagegen, dass Teammitglied 1 Product Owner, ScrumMaster und Team ist und der andere Team. Je nachdem, wer was am besten kann. Und das funktioniert auch ab zu zweit.

Zum Webclient: Der ist Prozessunabhängig, also auch für Scrum-Edition.

Zitat von »Razer«

Wie meinst du das?
Ist in der Personal Edition ein Webclient dabei?

Es gibt ja in-Step auch als Server Edition, aber der scheint was zu kosten, bzw. es gibt keine Personal Edition (wird dann bestimmt richtig teuer werden).

Bzw. wie soll ich das jetzt lösen?

Du kannst sehr einfach Dateien mit Dropboxsharen und synchronisieren.

Eine Rolle ist ein Verantwortungsbereich. Es spricht nichts dagegen, dass eine Person mehre Rollen einnimmt. In vielen jungen Unternehmen wird es genauso gemacht.. da ist CEO, Leader Development, Sales Manager, Leader Market Research, Support Manager, etc eine einzige Person

Hmm, so wie ich Scrum kenne, darf ein Scrum Master und ein Product Owner kein Mitglied des Teams sein. Ansonsten besteht da ein Interessenkonflikt.
Klar, wenn man IMMER, zu jeder Zeit unterscheiden kann, in welcher Rolle man grad handelt, könnte das gehen. Aber das geht nicht gut (kenn ich aus eigener Erfahrung).

Zitat von »Razer«

Jetzt hab ich noch eine Frage.
Gibts irgendwo eine Darstellung, aus welchen Kernelementen ein Spiel gebaut ist?

Ich hab irgendwie das Problem, dass wenn ich überleg, was ich für das Spiel brauch, mir nie all
das einfällt, was ich wirklich brauchen würd.

Momentan denk ich eher an einen Art InputManager, GraphicsManager usw. welche die Basis für das Spiel darstellt,
aber ich weiß ehrlich nicht, wo ich anfangen soll die ersteln Elemente für das Product Backlog zu setzen ...

Habt ihr da noch einen Tipp?

Fang mit einem Prototypen an, dann wirst du feststellen was du brauchst. Planning is guessing.

Du kannst so viel planen wie du willst, irgendwas wirst du vergessen. Da ist es von Vorteil wenn man Agil entwickelt, und sich darauf konzentriert einen funktionierenden Prototypen zu entwickeln.

Wenn du etwas abstraktionsvermögen besitzt dann sollte dir dieser link helfen:

http://gettingreal.37signals.com/toc.php

Das Buch ist für Webanwendungen geschrieben, jedoch lässt es sich auf fast alle Projektarten anwenden die nicht zu komplex und groß sind, und damit auf fast alle Software projekte.

Riesige Planungsdokumente sehen zwar toll und professionell aus und man kann überall vorzeigen wie "professionell" man ist.. nützen in der Regel für solche Projekte nix - im Gegenteil, in der Zeit haben manch andere ne erste Version des Spiels fertig.

Was ich mit Prototyp meine: Die wichtige Frage hier ist: Was macht dein Spiel aus? Was ist das absolut mindeste was in dem Spiel funktionieren muss, damit man es als Spiel bezeichnen kann?
Und genau das ist deine erste Version vom Spiel.

Das mit der Versionsverwaltung habe ich mir mal angehört (mein erster Podcast ). Ich muss sagen, die Argumente überzeugen, aber für kleine Projekte ist die zentrale Versionsverwaltung ok, da dass erstellen von Branches nicht so oft vorkommt. Sollte ich mal wieder eine Versionsverwaltung aufsetzen, dann würde ich GitHub definitiv mal ausprobieren und bei gefallen nutzen. Ich denke bei sowas braucht man einfach die Praxiserfahrung um zu sehen ob es mehr oder weniger Aufwand ist.

Zum Prototypen: Ich selbst benutze immer Prototyping bei der Entwicklung. Meist sind es funktionale Prototypen von Modulen (experimentelles Prototyping), ab und an aber auch horizontales Prototyping, um zum Beispiel Kunden zu zeigen wie das Ergebnis aussehen könnte. So verhindere ich früh, dass ich in eine falsche Richtung entwickle.
Das Projekt selber wird aber immer mit evolutionären Prototypen entwickelt. Bei mir kommen so immer stabile Produkte bei raus, bei denen die Fehlerquote sehr gering ist, da Fehler früh auffallen und leicht (kostengünstig) behoben werden können. Man hat auch immer etwas, dass man dem Chef zeigen können. Fortschritt der nicht sichtbar ist, kann man dem Chef schwer erklären, wenn er mit dem Quellcode nichts anfangen kann. Bei Spielen ist das natürlich auch der Fall.
Ich bin mir nicht ganz sicher, aber ich würde sagen, dass Overgrowth von Wolfire auch in diese Kategorie fällt.