Ich dachte mir, dass ein Thread für kurze Projektvorstellungen nützlich wäre, also hier ist einer
Ich hatte neulich Lust, mich ein wenig mit JS-Spielprogrammierung zu befassen, und hab hierfür ein uraltes Schulprojekt von Delphi (:D) portiert. Es ist das klassische „Berühre die Wände nicht“-Spiel, aber mit coolen Paint-Karten ^^ Für eine Pomodoro-Pause sicherlich ganz nett :coding: Unterstützt werden jedoch nur Firefox/Chrome (Desktop), damit ich die Maus auf dem Canvas steuern kann (mit ESC kommt man wieder raus).
Klingt interessant, hab das Thema mal oben festgehalten. @darekkay : hab nen Bug gefunden: spätestens ab level 3 komme ich mit einer schnellen Mausbewegung ganz schnell durch die Levels bis ans Ende der Welt.
@mdickie
Meine Javascript Kenntnisse reichen dafür nicht. Kann halt besser in Java programmieren. @darekkay
Wenn ich die Suchtiefe kleiner stelle, geht es schon schneller. Leider ist es meiner Frau dann zu einfach.
Letztes Jahr mussten wir in der Vorlesung “Clean Code Development” Schach für 3 Spieler umsetzen. Dabei sollten wir uns auch mit gängigen Konzepten auseinandersetzen: TDD, Projektmanagement (Jira), Build-Server/CI (Jenkins), VCS (Mercurial) etc. Ich nutzte die Gelegenheit und zwang unserem Team zusätzlich Maven, DI (Guice) und einen EventBus auf. Meine bisheringen (privaten) Projekte waren zu klein, als dass man effektiv mit den Techniken arbeiten könnte. Dementsprechend war ich bei diesem Projekt hochmotiviert und steckte freiwillig noch etwas mehr Zeit rein. Nun habe ich das Projekt mit Einverständnis der Teammitglieder auf GitHub veröffentlicht. Hier findet ihr das kompilierte Spiel (zip). Die Regeln findet ihr hier.
@darekkay Da hatte mich jetzt doch mal das Hexagon interessiert - ist aber anscheinend ziemlich “manuell” mit vielen “switch”-Konstrukten gelöst. Kürzlich (naja, vor fast einem Jahr) hatte ich mal ein bißchen was von Hexagonal Grids nachgebaut…
@Marco13 Welche switch-Konstrukte meinst du? Das Hexagon besteht aus (x,y) Tupeln. Hiermit werden Gerade und Diagonale definiert, sodass die meisten Schachregeln 1 zu 1 übernommern werden konnten. Das Hexagon ist ein skaliertes Bild, und beim Click wird das zugehörige Feld berechnet. Dazu wird die kürzeste Distanz zum nächsten Hexagon-Feld-Mittelpunkt genommen.
public interface HexagonGrid
{
Point2D getCenter(int x, int y, Point2D p);
Point getNeighbor(int x, int y, int direction, Point p);
Point convertOffsetToCubeCoordinates(int x, int y, Point p);
Point convertCubeToOffsetCoordinates(int x, int y, Point p);
}
class HorizontalEvenShiftedHexagonGrid implements HexagonGrid { ... }
class HorizontalOddShiftedHexagonGrid implements HexagonGrid { ... }
class VerticalEvenShiftedHexagonGrid implements HexagonGrid { ... }
class VerticalOddShiftedHexagonGrid implements HexagonGrid { ... }
(die aber kein “Spielfeld” beschreiben (also keine “Größe” haben), sondern nur die geometrischen/topologischen Eigenschaften eines unendlich großen Hexagon-Grids kapseln…)
Ach, da war ja was. Ich hab das TODO hinzugefügt, als ich den Code gesehen/reviewt habe. Aber wie im “realen Leben” standen wir dann unter Zeitdruck, und Features hatten Vorrang ^^
Das Prinzip dahinter war schon in Ordnung: wir haben ein einfaches Netz mit Feldmittelpunkten “drübergelegt”, und es galt nun die Felder außerhalb des Hexagons auszuschließen. Bei der Implementierung wurde einfach der Anfang und das Ende pro Reihe definiert, was mathematisch etwas schicker lösbar wäre.
Ja, vor Jahren hatte ich mal … naja, zumindest angefangen, ein Abalone (Spiel) – Wikipedia zu implementieren (eigentlich ging es mir da vorrangig um die KI), das ist vom Spielfeld her ähnlich, und da ist mir auch irgendwann aufgefallen, dass das eigentlich nur ein ganz normaler 2D-Array ist, bei dem die Ecken fehlen…
… da man mit steigender Spielesammlung so langsam den Überblick verliert
Außerdem kann ich mir nur die Spiele anzeigen lassen, welche für eine bestimmte Spielerzahl geeignet sind.
Habs mir auch angeschaut und sieht gut aus. Ein Punkt, den ich anders gemacht hätte ist das mit den Daten.
Die Bilder sind im public-Folder und dort hätte ich auch die data/games.json deponiert und nicht im src-Folder.
In der App.js dann nicht das json-File importieren, sondern über einen Request in der componentWillMount-Methode die Daten holen und zum State hinzufügen.
So hätte man dann Frontend und Backend schön getrennt, denn die Daten würden ja meist aus einer Datenbank oder sonstwas bezogen werden und nicht “Hardcodiert” in der Anwendung liegen.
Ich bin ein großer Fan von “Static Site Generators”, und bin etwa mit meinem Blog von Wordpress auf Hexo umgestiegen. Hierbei gibt es keinen Backend, sondern reines HTML + CSS (und evtl. JS). Die gesamte Seite wird immer neu (= statisch) generiert. So funktioniert es auch bei diesem Projekt. Der public Ordner ist nicht der “echte” Ordner auf dem Server. Der Build-Skript packt am Ende alles in den build Ordner.
Wenn ich ein Spiel hinzufüge, muss ich die JSON anpassen (bzw. die YAML, aus der die JSON generiert wird), ein Cover hinzufügen und die Änderungen pushen. Bei meiner Variante kommt “nur” noch der Build-Schritt. Diesen geringen Mehraufwand nehme ich in Kauf, um die Seite völlig statisch zu lassen und ein paar Millisekunden rauszuholen.
Anders sieht es übrigens bei meiner Filmsammlung aus. Hier liegen alle Daten in einer DB, und ich muss tatsächlich nur noch die Cover einchecken. Das ist übrigens weitgehend automatisiert: Die Filme werden mit meiner Festplatte abgeglichen, ich muss dann bloß die entsprechende IMDB ID zuweisen, und die Daten, Cover, Watchlisten und Bewertungen werden aus IMDB geholt. Man könnte sagen, es ist bloß meine persönliche UI für IMDB. Der Performanceunterschied ist beachtlich, wobei ein Vergleich von 50 Spielen mit 1000+ Filmen (sowie Angluar 1 vs React) unfair ist.
Ich übrigens auch. Static Site Generator sind definitiv praktisch und lassen sich gut in Zusammenhang mit Gitlab nutzen (kostenlose private Repositories, CI-Runner, Webhosting und Möglichkeit eigene SSL-Certs einzurichten). Ich spiele schon längere Zeit mit dem Gedanken einen Generator selber zu schreiben (frei nach NIH), Habe aber derzeit nichts brauchbares.
(Dynamic) Context Based Multithreading (CBM) - eine Threading Technologie zur Entwicklung von Multimedia-Anwendungen die eine beliebig dynamische Anzahl von CPU-Kernen nutzen kann.
Im Bild “sieht” man eine kleine mini-Simulation in Action - nunja viel gibt es nicht zu sehen, außer meiner Versicherung dass das Programm alle 8 Kerne meiner CPU nutzt.
Das ganze kann Hand in Hand mit klassischen Workerthreads ergänzt werden, aber hier läuft das ausschließlich mit CBM.
Langsam kommt das Projekt in einen End-Beta-Status. Das Projekt wird aber noch nicht veröffentlicht, weil ich erstmal evaluieren muss ob sich daraus etwas verwertbares machen lässt, möchte das ganze nicht einfach in den Sand setzen.
In den nächsten 2 Monaten muss ich aus beruflichen Gründen das Projekt sowieso mal wieder zur Seite legen bevor ich es fertigstellen kann. Neben ein paar “merkwürdigen” Concurrency-Problemen bei der Initialisierung und einer etwas schickeren API ist das aber bereits in einem sehr brauchbaren Zustand.
