Broadcast Network Active – eine neue Art des Locals in EvE Online

Veröffentlicht: 9. März 2015 von Syzygium in Kommentar

Aktuell überschlagen sich ja die Gerüchte und Ankündigungen im EvE Online Universum. Kurz nach den ersten Berichten, die Art und Weise wie Sov (aka Systembesitz) im Nullsec zukünftig ablaufen soll, legte CCP direkt nochmal nach und kündigte drastische Änderungen an den Supercapital-Schiffen an und äußerte Ideen bezüglich eines veränderten Local-Chats fürs Nullsec.

An dieser Stelle möchte ich mich kurz einklinken, denn es bietet sich hier eine Gelegenheit, die man nicht ungenutzt verstreichen lassen sollte. Einerseits hat man die Chance, die Kontrolle des Locals als „Intel-Tool“ in die Hände der Spieler zu geben (zumindest in spielerkontrolierten Gebieten) und man hätte eine Game-Mechanik eingeführt, die Sov-Holdern in ihrem eigenen Space tatsächliche Vorteile bringt, die mal nicht als irgendwelche Schiffs- oder Geldboni wirken sondern tatsächlich die Verteidigung des eigenen Gebietes erleichtern – durch einen Informationsvorsprung.

Wie das Ganze aussehen könnte, möchte ich hier kurz umreissen.

Der bisherige Local-Chat in EvE Online funktioniert in zwei Varianten. Der sogenannte „Insta-Local“ im Known-Space (K-Space: 0.0, Lowsec, HighSec) und der sogenannte „Delayed-Local“ im Wormhole-Space. Beim Insta-Local wird jeder Spieler im System automatisch im Systemchat angezeigt wenn er das System betritt, bleibt so lange sichtbar wie er sich im System aufhält und wird aus der Liste entfernt, sobald er das System verlässt. Beim delayed Local passiert genau dies nicht, es tauchen nur Leute in der Chatliste auf, die selbst irgend etwas in den Chat schreiben. Alle im System anwesenden Player können dies zwar lesen, werden ihrerseits jedoch nur sichtbar, wenn sie ebenfalls etwas schreiben. Man sieht also nicht, wer ein System betritt, verlässt oder wer schon da ist – es sei denn, derjenige macht sich absichtlich bemerkbar.

Beide Variante haben Vor- und Nachteile, der Delayed-Local im WH gilt allgemein als herausfordernd aber auch gefährlich, da er oft für Jäger und Gejagte zum Verhängnis aber auch zum Vorteil werden kann. Es gibt Spieler, die sind eher PvP-orientiert und wünschen sich den Delayed Local für alle Gebiete von EvE, andere bevorzugen die Gewissheit des Insta-Locals weil sie PvP eher aus dem Weg gehen wollen. Allgemeiner Konsens ist imho, dass InstaLocal für den HighSec ok ist, DelayedLocal fürs WH ok ist und Lowsec/NullNull diskussionswürdig sind.

Mein Ansatz wäre folgender: Aus Roleplay-Gründen und Anfängerfreundlichkeit würde ich im High- und Lowsec weiterhin den InstaLocal bestehen lassen, denn beides (ja auch LowSec) ist NPC-kontrollierter Space. Die „SovHolder“ dort sind die NPC-Imperien und auch wenn der LowSec eine beliebte PvP-Area ist, unterliegt er dennoch der Kontrolle und Hoheitsgewalt des jeweiligen Imperiums. Und ich halte es für glaubwürdiger, wenn diese aus Sicherheits- und Kontrollüberlegungen heraus, da wohl eine Komplettüberwachung bevorzugen würden.

Anders im 0.0. Große Teile des 0.0 sind spielerkontrolliert. Spieler-Allianzen können Systeme claimen, ausbauen, bewirtschaften. Sollen sie doch auch selbst entscheiden, welche Art von Local sie in ihrem eigenen Space bevorzugen? Wie das geht, soll im folgenden kurz erklärt werden.

Standardmässig wäre der Local in jedem 0.0 erstmal ein DelayedLocal, denn wer sollte in unverwaltetem Space auch ein lokales Funk- und Überwachungsnetzwerk betreiben? Gesehen wird also nur, wer was in den Space hinausfunkt. Sobald in einem System jedoch jemand Hoheitsansprüche anmeldet, sollte er auch die Möglichkeit haben, ein solches System einzurichten und zu betreiben. Hierzu wird eine weitere Sov-Struktur eingeführt, ein verankerbarer „Local Broadcasting Node“ – kurz LBN. Jeder LBN deckt genau ein Grid ab und er kann überall im Space verankert werden, jedoch pro Grid nur ein einziger LBN. Es ist für den Sovholder also durchaus möglich, an jeden Belt, Plani, Mond, an jedes Gate, POCO oder jeden Outpost auch ein LBN zu stellen, welcher dort das Grid überwacht. Kontrollierte Outposts übernehmen diese Funktion für die dort gedockten Spieler automatisch.

Dieser LBN füllt nun den Localchat mit allen Spielern, die er identifizieren kann. Dies geschieht automatisch, sobald ein Spieler im Grid eines LBN auftaucht, mit einem Delay von 2 Sekunden. Warum der Delay? Dazu später!
Ebenso kann der SovHolder einstellen, dass „eigene“ Allianzmember automatisch im Local angezeigt werden, sobald sie im System sind, egal ob ein LBN sie sieht oder nicht.
Spieler, die für eine einstellbare Zeit X nicht von einem LBN erfasst werden, werden automatisch aus der Local-Liste gelöscht. Spieler die das System über ein Gate oder via Podkill verlassen, werden sofort entfernt.

Wer diese Local-Liste dann sehen kann, legt der Sovholder selbst fest. Er kann einstellen, dass die Liste für jederman einsehbar ist, oder auch nur für Allianzmember oder Allianz+Blues. Oder für Neutrals aber nicht für Reds.

Kurzzusammenfassung bis hierher:

  • Der Standardlocal im ungeclaimten (und NPC-) 0.0 wird „delayed“ wie im WH. Spieler sind nur sichtbar, wenn sie schreiben.
  • Sov-Holder können LBNs in ihrem Space verankern, die jeden Spieler den sie im Grid sehen automatisch in eine Local-Liste einfügen.
  • Diese Local-Liste ist nur für Berechtigte sichtbar, die Berechtigungen verteilt der SovHolder. Unberechtigte sehen weiterhin nur den DelayedLocal.

Nun, wie sieht das Ganze dann in der Praxis aus und welche Gegenmaßnahmen gibt es?

Kommen wir zuerst zu den Gegenmaßnahmen. Natürlich ist es für den SovHolder ein Vorteil zu sehen wer ins System kommt, wer schon da ist und wer das System verlässt, während „Eindringlinge“ sich diese Informationen durch Beobachtung im System, Scanning und Probing beschaffen müssen. Dafür hat der SovHolder zwar Aufwand betrieben, aber auch seine Gegner sollen Möglichkeiten haben, mit entsprechenden Tools die Sicherheit des SovHolders zumindest teils auszuhebeln.

  1. Hier kommt als erstes der angesprochene 2-Sek-Delay ins Spiel. Wir begründen das Storytechnisch so, dass der LBN ca. 2 Sekunden benötigt um ein Spielerschiff zu scannen. Was aber, wenn das Spielerschiff sich vorher cloaked? Dann fügt der LBN dem Local nur einen „Unknown Contact“ hinzu, der jedoch keine Rückschlüsse auf Spieler, Corp, Allianz oder Schiff zulässt. Die Bewohner wissen nun also, dass jemand gesehen wurde, aber nicht wer.
  2. Zusätzlich gibt es ein neues Electronic-Superiority-Rig namens „Scan System Destabilizer“ welches folgende Werte hat:
    T1: 100 Calibration, Ship & Cargo Scans have 50% Chance to fail, LBN Scan time increased to 60sek
    T2: 150 Calibration, Ship & Cargo Scans have 75% Chance to fail, LBN Scan time increased to 90sek
    Das bedeutet: Ein Schiff mit diesem Rig kann sich bis zu 90sekunden auf dem Grid eines LBNs aufhalten, ohne im Local zu erscheinen. Es ist also möglich, durch Systeme zu traveln ohne direkt auf sich aufmerksam zu machen. Kombiniert mit dem Cloak eines Recons/Bombers/CovOps oder der DScan-Immunity eines CombatRecons eine Möglichkeit, ungesehen durchs 0.0 zu kommen.
  3. BlackOps Schiffe erhalten einen Role-Bonus, mit einem 120sek LBN-Immunity-Effekt, ohne ein Rig zu benötigen.
  4. LBNs sind hackbar, Voraussetzung sind ein gefitteter Data Analyzer II und der Skill Hacking V. Es erscheint das selbe Minigame wie beim Hacken von Containern, gewinnt der Spieler, bekommt er die LocalListe des SovHolders mit aktuellem Stand angezeigt (aber keine zukünftigen Änderungen, dafür müsste er erneut hacken). Der Sovholder bekommt bei fehlgeschlagenen Hackingversuchen eine Notification.
  5. LBNs sind wie andere Strukturen mittels Entosis-Link deaktivierbar. Inaktiviert man ein LBN, fällt er in seiner Funktion aus und muss vom SovHolder mittels eigenem Entosis-Link reaktiviert werden.
  6. LBNs sind zerstörbar, mit ungefähr den Hitpoints eines POCOs und ähnlichem RF-Timer. Reinforced LBNs funktionieren nicht. Sprich, eine Kampfstarke Gang kann als Vorbereitung eines Angriffs die LBNs eines Systems oder einer Constellation (auch ausserhalb der PrimeTime des SovHolders) reinforcen und möglicherweise zum RF-Timer zerstören, um dessen Intel zu stören.
  7. Es werden so genannte „Broadcast Identifier Probes“ eingeführt, die in einen Expanded Probelauncher geladen werden können. Auf einem Grid abgefeuert, übernimmt diese Probe für X Minuten die Funktion eines LBN für den Piloten des Schiffs. Ergo: Alle Spieler die von der Probe gesehen werden, sind für den Piloten des Schiffs im Local sichtbar. Gut zur Vorab-Infiltration von Angriffszielen, wenn man den LBN auf Grund feindlicher Präsenz nicht hacken kann. Natürlich deckt die Probe nur das aktuelle Grid ab, man muss also mehrere im System verteilen wenn man einen genaueren Überblick bekommen möchte. Die Bewohner werden dadurch natürlich gewarnt, dass jemand herumstöbert.
  8. Last but not least, werden natürlich Schiffe die über ein Wurmloch oder ein CovertCyno ins System gebracht werden, nicht von LBNs registriert. Diese können sich mittels Cloak oder Safespots im System verstecken, ohne dass die Bewohner gewarnt werden.
  9. Von der Standardmethode, einen Spy in die betreffende Ally einzuschleusen und sich die Local-Infos zu stehlen, mal ganz abgesehen.

Nun hört sich das vielleicht auf den ersten Blick sehr kompliziert an, ist es nach mehrfachem Lesen aber nicht wirklich. Alle Schritte von der Erkennung bis zur Entfernung eines Spielers aus dem Local sind einfach und logisch nachvollziehbar. Nach einer gewissen Eingewöhnungszeit, sollte das System für beide Seiten nachvollziehbar und verständlich sein.

Als Erleichterung hier noch ein paar praktische Beispiele:

Beispiel A:
Im System sind 20 eigene Leute und 5 Blues. Jeder dieser 25 Leute sieht auch alle anderen 24 im Local. Nun kommt ein Neut/Red mit seinem Ceptor durch ein Gate ins System gesprungen und an diesem Gate ist ein BroadcastNode installiert. Der Ceptorpilot kann sich natürlich nicht ins BroadcastNetwork einklinken mangels Berechtigung. Er sieht also niemanden im Local. Sobald er sich decloaked wird er jedoch vom BroadcastNode am Stargate identifiziert und im Local angezeigt. Er hat nun also den Nachteil, dass er als Eindringling nicht weiss, wer im System ist, aber alle wissen dass er da ist. Er kann sich nun auf Safespots aufhalten bis er aus dem Local wieder entfernt wird, sobald er jedoch wieder auf ein Grid kommt wo ein BroadcastNode steht, wird er wieder angezeigt. Warpt er also an den Star und dort steht ein BroadcastNode, sieht man ihn wieder im Local. Tackled er jemanden in einem Belt oder Ano wo kein Node steht, sieht man ihn nicht.

Beispiel B:
Eine CovOps betritt das System durch ein Gate, cloaked sich jedoch bevor der BroadcastNode seine Identifizierung abgeschlossen hat. Im Local erscheint „Unknown Contact“, der jedoch keine Rückschlüsse auf Char/Ship/Ally zulässt. Gecloaked kann sich die CovOps im System bewegen und wird von keinem Node mehr erfasst, nach einiger Zeit wird der „Unknown Contact“ auch aus dem Local gelöscht, da ihn kein Node mehr gesehen hat. Ob die CovOps noch da ist oder längst durch ein WH raus ist, niemand weiss es.

Beispiel C:
Ein Bomber betritt das System durch ein Wormhole oder ein (Covert)Cyno. Er erscheint nicht im Local da er von keinem Broadcastnode wahrgenommen wurde. Er kann sich einen Überblick verschaffen wer alles im System ist, ohne selbst gesehen zu werden. Bis er etwas schreibt oder sich decloaked, wird er nicht im Local auftauchen.

Beispiel D:
Eine kampfstarke Gang kommt als Vorhut für eine Fleet durch ein Stargate ins System, wird vom BroadcastNode nach dem Decloak im Local angezeigt. Die Gang reinforced den Node, die Fleet die später nachspringt wird nicht mehr im Local angezeigt.

Der SovHolder hat natürlich auch die Möglichkeit, Reds/Neuts den Zugriff aufs LocalNetwork zu gestatten, die können sich dann einklinken und dann zwar sehen wer alles da ist, werden ihrerseits dann aber auch sofort angezeigt. Klinken sie sich wieder aus, verlieren sie alle Infos aus dem Local aber werden selbst nach einiger Zeit ohne Kontakt mit BroadCastNodes auch wieder entfernt.

Warum halte ich diesen Ansatz für besser als die bisherige Situation? Nun, so hätte man eine Unterscheidung zum WH, einen weiteren Vorteil des SovHolders und Infiltration über NodeReinforcement/Hacking, CovertCynos und WH-Exits wären eine taktisch wertvolle Informationsquelle ohne selbst gesehen zu werden und das Sov-0.0 hätte ein weiteres Alleinstellungsmerkmal, welches dem SovHolder mal ganz unabhängig von Schiffs- oder ISK-Boni weiterhilft und es Angreifern erschwert, gehaltenen Space einfach zu übernehmen.

Ich hoffe, mit diesen Ideen ein paar Anreize gegeben zu haben, um sich fürs Sov-0.0 ein einzigartiges und nüzliches Local-Konzept auszudenken, an Stelle auf 0815-Lösungen zurückzugreifen die jeweils die eine oder andere Seite vor den Kopf stoßen würden und vor allem viele taktische Möglichkeiten der Interaktion von Spielern unmöglich machen würden.

/Syz

Kommentare
  1. l0rd carlos sagt:

    Wie ECM, nur fuers local :P Orginal chancen bassiert und binär.

    Ich wuerde lieber ganz weg vom lokal. Also so das man ihn ihm noch chatten kann, aber kein intel tool mehr ist.

    Jetztigen Local + jetztigen d-scan + jetziges scanner overview mischen. Eine art scanner, der bei 360 grad aber recht fuzzy ist. Wenn 10 Battleships 100 AU weg stehen, sollte man da immernoch was sehen, aber weit aus weniger als wenn die selbe gruppe 1000km offgrid sind. Es sollte recht schwer sein eine kleine frig die 20 AU entfernt ist anzupeilen ohne probes. Wenn aber 20 frigs an der gleiche stelle stehen sollte es einfacher sein.

    Wie es genau implementiert werden kann oder wie es ausieht weis ich nicht. Vielleicht so eine art heat map im overview oder map? Jedenfalls halte ich die binäre lokal darstellung fuer ein relict alter Zeiten. Und warum noch chancen bassiert dazu stecken?

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s