Patrizierforum

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 )

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 ? ...
  

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.