Patrizierforum

Ich würde gerne auch bei der Technik mithelfen, hab aber - wie wahrscheinlich die Mehrheit hier - keine Ahnung von den Feinheiten der Programmiersprachen.

Es gibt doch sicher eine ganze Menge "Fleißarbeiten" zu erledigen, die mit ein paar erklärenden Worten und vielleicht einem Standardprogramm abgearbeitet werden können. Ich denke da ganz laienhaft in etwa "hier sind die Grafikdateien von allen Städten, öffne die mit Paint / Photoshop / ... und setze mit Copy und Paste da Bäume rein" oder "Kann mal jemand eine Excel-Liste mit allen Warenpreisen für alle Städte zusammenstellen" oder oder oder.

Wir haben bisher nur fünf Aktive, die sich aufs Programmieren verstehen! Macht euch schon mal Gedanken, wie ihr uns andere einspannen könnt, ihr müsst nicht ALLES alleine stemmen.

Hey mit sowas hätte ich nie gerechnet ich weiss jetzt schon dass ich das neue spiel wenn es denn soweit kommt lieben werde zumal ich auch p2 über alles liebe.

Also hier mein Vorschlag ich will euch auf jeden Fall unterstützen...
1. Ich will auf jeden Fall Tester sein wenn das drin ist Fehler finde ich schnell versprochen und
2. viel wichtiger ist ich mache viel Musik und schreibe sie vor allem selbst und ich würde es als riesen Herausforderung sehen für euer bzw. unser neues Spiel die Musik zu schreiben... in diesem Sinne kommt euer Projekt eigentlich wie gerufen für mich also wenn ihr noch keinen habt sagt mir bescheid und ich komponiere die ersten Stücke sobald ich die ersten auszüge aus dem Spiel habe ich brauche natürlich inspirationen also Bilder Story usw. und natürlich Zeit aber ich würde mich auf jeden Fall bereit erklären mich daran zu versuchen.
Bitte um Rückmeldung...

Also haut rein leute ich bin dabei

@Mighty

Das ist ja suuper. Jetzt noch ein echter Grafiker und dann ganz wirklich richtig losgehen

Zitat

Original von Jo
... und meine selbstgezeichneten Grafiken sind eher lächerlich.

Hallo Jo,
wieso lächerlich - zeichnest Du nur Strichmänchen

Spaß beiseite - Stell doch mal Deine "Entwürfe" ins Netz.

Hallo zusammen,

ich kann Euch auch unterstützen wenn gewünscht.

Meine Stärken:

Erstellen und zusammenschnipseln von Sounddateien.
Grafikerstellung ( profi ) mit Corel Draw 12. Grafikanimationen sind möglich muß ich mir dann aber noch genau "beibringen" weil selten gemacht.

Texte verfassen im mittelalterlichen Stil
Betatesting u Feedback



Programiersprachen kann ich leider keine.

viele Grüße aus Hannover
Frank

@Jo und Frank,

Euere talente können wir sehr gut gebrauchen.

Hallo Frank,

ich kann mich da nur Brasileiro anschließen.
Ein Grafilker/Sounder können wir wirklich gut gebrauchen

würde mal vorschlagen, so langsam mit dem Projekt "III" zu beginnen:

1. Stufe wird so oder so die Seekartenansicht werden, da der Rest ohne nicht läuft, umgekehrt aber schon.

Dazu bräuchten wir unabhängig von Programmierumgebung und Betriebssystem:

Konzeptautor
Sammelt Ideen aus dem Forum, versucht sie in einen realisierbaren Gesamtsinn zu bringen
und erstellt daraus für die Programmierer ein grobes Objektmodell mit den wichtigsten Daten und Algorithmen.

Programmierung: Datenmanipulationen Interesse: Seebär
Attribute und Methoden (anschaulich: Objekt "Schiff" bewegt sich von Position x zu y") erstellen,
dazu gehören u.a. Listen und einfache Berechnungen wie z.B. Abnutzung
Programmierung:Algorithmen
Schwerpunkt: Wegfindung der Schiffe, KI - Verhalten

Programmierung: Netzwerk
zuständig für synchronen Client & Server - Transfer, insbesondere Abfangen möglicher Probleme ( "Schiff schon versenkt", "Schiff längst woanders")

Programmierung: Interface
kümmert sich um Auswertung der Nutzeraktionen, Anzeige von Information, aufrufen entsprechender Objekte & Methoden ( Scrollen, Mausauswertung, Menüs, sichtbare Informationen)

Grafiker
müsste ein schickes Interface designen, eine ordentliche Seekarte ( nicht animiert, aber korrekte Landmassen) und Platzhalter - Grafiken für Schiffe etc.

Fleißarbeit: Geographie Interesse: Mercator
Bei Seekarten - Alternative 1 Land - und Seepixel der Karte zusammenstellen oder bei Alternative 2 Wetter - Daten für den Zufallsgenerator erstellen, Wegknotennetz basteln
Fleißarbeit: Karte füllen
Startsituation generieren: KI - Konvois, Städte etc. , d.h. hunderte Objekt - Instanzen mit ihren Parametern füllen

Testleitung
Tester motivieren, anleiten was ausprobiert werden soll,
Feedback sammeln und in brauchbarer Form an den zuständigen Programmierer weiterleiten,
besonders wichtig: aufs Balancing achten
Tester
Das Seekartenmodul ausprobieren,
wann und nach welchen Aktionen bleibt das Programm hängen ? verhält sich die KI zu doof ? ist das Interface intuitiv und bequem ?
Balancing: welches Verhalten ist eine Goldgrube ? - welches ist derzeit nicht lukrativ ?
{ Warnung: Man sollte sich das Testen einer so frühen Modulversion nicht als spaßiges Gratis - Spielen vorstellen,
sondern als harte Arbeit, da vieles noch nicht funktioniert !}

Koordinator RF
hier im Forum oder auf einer Webseite immer den aktuellsten Projektstand vorhalten,
Teammitglieder mit den neuesten Versionen versorgen, Termine koordinieren

nach außen:
weitere Programmierer, Grafiker etc. anwerben
Projekt nach außen darstellen ( Stand & Ziele), Tester anlocken ...


Dazu wäre es nett,
wenn sich alle noch mal melden,
welchen Bereich sie übernehmen könnten:
( bitte nur melden, wenn man auch dazu motiviert ist, es ernsthaft in den nächsten mühevollen Monaten durchzuziehen, und die dafür nötige Zeit zur Verfügung hat)

Von den Programmiererern werden zusätzlich die beherrschten Sprachen benötigt,
welche IDE, welcher Compiler, welche Standardbibliotheken ?
Und idealerweise auch Ahnung vom ausgesuchteten Gebiet haben:

• für die Datenmanipulation sollte man schon mal richtig komplizierte Daten auf Platte gespeichert haben und Listen und ähnliche Strukturen sauber erstellen können - sonst müssen wir Java oder C # nehmen
  
• Interface -Interessierte sollten sich mit Menüs & Mausabfragen auskennen, außerdem mitteilen ob sie DirectX können, ober in welchem Format ansonsten Grafiken abzuliefern sind
  
• fürs Netzwerk sollte man sich entsprechend für komplexe Echtzeitsysteme auskennen,
  sondern bleibt es besser ein reines Solospiel
  
• und vor allem wirklich objektorientiert arbeiten, d.h. konsequent alle Daten kapseln und Zugriffe nur über die Methoden zulassen und diese sauber dokumentieren - mit Spaghetti - Code würde noch nicht mal die Seekarte fertig werden
  

gut,
ein Projektpagebereich für die Entwickler wird wohl nötig sein,
da das Verschicken der aktuellen Versionen ( Code, Grafik) an alle per Mailanhang schnell kompliziert werden dürfte,
erst recht wenn man später freiwillige Tester einbinden muss.

Für Seekartenalternative 2 könnte ich das Konzept samt erstes Modell für Objekte und Algorithmen beisteuern.
Für Alternative 1 leider nicht,
da mir dort für die Umsetzung der Wegfindung und die Trennung Land- vs. Wassermasse das KnowHow fehlt.
Schließlich soll ein Konvoi von Danzig nach Brügge den (festen) kürzest möglichen Weg nehmen, ohne durch Dänemark und Norddeutschland zu schrammen, man aber diesen unterwegs aber auch auf jede beliebige Wasserstelle umdirigieren können

Also ich würde mich zur Gruppe Datenmanipulation zugehörig fühlen.
SQL Datenbanken setze ich beruflich ein.
Auf Client/Server Datenbankbasis kenne ich mich mit MySQL aus.

Für das Entwickeln von Objekten könnte ich auch mit UML etwas beitragen

Hauptsächlich benutze ich den Borland C++ Builder 5.0.
Mit MSVC 6.0 habe ich auch etwas Erfahrung.
Der GNU C++ Compiler wäre auch kein Problem.

Pascal/Delphi wäre etwas problematisch da ich in Delphi schon seit ein paar Jahren nicht mehr programmiere.

@ Mercator

sieht derzeit nach C++ aus, dürfte ein ziemlicher Umstieg sein,
aber Hilfe beim Erstellen von Kartenzonen, Konvois, etc. und beim Testen ist aber auch hoch willkommen.

@ Seebär
wunderbar,
müssten dann das Spielkonzept etwas datenbank-tauglicher als P2 machen,
aber das sollte machbar sein.

C++ ist okay,
müssten aber wohl aus rechtlichen Gründen den GNU nehmen,
der ist wie MySQL frei,
oder erlaubt Borland eine "nicht-kommerzielle" statt "privater/ persönlicher" Nutzung ?
Nicht das den Beteiligten mit steigender Bekanntheit teure Post vom Anwalt ins Haus flattert.

Ja bei Access kann man auch "SQL" - Abfragen verwenden,
bei großen Datenbanken sind die aber etwas mächtiger und kniffliger.

Aber letztlich läuft das ähnlich wie bei Access,
Kartenstücke, Schiffe, Betriebe, ... landen alle in einer Datenbank,
und per SQL sucht man sich dann z.B. alle Brauerein von Spieler x in Stadt y raus,
oder alle Schiffe in Zone z, um Sichtweite oder Piratenangriffe zu berechnen.

bei C++ ist vor allem die Objektorientierung wichtig,
ohne deren saubere Anwendung werden größere Projekte zur Hölle bei der Fehlersuche.

Hallo zusammen!


Ich finde es klasse, dass sich aus dieser Community heraus die Initiative für die Weiterentwicklung von P2 gebildet hat! Es ist ein geniales Spiel, dass unbedingt fortgesetzt werden sollte, da sind wir uns sicher einig. Nachvollziehbar ist, dass Ascaron dies (zumindest derzeit) nicht leisten kann, da sie als Firma natürlich stark am Markt orientiert arbeiten müssen und da ist das Eis derzeit verdammt dünn. Der große Vorteil von P3 als User-Projekt ist ja gerade, dass es ein "Herzensangelegenheit" sein kann, ohne irgendwelchen kommerziellen Erwartungen gerecht werden zu müssen.

Auch wenn ich neu hier bin und auch niemanden bremsen möchte, so würde ich doch gerne ein paar eigene Erfahrungen zum Thema Spieleprogrammierung loswerden. Ich habe früher (als es noch DOS und Win 3.1 gab ) selber ein paar Spiele (sowohl alleine auch als in einer kleinen Gruppe) in C++ und Assembler programmiert (oder wir haben es zumindest versucht). Dabei habe sich einige Dinge als absolute Show-Stopper herausgestellt, die ich hier auch teilweise wieder aufleuchten sehe:

1.) Das Design und die Spieleidee ist das absolut Wichtigste!!! Man kann gar nicht genug Zeit in ein vernünftiges Konzept stecken! Was macht das Spiel interessant, was motiviert, was macht P3 besser, interessanter und überhaupt viel doller als P2?
Es wurden ja schon einige gute Ideen zusammen getragen, aber sie müssen zusammen auch ein gutes und stimmiges Konzept bilden. Dieses Konzept muss gut ausgearbeitet sein und bereits eine gewisse Tiefe haben, auch wenn sich später noch Details ändern können. Aber es sollten sich dann auch wirklich nur Details ändern und nicht das halbe Konzept, sonst war die Desginphase zu kurz.
Man möchte ja unbedingt loslegen, es juckt in den Fingern, aber ein durchdachtes Konzept erspart Nächte am Computer, tausende Zeilen Code und viel, viel Frustration, die so ein Projekt schließlich auch kippen kann.

2.) Das Programmieren kommt ganz zum Schluss!!! Erst dann, wenn das Konzept steht, alles klar ist und der Code nur noch heruntergeschrieben werden muss. Es ergeben sich dann noch genug Probleme, ganz sicher!
Dass man zu früh mit dem Programmieren angefangen hat merkt man spätestens dann, wenn man wegen unerwarteten Änderungen im Spielkonzept megabyteweise Code löschen kann!

3.) Das Programmieren ist nur ein kleiner (und der letzte) Teil der Arbeit, Design, Grafik (!!!) und Sound erfordern sehr viel mehr Zeit. Wenn die Architektur und die Statik stimmt, müssen die Mauern nur noch hochgezogen werden.

4.) Programmieren sollten nur wenige Leute, d.h. höchstens drei! Ich habe in den Credits eines Spiels noch nie mehr als drei Namen für die Programmierung gelesen. Das liegt daran, dass die meisten Fehler an den Schnittstellen zwischen den Codeblöcken der einzelnen Programmierer (die ja auch einen unterschiedlichen Stil haben) entstehen. Deshalb sind klar definierte Schnittstellen zwischen den Modulen und eine homogene Variablennomenklatur ein absolutes MUSS!!!

Ich möchte hier wirklich niemandem den Spaß verderben! Aber gerade deshalb sollte es nicht so laufen, dass wegen solchen "Klassikern" schließlich die Motivation auf der Strecke bleibt (ihr macht das ja schließlich gratis in eurer Freizeit!), die ersten Leute abspringen und schließlich das Projekt kippt. Dafür ist es zu schade!

Zum Schluss noch zwei ganz heiße Buchtipps, die ich hier jedem ans Herz legen möchte:

Game Architecture and Design (Andrew Rollings, Dave Morris) <-- hiervon gibt es auch eine "New Edition"!
The Indie Game Development Survival Guide (David Michael)

Ich wünsche dem Projekt viel Erfolg!