Beiträge von Hoegnison

    Mich errinert das Spiel irgendwie an "Insurgency". Mal abwarten wie es bei Release aussieht.


    Eine Aussage, die ich immer wieder höre, die aber wenn man das Gameplay genau unter die Lupe nimmt, nicht stimmt. Da ja hier wohl Aufklärungsbedarf besteht, wie Grey das bemerkt hat, vlt an dieser Stelle noch ein paar Worte zu Squad :)


    Squad lässt sich schwierig in wenigen Worten beschreiben. Am schnellsten geht es wohl, indem man sagt: "Squad spielt sich sehr ähnlich wie Project Reality BF2."
    Jetzt ist es aber so, dass nicht jeder in den Genuss von PR kam. Was macht das Spiel besonders?
    In PR findet man öffentliche TvT Gefechte, die koodriniert ablaufen und bei denen jedes mal mehrere Truppengattungen zum Einsatz kommen. Infanterie, Panzer, leichte Fahrzeuge, Schützenpanzer, Flugzeuge, Helikopter und alles was sich der Hobbysoldat wünscht, kann man dort finden. Praktisch ist der integrierte Voicechat, der ähnliche Funktionalität wie in ArmA aufweist (Squadchat, ein lokaler Chat mit 3D Position des Sounds, ein Commander Chat und einen eigenen Kanal für jeden einzelenen SL). Der Vorteil ist, dass dieser Voicechat funktioniert und auch 100 Spieler ohne Mühe aushält. Das Gameplay als solches würde ich als langsam und vorsichtig beschreiben. Oft läuft man größere Strecken auf den meist 4x4 km großen Maps und versucht sich selbst in einer bessere Position mit seinem Squad zu bringen oder sich mit einem anderen Squad abzusprechen. Warten auf Panzerunterstützung, Transporthelikopter oder Logistik gehören ebenfalls dazu. Es gibt die Möglichkeit Baumaterial an die Front zu bringen (via LKW oder Heli) um dort Stellungen auszuheben.
    Dies wird gepaart mit einem ausgeklügelten System im Infanteriekampf, bei dem Verwundete gerettet werden können, es einen Unterdrückungseffekt gibt und ein Kitsystem, dass 8 Mann Sniper Squads verhindert. Diese Einschränkungen funktionieren je nach Klasse sogar global für das gesamte Team, sodass es einem Squad passieren kann, dass es sich keine schwere AT mehr holen kann, weil alle vergriffen sind.
    D.h die SL müssen einiges an Kommunikation betreiben, um ihr Squad naha am Geschehen zu behalten und ohne Squad ist der Einzelne komplett nutzlos und wird nebenbei auch automatisch vom Server gekickt.
    Spielmodi gibt es mehrere wie z.B "Suchen und Zerstören", "Advance and Secure" etc. Lange Zeit war PR meine einzige richtige Alternative zu meinen ArmA Coop MilSim Operationen im Clan. Was spiele ich, wenn ich mal eben 2 Stunden Zeit habe und ein taktisches Erlebnis will? Das Feeling an einer großen OP teilzunehmen haben will? Mit Leuten aus aller Welt interagieren will? Die ArmA Public Spielmodi kamen für mich da nie wirklich in Frage. Mitlerweile gibt es ja einige, die vieles richtig machen, doch leider wird die Serverliste von AL und King of the Hill dominiert. Daher hatte PR in meinen Augen immer eine Daseinsberechtigung neben ArmA.


    SQUAD ist ein Projekt ehemaliger PR Entwickler und will ganz ähnliche Aspekte umsetzen. Das Coregameplay soll ganz klar an PR anknüpfen und es fühlt sich auch jetzt schon so an.
    Man merkt also, Insurgency ist nicht mal ansatzweise ein ähnliches Produkt, was ja nicht heißt, dass es schlecht ist :)

    Aber genau das ist doch das Problem an Triggern! Genau deshalb sollte man die ja auch nur sehr eingeschränkt benutzen, gerade im MP. Ein Übel rechtfertigt doch kein Anderes.


    Etwas zu benutzen, weil man es spannend findet, ist ein schlechter Grund.


    Ich glaube, dass eine simple Abfrage, die einen logischen Ausdruck prüft, ist wohl weniger ein Übel. Man sollte natürlich aufpassen, welche Funktionsaufruf man verwendet. Es gibt sicherlich Anweisungen die nicht sonderlich performant skalieren. Selbiges gilt auch für manche BI Function. Jedoch lässt sich ein Missionsablauf nur schwierig steuern,ohne zu prüfen. Ich wage auch zu behaupten, dass man sich mit dem sinvollen Einsatz von FSMs den ein oder anderen Trigger sparen kann. Die Dosis macht das Gift. Effizienz und Effektivität sollte immer gegeneinander abgewogen werden.

    Kann die Euphorie über .FSM Automaten hier nicht wirklich verstehen. Die Dinger sind nicht gerade förderlich für Performance (Bedingungen werden jeden Frame überprüft!) und generell eher unübersichtlich. Debugging ist auch schwerer, da nur eingeschränkt Fehlermeldungen ausgegeben werden. Alles in Allem sollte man um die Dinger einen Bogen machen.


    Dass Bedingungen in jedem Frame überprüft werden ist jetzt keine Seltenheit oder? Ist das nicht auch bei Auslösern so? Ich schätze mal wie immer macht die Dosis das Gift und man sollte darauf achten, welche Bedingungskonstrukte man zusammen baut. Mit ein paar Regeln der Logik, lassen sich auch viele komplexe Konstrukte vereinfachen. Unübersichtlich ist das Format der FSMs sicherlich, doch mit Automaten ist eine strukturierte Verhaltenssteuerung eigentlich sehr schön umzusetzen. Ich muss aber auch gestehen, dass ich Automatentheorie schon immer spannend fand :Flush:


    Vielleicht hilft ja auch das hier, habe ich selbst aber noch nicht getestet:


    https://community.bistudio.com/wiki/FSM_Editor

    mit FSM kannst du ASynchrone aufgaben in den synchronen teilbereich ziehen (du spawnst etwas für endlose loops und führst den code anschließend in einem nicht-asynchronen FSM call aus, vorteil: bessere "performance" da der code ohne stop durchgeführt wird, nachteil: zu lange prozesse gehen auf die FPS)


    FSM selbst ist hauptsächlich für AI entwickelt worden und hat für den durchschnitts scripter daher keinen wirklichen sinn (bis auf async zu sync)


    Richtig. Ich sehe auch dort den Hauptverwendungszweck. Generell lassen sich Verhaltensmuster mit Automaten sehr schön simulieren. Vlt setze ich mich mal mit den FSMs mehr auseinander und mache davon sogar ein Video.


    Ich sehe gerade den Beitrag #13. So sehe ich das auch. Alles, was wir im Spiel machen, ist ein Komprimiss mit der Wirklichkeit und kein genaues Abbild. Jede Gruppe wird sich die Addons heraussuchen, die der eigenen Spielweise am ehesten entsprechen.


    Genau :) Genau so kann man das unterschreiben :)

    Wir haben das ADSS in vielen unserer Missionen genutzt und selbst kritsch eingestellt Nutzer haben hinterher zugegeben, dass es ein netter Beitrag zur Immersion war. "Realistisch" ist natürlich relativ. Es ist auch alles andere als realistisch 20 Mann als einen Zug zu bezeichnen oder dass man jedem Soldaten eine Karte in die Hand presst. Es ist auch nicht realistisch, dass man die Squadleader in jedem Einsatz tauscht, die Bewaffnung wechselt oder Feindfahrzeuge kapert. Totzdem wird auch dies von Spielern betrieben. Was man selbst als realistisch bezeichnet, liegt daran, wie weit man MilSim treiben will, wie sehr man Roleplay wünscht und worauf man in einer MilSim Wert legt. Wie weit kann man reale Vorgänge abstrahieren und in die Spielwelt übertragen? Man bedenke, dass auch auf den Klappentexten, von CoD und BF steht, dass diese Titel realistisch wären. Alles eine Frage des Blickwinkels ;)
    Wir bezeichnen uns in dieser Hinsicht auch selbst gerne als "Irre" oder "Hardliner". Jedermans Sache ist das also mit Sicherheit nicht, aber es gibt ja auch kaum ein Spiel, dass so viel Spielraum wie ArmA bietet.


    Ein weiterer Effekt des Addons ist, dass wir zu in unseren Augen "realistischeren" Bewegungsmustern beitragen konnten. Die Jungs sind quasi gezwungen gewesen, sich so oft wie möglich im Marsch forzubewegen, da sie ihre Energiereserven für den Kampf aufsparen mussten.

    Dazu hat Jay bereits etwas entwickelt. Ich hoffe wir kommen bald zu Veröffentlichung. Das Tool existiert schon seit ArmA2 für unsere claninternen Zwecke, wurde jedoch von Jay nochmal komplett überarbeitet:


    Danke für das Teilen meines Videos Doc ;)


    Also wie man sich denken kann, bin ich relativ angetan von dem Konzept, das Squad verfolgt. Schon jetzt in diesen frühen prealpha Tests fühlt es sich wie PR an. Abgesehen davon, dass es besser aussieht, mehr Potential hat und dieses mal keine Engine die Ideen der Entwickler eingrenzt. Daher habe ich große Hoffnung, dass Squad seinen Platz in unseren Herzen als Teamplay orientierter, taktischer FPS finden wird. Man sollte bedenken, dass Squad nicht versucht ein neues ArmA zu werden, sondern wesentlich zugänglicher sein will. Leicht zu lernen, schwer zu meistern, ist der Ansatz der Entwickler.


    Gruß


    Ich persönlich versuche im Internet möglichst anonym zu bleiben und vom Real Life zu trennen. Ich habe kein Interesse daran, dass ein Arbeitskollege aus Zufall auf meine Stimme im Internet stößt.


    Kann ich verstehen und ein Mitschneiden ohne Ankündigung ist meines Erachtens nach ein Zeichen von Unprofessionalität.
    Bei der GeCo habe ich zunächst mein Squad gefragt, ob sie denn gerne gefilmt werden würden. So handhabe ich das bei jedem "Event", egal in welchem Spiel. Clanintern weiß man ja über mein YT Hobby Bescheid und viele von den Jungs halten schöne Momente fest.
    Streams sind jedoch immer wieder als schwierig zu erachten. Wir versuchen es zu vermeiden, dass jemand ohne unser Wissen streamt, was bis jetzt wohl gut funktioniert hat. Wir haben vielleicht noch das Glück, dass unsere Jungs IG weitaus anders auftreten, als im TS. Sprich Disziplin, RP und der Umgang untereinander ist nichts wofür wir uns schämen müssten, sondern das präsentieren wir gerne nach außen. Peinlich sind nur technische Probleme oder Aussetzer in der Mission. Das sollte auch live nicht gezeigt werden.



    too long, didnt read: Streams nicht gut.


    Stimme ich also nur bedingt zu. Clanintern mit Ansage kein Problem aus meiner subjektiven Sicht heraus. Auf Events unter Umständen problematisch und ohne Ansage absolutes NoGo.


    Ich sehe Streams in ihrer Intention auch ein wenig anders platziert. In meinen Augen kann ich Streams als Mittel nutzen, um mit meiner Community zu interagieren, dieses möglichst direkt, indem ich z.B auf den Chat eingehe. In einer ArmA Mission, die Immersion schaffen soll, finde ich dies befremdlich. Da eigenen sich andere Spiele, bei denen man nebenbei entspannt plaudern kann, doch viel besser :)


    Gruß

    Ich finds super, dass du diesen Guide anfängst. Dazu hab ich direkt mal 3 Fragen:

    • was heißt "schlecht", "auch schlecht" und "besser"?
    • wie kommts zu dieser einstufung?
    • wie siehts für große n aus?


    Zu 1.)


    Was hier gemeint ist, dass die unterschiedlichen Lösungen unterschiedlich schnell/langsam skalieren. Was bei winzigen Datenmengen kaum auffällt, wird bei größeren Datenmengen wieder spürbar. Gut/besser/schlecht sind hier nur relative Einstufungen zur Effizienz verschiedener Algorithmen.


    Zu 2.)
    Seine Einstufung ergibt sich entweder aus Performancetests oder aus theoretischem Wissen über Algorithmen und Datenstrukturen. Man kann unabhängig des Faktors Hardware berechnen, wie gut ein Algorithmus arbeitet. Dazu kannst du dir mal die O Notation anschauen.


    Zu 3.)
    Große N werden in der Regel diese aufgeführten Richtlinien bestätigen. Allerdings ist das nicht immer der Fall. Es gibt durchaus auch Algorithmen, die bei großen N wesentlich schneller sind als andere Algorithmen, bei kleinererm N jedoch weniger gut dastehen.


    Gruß

    Das is aber wieder Traffic unso.


    Nope ;) Der Eventhandler triggert nur local auf der Maschine, auf der er hinzugefügt wurde. Die Granate kann dann local mit deleteVehicle gelöscht werden, denn diese Befehl hat eine globale Auswirkung. Weniger Traffic geht nicht.
    Schau dir mal diesen Eventhandler an:
    [h=4]FiredNear[/h]
    Könnte man zum Beispiel einem unsichtbaren H hinzufügen oder einem Schild in der Base.

    Gude,


    FSM steht für "Final State Machine", was auf deutsch ein "endlicher Automat" wäre. Automaten sind Konzepte der theoretischen Informatik, mit denen man Prozessabläufe darstellen kann. Ein Automat hat dabei mehrere Zustände, einen Startzustand und einen Ednzustand (jedenfalls bei den endlichen/deterministischen).
    Dann gibt es Eingaben/Events, die dazu führen, dass der Automat den Zustand wechselt. Das passiert solange, bis man den Endzustand erreicht hat. Natürlich kann man innerhalb eines Prozesses beliebig oft in einen bestimmten Zustand geraten, auch ein Neustart ab Startzustand (z.B bei Fehleingabe) ist möglich.
    Über Automaten und die unterschiedlichsten Automatenformen kann man noch lange sprechen, aber ich denke das Prinzip ist klar.


    FSM ist ein Fileformat, um dieses geniale Konzept umzusetzen.
    In den FSMs in ArmA kann man nun auch Zustände/States deklarieren und Events mit Prioritäten angeben, die den Automaten den Zustand wechseln lassen. So kann man zum Beispiel KI Verhalten prozedural aufdröseln und geschickt umsetzen.


    Dazu gibt es auch eine nette Seite von BI ;)