Port to .NET 5/6

[tomwendel]

Das hier ist ein dickeres Brett. Ich google mich gerade so durch. Soweit ich mich erinnere, hat @patteki damit schon angefangen und ist über eine Reihe von Problemen gestolpert die es zu lösen gilt.

Im Simulation Core Bereich gibts hier ganz klar das Sicherheitsproblem. Das aktuelle Spiel nutzt dafür AppDomains um a) den ausgeführten Code in seinen Zugriffsrechten stark zu limitieren (das würde grundsätzlich auch mit der Code Access Security (CAS) funktionieren. Aber sie sorgt auch für das saubere Entladen von externen DLLs nach der Simulation.

Um also eine klare Trennung zwischen Hauptapplikation und den Simulationsdaten zu schaffen, könnte man mit einem zweiten Prozess arbeiten. Soweit, sogut.

Auf UI Seite wird das Problem aber etwas umfangreicher. Wenn der Port auf .NET 5+ gleichzeitig die Plattformunabhängigkeit herbeiführen soll, muss sich das UI grundlegenden ändern. Aktuell ist das ja eine hübsche WinForms App deren Inhalte aus den geladenen Plugin-Libs mit weiteren WinForms UserControls gefüttert werden.

Um das mit einem passenden Konzept abzulösen fallen mir eine Reihe von Frameworks ein

• Avalonia (mein aktueller Favorit) um das UI entspannt mit XAML hinzubekommen. Leider bekommen wir da Schwierigkeiten mit der 3D-Ansicht)
• MAUI (wäre dann mit .NET 6 spannend)
• MonoGame. händische Renderei, bekommt aber das Problem mit der 3D-Ansicht in den Griff, das wir mit den ersten beiden haben.
• Irgendwas web-basiertes in einem Electron Container (Reactive/Angular + irgendeiner web render Nummer wie Babylon). Web (zumindest die beiden genannten SPA frameworks) scheint mir aber vollkommen unfährig mit Plugins umzugehen. Also zusätzliche Bausteine per Plugin nachzuladen.

Und jetzt stehe ich wieder da und weiß nicht weiter. Ich bitte um Diskussion

[ManuelHu]

Entladen von Assemblies geht auch weiterhin mit .NET, dazu gibt es einen neuen Mechanismus (AseemblyLoadContext). Das Sicherheitsproblem bleibt halt. CAS wird ja scheinbar gar nicht mehr unterstützt. Ich habe mein Templating auf eine in .NET implementierte JS-Sandbox umgestellt, das ist aber natürlich für AntMe eher nicht machbar :-)

Ein zweiter Prozess ist damit auch nicht trivial als Sandbox umzusetzen, ohne da plattformabhängige APIs zu nutzen (z.B. seccomp, namespace unter Linux). Der zweite Prozess kann ja per Default immer noch Dateien schreiben und Netzwerkverbindungen nutzen...

• Eto kommt auch noch in Frage, ist recht ähnlich zu Avalonia und benutzt auch einen XAML-Dialekt. Es ist aber eher ein Coomunity-Projekt und wird z.B. für das MonoGame Pipeline Tool verwendet. Auch ich habe das bei einigen Projekten im Einsatz.
  Mit ein wenig Bastelei läuft das plattformunabhängig nativ (also z.B. WPF auf Windows, Gtk3 auf Linux, nativ unter macOS). Mit 3D habe ich da aber auch keine Erfahrung, es gibt aber wohl ein oder zwei Projekte zu. Den Status kenne ich aber nicht. Prinzipiell kann man damit auch Native Controls einbetten, müsste diese aber halt für 3 Plattformen entwickeln.

[TheBlubb14]

Ich stelle mir die Frage ob es überhaupt den Aufwand wert ist den Ameisen Code von der Simulation zu isolieren.
War nicht einer der Gründe, dass Appdomains, so wie sie in .NetFramework existieren, nicht nach .Net5 zu portieren darin dass es, wenn der Anwender es möchte, immer einen Weg geben wird um die Isolation zu umgehen?

[ManuelHu]

Das war ja wohl ein Grund, und auch die Komplexität das zu portieren (insbesondere zu .NET Native...). Es gibt ja zwei verschiedene Probleme: Cheating über Netzwerk/IPC/o.ä. (nicht so wirklich schlimm) und ggf. Malware in gegnerischen Ameisenvölkern... Gegen Cheating im selben Prozess hilft ja schon ein einfacher anderer Prozess mit ein bisschen IPC-Code. Das hilft auch gegen Abstürze mit StackOverflowException (was ggf. häufiger vorkommt bei Programmier-Anfängern?).

[tomwendel]

Ja, den Aufwand zur Isolierung zu treiben ist essentiell. Sicher nicht für die eigene KI, aber spätestens im Multiplayer Modus und für eine Simulation online auf einem zentralen Server. Das ist einerseits Systemschutz, als auch Cheatsicherheit. Der Wegfall der CAS ist mir neu. das muss ich nachprüfen. Dieser Teil ist auch nicht mein primäres Problem.

Viel problematischer ist der UI Kram. Der Mix aus klassischen Form Controls, 3D Rendering und dem plugin getriebenen Ansatz - und das Ganze Plattformübergreifend. Sehe keine perfekte Lösung 🙄

[tomwendel]

CAS nicht mehr da 😱 damit wirds wirklich schwierig bzw. kompliziert. Damit braucht sowohl die Simulation, als auch die eigentliche Ameisenimplementierung einen eigenen Prozess - idealerweise sogar pro Ameise. aber es wird wohl pro Player werden...

[susch19]

Hier mal mein Senf zu CAS Alterantive im .net
Also an einem separaten Prozess wird man vermutlich nur schwierig dran vorbeikommen, denke ich mal. Wir haben das bei unserem Bot System auch so gemacht, aber dort haben wir kein Problem mit Files oder Netzwerkzugriff, eher im Gegenteil. Dort nutzen wir den AssemblyLoadContext nur für Debugging Zwecke, damit alles in einem Prozess läuft.

Aber wie wäre es, wenn man Plugins als "Self Contained Application" builden muss und dann nur einen bestimmten Teil an dlls erlaubt, aber System.IO, System.Net, etc. nicht. Die dlls würden dann nicht mit dem Plugin ausgeliefert werden, sondern mit der AntMe Version. So könnte dann AntMe die erlaubten dlls + plugin in einem seperaten Prozess starten. Wenn jemand System.IO nutzt oder System.Net, dann würde das Plugin bereits beim Laden den Fehler werfen, dass die dll nicht gefunden werden kann.

Das einzige Problem, was ich mit diesem System sehe, sind verschiedene dll Versionen von den Framework dlls, aber hier könnten zumindest ansatzweise binding redirects Abhilfe schaffen, solange die genutzten Funktionen gleiche Signatur haben. Natürlich wäre es auch nicht mehr möglich, dass ein AntMe Plugin in mehrere dlls aufgetrennt werden kann, aber da ist die Frage, ob das überhaupt genutzt wurde oder bisher möglich war.

Bezüglich UI:
OctoAwesome läuft doch Plattformübergreifend ohne Probleme. Klar sind da nicht die schönsten Controls und es fehlen auch einige, aber es wäre zumindest eine Lösung von vermutlich vielen. Monogame zum Beispiel hat auch .net 5 Support, aber die haben glaube ich gar keine Standard Controls, oder?
Gut es gibt ein paar Community UI Frameworks, um mal 2 zu nennen:

• https://github.com/RonenNess/GeonBit.UI
• https://github.com/rds1983/Myra

[jfellien]

Also, wie auf Twitter schon erwähnt, Unity als Engine wäre meine erste Wahl. 2D UI ist einfach und 3D bekommst du geschenkt. Außerdem ein Gameloop und jede Menge Game engine stuff. Als .Net kannst du zwischen 4.7 und .Net Standard aussuchen, wobei ich glaube 4.7 wird bald abgeschafft.

[jfellien]

Der andere Punkt ist scheinbar das dynamische Laden von DLLs und geschriebenem Code. Da denke ich, wäre ein PlugInSystem denkbar, auch unter Unity, denn die Engine läuft separiert von allem, was ausgeführt wird. Ob eine Sandbox eingerichtet werden kann, weiß ich leider nicht. Aber wenn du den Unity Weg gehen würdest, könnte ich ja mal mit Kollegen von mir reden und/oder selber etwas versuchen.

[Gallimathias]

Im Wesentlichen hat Sascha bereits meine Punkte genannt. CAS und die AppDomains stehen beide nicht mehr zur Verfügung. Die Begründung sind sehr vielschichtig. Die Portierung zu Linux stand im Weg, Performance und einige Runtime spezifischen API's die benötigt worden sind bereits deprecated gewesen.

Plugins

Wie bereits erwähnt wären eigene Prozesse möglich (Netzwerk Kommunikation für Remote Extensions oder Sockets wenn auf dem gleichen Rechner). Wir haben damit bereits in unserem Bot experimentiert. Das hätte natürlich den Charm das AntMe! Selbst zwar in .NET geschrieben ist aber jede andere Sprache als Plugin möglich wäre. Es müsste nur eine Art Pluginhost geschrieben werden, der die Kommunikation übernimmt. Diese Flexibilität fänd ich schon cool und würde dem Teaching Charakter von AntMe! Entsprechen.

Dll's direkt laden würde natürlich mit dem AssemblyLoadContext laufen. (Damit klappt nun auch entladen von dlls super) aber natürlich wäre auf diesem Weg das Thema Sicherheit nur deutlich oberflächlicher einsetzbar.

UI

Aus meiner sehr bescheidenen Erfahrung heraus würde ich tatsächlich kein "klassisches" UI Framework verwenden, auch wenn das seine Anreize hätte. Die Möglichkeit auf ein Framework zu setzen das man einbinden kann und einem Arbeit abnimmt, wäre schon charmant. An sich gibt es unglaublich viele Frameworks da draußen, alle haben ihre Pro- und Contras. Da habe ich mit zu wenigen gearbeitet um eine gute Aussage treffen zu können

Zum Thema großer komplett Pakete / Engine ala Unity und wie sie alle heißen würde ich selber nicht greifen. Ich glaube, das passt nicht mit der Philosophie zusammen die du mit AntMe! Vermittelst. Unity als Beispiel macht sicherlich "manche" dinge einfach und schön aussehende. Aber sehr viele Dinge lösen und erzwingen sie auf eine ganz eigene Weise. Da Programmieren vermittelt werden soll und nicht wie man mit Unity umgeht halte ich es nach wie vor Schwierig jemanden vor Unity zu setzen. Und die Engine ist auch für Anfänger meiner Meinung nach viel zu groß.

Die Webvariante könnte eine interessante Möglichkeit darstellen, vor allem wenn man ganz Modern und Barriere los etwas als "as a Service" bereitstellen möchte (s.h. Codegame). Hier würde ich aber nur als Website selbst auf ein SPA Framework setzen. Der Kerninhalt würde ich mit einem JS Gameframework, umsetzen. Hier habe ich bei meinem Workshop mit Phaser eine gute Erfahrung gemacht. Da die Plugins auch Primär eher auf das Spiel selbst aus wären, wäre im Web damit das Pluginthema nicht ganz so wild wie mit einer Reinen Angular oder Vue etc... Lösung, da solche Frameworks sich durchaus leicht erweitern lassen würden.

[tomwendel]

Sehr coole Rückmeldung bisher. Ich danke euch. was die Code Sicherheit angeht ist das schon sehr nah an dem was ich ohnehin (auch für Lets code drones) konzipiert habe.

Beim UI gehts ja in einige Richtungen. Die Unity Idee gefällt mir eigentlich ganz gut. Bei dem bisherigen Spiel gabs ein paar gute Argumente dagegen (Zu lange Startup Zeit, Deterministrik bei der Simulation, Unity lässt sich nicht in der eigenen Applikation hosten,...) die dagegen sprachen. Alles bedingt durch die Art und Weise wie der Spieler aktuell den Debugger startet (Exe wird bei jedem Debug Prozess neu gestartet). Ansonsten wäre der Web-Weg eine Alternative (wie bei drones geplant). nur dann vieles "zu fuß". Lasst uns dazu ein paar PoCs machen.

Also sobald ich mal wieder am Rechner bin werde ich mal kurz skizzieren wie weit ich bei diesen Themen grundsätzlich bin und welche Eckdaten genau erfüllt sein müssen (und warum).

[TheBlubb14]

Hier mal ein paar pro/contra Argumente zu den Engines

Unity

pro

• Einsteiger freundlich
• offizielle C# Unterstützung
• gut fürs Prototyping

contra

• ab 100.000€ Umsatz fallen Gebühren an
• Bugs in Engine fixen selbst nicht möglich, könnte Jahre dauern bis behoben
• .Net 6 Support steht in den Sternen

Unreal

pro

• erst 5% Tantiemen über einem Umsatz von mehr als 1 Mio. €
• soweit ich das in einem Blog Post gelesen habe werden auch Bug Fixes schneller bearbeitet und man kann sie selbst fixen
• .Net 6 Support (Community)
• Visuelles Programmieren per Nodes möglich

contra

• Einstieg schwieriger
• .Net Support inoffiziell