Re: [Widelands-public] Am back

[Nicolai H. <pre...@gm...>]

On Friday 30 August 2002 13:25, Si...@gm... wrote:
> sooodela,
>
> ich bin also aus dem urlaub wieder da. aber ich war gar nicht faul und
> deshalb gebe ich einen kurzen statusbericht.

Willkommen zurueck :)

> 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.
[snip]
> 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.

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

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

Um ehrlich zu sein bin ich der Ansicht, dass die AI sowieso sehr, sehr gut 
und flexibel sein muss ;)
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...).
Solche Zusammenhaenge _muss_ die AI einfach erkennen. Und wenn sie das kann 
duerften auch die verschiedenen Voelker nicht mehr soo das Problem sein.

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

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.

2. Alte Karten updaten - etwas anderes bleibt uns nicht 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. ;)
Da wir ohnehin vom ersten bis zum Ende gespielten Spiel noch eine ganze 
Weile weg sind kommen eh nur unstable builds in Frage.

> 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. Vielleicht waere es sinnvoll, den Job in 
Arbeiter- und Haus-bezogene Teile aufzuteilen.

#######
worker holzfaeller; // fuer grafiken und so

job schnitzen {
	worker {
		// Sammle von einem <tree> im Radius 8 die Ware Holz ein.
		harvest bob tree for ware wood radius 8;
		return home; // bring die getragene ware ins haus zurueck
	}
	fail {
		notice no-nearby-object(tree); // nachricht an spieler
		break; // ende der fahnenstange
	};

	wait 15; // warten
	animate <animations-name>; // animiere gebaeude
	wait 120;
	produce ware geschnitzter_baum;
	wait 15; // cool-down-phase bis zum naechste arbeiten
};

job holzhacken {
	worker {
		harvest bob tree for wood radius 8;
		return flag; // bringe die getragene ware zur flagge
	}
	fail {
		notice no-nearby-object(tree); // nachricht an spieler
		break;
	}

	wait 15; // cool-down-phase
};
#######

#######
worker forester;

job plant {
	worker {
		plant bob tree radius 8;
		// Alternativ:
		//plant bob [tree1,tree2,tree3,tree4] radius 8;
		return;
	}
	fail {
		notice no-space-for(tree); // nachricht an spieler
		break;
	}

	wait 15; // cool-down-phase
};
########

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

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

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

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

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.

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

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.

cu,
Nicolai

> Soo, jetzt mal fruehstueck.
> Holger