Hmm, bei solch hohen Werten geht die taktische tiefe aber wieder verloren, denn der Spieler kommt mit rechnen garnicht mehr hinterher/ bzw. er merkt garnicht, ob ein Untergrund verlangsamt.
Beispiel: normal 10 ZE daraus folgt diagonal 14 ZE. Kleinstmöglicher Faktor 1,5 also 15 ZE und 21 ZE. Keine schönen Zahlen. Und da der Spieler ja nicht den ZE-Verbrauch für jedes einzelne Feld angezeigt bekommt, sondern nur für die Gesamtstrecke ...

PS: mehr Zwischenstufen klappen auch nur gut, wenn es nur eine Grundgeschwindigkeit gibt (also keine unterschiedlich schnellen Einheiten).

stimmt villeicht ist 30 40, 33 44, 36 48 usw besser geeignet.

Die Grundgeschwindigkeit der Einheiten kann eigendlich eh dadurch reguliert werden wieviele zeiteinheiten die einheit hat.

ggf auch wieviele zeiteinheiten eine spezielle einheitenart auf einem boden braucht, wobei ich hier sage das führt zu weit zb zu sagen ein schweres kettenfahrzeug braucht im sumpf doppelt soviele ze wie ein soldat weil es versinkt, oder der sumpf ist für es einfach unpassierbar.
Oder ein flugzeug hat überall die gleiche geschwindigkeit.
Das würde zwar wundervolle tecktische möglichkeiten eröffnen, aber ist noch absolute zukunfts musik bisher sind ja eh nur soldaten eingeplant.

Die Bewegung wurde übrigens auch intern diskutiert - früher im Zusammenhang mit dem Einheitenkonzept und jetzt auch nochmal aufgefrischt.

Eine endgültige Entscheidung ist noch nicht gefallen, aber momentan sieht es so aus alsob es keinerlei unterschiedliche Bewegungskosten für Untergründe geben wird.

Der Grund liegt darin das der Aufwand und die Probleme beim Umsetzen anscheinend deutlich schwerer wiegen als der Gewinn an Realismus, den man dadurch für den Spieler erreichen könnte.

hmm wäre schade, ich würde schon einen gewissen hoch einzuschätzenden gewinn an tacktischen möglichkeiten sehen.

Nicht wirklich - wenn Du nicht etwas im Kopf hast das wir übersehen haben dann überschätzt Du den Gewinn oder unterschätzt den Aufwand und die Probleme die dabei auftauchen.

Mach doch mal ein konkretes Beispiel inklusive Zahlenwerte für was für eine Mission unterschiedliche Bewegungskosten einen spielerischen Vorteil bringen - und bedenke dabei auch das die Kosten pro Feld unterschiedlich sein müssen, gerundete Werte darf es nicht geben oder andere Probleme würden auftauchen.

nunja also stell dir mal eine mission vor bei der das Ufo im Sumpf abgestürzt ist, der
1. von normalen fahrzeugen nicht befahren werden kann,
2. in dem bodentruppen nur halbsoschnell sind
3. Flugzeuge normal schnell sind

man selber hat nur bodentruppen zu verfügung, während der gegner mit flugeinheiten angreift.
Ziel der mission ist es den teleporter der sich im ufo befindet und jede runde eine Flugeinheit herwarpt auszuschalten.
das problem dabei ist
A) man muss sich irgendwie einbunkern damit die flugeinheiten nicht zu leichtes spiel haben
B) dennoch vorankommen, damit man gewinnen kann und nicht immer noch mehr flugeinheiten hergewarpt werden.

Bei sowas wäre es wichtig das es unterschiedliche bewegungsgeschwindigkeiten gibt, sonst würden neue flugzeuge entweder zu lange brauchen oder die soldaten zu schnell bei ufo sein.

Noch wichtiger als verschiedene geschwindigkeiten wäre allerdings das gebiete von einigen einheiten befahren werden können und von anderen nicht.

zu 1: Fahrzeuge gibt es nicht im Bodeneinsatz, nur Soldaten. Im Wiki kannst Du nachlesen weshalb sich das auch erstmal nicht ändern wird, dafür gibt es einfach nicht genug Programmierer an der XForce.

zu 3: Flugzeuge gibt es auch noch nicht, und selbst wenn man Flugfähige Aliens simulieren würde dann könnte man das genausogut machen, indem man ihnen mehr ZE und ein passendes Bild gibt.

zu 2: Wenn das gesamte Gebiet für alle Einheiten des Spielers gleich gebremst/verändert sein soll, dann gibt es keine taktische Auswirkung unterschiedlicher Untergründe.

Zu Bewegungsklassen: Unterschiedliche Typen von Bewegungsformen zu programmieren ist noch ein vielfaches Aufwendiger als "nur" für alle Klassen identische Bewegungskosten.
Insbesondere bedeutet dies das ein Spielsatzersteller noch mehr Probleme bei der Abstimmung erhält als das jetzt der Fall ist, denn was ist wenn z.B. eine Karte das vorhandensein bestimmter Einheiten mit entsprechenden Bewegungstypen erfordert, aber diese Einheiten in dem Spielsatz gar nicht oder sehr spät verfügbar sind? Abgesehen davon das dann der Spieler noch rätseln muss was er in welcher Mission in den Transporter packen muss?

Eine Umsetzung von Sentos Missionsmöglichkeiten würde also neben mehr Programmierarbeit auch eine drastische Einschränkung der Mod-Möglichkeiten von XForce bedeuten, denn dann müsste man den Spielsatzerstellern entweder vorschreiben was für Einheiten sie wie einbauen oder aber die betreffenden Karten müssten von den Spielsätzen ignoriert werden - d.h. die ganze Arbeit wäre fast umsonst gemacht.

Endergebnis: nicht praktikabel, so schön es sich auch im ersten Moment anhört. Selbst wenn wir die Programmierer für so eine Arbeit hätten, würde die Umsetzung wahrscheinlich zu mehr Beschwerden aus dem Lager der Spielsatzersteller führen, die das einfach nicht alles aufeinander abstimmen können...

1. ja ich weis, ich würde die verschiedenen geschwindigkeiten auch noch nicht für jetzt planen sondern eher dann einbaun wenn fahrzeuge und so drinne sind, bei flugzeugen gilt das gleiche, deswegen ist es auch witzlos jetzt drüber zu diskutiren ^^

Nein, es ist nicht sinnlos darüber zu reden.

Zum einen verhindert dies spätere unnötige Korrekturen weil man keine Werte nachfügen muss die man schon von Anfang an eingeplant hat.

Und zum anderen verhindert dies auch Fehlplanungen, denn nur weil etwas später gemacht werden kann heißt das noch lange nicht das es auch gemacht werden sollte.

Eine der Stärken von XForce ist die Mod-Barkeit. Ein Teil dieses Moddings ist der Austausch von Elementen wie z.B. der Tilesets und der Karten.

Ein Szenario wie das oben vorgestellte Sumpf-Szenario würde aber genau diese modbarkeit einschränken, denn eine solche Karte könnte nicht mehr beliebig zwischen Spielsätzen getauscht werden, sondern wäre auf das Vorhandensein entsprechender Einheiten angewiesen.
Ganz abgesehen davon das eine Zufallskarte auf der Basis unterschiedlicher Kartenräume nur schwer mit unterschiedlichen Beweglichkeiten in verschiedenen Kartenräumen aufgebaut werden kann.


Bisher habe ich hier noch keinen Grund gesehen weshalb die Beweglichkeit eingebaut werden sollte - selbst wenn wir 1000 Programmierer hätten die das per Fingerschnippen morgen fertig hätten würde ich gegen unterschiedliche Beweglichkeiten Bewegungstypen stimmen, denn der Einbau eines solchen Konzeptes bringt Probleme für die Spielsatzersteller, die nicht alles selber machen können oder wollen.

Es ist so ähnlich wie beim Multiplayer - jeder (inklusive meiner einer) findet den beim ersten Gedanken cool, aber die genauere Analyse hat gezeigt das es einfach nicht funktionieren kann.

Wenn also jemand einen ausreichenden Grund für Bewegungstypen kennt, der über ein "finde ich cool" hinaus geht oder eine Idee, die die entstehenden Probleme für die Spielsatzersteller beseitigen könnte, dann bitte posten.

naja siehs mal andersherum:
Jedes spezielle scenario das auf bestimmten einheiten und taktiken basiert, so wie es in den meisten spielen in kampagnen vorkommt wird nicht frei austauschbar sein, schlieslich geht es ja von bestimmten vom spielsatz gegebenen vorraussetzungen aus, wären diese anders würde die taktik immer zerstört oder zumindest verändert werden.

Nur soll man das aus diesem grund ausschließen das solche scenarien gemacht werden?
Fänd ich auch keine gute idee ;)

In dem sinne würde ich auch sagen das normale karten nicht unbedingt bewegungs unterschiede enthalten müssen.
Sinvoll wärs aber bei speziellen scenarien die sowiso nicht universalkompatibel wären und nur in einen spielsatz passen, und sowiso 100%tig an diesen angepasst werden.

Das mit der bewegungsrate anpassen ist ja ein netter gedanke, dachte ich auch erst, nur dann muss man auch wieder wenn man eine andere karte schafft bei der man keine verlangsamung hat wiederum andere flugobjeckte benutzen, die wieder langsam sind.
Ausserdem müsste man bei der Sumpfkarte die kartengröße so anpassen das die soldaten den doppelten weg haben.
Abgesehn von der Bewegungsgeschwindigkeit bräuchte man zwingend eine möglichkeit bestimmte einheiten zu sperren, das wird vorallem wichtig wenn man diese einheiten nicht auf der karte (oder auf bestimmten teilen der karte "zb von hier an nur noch fußvolk") haben will weil sie zb zu stark oder zu schnell sind (diese funktion ist noch wichtiger als die bewegungsgeschwindigkeit).

Es ist eine Frage von wieviel Aufwand. Wie Du in der Diskussion über die Wände nachlesen kannst muss man selbst normale Wände an den jeweiligen Spielsatz anpassen, aber das ist deutlich einfacher als eine Bewegungsform.

Wenn man 6 Monate Programmierarbeit braucht um eine Besonderheit einzubauen die dann nur einmal unter 300 Bodeneinsätzen genutzt wird, dann lautet die Antwort
JA - mit drei Ausrufezeichen.

Wenn es in den normalen Karten keine solchen Unterschiede gibt, dann wird der Spieler in den Spezialkarten auch nicht damit rechnen und keine Einheiten dafür parat haben.
Dementsprechend ist das dann noch witzloser sowas zu machen.

Und der letzte Absatz von Dir zählt alle Negativ-Gründe auf, weshalb man sich unterschiedliche Bewegungstypen schlichtweg gar nicht erst antun sollte. Denn die ganzen dort genannten Probleme gibt es nicht, wenn man die Bewegungstypen gar nicht erst einführt.

Da hier keine neuen Gedanken mehr kommen fasse ich mal zusammen:

Ein Bodentile besteht aus 4 Bildern, die der Ausrichtung der dargestellten Grafik in die vier Hauptrichtungen entsprechen. Die Spiegelgrafik wird gestrichen.

Es hat eine interne ID innerhalb seines Tilesets. Seine komplette ID setzt sich aus Tileset-ID und Tile-ID zusammen. Diese ID ist nicht sichtbar und wird bei der Umsetzung/Programmierung noch genauer definiert.

Das Bodentile hat einen Namen mit einer begrenzten Anzahl von Zeichen, der vom Tileersteller festgelegt wird und auch geändert werden kann.
Der Name wird nur im Tileeditor und im Karteneditor angezeigt, die Begrenzung auf eine feste Anzahl von Zeichen dient auch nur zur besseren Anzeigeformatierung in den Editoren. Das Tileset wird automatisch nach diesem Namen sortiert, wenn es in einem der Editoren angezeigt wird.

Die letzte Eigenschaft ist ein Flag "Betretbar", das angibt ob eine Einheit dieses Feld begehen darf oder nicht.
(Anmerkung für später: im Karteneditor sollte es ein grafisches Kennzeichen für unbetretbare Bodenfelder geben, dies vereinfacht die Arbeit für den Kartenersteller)

-----------------

Variable Bewegungskosten werden ausdrücklich nicht eingebaut, alle Felder werden immer dieselben Bewegungskosten haben.
Und dieser Punkt steht jetzt auch nicht mehr zur Diskussion...

-----------------

Irgendwelche letzte Anmerkungen oder Ergänzungen?

ja
danke für die Zusammenfassung jetzt versteht jeder was ihr bei euren Posts meintet
wenn man den ganzen Thraet ließt kommt man leicht ins taumeln wenn man nicht aufpasst ^^