[Widelands-public] Am back

[<Si...@gm...>]

sooodela,

ich bin also aus dem urlaub wieder da. aber ich war gar nicht faul und
deshalb gebe ich einen kurzen statusbericht.

Story
-----
Mein bruder und ich haben uns gechilled am strand eine story ausgedacht,
die in etwa dem realismus/zauber kontingent entspricht, dass S2 auch
hatte. Die frage ist, inwiefern ihr sie gut findet oder schlecht.
Also: die story spielt zur zeit des roemischen germanen feldzuges. die
germanen schlagen am anfang ihr lager am rander der roemischen provinzen
auf und man wird als spieler losgeschickt, diese stellungen zu
verstarken und die germanen, bei einem eventuellen feindlichen akt
zurueckzu schlagen. (erste mission: aufbau, erklaerung vom siedeln
usw.). Im laufe der geschichte erweisen sich die germanen als staerkere
gegener als zuerst vermutet aufgrund ihrerer schamanen, die ueber wissen
und techniken verfuegen, die die waffen haerter, die schilde staerker
usw machen. im laufe des spieles wird erst klar, dass die schamanen
keine native-germanen sind, dann, dass sie von dem sagenumwogenen volk
der atlanteiden abstammen. Der Senat in rom schickt den spieler
daraufhin los, Atlantis zu finden und nach etwas zu suchen, dass sich
'Goetterblut' nennt, von dem keiner weiss, was genau es ist, aber dass
es das ist, was die schamenen fuer ihre tricksereien verwenden.
Also kommt dort unser drittes volk ins spiel: die atlanteiden. Eine
Aristokratier, mit monarchischer spitze (die koenigin), die laufenden in
irgendwelchen clinches miteinander stehen.
Also: das ist ganz grob die story, 3 voelker (atlanteiden, roemer,
germanen), 3 missionen (irgendwann) von jedem volk eine, die zeitlich
aneinander anschliessen (wie starcraft). wir haben die storyline ein
wenig weiter gedacht, aber wenn ihr damit einverstanden seid, dann bauen
mein bruder und ich die geschichte weiter und spezifizieren missionen
und gebauede, so dass, wenn ich die ersten missionen release, ihr auch
spass am spielen habt, weil ihr die story noch nicht kennt 8). wenn ihr
das nicht wollt, halte ich praeziser aufm laufenden.

folgende probleme hab ich noch durchgedacht in den ferien:

AI
---
Da jedes volk eine voellig andere wirtschaft haben wird (bsp: die roemer
faellen baeume und hauen steine, waeren die atlanteiden lehm aus dem
boden holen und die germanen brennen ziegel aus lehm und wasser) muss
die AI entweder sehr, sehr gut und flexibel sein (das ist unmoeglich!
das wuerde bedeuten, dass das spiel komplexe zusammenhaenge erkennt und
aufloest), oder aber, dass die AI fuer jedes volk neu geschrieben werden
muss, oder, dass die AI selber 'programmierbar' ist. die zweite loesung
ist die einzig sinnvolle. das heist aber auch, dass es hoellisch schwer
ist, weitere voelker hinzuzufuegen.

Resourcen
---------
Mal angenommen, wir machen diese roemer-story, irgenwann fuegen wir ein
viertes volk hinzu, dass dann aber eine weitere resource benoetigt.
nachteil: die alten und die neuen voelker koennen nur auf voellig neuen
karten zusammen spielen, die karten vom 'orginalspiel' sind dann nicht
spielbar. ich sehe keinen guten weg, diesen konflikt sinnvoll
aufzuloesen ohne dass das neue volk auf alten karten im nachteil ist,
weil eben der rohstoff fehlt. hat jemand eine idee?

Science
-------
Science muss in das erste release, finde ich inzwischen. das gibt dem
spiel so ungleich viel mehr facetten.
Ich denke, sie wird dann aehnlich gescripted wie die haueser (siehe
unten)

Kategorisierung der haeuser
---------------------------
Die haueser typen sind gerade eingeteil nach sit, dig, search usw. das
finde ich inzwischen unpraktisch. ich denke, dass man das umgehen kann,
in dem man die arbeitsbeschreibungen der haeuser scriptet. man brauchte
verschiedene key woerter, aber man waere sehr flexibel (ausserdem waere
es zum beispiel moeglich, dass beim baumfaeller gleichzeitig auch
geschnitzte statuen bestellt werden koennten (mischung aus sit und
search building). ich stelle mir das etwa so vor:
  job_descr_1 {
     wait_order
     search tree         # finde baum, latsch hin
     work                # baumfell aktion
     gohome              # heimlatschen
     wait 15             # bissle warten
     housework           # haus animiert --> arbeit
     wait 120            
     houseidle           # arbeit getan
     produce ware12      # oder 'produce ware geschnitzter_baum'
                         # oder 'produce bob world schaf'
                         # oder 'produce bob tribe esel'
  } # end job1
ausserdem ist es sinnvoll fuer karten bobs obergruppen zu definieren:
bsp, tree1, tree2, usw sind alles baueme. der vorteil: eine neue karte,
die nur 6 verschiedene baeume definiert ist weiterhin spielbar, weil der
baumfaeller nicht nach tree1-tree99 sucht.

Updaten
-------
Wir waren uns ja einig, dass wir science wollen. Nun ist aber noch die
frage was wir wollen, mit gebaeuden:
wir erforschen den verbesserten baumfaeller. nun ist es unbeding
sinnvoll, dass alle alten baumfaeller zu verbesserten werden, die frage
ist nur, inwiefern geht das vor sich. macht es klick und die alten sind
neue, oder bleiben die gebauten was sie sind oder kann man nur noch neue
bauen, die alten aber aufruesten. ich mag das letzte am liebsten, das
mit dem aufruesten, aber das gibt dem ganzen einen starcraft geschmack
(kriecherkolonie --> tiefenkolonie oder so). aber ich faende es ziemlich
cool, wenn man an der grenze eine festung bauen kann und die dann bei
droohender gefaehr zum kastell und dann zur trutzburg ausbauen koennte.
Das waere relativ einfach zu implementieren, ich mag es, aber was
haltet ihr davon?


Uff. ich glaube, jetzt hab ich alles erwaehnt. aber sicher bin ich mir
nicht, wenn mir noch was einfaellt sage ich bescheid. bin gespannt auf
euere komments.

Ach ja: hier am schluss noch mal ein grosses hut-ab an die mortz arbeit
mit homepage und releases, Nicolai. das ist denk ich ein grosser schritt
in die richtige richtung.
und noch was: ich bin dafuer, dass wir die autotools kicken und lieber
unsere eigenen Makefiles schreiben. fuer libs usw. macht man dann im
master Makefile eine var: is_edited=no, der user muss das Makefile
checken und die angaben kontrollieren und dann die var auf yes setzen,
erst dann compiled widelands.


Soo, jetzt mal fruehstueck. 
Holger