Was ist Projektmanagement ?

  • Wozu braucht man Projektmanagement,
    schließlich will man doch nur ein spaßiges Spiel und Programmierer scheinen zwar gerne unverständliche Fachbegriffe zu verwenden aber dafür alles "locker" machen zu können ???


    ZEIT


    Was ? Wieso ?


    Ganz einfach, die Entwicklung, der Rechner, der Spieler - alle brauchen immer mehr Zeit als zur Verfügung steht.
    Ein Projekt ist daher zwangsläufig immer ein schmerzhafter Kompromis,
    um das umsetzen zu können, was zeitlich überhaupt realisierbar ist.


    Denn diie Programmierer kriegen bei jedem Projekt schon nach kurzer Zeit Erinnerungslücken ( "ich hab nie was von locker gesagt") und die Nutzer jammern regelmäßig darüber, dass ihre Vorgaben entweder 1 zu 1 umgesetzt wurden ( "warum hat das vorher keiner gesagt ? so macht das abe rkeinen Spaß! ") oder dass die Luftschlösser fröhlich geplatzt sind.


    Aha und nun ?
    Daher braucht ein Projekt einen Zeitplan ( auch wer denn sowieso nie eingehalten wird ) und ein Gesamt - Konzept das auf Realisierbarkeit abgeklopft ist.
    Und dort regiert der bittere Rotstift.
    Außerdem braucht es einen Projektleiter, der die Beteiligten ständig mit Zeitplan, Koordination und Rotstift - Gebrauch quält ;)


    Och meno, was ist denn nun realisierbar ?


    Der Feind der Realisierbarkeit ist siehe oben die ZEIT :


    Entwicklungszeit
    Das reine Schreiben des Programmcodes ist eher harmlos,
    viel schwieriger ist es vorher zu überlegen, was man eigentlich schreiben muss,
    damit der Rechner auch das Gewünschte tut.
    Die dumme Blechbüchse braucht nämlich alles haargenau als Schritt - für - Schritt - Anweisung, und ignoriert alles, was jeder Mensch als selbstverständlich voraussetzt.


    Testzeit
    Je komplizierter die Berechnungen, je vielfältiger die Aktionsmöglichkeiten, desto nerven - und zeitraubender wird es zwangsläufig auftretende Fehler und Balancingprobleme zu finden und in den Griff zu bekommen ( wo reagiert die Blechbüchse auf welche Schritt - Anweisung welches Programmierers nicht, wie es dieser erwartet hat ? )


    Rechenzeit
    Auch 3 GHz - CPUs und GB RAM kann man durch Anzahl und Komplexität der Berechnungen und Daten locker in die Knie zwingen.


    Übertragungszeit
    Im Mehrspieler - Modus brauchen die Daten übers Netz eine gewisse Zeit zum Server,
    kritisch wird es sobald mehrere Beteiligte beschränkte Ressourcen zum selben Zeitpunkt nutzen wollen ( z.B. kaufen, Schiff angreifen), aber nur einer diese kriegen darf ( Ware weg, Schiff bereits versenkt ).
    Wenn das nicht alle beteiligten Rechner rechtzeitig mitkriegen und abfangen,
    hagelt es Synchronisationsprobleme ( zuviel bezahlt, Absturz da Schiff gar nicht mehr da ...)


    Bedienzeit
    Auch der Spieler hat hinterher nicht Zeit sich ständig um jeden Kleinkram zu kümmern ( wie z.B. die berüchtigte Autorouten - Pause ;) ) ,
    er hat auch keine Lust mit 20 Konvois eifrig manuell zu handeln,
    seine 100 Schiffe manuell zu reparieren
    oder irgendwelchen Festgästen umständlich was zum Fressen und Saufen zu besorgen.


    Ständig sich wiederholende Mini - Aktionen werden schnell langweilig und sind dann nur noch Zeitfresser.



    Und wie erkennt man als Laie, ob ein Feature realisierbar sein könnte ?


    Das ist schwer zu sagen,
    aber die Abwägung
    " wirkt es sich spürbar aus und bringt deutlich mehr Spaß ?"
    gegen
    "kann der Spieler das zeitlich schaffen und was braucht man im Programm alles dafür ?"
    reicht für eine erste Einschätzung aus.



    Wie könnte ein Projektplan aussehen ?


    I Technik und Beteiligte abklären


    II Aufteilung des Projekts in Abschnitte, Diskussion & Abstimmung über Ideen zu diesen,
    --> Grobkonzept für jeden Abschnitt ( realisierbare Features)


    III Entwurf eines detaillierten Konzepts für den Abschnitt
    IV Erstellen von Klassen- / Datenmodell, Auswahl von Algorithmen, Grafiklayout
    V Programmierung
    VI Test des Moduls


    Die Phasen III - VI wiederholen sich für jeden Abschnitt, einiges geht auch parrallel


    VII Gesamttest & Balancing


    als Arbeitsabschnitte bieten sich an:
    1. Seekartensicht
    2. Konvoi - Bewegungen
    3. Konvoi - Logik und Aktionen
    4. Stadtkartensicht
    5. Baumodus
    6. Produktion
    7. Wohnen & Stadt
    8. Lager & Nachfrage
    9. Handelssystem
    10. Aktionsgebäude, Ereignisse
    11. Aufstieg, Familie ...
    12. Politik
    13. Seeschlachten
    14. Belagerungen, Diplomatie & Co
    15. MM - Handel etc.


    Ohne die Grundfunktionen kann man die darauf aufbauenden Bereiche nur sehr grob diskutieren, da die Umsetzbarkeit i.d. Regel von diesen abhängt.
    Außerdem kann man später besser beurteilen, wieviel Zeit man für Extras noch hat bzw. diese recht einfach als Zusatzmodul nachliefern ...
    ( ist wie beim Hausbau vom Keller bis zur Innenausstattung :D )

  • Salve,


    I.
    -Die Beteiligten sind soweit geklärt.
    -Als Programmiersprache für das Spiel hat sich C++ herauskristallisiert.

  • Das wird die Pascal / Delphi - Fraktion sicher mit Beifall aufnehmen ;)


    Nach eurer Liste bevorzugen Sephral und Brasilliero das nämlich,
    Snoosy ist C++ - Anfänger ( wird dann wohl eher engagiert Fleißaufgaben übernehmen)
    und Adalbertus scheint nach der Linux - Diskussion abgetaucht zu sein,
    bleibt Seebär der keine Präferenz zwischen C++ und Delphi angegeben hat.


    3 erfahrene Programmierer und 1 Grafiker sind aber für ein Spiel leider zuwenig,
    selbst wenn man sich auf minimale Features ( kein erweiterter P 2 - Nachbau) konzentrieren und Fleißarbeiten durch Helfer erledigen lassen sollte.
    Das würde nicht mal mit langsam-bequemen modernen Sprachen wie C#, Java oder PHP reichen,
    erst recht nicht mit Pascal oder C++.


    Zumal sich eigentlich keiner richtig der Probleme und des Aufwands eines (Fan)projekts bewusst zu sein scheint:

    • Borlands und Microsofts Werkzeuge sind für solche Aktivitäten nicht gratis (und die "kopieren doch alle, merkt doch keiner" - Tour zieht hier nicht),
      also gilt es erstmal eine gemeinsame Programmierumgebung zu finden.


    • Man braucht ein durchdachtes, realisierbares Konzept - schließlich sind auch kommerzielle Spiele nicht so wie sie sind, weil die Entwickler keine besseren Ideen hätten, sondern weil diese oft nicht umsetzbar sind.


    • Ein Projekt - Alltag besteht nicht aus dem Ersinnen immer weiterer cooler Features (Schiffsbaukasten, wird bestimmt genial),
      sondern aus so uncoolen Dingen wie welche Auflösung nehmen wir überhaupt, wie sieht das Interface aus,
      warum schaffen die Proggis es nicht, dieses an 2 Tagen fertig zu kriegen ? und warum finden die Tester es plötzlich doof ? ...
  • Zitat

    Original von Galilei
    .. bleibt Seebär der keine Präferenz zwischen C++ und Delphi angegeben hat.


    Also ich bevorzuge C++. Vor ein paar Jahren habe ich mal in Delphi programmiert (Delphi 2.0).
    Deshalb müßte ich mich da erstmal wieder reinarbeiten.


    Aber irgendwie finde ich C++ cooler - Aber ich möchte hier keine Grundsatzdiskussion anfangen welche Sprache besser ist C++ oder Delphi/Pascal.

  • C++, Delphi, C#, Java, VBasic, PHP ...
    hat alles eigene Vor- und Nachteile.


    Mit der derzeitigen Personalstärke bleiben eigentlich nur C# und Java,
    mit 3 Mann hat man keine Zeit sich um Standardkram wie z.B. Listen oder Objektverwaltung zu kümmern,
    schon gar nicht ein eigenes Speichersystem zu basteln ( bei Seekartenalternative 1 muss man die Positionen, Routen etc. unbedingt in Objekten sichern, SQL ist für Echtzeit bei hunderten Schiffen auf einem Standard - PC gnadenlos überfordert - der Transfer Echtzeit - Objekt -> SQL - Spielstand kein Zuckerschlecken und auch in einer Textdatei kriegt man die ganzen Zahlen nicht sauber unter)


    Die haben aber den Nachteil, doch ordentlich Performance zu schlucken,
    nehmen aber viel Routine - Arbeit ( komplettes Objekt auf Platte schreiben, Standard - Datenstrukturen,
    Arbeiten mit Objekten) ab.

  • Wie wäre es damit zu beginnen, gemeinsam einen Projektplan aufzustellen? Der Plan im Beitrag von Galilei ist schon gut, aber wir müssen einen Weg finden, wie wir ihn weiter aufbauen und dabei die Übersicht wahren können.


    Wir brauchen ein zentrales Dokument (z.B. eine Homepage mit Zugangsbeschränkung), in dem wir erstmal Ideen sammeln, sie strukturieren und dann Zeiten und Aufgaben zuordnen können. Das hätte den Vorteil, dass der aktuelle Status immer für alle verfügbar ist und wir so auch zusammen ein richtig gutes Gesamtkonzept erarbeiten können.
    Ich halte es für schwierig, das hier im Forum zu leisten. Für das Zusammentragen von Ideen ist es völlig OK, aber für Strukturierung und Planung ist es einfach nicht gemacht, da wird man schnell an Grenzen stoßen.


    Solange wir kein gutes und schlüssiges Spielkonzept haben, dass die Frage "Was macht P III noch besser als P2?" zur allgemeinen Zufriedenheit beantwortet, brauchen wir uns auch nicht darüber unterhalten, ob wir in C++, Java oder Amiga Basic programmieren. Sorry, wenn das jetzt etwas hart klingt.

  • Salve,


    ich versuche, für die HP da was ordentliches hinzubekommen. Wenn jemand zufällig ein PHP-Wiki hat, wäre das sehr gut. Ansonsten sollte eine HP mit Code-austausch etc. spätestens nach den sächs. Sommerferien stehen. Was wir nach außenhin machen, müssen wir nochmal bereden, ich hatte diesbezüglich schonmal mit Galilei gesprochen.


    Ich hoffe, dass ich in den nächsten Wochen zumindest erstmal das LogIn-Fenster präsentieren kann. Webspace habe ich dann auch erstmal genug.


    Vale RF