search

dbogatz / node-galaxyboard

A free & simple nodejs bulletin-board
Other
0 stars 0 forks source link

Spacepioneers #6

Open Saw1989 opened 2 years ago

Saw1989 commented 2 years ago

Ich weiss nicht, wie ich anders in Kontakt treten kann.- Gibt es eine Chance an den source code von dem ehemaligen spacepioneers ran zu kommen? Über die früheren (späteren) Betreiber kommt man an nichts mehr ran. Aussagen wie "wir haben keine source codes von alten spielen mehr" bis hin zu "was ist ein source code" lassen mich verzweifeln. Also den alten coyer fragen 😉

mschop commented 2 years ago

Selbst wenn Coyer den Code hätte, dürfte er den dir vermutlich nicht geben, da er das Spiel ja an Looki verkauft hat.

AFAIK hat Coyer ja unter https://galaxytrek.com/ ein neues Game veröffentlicht. Ggf. ist das ja etwas für dich. Das hat glaube ich aber auch leicht andere Mechaniken als Spacepioneers.

dbogatz commented 2 years ago

Ja, wenn ich den Code noch hätte, dürfte ich den ohnehin nicht rausgeben. Looki war damals zu blöd für einen stabilen Serverbetrieb zu sorgen - ich war ja nur noch damit beschäftigt Erstattungsansprüche zu bearbeiten - das war der Hauptgrund warum ich SP verlassen habe. Vertraglich konnte ich die Server nicht mehr selbst betreiben - war wohl zu naiv und gutgläubig. Galaxytrek ist ähnlich aber wurde zur damaligen Zeit wesentlich einfacher gestrickt und mit focus auf Echtzeitaktualisierungen was es damals so noch nicht gab.

Saw1989 commented 2 years ago

Erstmal danke für die Antworten. Schade, das der Source Code nun so im Nirvana verloren geht. Bei dem heutigen Betreiber bekommt man wie erwähnt auch nichts mehr raus- Dann bleibt mir nichts weiter als danke zu sagen! Danke an dich @dbogatz für die legendären und zeitweise anstrengenden Nächte. Wie du siehst gibt es immer noch User, die nach so langer Zeit an dich denken 😉 Sollte der Code mal frei werden/sein, sind wir (als kleine Spielergemeinschaft) gerne bereit unsere Zeit und Geld zu investieren.

dbogatz commented 2 years ago

Danke für die Blumen. Das reale Leben hat mich längst eingeholt und lässt mir wenig Zeit in Richtung SP.

Bei GT steht technisch mal wieder ein Umbau an (erstmal Frontend) - vielleicht wird das ja dann mal auf Github veröffentlicht und vielleicht wird auch mal wieder das ein oder andere Konzept aus SP seinen Weg in GT finden.

mschop commented 2 years ago

SP war damals sehr geil. Mit GT bin ich selbst aus Spielersicht nicht richtig warm geworden, was aber wahrscheinlich an meinem Zeitmangel gelegen haben könnte.

Ggf. könnte man ja auch einen Open-Source-SP-Remake programmieren mit neuesten Technologien. Da würde ich auch auf jeden Fall contributen.

mschop commented 2 years ago

Apropo @dbogatz Ich glaube dieses Repo können wir eigentlich archivieren, oder? Nachdem ich keine Zeit mehr für das Projekt hatte, wurde ja ein PHP basiertes Forum eingerichtet.

Was meinst du?

Saw1989 commented 2 years ago

SP war damals sehr geil. Mit GT bin ich selbst aus Spielersicht nicht richtig warm geworden, was aber wahrscheinlich an meinem Zeitmangel gelegen haben könnte.

Ggf. könnte man ja auch einen Open-Source-SP-Remake programmieren mit neuesten Technologien. Da würde ich auch auf jeden Fall contributen.

GT ebenso schon probiert, trotzdem war es nicht das erwünschte SP. Sonst hätten wir uns nicht die Mühe gemacht in Kontakt zu treten 😇 In Bezug auf ein Open source Remake- tolle Idee, dann mal los 😊

dbogatz commented 2 years ago

Ja das galaxyboard ist ja erstmal tot; könnte man ggf archivieren. Ich hätte das zwar schon gerne irgendwann mal neu aufgelegt, aber zeitlich ist das alles immer ziemlich mau.

Bei GT hatte ich mal eine Version des Frontends auf Basis von REACT angefangen - fand' die Entwicklung aber zu sperrig. Aktuell ist wieder ein Ansatz mit Knockoout+Typescript+Webpack vorhanden. Die bestehende Version von GT umfasst einfach zuviele unterschiedliche Technologien um da noch sinnvolle Änderungen vornehmen zu können.

Bzgl. Opensource hätte ich noch Bedenken das ein Wildwuchs an angepassten Clients entstehen könnte welche diverse Makros/Bots integriert haben.

mschop commented 2 years ago

Ich persönlich glaube nicht, dass es besonders schwer wäre, einen Bot für GT zu schreiben. :thinking:

Im Endeffekt ist ja sämtliches JS und auch die API-Calls/Websocket-Messages offen einsehbar.

Aus Interesse: Bringen denn Websockets / Echtzeitaktualisierungen im Kontext von Browsergames einen so großen Vorteil? Die einzigen Sachen, die mir einfallen sind:

Ansonsten fallen mir keine Funktionen ein, wo das wirklich was bringt, oder?

dbogatz commented 2 years ago

Alles was im Netz läuft kann letztendlich auch per Bot gesteuert werden - dürfte mit einem Opensource-Client aber noch einfacher werden sich da was selbst reinzufummeln.

Auch ohne Echtzeitaktualisierungen kann man ja Aktionen scripten; dies wäre ggf noch schädlicher, da der aktuelle Status "gepollt" werden würde und dies ggf in sehr kurzen Intervallen; machen das viele so, ist das quasi wie eine DDOS Attacke.

mschop commented 2 years ago

Bots

Ich verstehe was du meinst. Es fällt mir jedoch schwer zu glauben, dass das einen großen Unterschied macht. Zumal ich eher darauf setzen würde, eine Verhaltens-basierte Bot-Erkennung zu nutzen. Damit geht man dann wenigstens gegen alle Bots vor.

Vision

Am liebsten würde ich den Stack so einfach wie möglich halten. Insbesondere bei einem Open-Source-Projekt zahlt sich Einfachheit aus. Ich persönlich starte gerade mit Laravel Livewire (https://laravel-livewire.com/) und bin ziemlich begeistert.

Das Problem mit den Echtzeit-Aktualisierungen vs. Polling könnte man lösen, indem man einen klassischen Request-Response-Ansatz mit einem Websocket-Server der nur Events triggert kombiniert. (https://laravel-livewire.com/docs/2.x/events#from-js)

Auf diese Weise würde der Client-Seitige JS-Code fast vollständig weg fallen und die Logiken wären fast zu 100% auf dem Server. Wenn es dann z.B. eine Aktualisierung bei den Flottenbewegungen gibt, könnte man über die Websocket-Verbindung an den Client eine Message schicken, welches dann wieder ein Livewire-Event auslöst.

Vorteile wären:

Bezüglich Galaxyboard

Mir fällt einfach kein Grund ein, warum man das weiter entwickeln oder neu aufsetzen sollte. Es gibt so viele sehr gute Bulletin-Board-Lösungen. Es braucht eigentlich keine weitere.

dbogatz commented 2 years ago

Bots

Ich denke schon das ein offener Quellcode an der Stelle es einfacher macht eigene Clients zu entwickeln die man dann auch nicht erkennen/ausschließen kann. Es sind ja auch Dinge möglich wie das automartische Abgreifen von Daten (z.B. Sonnensysteme) indem man zwar manuell selbst klickt (eine Verhaltensbasierte Erkennung somit kaum greift) aber dennoch die Daten in DBs gesammelt werden.

Vision

Der Techstack sollte einfach und stringent sein - das sehe ich auch so. Laravel ist mir neu - habe eben kurz drübergelesen. PHP ist aber nicht so mein Ding (selbst wenn es seit der 7er oder 8er tatsächlich schnell geworden sein soll).

Mit Typescript hätte man auch in der JS Welt eine brauchbare Lösung bzgl. OOP. Das unterscheidet sich auch nur marginal zum heutigen PHP imho. Komponentenbasierte Ansätze sind ja eher was neueres; ich glaube Webcomponents z.B. gibt es erst seit 2014/2015. Andere Frameworks bieten aber auch gute Ansätze für Komponenten. Die beschriebene Weise der getriggerten Events ist ja heute schon so - das JS im Frontend dient lediglich dazu die UI zu Aktualisieren etc; natürlich hat es da auch Logiken um z.B. Nachrichten in einer virtuellen Liste anzuzeigen da Spieler teilweise mehrere tausend Nachrichten haben und die Browser klassisch sonst tausende Nodes einfügen müssten. Beim Scrolling durch die Nachrichten wird nur der angezeigte Ausschnitt neu berechnet. Sei Dir versichert, das es anders viel zu träge wäre und ich glaube sowas ist auch mit den meisten Frameworks nicht lösbar.

Galaxyboard

Das wäre eine gewisse Dekadenz die es wirklich nicht braucht und die man sich auch leisten können müsste. Dennoch finde ich bestehende Lösungen alle schlecht; ich bin jetzt auch kein Boardmemensch und weiß nicht ob sich im Laufe der Zeit dort etwas getan hat - Standard BBs werden ja regelmäßig von Bots besucht die dort reinspammen; Standard-Plugins für Captchas etc helfen da meist auch nicht. Ein Galaxyboard wäre zu unbedeutend das jemand (außerhalb von GT) Spambots schreiben würde. Zumal das Erweitern dieser PHP Lösungen immer sehr aufwändig sind.

mschop commented 2 years ago

Bots

Ich denke, du hast recht, glaube aber, dass es keine Relevanz hat, da man in dem Fall eines Closed-Source-Programmes es nur erschwert. Ich würde wetten, dass ich es innerhalb von 8h schaffe einen Scanner für die GT-Galaxie zu programmieren.

Vision PHP wird langsam echt Mature. Noch vor 4-5 Jahren habe ich über PHP geflucht. Aber spätestens ab PHP 8.1 ist PHP wirklich in Ordnung. Und dabei beziehe ich mich nicht auf die Performance sondern eher auf Sprach-Features.

Ich bin wegen des zusätzlichen Transpile-Schrittes by Typescript nicht so ein großer Fan von Typescript (oder generell allen Transpilierten Sprachen). Spätestens wenn man Mutation-Testing mache möchte, braucht man ein Testing-Framwork, dass Typescript explizit unterstützt. Zuletzt, wo ich mit Typescript gearbeitet habe (vor 5-6 Jahren) gab es noch keine solches Testing-Framework. Mittlerweile gibt es das wohl. Trotzdem schreckt mit das grundsätzlich ab.

Außerdem macht es ein Transpile-Schritt für Neulinge schwieriger zu contributen.

Aber grundsätzlich ist mir die Technologie eigentlich egal. Geil wäre auch z.B. mal was in Rust (Serverseitig + Clientseitig mit WASM) zu machen. Oder Haskell :heart: . Aber ich glaube, da ist die Anzahl der möglichen Contributor echt klein.

Bezüglich des Endless-Scrollings bei Nachrichten: Das würde man auch gut mit Laravel-Livewire hinbekommen (auch hoch performant). Da mache ich mir keine Sorgen. Selbst wenn es nicht funktionieren würde, könnte man immer noch alternativ Pagination verwenden.

Galaxyboard

Ich bin auch absolut kein Board-Nutzer. Aber bisher habe ich bei den wenigen Malen, wo ich eine Board-Software verwendet habe nicht viel vermisst. Bot-Protection ist natürlich eine andere Sache, aber sollten Recaptcha oder HCaptcha dort nicht eigentlich einen Riegel vorschieben?