Re: [Widelands-public] Am back

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

> > Story
> > -----
> [snip]
> Hmm, das gefaellt mir :) Ganz so krass unterschiedlich wie bei StarCraft 
> werden die Voelker zwar wahrscheinlich nicht ausfallen, aber das ist nicht 
> unbedingt ein Nachteil.
mmh, wir haben viel spielraum, die voelker werden auch ziemlich
unterschiedlich werden. wir sind schon ziemlich kreativ

> Was das auf-dem-laufenden halten angeht: zumindest die Technologien werden 
> wir ja sowieso sehen... immerhin ist es ein weiter Schritt bis zum ersten 
> komplett bis zum Ende gespielten Spiel mit KI und so.
klar, aber die storyline koennt ihr selber entdecken 8)

> 
> > AI
> > ---
> Um ehrlich zu sein bin ich der Ansicht, dass die AI sowieso sehr, sehr gut 
> und flexibel sein muss ;)
klar, das ist keine alchemie: je klueger, desto besser. Aber, AI ist
kein triviales thema und eine DERMASSEN komplexe Ai ist hart.
> Mich nervt das dermassen bei den meisten Strategiespielen, dass die AI nicht 
> flexibel reagieren kann. Gutes Beispiel ist da S2 selbst: auf der Karte "Im 
> Gebirge" gibt es keinen Bob-Granit (nur Granit fuer Bergwerke). Da die 
> Computerspieler die Verbrauchsprioritaeten der Bergwerke nicht umstellen 
> laeuft das darauf hinaus, dass sie irgendwann kein Stein mehr haben - 
> besonders wenn sie keine Jagdhuette bauen und zu spaet anfangen, andere 
> Nahrungsquellen aufzuschliessen (Bauernhoefe...).
stimmt, das ist laestig, auch, dass die AI sich auf der gleichen karte
jedesmal vergleichbar verhaellt ist laestig. aber wie gesagt, AI ist
schwer
> Solche Zusammenhaenge _muss_ die AI einfach erkennen. Und wenn sie das kann 
> duerften auch die verschiedenen Voelker nicht mehr soo das Problem sein.
nun, wenn du meinst. lassen wir das auf uns zu kommen. aber ich denke,
dass trotzdem die voelker zumindest einen teil (vielleicht eine art
kommando system) an die AI weitergeben muss. eine art simpleste
programmierung oder so

> 
> > Resourcen
> > ---------
> 1. Frueh genug brainstormen und soviele Resourcentypen wie moeglich 
> aufzaehlen. Evtl. kann man das neue, vierte Volk dann einfach aus einer 
> neuen Kombination von Resourcen zusammensetzen.
mmh, angedacht war, dass wir ca. 8 rohstoffe haben. jedes volk benutzt
davon 7 und kann man dem letzten nicht handeln. wenn wir geschickt sind,
bleiben guenstige kombinationen uebrig...

> > 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)
> 
> Das wirft die Frage auf, ob wir ueberhaupt irgendwann sagen: Okay, jetzt ist 
> Widelands fertig. ;)
wann ist software schonmal fertig 8)
> Da wir ohnehin vom ersten bis zum Ende gespielten Spiel noch eine ganze 
> Weile weg sind kommen eh nur unstable builds in Frage.
joh, aber ich meine damit, dass ich es doch nicht auf eis liegen lassen
will, wie ich zuerst vor hatte, sondern es in die tribes implementieren
moechte.

> 
> > 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
> 
> Hoert sich nicht schlecht an. Das koennte sogar recht gut mit den Tasks im 
> Map_Object-Code zusammenarbeiten. 
das war auch meine idee. die key woerter aus der job descr koennte fuer
das act-cmd jeweils ein argument haben, so dass die key woerter einzeln
implementiert sind. es waere dann leicht, eine neue aktion (_Bau
schiff_) hinzu zu fuegen.

> Vielleicht waere es sinnvoll, den Job in Arbeiter- und Haus-bezogene Teile aufzuteilen.
das finde ich nicht so schrecklich gut, da, sobald der worker im haus
ist, die beiden eine logische einheit bieten
> 
<snip>
Nicolai, deine beispiele finde ich kryptischer als meine, auch kommen
sie mir nicht so flexibel vor. wir muessen etwas in der komplexitaet dazischen finden.
> "notice" schickt eine Notiz an den Spieler, zunaechst nur als Code. Der 
> UI-Code macht dann, falls angebracht, aus diesem Code eine Nachricht fuers 
> Nachrichtenfenster.
> Die notice beim Foerster waere fuer einen Spieler vielleicht uninteressant, 
> aber fuer die AI ist sie auf jeden Fall wichtig.
ja, das muss rein

> 
> Allerdings ist das Beispiel oben nicht wirklich im Sinne von Siedler 2: bei 
> Siedler 2 gaebe es dann den normalen Holzfaeller, und einen Schnitzer, der 
> aus Baumstaemmen das geschnitzte Zeug macht...
ja, in siedler2 sind die haeuser strickt in typen geteilt, dass war auch
der grund warum ich zuerst diese einteilung gewaehlt hatte. aber
eigentlich spricht nichts dagegen, alles zusammen zu schmeissen und mir
gefaellt auch diese idee: man erforscht die schnitzkunst, danach kann
man den holzfaeller zum schnitzer ausbauen, der dann weiterhin baeume
faellt (oder nicht, mal sehen), aber auf bestellung sowohl bug-figuren
fuer schiffe wie holzidole fuer kirchen machen kann. oder so

> 
> > 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.
> 
> Das koennte jetzt schon mit Hilfe der Attribute gemacht werden. Man 
> braeuchte nur noch einen Manager, der automatisch aus Strings Attribut-IDs 
> macht (auf der Bais von std::map).
man kommt aber trotzdem nicht drum run, ein weiteres keyword bei den
diminishings einzubauen, i guess

> 
> > Updaten
> > -------
> Ich mag es auch, weil's einfach mehr zu der Oekonomie von Siedler 2 passt. 
> Genauso wie die Waren nicht sofort am Zielort sind sollten auch die 
> Verbesserungen nicht sofort am Zielort sein.
oki, dann sind wir uns wohl einig

> Jajajajajajajajaaaaaa! Weg mit den Autotools und wir sind alle gluecklicher 
> =)
> Apropos make und so: http://aegis.sourceforge.net/auug97.pdf ist ganz 
> interessant was make angeht.
k, dann les ich das mal und mach mich dran, die autotools zu kicken.

cya
Holger