Topic: Hallo, Build B18!
|
Adamant Topic Opener
Joined: 2012-10-11, 15:21
Posts: 180  Widelands-Forum-Junkie Location: Alemania |
Posted at: 2014-03-03, 06:49
Gratuliere zum neuen Build! Btw jedes Nightly Built stellt ein Build da inclusiv die RCs etc ... Ich schlage vor statt dem PreFix Build stattdessen Release bzw dieses R18 zu nennen was sachlich näher den Tatsachen steht und IMO aus schlichter Player Sicht nur ein weiterer seltsamer Namens-Prefix darstellt. Player als Non-Developer wundert sich nur und ratet vll welche BuchStaben-Suppe die bessere sein müsste - ist so jedenfalls vom mr selbst einmal so praktiziert worden und Ich wusste nur dass State Alpha weniger halbgar is als Beta aber an sonsten hab Ich einfach raufgepackt und wenn ging dann ging und wenn andere Spieler alle eine bestimmte Version bevorzugten (nimmst du diese..) dann hab Ich ebenso diese zunächst als Tip bevorzugt. Ich hab da nit in Gramm sondern Kilo oder Tonnene gemessen und die kleinen Detail Verbesserungen waren mir kein Argument. Zack-rauf-probieren und wenn nit läuft andere testen.. Ein Freund, der viel mehr praktische Ahnung vom programmiern hatte (ich würde jetzt nur noch fremdartige Erfahrungen attestieren) staunte über meinen Approach aus Teilen etwas funzendes zusammen gekloppt zu haben durch schlichtes überkopieren. ICh würd diesen Ansatz heute als Super-Pro-N00b-Methode beschreiben. Soweit meine Idee über die meisten anderen Spieler, welche nicht durch die Meinung der Forum-Nutzer zweifelsfrei wiedergegeben werden kann weil diese meisten Spieler einfach keine Forum-Nutzer sind: Alpha, Beta, RC und R - Erfahrung zeigt dass manche Buchstaben Kombinationen eher häufig gut funzen - was die Developer damit sich gegenseitig erklären wollen ist dagegen wenig für den Spieler praxis-relevant. Der Nightly Built is in soweit leicht verständlich als das etwas völlig halbgares vom ArbeitsTisch gezogen wird und wenn das funzt eigentlich schon eine Überraschung wert - da erwartet man eher nix ohne Erfahrung und erhofft sich nur ein paar super-neue Verbesserungen -- ohne Ahnung dass man diese oft mit der Lupe suchen muss möcht man denken es wurden nur Sachen in KleinArbeit verbessert weil keine Ahnung - eigentlich das gleiche Ding -- vll wurd iwo ein Detail geändert wie ADD statt MUL weil Mul nicht richtig und jetzt geht es richtiger ohne dass man es merk. Keine Ahnung warum dieser Aufwand für solche Details betrieben wird - macht ja vll Sinn aber mir ist dieser aus dieser Perspektive nicht ersichtlich - keine Kritik! Kommt mir aber schon etwas seltsam vor.... nimm die Alpha wenn siehst Alpha und Beta und wenn RC,R und ... Build?!? Keine Ahnung! Die gehen alle eigentlich aber die Beta hat viele Probleme und ist nicht fertig. SO war einmal meine pragmatische Haltung für den ganzen Versions-Kram und keine Site hat mir nur einmal diesen Versions-WirrWarr erklärt - Ich hab einfach die neuesteste Version als pot beste gezogen und hab eigentlich so auch die gewöhnlich beste Wahl getroffen. Aus meiner heutigen Sicht sollt das B18 besseer R18 heissen aber den meisten Usern ist das Latte. Also ... R18 -- lang von mir erwartet, als Ich merkte das Jahr seit dem letzten R ist schon vorüber und die vorhrigen nicht völlig regelmässig benötigten etwa auch ein Jahr. R18 aber nahm grob 2 Jahre in Anspruch - Ich runde die Quartale. ICh hätt mich also sehr freuen wolllen und sollen aber tatsächlich hatte Ich ab und an auch die Nightly Builts genutzt und da war die große Überraschung natürlich schon vorweg genommen --- da kann Ich die Developer wirklich nicht verantwortlich. Das R hat wohl viel Arbeit gekostet und da Ich den Schweiss dahinter nicht direkt sehen kann ist meine Freude über den Erfolg bzw Erreichen dieses MileStones nicht die selbe wie die der Developer - Ich daher sage nur relativ kühl gratuliere und vermute dass diese sich über das R18 wesentlich mehr freuten als Ich der theoretisch noch den letzten NightlyBuilt davor hätte herunter laden können und
dann sind die weiteren Erneuerungen gegen Null -- sorry dass Ich mich nicht so darüber freuen wie Ihr aber Ihr habt wohl mein Verständnis. Der passive Community Teilhaber fragt nur wo DownLoad und der active TeilHaber Super wenn er mitgeschwitzt hat aber normal auch Super wenn er das zu sagen schickt findet .. Ich sage ... ... super! :))) (stimmt wohl aber Ich werfe kein Konfetti aus gespielter Überfreude!) Ich bin aber sehr wohl über das Gedeih des Spiels interessiert und da sehe Ich den normalen (passiven) User in die DownLoadSection gehen und den neuesten Build ziehen und was der bietet ist praktisch für die meisten anderen Spieler der Stand der Dinge und daaa kann Ich wohl positive Dinge berichten. WL als Game ist nit neu - R18 aber als Nachfolger von R17 wohl schon, ein Review beinhaltet quasi ein Update des schon bekannten und bietet dadurch auch kompaktere Informationen für den Spieler. In Sachen UnterStützung der Reviewer - es ist definitiv nicht mein Interesse eine Meinung oder Richtung vvorzugeben abgesehen von einer moderat wohlwollenden Meinung (wäree ja blöde wenn der das Spiel zerreist nur weil er Spiele die mit W anfangen nicht leiden kann - Aim is moderate) und dann hoffen das unter dem Strich ein gutes Review heraus kommt das vor allem durch Korrektheit besticht -- Ich werte den Nutzwert eines unserioösen Reeviews für contra- productive - auch bzw besonders wenn dieser viel zu positiv ausfälllt: wenn damit zu hohe Erwartungen geschürrt werden laden es viel mehr Leute herunter und ein größerer Anteil dieser Leute findet dann das Spiel ka..tastriös und eerzählen dann dieses überall herum und das schreckt Leute vom Spiel ab. --- Dont sell what is not inside the Package! Um die vielen Unterschiede bzw Neuerungen den Reviewern leichter auffindbar zu machen (siehee oben: Ich suchte diese nicht mit der Lupe!!) würd Ich dazu ein Doc schreiben, welche diese genauer erkl ärt -- nach erstem Rating für Player-Relevance bzw Value, damit der Reviewer NACH ersten Spiel-Eindrücken auch diese im Spiel auffinden und als Ursache des neuen Eindrucks heran ziehen kann -- als GegenDarstellung: ist besser aber keine Ahnung warum -- aber diese Feature-List nicht Basis seines Reviews wird -- erst gucken was in List steht um zu wissen ob man das besser findet. Dem Spieler interessieren weniger die technischen Details sondern 1) der SpielSpass und diese vor allem durch 2) die Spiel-Optionen die das Spiel dem Spieler bietet. Look&Feel muss dem individuellen gewohnten bzw gewählten Ansprüchen genügen über den technischen Erfordernissen hinaus - der Spieler MUSS erkennen die grundlegenden Informationen im Spiel erkennen können - darüber hinaus darf es chick sein. Nach meiner Erfahrung ist den reiferen Spielern zugänglich, dass die SpielOptionen für den eigentlichen Lang-Zeit-SpielReiz von größerer Bedeutung sind als der Chick über die Notwendigkeit hinaus -- sonst
könnt ein Bild-Betrachtungs-Programm mit sehr hübschen Bild als Super-Knaller-Spiel Wirbel machen - man erwartet aber von einen guten Spiel ein vergleichbar gutes Aussehen -- in der kommerziellen Game
Industrie versuchte man oft und vergebens schwache Spiel-Konzepte mit MordsGraphic zu kompensieren -- ICh kenne nicht die Investions-Summen aber hinsichtlich Markt-Erfolges blieben diese Spiele alle
auf der Strecke! Wie hiess doch gleich dies eine super-toll aussehende Spiel dass ... na? Ich möcht dazu nüchtern erwähnen dass WideLands seine Community nicht durch Mords-gute Graphic gewonnnen hat. Ich kenne bislang jeoch kein OSS Game das eine bessere Eco bieter als WL! Der Apfel sieht also etwas komisch auch aber er bietet viele NährStoffe. Hinsichtlich Chick hier kurz aufgeführt kann Ich die Ursache für die optisch mangelhafte Attraktivität. Ich hab mich mit den Tecs und den ArtWorks beschäftigt und diese verglichen um die Ursache besser zu verstehen. Insbesondere die Berg-Textures waren mit rätselhaft: sie sehen asl ArtWork sehr gut aus aber im Spiel iwie .. nicht so. Als Ursache stellte Ich fest, dass dieses sehr von den scharfen klar ersichtlichen - auffälligen? - nein, sogar nicht ignorierbaren Feld Übergängen herrührt. An einen anderen Spiel, das mit technisch deutlich weniger leistungsfähigen Mitteln .. platte 2D Grphics aber Berge bzw 3D Morphology optisch unvergleichbar besser rüber kommt konnt Ich einen Teil der Probleme erkennen: Dessen Map ist weder rectangular noch triangular sondern hexangular und daher eigentlich noch deutlich anfälliger als triangular in Hinsicht auf einförmige Gestaltung aber davon abgesehen wurd in diesem Spiel das Problem der scharfeen Feld-ÜberGänge, die Ich schlich Field-Transitions nenne, relativ direkt aber vor allem erfolgreich gelöst: Benachtbarte Felder passen entweder zusammen weil sie gleeichen Terrain Type besitzen oder aber passen nicht zusammen und dann werden spezielle Transition Images an die ÜberGänge geklebt, so dass zB Wiese an Soil, Erdreich, angrenzend eine Art überlappende GrassZunge bekommt, welche sich vor allem durch eine nicht scharfe, also irreguläre SchnittLinie auszeichnet. Das zweite Problem ward mit durch einen Artist erklärt, dass die Texturen zwangsläufig scheitern müssen, weil bei dem ZuSchnitt eine sehr grobe Methode verwendet wird, welche nicht beim ZuSchnitt auf das TextureMuster Rücksicht nimmt und wie bei einer Textur-Tapette vll bekannt sehr auffällig ausschaut. Weitere technische Verbesserungen sind denkbar welche zB in Richtung Tesselation zielen und geometrisch weichere ÜberGänge zwischen Fields berechnen und so die Map weniger eckig wird, aber daran würd Ich erst nach Behebung der oben aufgeführten Mängel denken. Soweit exemplarisch ein visuelle Aufbesserung des Spiels kurz (...) aufgeführt. Ich ziehe nun meine gebliebenen Erfahrungen mit den Nightly Builts heran um die Neuerungen zu reflektieren. Größte Änderung ist sicherlich die navale Expansion, welche den Spieler rmöglich, auf ganz neue und vor allem weitreichende Weise zu expandiere sowie über den KüstenVerlauf hinweg zu expandieren und operieren -- dazu fällt mir an erster Stelle nur die Expedition ein -- den LinienVerkehr im Carrier-Mode kann Ich weniger neues abgewinnen als dieser automatisch abläuft und im Grunde essessenzielles leistet: ohne dem wäre der neue Port am Ende seiner Optionen denn für jeglichen weiteren Ausbau der Kolonie würden die BauStoffe fehlen. Expedition bedeutet derzeit zugleich für eine Kolonie die erforderlichen Resourcen als Ladung für das ExpeditionasSchiff mitzuführen bzw zuvor auch bereit zu stellen -- für die besonders knappe Resource Gold heist dies ohne Option auch einen neuen Port zu errichten ist auch keine Expedition nur zwecks (resp Option) Errichtung eines neuen Hafens möglich. Auch eine schlichte militärische Nutzung unter dem Begriff Recon ist so nur eingeschränkt möglich: ohne Expedition kann Ich nicht ein Schiff zum Ausspähen von der Küste aus nutzen. Aus mir nicht genauer bekannten Gründen wurde die SichtWeite der Schiffe auf ca. 1 Feld weit entspricht einer SchiffsLänge reduziert -- das bedeutet praktisch das Schiff fährt ständig im Nebel. Ich vermute den Grund im derzeitigen Sicht-Model, das knapp gesagt 2D ist und bewirkt, dass ein Schiff hinter einen Berg gucken könnte wenn der Berg denn schmall genug ist. Ich würd dieses "ArteFakt" im Kauf mit der möglichen militärischen Nutzung für Recon nehmen - iwer entschied anders und Ich habe dazu nicht meine Position vertreten. (Ich meine wenn Ich dies so knapp aufführe klingt es iwie komisch aber wenn mein Punkt nicht so bedacht wurde wurde er auch nicht berücksichtigt .. der zufriedenstellendse Weg wäre es das SichtModel auf 3D zu ändern was bedeutet entweder ein LichtStrahl oder ein fiktiver Sicht-Strahl wird berechnet - die Rechnung ist im Grunde gleich, nur weiss nicht jedes Objekt ob es ein Seh-befähigtes Objekt anstrahlt wogegen der SichtStrahl ebend nur von seh-befähigten Objekten ausgeht und damit RechenArbeit einsparen kann, der wesentliche Code aber im Grunde gleich: man muss den Weg zwischen Viewer zum fraglichen Objekt prüfen ob ein anderes Objekt diesen versperrt. Wenn man dann noch bercksichtigen möchte dass es Objekte gibt die wohl in der SichtLinie stehen und so die Sicht beeinflussen aber nicht gänzlich verunmöglichen -- zB Objekt hinter BaumGruppe -- wird zusättzlicher Aufwand an Code und RechenArbeit notwendig. Nach meiner Einschätzung eine interessante Aufgabe -- aber nur wenn die Lösung einem möglich ist .. ergebnislos sich daran die Zähne ausbeissen ist definitiv kontra-produktiv. Ich wurde diesbezüglich nicht weiter befragt aber IIRC tat Ich wohl einen effizienten Algo vorschlagen - keine Ahnung ob dieser Beachtung fand..). Praktisch hab Ich in diesen Post mich nicht auf das Betrachten der Neuerungen bschränkt und diese vermutlich hinreichend gewürdigt -- vll macht dies besser noch jemand anders, denn IMO bietet R18 einen deutlich höheren MehrWert für den Spieler -- sondern in RückBlick des geschriebenen mehr auf verbesserungs - würdige (eigentlich Seife.. dat wo Game stark und maßgeblich schwächelt) und hiervon vor allem die Punke, die Ich für besonders geeignet halte dem Spiel einen größeren Erfolg zu ermöglichne. Vor wenigen war Ich zB sehr erstaunt von einem Freund den StandPunkt über ein anderes OSS Game zu hören "so einen Schrott spiele Ich doch nicht" und irrelevant dabei, dass Ich entgegnete "mag sein dass es nicht so schick aussieht.." sondern umgekehrt wahrnehmen musste dass Ich in diesen Fall zumindest den Aspekt Chick vergleichsweise zu gering erachtet hatte in Hinsicht meiner Vorstellung der Position anderer Spieler (ach solche Leute finden das catastrophal..). Ich vertrete daher weniger meine Meinung als meine Einsicht dass andere Spieler mehr Gewicht auf das Aussehen legen und wenn Ich selbst eher lauthals nach neuen Features schreien möchte muss Ich empfehlen dem Aspect Look einen stärkeren Fokus zu geben was nach meiner Einschätzung bedeuten würde dass Ich entgegen meiner Spieler Interessen noch länger auf neue Features warten müsste .. abgesehen von der 3D Sicht. Ich bin ja gewohnt das andere Meinungen meiner widersprechen aber vll posten andere Communer hierzu ebenso deren Reflektion wobei Ich nach Erfahrung nur selten ein Pro zu lesen bekam .. vll lieg Ich ja nur so daneben. Das neue Feat Schiff demonstriert, dass die Klassen Site bzw WareHouse und Unit bzw Carrier vereinbar sind! Ich empfehle darum an der Stelle Nägel mit Köpfen zu machen und sämtliche Units und Sites im Spiel als Fusion von Class Site und Class Worker -- propose hier als neue ClassID Class Unit -- zu gestalten was aus technischer Sicht bedeutet dass die Gebäude und Arbeiter cleverer werden da sie die zusätzlichen Fähigkeiten der anderen Class erhalten. ZB Schiff erbte die Ability (OOP Term Fähigkeit) Güter zu aufzunehmen. Das bedeutet, dass ein Worker das software-technische RüstZeug gewinnen würde, über ein eigenes Inventory zu verfügen. Derzeit werden Worker von WH WareHouses "produziert", wobei die Rezptur lauten konsumiere einen Carrier und ein Tool und prodziere einen Worker. Ein Koch ist daher kein Worker der mit KochLöffel herum läuft sondern ein Worker ohne Ausrüstung. Ähnlich arbeiten die TrainCenters welche aus Soldiers mit besseren Stats machen indem dafür weitere bessere Equips konsumiert werden. Ein Soldat aus einen Carrier produzieren kostet zB Waffe + Rüstung. Diesen mit neuer Waffe zu trainieren kostet als Konsum diese neue Waffe. Als Ich iwann versuchte die TrainSite CFGs abzuändern musste Ich feststellen dass diese TrainSite wohl die Fähigkeit conume(Ware) besitzt aber nicht die Fähigkeit produce (Ware) um auf gleichen AbstractionsLevel das alte Schwert wieder zurück in die Eco zu führen um so das doch ungewöhnliche Verhalten, dass das alte Schwert aus Sicht des Spielers verschwindet. Tatsächlich aber verschwand es bereits währends des Trainings durch Consume. Ich hätte vermutet dass Class TrainSites die Class ProductionSite vollständig geerbt hätten was nicht der Fall war/ist und darum bitte Ich hier doch ebend dieses dadurch zu leisten, indem gleich die Class TrainSite in der neuen Class Unit mit aufgeht und ebenso die Class Soldier. Neben dem Vorteil der Schwert-RückGewinnung sehe Ich aus Sicht höherer Abstraction dass dadurch der Soldier XP erbt wie sie von Schmieden gewonnen werden und umgekeht, die Character-Attribute als Prototype generischer Character-Attribute es ermöglicht, auch normale Worker mit individuellen Attri buten auszustatten bzw diese zu trainieren oder auszubilden. ZB ein Worker erhält das Attribute int looks_good welches so erhöht bzw verringert werden kann. Die Verwertung dieser Attribute dass ein gut ausschauender Miner vll mehr Kohle abbauen kann wäre erst an zweiter Stelle zu berücksichtigen und dann wäre dazu vll das Attribute besser Kraft oder Geschwindigkeit dazu heranzuziehen. Auch ohne diese Generalisierung der Unit-Stats eingeführt durch Class Solider bzw Class Worker und XP stellt es kein Problem dar, wenn ein Worker diese military Stats erhält und auch nicht dass er das die Klasse (...) attackable erbt -- ich würde dies für HolzFäller und Jäger im Grunde unbedingt begrüssen - aber generell wäre nur die Frage wie wäre der Koch davon abzubrigen sich nicht auf die Soldaten zu stürzen sondern stattdessen Suppe zu kochen. Ein simples Attribute mayAttack und doesCounter könnten dieses improvisativ festlegen um ggf später durch eine komplexere Lösung ergänzt zu werden. Derzeit stört mich eigentlich sehr wenn Ich sehe wenn meine BorderGuards in der Kaserne Karten spielen und Nachbars HolzFäller in meinen Wäldern rumwildert. Keine Chance den Soldiers iwie anzuweisen ausbnahmsweise oder regulär den HolzFäller zu vertreiben. Umgekehrt aber halte Ich es für EXTREM vorteilhaft, wenn mittels XP die Einheiten in eine andere Einheit transformiert werden könnten. Dies würd aber derzeit daran scheitern, daß es eigentlich nur eine Klasse Soldat im Spiel gibt und noch keine zwei nebeneinander unterstützt werden. Es wäre daher nur möglich per XP Event andere Attribute im Set aber constant per Unit CFG neu zu setzen. An dieser Stelle nur einmal kurz und ohne HinterGrund bzw Tiefgehende Erklärung aufgeführt: Die WL CFGs stellen alle KLASSEN dar und für einige sind (keine) Methoden im WL Jargon Programm genannt
möglich aber der Constructur der Tribe-(CFG)-Klassen aber sind in Lua geschrieben. Die Frage wäre eigentlich nur, wie man Lua-Code in den CFGs einbinden und mit Programm-Calls verlinken könnte bzw umgekehrt die CFG Klassen mittels der Möglichkeiten von Lua erledigt. So würden die CFGs von WL die Mächtigkeit von Lua erreichen. (Ich bin kein richtiger Lua Fan da mich einige Sachen an Lua stören, an ersteller sei da OOP erwähnt bzw die Tatsache dass Lua auf Nievau Prozeduraler PRogrammierung funzt ... wenn Lua OOP wäre dann gilt dies auch für C und ASM). Die CFGs von WL aber sind tatsächlich OOP! (Sie missen jedoch vielen grundlegende Mittel der Imperalen under Prozeduralen Sprache -- aber sie Kennen Class und Object und sogar Methoden (allerding ohne Parameter und ohne generischen RückGabeTyp) Level ist etwas iin C++ Syntax (Site) site.worker.work(); Das bedeutet also tatsächlich dass Lua der CFG wiklich nicht in jeder Beziehung überlegen wäre! Ich möchte dazu nicht 100 weitere Beispiele für eine sinnvolle Anwendung aufzeigen sondern schlicht auf ein sehr großes Potential für das Spiel durch die schlichte Vereinigung der Classes Site und Worker hinweise, die nach meiner Erkenntnis aus Sicht der softzware-technischen Vereinigung keine großen Anforderungen stellt -- zB Fusion WareHouse mit Carrier wie bei Class Ship gemacht - was aber nicht bedeutet, dass hierduch sogleich als Ergebnis eine funktionierende Klasse Ship als Ergebnis herauskommt sondern Ich sage nur. dass diese Fusion aus SW-Sicht sehr leicht zu bewerkstelligen und das Ergebnis eher wenig Aufwand erfodert um praktisch den gleichen Nutzen für das Spiel zu bieten: WareHouse kann noch immer Waren lagern und Carrier noch immer Waren transportieren - für die praktische Verwendbarkeit dieser zusammengefügten Abilities und Properties aber ist sicher lich ein MehrAufwand notwendig was bedeutet, dass Ich hier NICHT behaupte dass so auch nur eine einzige neue praktische Eigenschaft in dem Spiel auf Level der CFG-Files entsteht -- aber Ich behaupte auch nicht dessen Gegenteil! Ich vermute aber beispielsweise das dadurch ebenso wie der Holz Fäller dann AUCH seine ArbeitsStätte in der Umgebung nach Bäumen suchen kann. Ich nenne das an dieser Stelle weder im allgemeinen ausnahmelos wünschenswert .. vll sollte das Site ja garnicht können ?!? (Ich denke aber in den meisten Fällen kann dies Möglichkeiten bieten). Bei dieser Fusion ist ein weiterer Kandidat für ein solches Vorgehen aufgefallen. Es handelt sich um immovable und movable BOB. Ich versuchte analog des GOB GameOBject Tree den Critters den Job der WildHüter zu erleichtern und es den Trees mit der Fähigkeit seed gleich zu tun. Experimente scheiterten an der Stelle seed bzw Ich musste überrascht feststellen dass hinnsichtlich der Abilties Class BOB gnutzt für Cirtter als Quasi Class Movables analog der Class Immovables, zb genutzt von Tree aber auch Stone sich nicht nur durch ein Attribute can_move=true unterscheidet sondern vor allem nur Animationen für move und idle kennt und diese von der Engine abgespielt werden. Weitere Experimente mit allgemeinen Ziel Verbesserung der Critter CFG scheiterten daran dass alle Critter im Grunde nur zwei Fähikeiten haben bzw nutzen können: geologist_search: bissl herumtappen und idle was beides allerdings nur durch Animation DFINs geleistet wird. In technischer Sprache: Critter weiss wie ein Idle aussieht aber kann den nicht selbst ausführen. Zum Vergleich: MOB Stone benutzt die gleiche Klasse wie Tree: Immovable. Daher könnten Steine ebenso die Function seed aufrufen. Daher lässt es sicht technisch rechtfertigen,
den innerhalb der Class erreichbaren Code inclusive durch Vererbung als Knowledge der Class bzw seiner Instanzen aufzufassen. In diesen Sinne ist ein WL-Stone einem WL-Critter im Interlekt haushoch überlegen! (Bei diesen Arbeiten bzw nach Erkenntnis des oben erklärten lehnte Ich zurück und sagte zu einer Critter auf der Map: siehst du den Stein nben dir? Der hat mehr drauf als du!) Würde Critter alle Abilties von Worker erben bzw die Class Worker anstatt Bob genutzt werden um Critter zu reallisieren, UND würde nicht die ANM idle vom Spiel abgespielt werden sondern ein sogenannten Programm "idle", bzw "main", welche an Stelle der bisherigen Kontroll-Weise aufgerufen wird, ergebe sich die Möglchkeit den Critters ein art-gerechteres Verhalten zu geben, ohne das dazu neuer Code geschrieben werden müsste. Gäbe es zB den Critter Typ Elefant, es wäre ein leichtes, diesem beizubringen nicht in den Bergen herum zu kraxeln. Ich hatte mich real wirklich gewundert, als Ich mich noch sorgte ob die Crittter auf erstellter Map sich über die Berge verteilen könnten -- erstes Critter in den Bergen potentiell diese passierend war ein Rind ... meine Bedenken wurden durch neue ersetzt. Mit den Fähigkeiten der Klasse Worker wäre es leicht möglich, das ein Critter zB in der Um gebung nach Wasser sucht um dort zu "idlen" -- was in vielen Fällen der ANM wie Trinken ausschauen würde. Zahllose weitere Beispiele sind leicht auffindbar - Ich verweise nur auf den generellen Ansatz, diese Klassen alle einfach nur in einer gemeinsamen Klasse zu vereinen und dann zu schauen, wie die so hinzugewonnenen Fähigkeiten im alten Code Umfeld genutzt bzw integriert werden können. Ohne mögliche Ausnahmen auszuschliessen, der wesentliche Ansatz bzw Vorschlag lautet hier: // 1) Stumpfe Fusion der Klassen define PV public virtual// Der Darstellung halber übervollständig -- einige Classes werden so mehrfach durch Vrerbung aufgeführt aber praktisch nur einmal integeriert - zB alle Worker sind auch BOB class Unit : PV Worker, PV Soldier, PV WareHouse, PV ProductionSite, PV MilitrySite, PV TrainSite, PV Builder, PV Carrier, PV Ship, PV Carrier2, PV Immovable, PV BOB {}; // 2) Ersetzung der Speziellen Typen durch die neue Class Unit typedef Unit Carrier; // 3) Integration der Classen Bottom Up sowie Ersetzung der integrierten Klassen durch die IntegrationsKlasse: class IntUnit { /Copy&Paste BOB und Immovable und NeuAnOrdnung der Felder / } typedef IntUnit BOB; typedef IntUnit Immovable; // weiss nit ob Compiler klagt das Class IntBob via TypeAlias in class Unit mehrfach aufgeführt wird - aber normal ist Class A excellent fusionierbar mit Class A - passt immer und Resultat ist sogar binary equivalent der Class A vor der Fusion - kommt nix neues hinzu! => : public virtual // keine strengere Zugriff-Policy als gegeben und virtual: alles auf/im selben Structure Level class A {int a; int x} class B {int b; int x} class C : A, B {int c; int x;} => { {int a; int x;} {int b; int x;} int c; int x;} class C : PV A, B {int c; int x;} => { {int b; int x} int a; int c; int x;} class C : PV A, PV B {int x;} => { int a; int b; int c; int x; } // alles in einen pott und nix doppelt -- ID/Type Kollision möglich! eg: bool attr; int attr; // so oder im Prinzip so -- im Detail bei der Anordnung könnte es sich anders verhalten aber die geschweiften Klammern sind korrekt und gegen das Prinzip gut wieder Einfach ALLE möglichen GOB/MOB Klassen, egal ob Feld, Baum oder Stein, Worker, Soldier, WareHouse, ProductionSite, MilitrySite, TrainSite, Builder&Co in einer einzelnen gemeinsamen Klasse UNIT, zunächst erst einmal stumpf und simple, zu vereinen und dann erst zu gucken wo es hackt sofern es überhaupt hacken sollte (!! .. wird es wohl abr nur wenig), und dann die SubKlassen von Unit wie zB Worker an den im Code verwendeten Stellen gegen Unit zu ersetzen und ggf durch Anpassung btw Erweiterung dieser Klasse zB durch ein Feld Type type=TYP_SITE; oder Feld bool32 abilites = CAN_MOVE | CAN_SWIM | ETC entsprechend der Notwendigkeiten der bisherigen HandHabung unterscheidbar bzw selektierbar bzw filterbar zu machen, um so einen EQUIVALENTEN Gerbauch zu erzielen. An jener Stelle würd Ich nicht um spezielle Features feilschen bzw diese letztlich sowieso in der entsprechenden CFG zugänglich machen was im Grunde ein weiteres paralllel Ziel der Fusion darstellt, welches gerne simultan erreicht werden sollte, um das Imlementieren vornherein deprecated Codes zu vermeiden. Neue Schwierigkeiten bzw Erfordernisse: Bisher implizierte der Typ bzw desseen Fähigkeiten ob zB eine Unit movable oder immovable ist. Wenn der bestehende Code dies nicht oder nicht mehr leisten kann, muss diese Eigenschaft dann neu mittels Attribute bestimmt werden: bool can_move = false // erstmal nit weglaufen CTOR muss das wissen bzw festlegen. In C++ Scope can man im Prinzip einem Gebäude Beine machen Ob ein WareHouse nicht moveable sein darf (Terristic Type) sondern dort zu bleiben hat wo es konstruiert wurde, oder aber vll sogar sich in die Lüfte erheben darf (mir fällt dazu ein bekanntes Spiel ein das den NamensTeil Craft trägt..) würde dann sinnvollerweise in Scope der Tribe CFG fallen und muss nicht auf Ebene der Model Implementation erfolgen: [site_cfg] can_move = "true"; // sky village?!? Ich würd den freien Constributoren nicht vorschreiben wollen ob sie einen Phantasy Tribe erstellen der Elfisch ist oder aber kleine grüne Männchen hat etc, wogegen die vom Project gepflegten Standard/MainStream-Tribes in Scope der antiken Culturen natürlich ebenso diese gebotene Freiheit geniesst. Was die freien Contributoren daraus schrauben muss nicht immer einen selbst gefallen (Ich denke dazu nur exemplarisch an die schrecklichen symmmetrischen Map - aber würd es schlimm finden wenn man solche Maps nicht erschaffen könnte weil dies nicht den Erwartungen bestimmte oder unbestimmter Personen entsprechen täte - schlechter Geschmack ist Freiheit! ;P (Im Rahmen von Gesetzzen, GPL und CC eigentlich auch impliziert)) Aus technischer Sicht spricht nicht dagegen aber sehr viel für diese Fusion. zB aus technischer und wissenschaftlicher Sicht -- allerdings nicht aus historischer Sicht!! -- das archimedische Prinzip war vor den Römern bekannt, feines Tuch konnten die Römer weben und auch Gepflechte wi Körbe war bekannt -- Kontakte bis Indien weiss Ich nicht genau - eigentlich doch: schon vor den Römern war dort reger SeeHandel ich vermute auch bis Indien und so die Seide theoretisch im Rom als Ware erhältlich .. muss da raten -- aber die Materialien für einen BALLON waren im Grunde zugänglich und wurden auch genutzt. Seile waren im Gebrauch, SandSäcke keine Hürde, nur der Auttrieb heisser Luft sowie eine leistungsfähige UND gut kontrollierbare EnergieQuelle zum Heizen wäre ein technischer KnackePunkt gewesen. Sicher wäre im Prinzip auch ein KohleFeuer bzw Kohle als Fuel möglich gewesen aber: man kann schnell ein Stück Kohle auf den Ofen werfen doch bis dieses mitheizt dauert und kann so nicht für schnelle FlugHöhen-Korrekturen nach oben benutzen - nur der Abwurf von SandSäcken hätten dazu genutzt werden können. Ich vermute also das wäre auch praktisch gegangen auch wenn eine GasBefeuerung mittels Ethin gewonnen durch AutoGen-Prozess von CalciumCarbid mit Wasser technisch leicht möglich gewesen wären - allein der Stoff CalciumCarbide bzw dessen simple Herstellung war schätzungsweise (..) mir nicht bekannt. (ich hätte das hinbekommen) Kautschuk war als seltsame Spielerei ebenso schon sehr lange bekannt -- die lokalen Einwohner nutzten es für SpielBälle ihrer Kids - eine Sulfur-Fixierung (Vulkanisierung) war nicht bekannt um daraus Gummi herzustellen .. man hätte mit tierischen Materialien improvisieren müssen und könnnen. Für eine Phantasie-Campaign wäre es möglich, die Herstellung eines HeissLuft-Ballons zu verwenden ohne historischen Hintrgrund abgesehen davon dass ein HeissLuftBallon in der Zeit der Antike zum einen mir nicht bekannt und mir sicherlich bekannt gewesen wäre hätte ein solcher öffentlich wahrnehmbar gegeben -- es sind jdoch viele historische Dokumente gefunden wordeen welche unbekannte rätselhafte Geräte und Mittel beschreiben, die, da diese nicht Alltagsgut wurden und so breiter und genauer bekannt wurden, in der Ruprik Rätselhaftes landeten. Ein HeissLuftBallon würde da nicht wirklich hervorstechen. Soweit meine historische Abklopfung für einen HeissLuft-Ballon in eine fiktiven Campaign in der Antike. Einen solchen abgenommen wäre es leicht möglich diesen in einer Custom Tribe CFG durch ein Community Member ausseerhalb der Campaign spielbar zu machen bzw wenn es den Spielern sehr gefällt mit einen HeissLuftBallon herumzudüsen, dann wird man das letztlich hinnehmen müssen würden - warum auch nicht - Ich tue mir mit Mörtel aus BranntKalk da erheblich schwerer denn es verletzt zwangsläufig auch Historie da es schon die Physik verletzt. Aber auch ohne Ballon gibt es derzeit nur Enten unter den Critter, weil diese bekanntlich in Gewässern ihre Lebensgrundlage finden .. navaler VogelTyp würd Ich attestieren. :)
Möchte man VogelArten unterstützen welche vor allem durch Fliegen bekannt sind und weniger durch Laufen oder Schwimmen - ideales Beispiel der Albatross! - dann muss man zwangsläufig neben der Fähigkeit Schwimmen und Laufen noch Fliegen hinzu nehmen! Im Grunde verlangen sowohl Fliegen als auch Tauchen neben x,y noch nach z - denn sonst ergeben sich ungewöhnliche Probleme im FlugVerkehr, sollten einmal Critter Raum beanspruchen bzw das Interface CanCollidate erben .... dessen implementierung ist im Grunde sehr simple! (VectorAlgebra: (x2-x1)²>= r2+r1 und um mögliche Collisionen frühzeitig zu erkennen: unit.speed_max=num; für 2 Units dSpeed_max=speed_max1+speed_max2; für Zeitraum dt=1second ist die mögliche WegWeite range=speed_maxdt; Der erforderliche Aufwand für diese Fusion kleingeredet bedeutet dieser Ansatz in entwicklungs-ökonomischer bzw auch software-logischer Hinsicht, das mit geringen Aufwand den bisherigen betreffenden Klassen eine sehr grosse Menge (bereits implementiertem) Knowledge (-> OOP Term) hinzugefügt wird. Das bedeutet klarer ausgedrückt dass durch relativ wenig ArbeitsAufwand ein sehr grosser Zugewinn an MehrWert des Spiels für den Tribe-Designer und dadurch für dem Spieler erreichen zu können. Das ist vergleichbar mit dem Beispiel den existierenden Motor einer MotorSäge dann auch für eine HandBohr- Maschine wiederzuverwerten ohne dazu den Motor selbst neu erfinden und fertigen zu müssen - wenn in C++ die Klasse steht ist die Instanz nur einen CTOR-Call entfernt. Natürlich macht dieser Motor an dem KaffeeVollAutomaten automatisch mitverrbt zwar keinen Sinn aber wem störts wenn dieser umsonst ist und nicht weiter behindert? has_motor=false; Im Rückblick des geschrieben möcht ich nochmals erwähnen, dass für die Gewinnung weiterer Spieler, bzw dem Erreichen einer besseren Verbreiterung des Spiels, die visuelle Qualität des Spiels nach meiner Erkenntnis (die Aussageweise meines Freundes machte den Punkt indiskutierbar und Ich möchte da eine persönliche Stellung zu dem fraglichen Spiel ausschliessn -- es war optisch einfach unter seinen Niveau -- Ich brauchte mich aber nicht rechtfertigen sowas zu spielen .. hab ich nur aus versehen herrunter geladen - kommt nit wieder vor Ich sage nicht es wäre gewiß möglich gewesen es besser=eher zu machen, aber als Feststellung muss es erlaubt sein zu sagen, dass nach meinen Geschmack B18 einfach zu lange benötigt hat, ohne dabei zu sagen wie es denn hätte besser gehen können. Ich sage also nicht es war falsch aber Ich sage die knappen 2 Jahre sind klar unvorteilhaft für den Erfolg des Spieles. Wodurch es verursacht wurde oder wie sowas zu vrhindern sei weiss ich nicht zu sagen noch ob eine schnellere Alternative unterm Strich besser gewesen wäre. Die 2 Jahre aber seblst lassen sich leichter bewerten: unangenehm lange. So sage Ich also diese beiden Felder sind die Felder, die Ich für die lukrativsten Felder hinsichtlich eines größeren Zugewinns an Spielern erkennen kann, wobei dieses aber für den Class-Fuse über diesen hinaus eine Utilization durch Tribe bzw Worlds implitziert - die Spieler zählen das was das Spiel bietet und nicht das was das Spiel technisch bieten könnte. Ich kaufe zB kein Klavier nur weil andere Leute damit Musik machen könnten und sogar machen -- so ein Kauf würde mir persönlich leider keinen OhrenSchmaus verschaffen ganz gleich was das Teil eigentlich alles könnte. Der Class-Fusion-Teil stellt daher nur Vorraussetzung der dadurch gebotenen Möglichkeiten dar und eine sinnvolle Verfügbarmachung dieser Fähigkeiten erfordert mehr oder weniger weitere Überdenkungen der bisherigen Konzepte. ZB wäre es möglich bzw denkbar, den Builder, dessen Abilities bisher nur vom WareHouse als Teil einer der CFG verborgenden Engine genutzt werden können, eine neue Baustelle an der ECO per Road angeklemmt bewirkt iwie einen REQ für einen Builder und iwie handhabt diesen dann ein WareHouse und schickt einen Builder dorthin. Es wäre möglich zB wie beim HolzFäller den Bulder einfach vor die Tür treten zu lassen damit dieser nach BauStellen ausschau hat die er bearbeiten kann. Ich störe mich hier weniger an der Weise wie es sich aus Sicht der Spieler verhält sondern aus Sicht eines Tribe-Gestalters, der zB nicht entscheiden kann, über welche Möglichkeiten der BauHof verfügen darf sondern muss hierzu den eigentlich gar nicht konfigurierbaren Type WareHouse nehmen bzw auch HQ oder Port agieren zugleich als bzw stellen ein WareHouse da. Weniger speziell aufgezeigt, also genereller erklärt, stören mich die vielen nicht für dessen Aufgabe notwendigen für die CFG unsichtbaren Modell-Eigenschaften, welche eigentlich alle auch per CFG bzw Worker und Site Programme grundsätzlich gelöst werden könnten - auch wenn dazu neue BuiltIn-Funktionen notwendig wären. Hinsichtlich der möglichen Gestaltbarkeit zwecks Verschiedenheit der Tribes ergeben sich dadurch neue Möglichkeiten. Ich halte die Frage an die Kommunity aus persönlicher Sicht als Spieler ob mehr Schick oder mehr Feature für ungeeignet, um darauf basierend strategisch zu entscheiden was für das Projekt vorteilhafter ist - Ich würde bei dieser Fragestellung (so die aktive Community eingeschätzt) ebenso nach Feature rufen denn die Tatsache aktives Mitglied im Forum zu sein beweist eigentlich, nicht mehr zu eigentlich representivieren Mehrheit der inaktiven Community zu gehören -- die hier gestellte Frage der stratgischen Entscheidung für den zu bestimmend Priorisierung der (hier nur meine persönlich vorgeschlagenen bzw befürworteten - jemand anders könnte dazu andere wählen aber die Fragestelung hier bleibt die gleiche) .. strategischen Schwerpunkte der nächsten EntwicklungsPhase keinesfalls an dem Ergebnis einer solchen Befragung orientieren. Ich könnt im Sinne der FrageStellung ebenso Kinder fragen ob sie Spinat oder Suessigkeiten bvevorzugen .. die Frage aber lautet was verhilft eher zu mehr Wachstum - eine signifikante Wachstums-störende MangelErscheinung habe Ich aufgezeigt -- wäre die FrageStellung an die Community hinsichtlich der strategischen Wichtigkeit, würd ich deren Antwort dazu nicht abschätzen wollen. Ich weiss aber was besser schmeckt! Um diesen Post abschliessend dem Titel des Threads wieder nahe zurücken: Ich habe versucht, die Gründe und Vorteile der langen Release-Date-Distanz herauszufinden ... genau genommen fiel mr auf dass sehr viele BugFixes in ChangeLog aufgeführt wurden und Ich die Vermutung aufstellte dass hier vll durch neue Methodik besonders effektiv viele Bugs sicher lokalisiert und beseitigt werden konnten, dass mag stimmen und wenn dies stimmt hätte dies definitiv Vorteile auf di künftige Entwicklung weil neuere Bugs dann einfacher einer Code-Änderung zugeordnet werden könnten ... doch für die BugFixRate des jüngsten Release hat dies nicht zu einer höheren BugFixListungsRate geführt -- wenn eine solche neue Mthodik auch dazu führt, dass auch weniger neue Bugs in den Code einfliessen, dann stellt eine kleinere BFRate auch kein klares Signal für eine schlechtere EntwicklungsPerformance dar: Ein guter Doc heilt nicht viele Patienten sondern wenige weil weniger krank werdem. Letztlich: Gratuliere nochmals zu R18, hab lange gewarten und im Rückblick auf die FeatureList stellt der lange Zeitraum keine Vergeudung von EntwicklungsLeistung dar und im absoluten Vergleich R18 zu R17 stellt R18 ein deutlicher Fortschritt dar -- Ich werd demnächst auf des Medien-Echo lauern und gucken was dritte Meinung dazu sagt, die nicht von NB NightlyBuilt zu NB durch stete Änderung schwer den GesammtFortschritt betrachten kann und in Hinsicht einer kompetenten unabhängigen SpielerMeinung mir eher sagen kann was ein normaler Spieler zu R18 sagen würd. Ich darf vermuten wenn es ein Medien-Echo denn gibt (man kann dieses ja unterstützen), dann wird die nächsten 1-2 Monate ein verstärkter Spieler Zulauf stattfinden und je nach Treffen des jeweiligen SpielerGeschmackes mehr oder weniger Spieler nach anklingen des Neuen des Spiels sich die ActiveUserBase auf ein neues unbekanntes Niveau einpendeln. Diese Base ist die selbe, aus der sich neue ProjektMitglieder ergeben. Die schlichte Annahme ist mit fiktiven Zahlen, wenn 10% der aktiven Forum User zugleich auch Projekt Contributoren sind bzw geworden sind, dann würde eine 20% größere UserBase auch ca. 20% mehr Contributoren bewirken. Daher ist der Zuwachs durch neue Spieler außerordentlich wichtig und dient dem Interesse der Spieler nach mehr Zucker - wirkt aber erst indirekt aus zweiter Linie dafür aber wirksamer und nachhaltiger. Daher kommt mein spezielles Interesse am Medien Echo denn diese Medien bevorzugen Produkte welche positive Meldungen ermöglichen. Ab und zu kann man ja ein Game zerreissen aber Ich würd da weniger lesen wolllen was ICh nicht spielen möchte sondern mehr was Ich spielen möchte. 3 mal Trash Product gelesen und Ich bekomme eine SinnKrise - was such Ich denn dort? Ich hoffe die Developers konnten die Kritik (die die positiven Aspekte doc wirklich nicht übermäßig hervorgehoben haben auch wenn es sie gibt -- bitte gerne diese nachreichen wenn hier nicht ausreichend berücksichtigt - ich hab mit meinr Brille geguckt und du mit deiner) gut verkraften und es war wirklich nicht meine Absicht eine Leistung schlecht zu reden sondern die Gelegenheit des R 18 zu nutzen, um eine zurückblickende Zusammenfassung zu versuchen sowie eine persönliche Aufstellung der gegenwärtigen Schwächen und bestehenden Möglichkeiten .. das erreichte ist das bestehende doch das bessere ist nach vorne gerichtet und orientiert sich am verbesserungsfähigen gegegeben. In diesem Aufzeig wird vll der konstruktive Charakter meines Posts deutlich auch wenn es eher üblich ist Laudatio über nur voll gut ey zu halten ... da hab Ich nie versucht Talent darin zu erreichen Ich hoffe auf weitere Reflektionen die so vll ein runderes Bild bieten können denn meine Reflektion ist zwangsläufig einseitig. Nun erst einmal gucken ob die GameTester überhaupt von der Existenz des Release berichten bzw dazu ankündigen. Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too. 
Top
Quote
|
Kann man ja nennen wie man möcht - Ich möcht den .. Build R18 nennen. 
Vergleichsweise bietet R18 deutlich mehr Features als R17. Die neuen Feat wurden schon in der News aufgelistet. Nun bitt Ich doch die PR Abteilung .. PR bedeutet NICHT PM Public Manipulation (das klingt in meinen Ohren immer mit: ah - PR also) sondern Public Relation, bitte also PR sich mit geeeigneten Spiel-Test-Sites in Verbindung zu setzen -- formal generic ist das wohl eine Presse-Mitteilung und speciell würd Ich geezielt respektierte Tester bitten ein Review des Spiels hinsichtlich der Neuerungen - also R17 vs R18 zu schreiben, um unabhöngige Meinung über das Spiel zu bemühen, zum einen um das Review selbst willen aber auch um dessen Verbreitung über deren eigenen
InformationsDistritbutionsWege zu erreichen. Dazu natürlich freundliche Bitte und freundliches Danke und special Support falls was nit klappt im Sinne einer gegenseitigen InteressenUnterstützung -- mir wollen das Review und der anvisierte Reviewer hoffentlich auch - und wenn ihm ein Steinchen dazu im Wege liegt ist es WL Interesse diesses zu entfernen -- Ich sehe den Scope PR mit Abgrenzung zur PM un Schleimerei sachlich gewahrt. 
Ich kann tatsächlich aber wegen OOP als SuperSet prozedurale Sprachen nicht leiden. Nur ASM bzw MicroCode fallen in unterliegendene Bereiche die Ich in fortbestehender Anwendung respektiere. C++ etwa
so schnell wie C und wenn es wirllich schnell sein muss dann nimmt man ASM und nicht C nur weil es vll 10% schneller bei simplen Code/Tasks ist. Man kann mit C++ übrigens im C Style programmieren,
was aber leider kein grosses Geheimnis ist :)))
Visual Improvement durch Field-Transition und Advanced-Texture-Cutting einen klaren Vorteil für eine dieser beiden SchwerPunkte ausmachen und somit hervorstellen -- angemerkt sei dass Ich den visuellen Aspekt schon einmal unterschätzt habe -- und es ist mr nicht möglich die gegeben sogenannten Development-Resourcen (dabei handelt es ich an erster Stelle um Menschen) abzuschätzen, in wie weit beide EntwicklungsZiele parallel zu beackern wären -- wenn beides zusammen 5 Jahre benötigen würde um im nächsten Release veröffentlich zu werden halte Ich dies aber für keine gute Idee -- das sind 5 Jahre Staub für den Spieler.