Ein letzter Anlauf - bevor das Licht ausgeht...

[Roy]

An die 2D/3D Mischung a lá Blitzkrieg hab ich garnicht mehr gedacht. Hab eben den Post von Schneefuchs in dem andren Thread gelesen, würde ich unterschreiben. Wenn das realisierbar ist, scheint mir das momentan die schönste Lösung zu sein,

[Kamui]

Apropos "bevor das Licht ausgeht". Was ist jetzt eigentlich noch mit Open Strike? Meiner Meinung nach tut sich hier garnichtsmehr. Wäre mal nett etwas handfestes zu bekommen oder zu hören.

[Gareth]

Stellt sich eine elementare Frage: Sollen SS2/mods Einheiten weiterhin verwendet werden können, oder nicht?

Ich bin für nein, da diese wahrscheinlich zu klein für größere Auflösungen als 1280x1024 sind

Stimme dir im Prinzip zu. Ich habe da vor einiger Zeit mal ein Viertelstündchen mit ner Bildbearbeitung und einigen SuSt-Screenshots verbracht und die SuSt-Grafik auf 1280x1024 und 1600x1200 hochgepuzzelt und dann im Vollbildmodus angeschaut. 1280x1024 war noch ok, selbst Infanterie für das trainierte SuSt-Spielerauge ziemlich gut erkennbar. Bei 1600x1200 waren die Einheiten aber doch arg winzig, Details nicht mehr erkennbar. Aber eine geniale Übersicht (schwärm)!
Im übrigen lass das Gehirn ruhig weiter stürmen, wieder sehr schöne und interessante Ideen dabei. Wenn man die guten Ideen aus dem Forum und aus dem bisherigen Entwurf umgesetzt bekäme, käme ein geniales Spiel dabei heraus. Wenn das Wörtchen "wenn" nicht wäre... Es gibt noch viel zu tun. Packen wir's an...

Was ist jetzt eigentlich noch mit Open Strike? Meiner Meinung nach tut sich hier garnichtsmehr. Wäre mal nett etwas handfestes zu bekommen oder zu hören.

In den letzten Tagen passiert hier wieder erstaunlich viel, zumindest was die Diskussion und konstruktive neue Vorschläge angeht. Erstaunlich deshalb, weil - und das meintest du ja vermutlich - an dieser Stelle im letzten Jahr mehr oder weniger Funkstille herrschte. Immerhin scheint ja trotz allem noch Interesse an dem Projekt zu bestehen. Was handfesteres als das kann ich leider noch nicht melden, so gern ich das tun würde.
Zum Status von OS habe ich einen Kommentar im News-Thread gepostet.

[-Barbarossa-]

Bevor man keinen/keine Programmierer hat, die wirklich in der Lage sind eine eigenständige Engine aufzubauen und zu bearbeiten finde ich diese Diskussionen schon viel zu sehr im Detail.
Ihr braucht erst einmal Leute die zu den Themen wirklich sagen können, was umgesetzt werden kann und was nicht. Und sowieso sollte man in solch einem "Projekt" vom kleinen ins große gehen. Wenn ein Grundgerüst steht, ist der kreative Geist gefragt.

[Gareth]

Das Arbeiten vom kleinen zum großen ist schon der richtige Ansatz. In der Implementierungsphase wird das auch genau so verfolgt werden, immer vorausgesetzt, dass es mal so weit kommt. Natürlich wird dann zuerst ein "Minimalspiel" erstellt, das nur die elementaren Features bietet. Selbst da wird es vorher viele kleine Prototypen für verschiedene Aspekte geben, z.B. beim Aufbau der Grafik-Engine.
Dass hier in einer Art Brainstorming trotzdem schon viele, teils auch ziemlich ins Detail gehende Ideen gesammelt werden, hat mehrere Gründe:
1. Nach den Erfahrungen aus dem bisherigen Ablauf des Projekts möchte ich, dass das vorläufige Game Design steht, bevor die Diskussion über die Machbarkeit mit den Programmierern beginnt. Nach den bisherigen Erfahrungen aus dem Projektablauf ist das schon deshalb nötig, weil die Programmierer nicht notwendigerweise Sudden Strike-Erfahrung mitbringen. Aus diesem Grund soll der Entwurf die Spielmechanik relativ detailliert beschreiben, damit eine gemeinsame Grundlage für die Diskussion über die Umsetzung existiert. Nicht realisierbare Features kann man dann in der Diskussion über den vorliegenden Entwurf identifizieren und vereinfachen bzw. aus dem Entwurf entfernen.
2. Die Features, die in der endgültigen Version realisiert werden sollen, sollten nach Möglichkeit vor Beginn der Implementierung bekannt sein. Features während der Implementierung in den Entwurf einzubauen, die nicht von Anfang an berücksichtigt worden sind, bringt u.U. sehr viele Änderungen an dem dann schon vorhandenen Code mit sich, was arbeitsaufwendig und fehlerträchtig ist.
3. Die Neuaufnahme der Diskussion dient auch (wie im News-Thread erwähnt) dazu, abzuschätzen, was an Wünschen existiert bzw. was sich evtl. seit der ursprünglichen Diskussion geändert hat und ob das Interesse der Community den Entwicklungsaufwand noch rechtfertigt.

Noch eine Bemerkung: Ich werde mich bemühen, in Zukunft konsequent zwischen Game Design (das oft erwähnte Design-Dokument, kurz DD) und dem Software-Entwurf zu unterscheiden, damit klar ist, wovon jeweils die Rede ist. Das Design-Dokument beschreibt die gesamte Spielmechanik relativ detailliert, aber - und das ist entscheidend - noch isoliert von allen konkreten Implementierungsaspekten. Das heißt, dass z.B. bei der Beschreibung der Bewegung von Einheiten beschrieben wird, wie diese im Spiel dargestellt werden soll, dass aber noch keine Aussage darüber gemacht wird, wie sie programmiertechnisch realisiert werden soll. Das ist zu diesem Zeitpunkt ja noch nicht geklärt, da wichtige Entscheidungen wie z.B. über die Grafik Engine noch ausstehen. Das Design-Dokument als Beschreibung der Spielmechanik dient dann als Grundlage für den Software-Entwurf. Erst an dieser Stelle kommen dann konkrete Überlegungen zur Implementierung, d.h. zur Programmierung ins Spiel. Dass diese Überlegungen zu Veränderungen am ursprünglichen Design-Dokument führen können und werden, ist klar und wohl auch nicht zu vermeiden. Um es nun einmal klar zu sagen: Das Projekt Open Strike befindet sich noch in der Phase des Game Designs und damit noch ganz am Anfang. Man könnte auch etwas bissig sagen, dass es sich um Gedankenspiele auf hohem Niveau, allerdings auch mit ernsthaften Absichten handelt.

[|FrEaK|Safran]

Nachdem ich nun alles was mit dem Thema OS zu tun hat (abgesehen von den Sachen im Br@vo-Forum, das ja in diesem Sinne down ist) gelesen habe, sage ich, dass ich gerne fest mitarbeiten würde. Inwiefern ich dort nützlich sein werde, wird sich zeigen

Also auf ein neues, oder

"Frisch ans Werk Mr. Freeman, frisch ans Werk..."





Wobei ich sagen muss, das Gehtnix`s vorraussage eines Releasedatums um 2010-12 gar nicht mal so falsch zu liegen scheint

[-gehtnix-]

Wobei ich sagen muss, das Gehtnix`s vorraussage eines Releasedatums um 2010-12 gar nicht mal so falsch zu liegen scheint

Dies würde mich nicht "schrecken", wenn das Ergebnis dass warten wert war!
"Bedenklich" finde ich, dass darüber diskutiert wird/wurde den Editor zu "vereinfachen" - was wäre, wenn Jemand auf die Idee kommt Schach zu vereinfachen und sagt alle Figuren können nur noch nach vorne gezogen werden? wo bleibt die "Strategie", nach wenigen Wochen wird ein spielen langweilig, da die Möglichkeiten zu sehr begrenzt ...!
Das z.B. Handlungen in Formation für die "KI" auch möglich sein sollte, wäre als eine Option o.k., doch freie Wahl wie man ein Script erstellt sollte bleiben um alle Strategischen Möglichkeiten durch eigene Vorstellungen nicht zu begrenzen!
Persönlich füge ich gerne noch an: "Nur weil die Mehrheit mit den jetzigen Möglichkeiten von SUST 2 nicht zurecht kommt muss nicht alles "vereinfacht" werden!"
MfG

[|FrEaK|Safran]

Ja, das stimmt.
Wobei man hier und dort doch ein paar Sachen optimieren und nicht vereinfachen könnte...
Was auch nett wäre, wenn man dem Ding eine erweiterte Befehlssprache mitgeben könnte, und den Vorschlag den Zonen auch Namen geben zu können halte ich für brauchbar, aber eines nach dem anderen

[Packard]

FrEaK|Safran, da stimme ich voll zu. Genau das sind zwei wesentliche Punkte, die bei der Skriptsprache erweitert werden sollten.


erweiterte Befehlssprache
Das Prinzip mit "if...then" Fenstern oben und unten ist schon gut und übersichtlich. Bei weitergehenden, komplizierteren Sachen würden gewisse Möglichkeiten fehlen.

Zonen auch Namen geben
Bei den Zonen und Variablen nur Nummern ist unübersichtlich, Nach einiger zeit wird es mühsam da noch durchzublicken.


Was ich bisher im Editor vermißt habe ist die Möglichkeit, die ganze Fläche mit einem Geländetyp zu füllen. Dabei müßte das programmiertechnisch sehr einfach sein. Anstatt mit einer Grünfläche wie es Standard ist könnte man die Fläche auch mit Boden oder Wasser füllen.

Außerdem haben solche Editoren meist auch die Möglichkeit eine Zufallslandschaft zu erzeugen, was auch nicht sehr schwierig sein dürfte.

Importmöglichkeiten gibt es bisher gar nicht, weder für Hintergrund noch für die Objekte oder Einheiten.

Den Zeitrahmen etwa 2010-12 für eine voll lauffähige Version halte ich für realistisch. Bei der Frage was wird die Zukunft bringen, denke ich mir, wir haben alle noch ein paar Jahrzehnte Lebenserwartung vor uns. Das Spielprinzip wird sich im Wesentlichen nicht ändern. Es ändert sich die Technik.

Diese zukünftigen Entwicklungen schon jetzt mit einzuplanen und ein in Module aufgeteiltes Programmsystem zu schaffen sollte günstige Voraussetzungen für die langfristige Weiterentwicklung ergeben.

[Gareth]

Nachdem ich nun alles was mit dem Thema OS zu tun hat (abgesehen von den Sachen im Br@vo-Forum, das ja in diesem Sinne down ist) gelesen habe, sage ich, dass ich gerne fest mitarbeiten würde.

Das nenne ich mal ein Wort! OK, du bist engagiert. Kannst mich ja per PM oder ICQ kontakten, dann können wir das eine oder andere schon mal abkaspern.

Wobei ich sagen muss, das Gehtnix`s vorraussage eines Releasedatums um 2010-12 gar nicht mal so falsch zu liegen scheint Rolling Eyes

Ja, zumal ja jetzt auch schon lange nicht mehr so viel gemacht worden ist.

"Bedenklich" finde ich, dass darüber diskutiert wird/wurde den Editor zu "vereinfachen"

Hm, hab jetzt nochmal kurz die bisherigen Diskussionen überflogen, hab dabei aber nur meine Äußerungen zur Vereinfachung der Bedienung des Editors gefunden. Jedenfalls kann ich dich da beruhigen. An den Skriptmöglichkeiten soll nicht gekürzt werden, eher wird es da mehr geben. Jedenfalls ist das die hehre Vorstellung davon, wie sie mir vorschwebt...

@Packard: Wieder viele gute Ideen. Hast du evtl. auch Lust mitzuwirken? Falls ja, siehe oben.

[-gehtnix-]

@ Gareth
Direkt hier, wo es eigentlich hingehörte, war ja nicht alles was geschrieben wurde!
MfG

[Packard]

@Gareth

Hast du evtl. auch Lust mitzuwirken?

Einen Teil würde ich schon machen. PM ist abgeschickt.

[|FrEaK|Safran]

Ich bin grad unterwegs, und werde mich Sonntag Abend oder Montag wieder melden

Freue mich!

Also Ziel: Editor vereinfachen, aber nicht in seinem Funktionsumfang beschränken. Vielleicht kann -gehtnix- ja einfach eine Liste mit Verbesserungswünschen erstellen, wir befinden uns ja noch in der "brainstorming"-Phase

[Ralf 207]

z.b. Angirff

sind truppen auf der karte und der spieler kommt in eine zone mussen die den spieler angreifen und bei ca 30 % zurück in eine zone gehn

mfg ralf

[|FrEaK|Safran]

z.b. Angirff

sind truppen auf der karte und der spieler kommt in eine zone mussen die den spieler angreifen und bei ca 30 % zurück in eine zone gehn (sicsicsic!)

Das ist doch durch ein einfaches Script jetzt schon möglich, oder habe ich dich missverstanden?

@Gareth

Hab dich im ICQ geaddet

Dank sei dem Unterrichtsausfall, ich tippe hier mal fix ein paar Ideen, über die Diskutiert werden darf ^^

...und zwar dachte ich, dass man eine Art "vierstufiges" Deckungssystem einführen könnte:

Wiese/Sumpf/Wüste...................Deckungslos (nur Standartwerte)
Krater.......................................Leichte Deckung (1)
Panzergräben/Schützenlöcher.....mittlere Deckung (2)
Schützengräben.........................gute Deckung (3)
Häuser/Bunker...........................gute Deckung (4)

Das ich zwischen Schützengräben und Häusern einen Unterschied mache, liegt daren, dass
man so die Wirkung von Steilwerfergeschossen (Mörser) und Artillerie simulieren könnte. Diese würden nämlich Deckung der Stufe 1-3 ignorieren.

Oben erwähnte ich Schützengräben / Schützenlöcher und Panzergräben;
ich dachte mir, dass es viel taktischer würde, wenn die Infantrie nur Schützenlöcher/Zweimannlöcher ausheben könnte. Für das richtige Schanzen wären dann Pioniere oder Bautrupps nötig. Panzergräben würden für Panzer unüberquerbar und müssten erst von einer Bulldozer/Räumeinheit durchquerbar gemacht werden.

In etwa stellte ich mir die verschiedenen Fähigkeiten so vor:

Pioniere:
- Zeitzündersprengsätze
- Panzerminen
- Personenminen
- Brückenreparatur
- Panzersperren
- Stacheldraht
- Schützengräben
- Panzergräben
- Minen räumen
- Knüppeldämme bauen (über Sumpf)
- Krater entfernen (Straße, Flugfeld, Eisenbahn)

Bulldozer/Raupen/Bagger(?)/Räumfahrzeuge:
- Bäume umfahren (das bei den Pios zu integrieren find ich reichlich zwecklos)
- Minen räumen
- Krater entfernen (Straße, Flugfeld)
- Panzergräben ziehen/verschütten
- Panzerwracks beiseite schieben

Bautrupps (zB: Organisation Todt):
Diese Wären leicht bewaffnet (Karabiner) und eine Alternative zu Pionieren, falls ein Mapper keine Minen auf der Karte sehen will.
- Brückenreparatur
- Panzersperren
- Stacheldraht
- Schützengräben
- Panzergräben
- Knüppeldämme
- Krater entfernen (Straße, Flugfeld, Eisenbahn)

Soviel dazu ^^

Es war ja bereits festgehalten worden, dass Untergrund auch eine Rolle spielt (Sümpfe bremsen, Straßen machen schneller), da könnte man auch Schnee berücksichtigen. Alle Einheiten werden etwas langsamer und die Genauigkeit leidet (abgesehen von Artillerie).
Zudem wäre es logisch, wenn Einheiten jetzt auch Kratern ausweichen würden. Man könnte Krater in zwei Stufen einrichten: mittel (Fahrzeuge weichen aus, Panzer fahren einfach drüber) und groß (Deckung (2) für Infantrie, auch Panzer fahren drumherum). Dies würde auch dazu führen, dass man Straßen wieder herrichtet
Die kleinen Krater haben einfach nur optischen Nutzen, es wäre ja auch seltsam, wenn sich ein Laster weigern würde über 10cm Tiefe Krater zu fahren

Das war mein Wunschzettel, was es davon schafft, wird man ja sehen ^^
Hab mir noch mehr gedanken gemacht, aber das brauch ich hier nicht Posten

MFG Safran