feat(projects): rewrite project texts with verified facts
Old copy was generic and did not match the code. Texts now describe the real features: PlayStation sync, file imports, tests, security. Add per-game itch.io links, new chips, and a test that checks every About project key exists in en and de.
This commit is contained in:
lobo committed
1 parent
106d39453d
commit
8681508cb6
5 files changed
+250
-185
No files matched your search
+92
-84
@@ -187,13 +187,13 @@
|
||||
"PROJECT": {
|
||||
"TBP": {
|
||||
"TITLE": "To Be Played",
|
||||
"DESCRIPTION": "Ein Steam-Backlog-Tracker, der meine Bibliothek importiert, Status, Bewertung und Notizen verwaltet und passend zur verfügbaren Zeit vorschlägt, was ich als Nächstes spiele. Drei selbst gehostete Dienste: Auth, Core und ein React-Frontend.",
|
||||
"DESCRIPTION": "Ein Backlog-Tracker für Steam und PlayStation, der meine Bibliotheken synchronisiert, Status, Bewertung und Notizen verwaltet und passend zur verfügbaren Zeit vorschlägt, was ich als Nächstes spielen kann. Drei selbst gehostete Dienste: Auth, Core und ein React-Frontend.",
|
||||
"LINK_EXTERNAL": "tbp.andreas-dahm.eu",
|
||||
"LINK_INTERNAL": "Projektdetails",
|
||||
"HIGHLIGHTS": {
|
||||
"P1": "Steam-Sync von Spielen, Spielzeit, Erfolgen und Wunschliste, dazu die Spieldauer (Time to Beat) aus IGDB.",
|
||||
"P2": "Vorschläge für „Was spiele ich als Nächstes?“, gefiltert nach Zeitbudget und Stimmung.",
|
||||
"P3": "Der Auth-Service signiert die Tokens mit Ed25519, Core kennt nur den öffentlichen Schlüssel."
|
||||
"P1": "Steam- und PlayStation-Sync von Spielen, Spielzeit, Erfolgen und Trophäen, dazu die Spieldauer (Time to Beat) aus IGDB.",
|
||||
"P2": "„Was spiele ich als Nächstes?“: sieben Reihen mit Vorschlägen, gefiltert nach Zeitbudget; ein Stimmungsfilter für die Zufallsvorschläge.",
|
||||
"P3": "Auth signiert die Tokens mit Ed25519; Core holt den öffentlichen Schlüssel über die Key-ID und prüft nur."
|
||||
}
|
||||
},
|
||||
"CLAUDE_BOX": {
|
||||
@@ -208,55 +208,55 @@
|
||||
},
|
||||
"P2": {
|
||||
"TITLE": "Playground",
|
||||
"DESCRIPTION": "Dieses Projekt ist, wie der Name schon sagt, ein persönlicher Playground, der im Laufe der Zeit wachsen soll. Es präsentiert verschiedene private Projekte, an denen ich arbeite, und dokumentiert deren Fortschritt, zentrale Ideen und wichtige Meilensteine.",
|
||||
"DESCRIPTION": "Diese Seite. Ein Portfolio und ein Ort, um Algorithmen im Browser auszuprobieren: Pfadfindung, Sortieren, Fraktale in GLSL sowie eine Stoff- und eine Doppelpendel-Simulation als WebGPU-Compute-Shader. Angular, Deutsch und Englisch, gebaut und ausgeliefert von meiner eigenen CI.",
|
||||
"LINK_EXTERNAL": "andreas-dahm.eu",
|
||||
"LINK_INTERNAL": "Projektdetails",
|
||||
"HIGHLIGHTS": {
|
||||
"P1": "Moderner Frontend-Stack und eine CI/CD-Pipeline mit Gitea Actions (Angular, Docker).",
|
||||
"P2": "Präsentation persönlicher Projekte und kontinuierliche Verbesserung algorithmischer Fähigkeiten.",
|
||||
"P3": "Vertiefung von JavaScript/TypeScript- und Angular-Kenntnissen durch praktisches Arbeiten."
|
||||
"P1": "Visualisierungen von Dijkstra bis zu 3D-Fraktalen per Raymarching, alles im Client.",
|
||||
"P2": "Zwei WebGPU-Compute-Simulationen (Stoff mit XPBD, Doppelpendel) mit CPU- oder WebGL-Fallback.",
|
||||
"P3": "Pipeline auf Gitea Actions: Lint, i18n-Prüfung, Tests, Lighthouse, Docker-Image in meine eigene Registry."
|
||||
}
|
||||
},
|
||||
"P1": {
|
||||
"TITLE": "El Mucho",
|
||||
"DESCRIPTION": "Dies ist mein erstes veröffentlichtes Spiel auf Steam. Ich habe es gemeinsam mit meinem Bruder entwickelt und damit eines meiner persönlichen Ziele erreicht: ein eigenes Videospiel zu erstellen und zu veröffentlichen.",
|
||||
"DESCRIPTION": "Mein erstes veröffentlichtes Spiel, ein rundenbasiertes taktisches Rollenspiel, das ich mit meinem Bruder in etwa drei Jahren gemacht und 2022 auf Steam veröffentlicht habe. Er hat es entworfen, ich habe es gebaut.",
|
||||
"LINK_EXTERNAL": "Steam Store",
|
||||
"LINK_INTERNAL": "Projektdetails",
|
||||
"HIGHLIGHTS": {
|
||||
"P1": "Veröffentlichung eines Spiels auf Steam und Integration der Steam-API.",
|
||||
"P2": "Konzeption, Planung und vollständige Entwicklung eines eigenen Spiels.",
|
||||
"P3": "Implementierung komplexer Algorithmen wie einer eigenen A*-Pfadfindungslogik und Spiel-KI."
|
||||
"P1": "Der gesamte Code in Unity (C#), die Builds, das Steam-Setup und der Release.",
|
||||
"P2": "16 Missionen, Erfolge, drei Sprachen (EN, DE, ES).",
|
||||
"P3": "Eine eigene KI für die gegnerischen Einheiten und mein eigenes A*-Pathfinding auf dem Kartenraster."
|
||||
}
|
||||
},
|
||||
"P0": {
|
||||
"TITLE": "Game Jams",
|
||||
"DESCRIPTION": "Dieser Bereich zeigt einige meiner bisherigen Game-Jam-Beiträge. Game Jams sind eine großartige Möglichkeit, neue Spielideen auszuprobieren und schnell zu überprüfen, ob ein Game-Loop funktioniert. Die engen Zeitvorgaben fördern den Fokus, es ist faszinierend, was man in so kurzer Zeit alles schaffen kann.",
|
||||
"DESCRIPTION": "Drei 48-Stunden-Jam-Spiele aus der BeansJam-Reihe, in Teams aus zwei oder drei Leuten. Ich war jedes Mal Programmierer und Leiter. Alle sind auf itch.io spielbar.",
|
||||
"LINK_EXTERNAL": "Itch.io Sammlung",
|
||||
"LINK_INTERNAL": "Projektdetails",
|
||||
"HIGHLIGHTS": {
|
||||
"P1": "Planung eines realistischen Projektumfangs mit einem Team, der innerhalb von 48 Stunden umsetzbar ist.",
|
||||
"P2": "Lernen, fokussiert und effizient unter strengen Zeitvorgaben zu arbeiten.",
|
||||
"P3": "Die Freude zu erleben, in kurzer Zeit ein spielbares Projekt zu erstellen und andere damit spielen zu sehen."
|
||||
"P1": "Peter Blue and the carnival of death (2018), Arkonauts (2020), Sloth Bros (2022).",
|
||||
"P2": "Freitag bis Sonntag: jedes Mal ein spielbares Spiel in 48 Stunden.",
|
||||
"P3": "Ein günstiger Weg, herauszufinden, ob eine Spielidee funktioniert, bevor man Jahre in sie steckt."
|
||||
}
|
||||
},
|
||||
"DIPLOMA": {
|
||||
"TITLE": "Diplomarbeit - Kollisionserkennung und Behandlung von komplexen Kleidungsstücken.",
|
||||
"DESCRIPTION": "Die Diplomarbeit handelt von der Erkennung und der Behandlung von Kollisionen zwischen, sowie innerhalb, einzelnen Kleidungsstücken in Echtzeit. Das ist gerade aufgrund der Flexibilität von Stoffen und deren unterschiedlichen Eigenschaften besonders herausfordernd.",
|
||||
"DESCRIPTION": "Selbstdurchdringungen innerhalb eines Kleidungsteils, etwa bei einem Plisseerock, in der Stoffsimulation Vidya bei assyst. Ich habe Intersection Contour Minimization an Vidyas k-DOP-Hierarchie angepasst und die Antwort um Masse und Geschwindigkeit erweitert. FH Bingen, März 2010.",
|
||||
"LINK_INTERNAL": "Projektdetails",
|
||||
"HIGHLIGHTS": {
|
||||
"P1": "Echtzeit behandlung von Kollisionserkennung und Behandlung.",
|
||||
"P2": "Verstehen und Einschätzen von wissenschaftlichen Arbeiten.",
|
||||
"P3": "Adaption und Weiterentwicklung von vorausgegangenen Forschungsarbeiten."
|
||||
"P1": "Erkennung auf der vorhandenen BVH mit k-DOPs; eine gemeinsame Hierarchie hat die Zeit für Update und Traversierung halbiert.",
|
||||
"P2": "Vier veröffentlichte Methoden verglichen und die globale Variante der Intersection Contour Minimization gewählt.",
|
||||
"P3": "Etwa 20 % schneller als der vorhandene Selbstkollisions-Detektor plus Layering, für den produktiven Einsatz vorgesehen."
|
||||
}
|
||||
},
|
||||
"TRIBBLE": {
|
||||
"TITLE": "Homeserver 'Tribble'",
|
||||
"DESCRIPTION": "In diesem Projekt geht es um die Einrichtung und Wartung meines eigenen Homeservers. Er betreibt mehrere Docker-Container wie Gitea, Jellyfin and more. Es ist eine großartige Lernerfahrung im Bereich Self-Hosting und Systemadministration.",
|
||||
"DESCRIPTION": "Ein Mini-PC zu Hause betreibt Gitea mit Actions-Runner und Registry, dazu Jellyfin, Paperless-ngx und AdGuard Home. Ein VPS liefert die öffentlichen Seiten aus und holt neue Images mit Watchtower über Tailscale. Läuft seit Mai 2024, Backups auf Google Drive.",
|
||||
"LINK_INTERNAL": "Projektdetails",
|
||||
"HIGHLIGHTS": {
|
||||
"P1": "Self-Hosting verschiedener Dienste mit Docker.",
|
||||
"P2": "CI/CD-Pipeline für die persönliche Website mit Gitea.",
|
||||
"P3": "Sicherer Fernzugriff mit Tailscale und Traefik."
|
||||
"P1": "Gitea-CI baut und testet diese Seite und To Be Played zu Hause; Watchtower spielt die Images auf dem VPS ein.",
|
||||
"P2": "Traefik für TLS und Routing, Tailscale zwischen den beiden Maschinen.",
|
||||
"P3": "Schwierig waren DNS und ein wiederholbares Setup, nicht die Dienste selbst."
|
||||
}
|
||||
}
|
||||
},
|
||||
@@ -309,69 +309,75 @@
|
||||
"LEARNINGS": "Learnings & Soft Skills"
|
||||
},
|
||||
"PLAYGROUND": {
|
||||
"TITLE": "Playground Portfolio",
|
||||
"SHORT_DESCRIPTION": "Frontend-Portfolio mit interaktiven Algorithmus-Visualisierungen.",
|
||||
"INTRODUCTION": "Diese Website dient als lebendiges Portfolio und Testumgebung für moderne Webtechnologien. Ziel ist es, komplexe Algorithmen und mathematische Konzepte (wie WebGPU-Simulationen oder Raymarching) anschaulich im Browser darzustellen.",
|
||||
"BULLET_1": "Entwicklung mit Angular und Material Design.",
|
||||
"BULLET_2": "Implementierung performanter Visualisierungen (WebGPU, Shader, Canvas).",
|
||||
"BULLET_3": "Automatisierte CI/CD mit Gitea Actions und Containerisierung mit Docker.",
|
||||
"BULLET_4": "Internationalization (i18n) für globale Reichweite.",
|
||||
"CHALLENGE_1": "Optimierung der Render-Performance bei komplexen 3D-Fraktalen in Echtzeit.",
|
||||
"CHALLENGE_2": "Architektur einer skalierbaren und wartbaren Frontend-Struktur für diverse Sub-Projekte.",
|
||||
"LEARNING_1": "Effektives UI/UX-Design für komplexe datengesteuerte Visualisierungen.",
|
||||
"LEARNING_2": "Modernstes State-Management und reaktive Programmierung in Angular."
|
||||
"TITLE": "Playground",
|
||||
"SHORT_DESCRIPTION": "Diese Seite: ein Portfolio mit Algorithmus-Visualisierungen, die im Browser laufen, einige davon auf der GPU.",
|
||||
"INTRODUCTION": "Auf dieser Seite probiere ich Dinge aus. Ich wollte sehen, wie weit ein normaler Browser mit den Algorithmen kommt, die ich mag. Deshalb läuft jede Visualisierung im Client: Pfadfindung, Labyrinth-Erzeugung, Sortieren, Conways Spiel des Lebens, Fraktale in GLSL-Shadern und zwei Physiksimulationen, die als Compute Shader auf WebGPU laufen. Der Rest ist eine normale Angular-App mit deutschen und englischen Texten, einem Dark Mode und einer CI-Pipeline, die sie baut, testet und als Docker-Image in meine eigene Registry schiebt.",
|
||||
"BULLET_1": "Pfadfindung mit Dijkstra und A*, Labyrinth-Erzeugung mit Prim und Kruskal, fünf Sortieralgorithmen mit Ton, Conways Spiel des Lebens und eine Vier-Farben-Karte.",
|
||||
"BULLET_2": "2D-Fraktale (Mandelbrot, Julia, Burning Ship, Newton) in einem GLSL-Shader und 3D-Fraktale (Mandelbulb, Mandelbox, Julia-Bulb) per Raymarching, mit Normalen aus dem Distanzfeld.",
|
||||
"BULLET_3": "Ein Doppelpendel und eine Stoffsimulation laufen als Compute Shader auf WebGPU. Ohne WebGPU weichen sie auf die CPU oder WebGL aus und sagen das in einer Snackbar.",
|
||||
"BULLET_4": "Angular mit Material und Tailwind, Signals für den Zustand, Deutsch und Englisch und ein Service Worker (PWA).",
|
||||
"BULLET_5": "CI auf Gitea Actions: Lint, i18n-Prüfung, Tests, Produktions-Build und ein Lighthouse-Bericht. Auf main baut sie ein Docker-Image und schiebt es in meine eigene Registry.",
|
||||
"CHALLENGE_1": "Der Stoff-Solver auf der GPU. XPBD-Constraints, die sich einen Partikel teilen, lassen sich nicht parallel lösen, ohne dass es zu einem Race kommt. Ich gruppiere die Constraints per Graphfärbung in acht Phasen. So berühren sich innerhalb einer Phase nie zwei Constraints am selben Partikel, und jede Phase läuft voll parallel.",
|
||||
"CHALLENGE_2": "Nicht jeder Browser hat WebGPU. Beide Simulationen haben einen CPU- oder WebGL-Pfad und eine Snackbar, die sagt, dass der Fallback aktiv ist. So funktioniert die Seite überall, und niemand fragt sich, warum es langsamer ist.",
|
||||
"LEARNING_1": "Compute Shader verändern, wie man über einen Algorithmus denkt. Das Datenlayout und die Reihenfolge der Schreibzugriffe zählen mehr als die Mathematik.",
|
||||
"LEARNING_2": "Eine kleine CI mit einer Schlüssel-Prüfung für die Übersetzungen und einem Lighthouse-Lauf fängt die langweiligen Fehler ab, eine fehlende Übersetzung oder eine langsame Seite, bevor ich sie auf der Live-Seite sehe."
|
||||
},
|
||||
"TRIBBLE": {
|
||||
"TITLE": "Self-Hosted Infrastructure",
|
||||
"SHORT_DESCRIPTION": "Home-Server für CI und private Dienste, dazu ein VPS für die öffentlichen Seiten.",
|
||||
"INTRODUCTION": "Zwei Maschinen: Der Home-Server „Tribble“ betreibt Gitea mit Actions-Runner und die privaten Dienste, ein Hostinger-VPS liefert die öffentlichen Seiten aus. Die CI baut die Images zu Hause, der VPS zieht neue Images mit Watchtower über Tailscale, und Traefik leitet die öffentlichen Seiten weiter.",
|
||||
"BULLET_1": "Zentrale Verwaltung via Docker-Compose und Portainer.",
|
||||
"BULLET_2": "Automatisches SSL-Management und Reverse-Proxy mit Traefik.",
|
||||
"BULLET_3": "Private Versionskontrolle und CI mit Gitea, Medien-Streaming mit Jellyfin.",
|
||||
"BULLET_4": "Netzwerkweite Ad-Blocking und DNS-Kontrolle via AdGuard Home.",
|
||||
"CHALLENGE_1": "Konfiguration sicherer Netzwerkschichten und Firewall-Regeln für Remote-Zugriff.",
|
||||
"CHALLENGE_2": "Automatisierung von Backups und Recovery-Strategien für containerisierte Daten.",
|
||||
"LEARNING_1": "Tiefes Verständnis für moderne Netzwerkprotokolle und IT-Sicherheit.",
|
||||
"LEARNING_2": "Effizientes Ressourcen-Management auf limitierten Server-Systemen."
|
||||
"INTRODUCTION": "Zwei Maschinen. Zu Hause läuft auf einem Mini-PC namens „Tribble“ Gitea mit Actions-Runner und Container-Registry, dazu die privaten Dienste. Ein Hostinger-VPS liefert die öffentlichen Seiten aus, auch diese hier. Ein Git-Push baut das Image zu Hause, der VPS holt es mit Watchtower über Tailscale, und Traefik übernimmt TLS und Routing. Das Ganze läuft seit Mai 2024.",
|
||||
"BULLET_1": "Hardware: ein KODLIX GD50 Mini-PC mit 8-Kern-Intel-Core-i5, 32 GB RAM und einer 512-GB-SSD.",
|
||||
"BULLET_2": "Gitea für Git, den Actions-Runner und die Container-Registry. Diese Seite und To Be Played werden dort gebaut und getestet.",
|
||||
"BULLET_3": "Private Dienste: Jellyfin für Medien, Paperless-ngx für Dokumente, AdGuard Home für DNS und Werbeblocker, Portainer, um die Container im Blick zu haben, und Traefik davor.",
|
||||
"BULLET_4": "Tailscale verbindet die beiden Maschinen. Darüber holt der VPS neue Images aus der Registry zu Hause, und Watchtower tauscht den laufenden Container aus.",
|
||||
"BULLET_5": "Die Backups gehen auf Google Drive.",
|
||||
"CHALLENGE_1": "DNS. Namen müssen aus dem Haus, über Tailscale und aus dem öffentlichen Internet auf die richtige Adresse zeigen, und AdGuard Home sitzt mittendrin. Das richtig hinzubekommen hat länger gedauert als jeder einzelne Dienst.",
|
||||
"CHALLENGE_2": "Alles gleichzeitig zum Laufen zu bringen und es dann wiederholbar zu machen. Das erste Setup war eine lange Liste von Handgriffen. Ich habe es automatisiert, damit sich der Server neu aufsetzen lässt, ohne dass ich mir jeden Schritt merken muss.",
|
||||
"LEARNING_1": "Selbst hosten kostet wenig Geld und viel Zeit. Die meiste Zeit geht in die Teile, die niemand sieht: DNS, Zertifikate und Backups.",
|
||||
"LEARNING_2": "Ein Git-Push, der ohne Handgriff dazwischen in einem laufenden Container auf dem VPS endet, ist der Teil dieses Setups, den ich nicht mehr hergeben würde."
|
||||
},
|
||||
"EL_MUCHO": {
|
||||
"TITLE": "El Mucho (Steam Release)",
|
||||
"SHORT_DESCRIPTION": "Rundenbasiertes Taktik-RPG, veröffentlicht auf Steam.",
|
||||
"INTRODUCTION": "Ein kommerzielles Spiel, das mein Bruder und ich von der ersten Idee bis zum Release auf Steam gebracht haben: geplant, gebaut, verkauft. Ein taktisches RPG, das klassische Gameplay-Elemente mit modernen Systemen verbindet.",
|
||||
"BULLET_1": "Spielentwicklung in Unity (C#).",
|
||||
"BULLET_2": "Integration von Steamworks-Funktionen (Achievements, Cloud Saves).",
|
||||
"BULLET_3": "Entwicklung einer eigenen taktischen KI und Pfadfindungs-Logik.",
|
||||
"BULLET_4": "Management des gesamten Asset-Pipelines und Sound-Designs.",
|
||||
"CHALLENGE_1": "Implementierung eines robusten rundenbasierten Systems mit komplexen Abhängigkeiten.",
|
||||
"CHALLENGE_2": "Performance-Optimierung für eine flüssige Darstellung auf verschiedenen Hardware-Profilen.",
|
||||
"LEARNING_1": "Durchhaltevermögen und Fokus über einen mehrjährigen Entwicklungszyklus.",
|
||||
"LEARNING_2": "Vermarktung und Community-Management für ein digitales Produkt."
|
||||
"SHORT_DESCRIPTION": "Ein rundenbasiertes taktisches Rollenspiel, das mein Bruder und ich auf Steam veröffentlicht haben.",
|
||||
"INTRODUCTION": "El Mucho ist ein rundenbasiertes taktisches Rollenspiel in einer erfundenen Welt namens Liberika, inspiriert von Langrisser. Mein Bruder und ich haben es in etwa drei Jahren neben einem Vollzeitjob gebaut und auf Steam veröffentlicht: Early Access im Juli 2021, die Vollversion im Februar 2022. Die Aufteilung war klar. Er hatte die Idee und hat die Assets, das Leveldesign, das Testen und das Balancing gemacht. Ich habe alles Technische gemacht: den Code in Unity, die Builds, das Steam-Setup und den Release.",
|
||||
"BULLET_1": "Unity und C#. Ein Entwickler für den gesamten Code.",
|
||||
"BULLET_2": "16 Missionen, Erfolge und Familienfreigabe auf Steam, veröffentlicht als Lobo Corp.",
|
||||
"BULLET_3": "Englisch, Deutsch und Spanisch. Die spanische Übersetzung hat ein Freund gemacht, der Muttersprachler ist.",
|
||||
"BULLET_4": "Grafik und Musik sind teils Open Source, teils von meinem Bruder, teils von mir.",
|
||||
"CHALLENGE_1": "Der Steam-Release als Ein-Personen-Technikteam. Builds, Store-Einrichtung, Upload und die Early-Access-Phase liefen alle über mich. Early Access startete im Juli 2021, die Vollversion folgte im Februar 2022.",
|
||||
"CHALLENGE_2": "Drei Sprachen. Jeden Text gibt es auf Englisch, Deutsch und Spanisch; für Spanisch habe ich mit einem Freund zusammengearbeitet, der Muttersprachler ist.",
|
||||
"CHALLENGE_3": "Die gegnerischen Einheiten. Dafür habe ich eine eigene KI und mein eigenes A*-Pathfinding auf dem Kartenraster geschrieben.",
|
||||
"LEARNING_1": "Fertigmachen dauert länger als Bauen. Allein die Strecke vom Early Access bis zur Vollversion hat etwa sieben Monate gedauert.",
|
||||
"LEARNING_2": "Eine klare Rollenverteilung hat ein Zwei-Personen-Team drei Jahre lang arbeitsfähig gehalten: Er war für das Spiel zuständig, ich für den Code und den Release."
|
||||
},
|
||||
"GAME_JAMS": {
|
||||
"TITLE": "Rapid Prototyping & Game Jams",
|
||||
"SHORT_DESCRIPTION": "Sammlung innovativer Spielkonzepte, entstanden in unter 48 Stunden.",
|
||||
"INTRODUCTION": "Teilnahme an nationalen Wettbewerben (z.B. Beansjam). Hier geht es darum, unter extremem Zeitdruck funktionale und spaßige Prototypen zu erschaffen.",
|
||||
"BULLET_1": "Fokus on 'Core Game Loop' und schnelles Feedback.",
|
||||
"BULLET_2": "Kollaborative Entwicklung in kleinen, agilen Teams.",
|
||||
"BULLET_3": "Effektives Zeitmanagement und Scope-Kontrolle.",
|
||||
"BULLET_4": "Veröffentlichung und Iteration basierend auf Community-Votings.",
|
||||
"CHALLENGE_1": "Reduzierung komplexer Ideen auf ein in 48h umsetzbares Minimum Viable Product (MVP).",
|
||||
"CHALLENGE_2": "Schnelle Fehlerdiagnose und Bugfixing unter massivem Zeitdruck.",
|
||||
"LEARNING_1": "Radikale Priorisierung von Features ('Kill your darlings').",
|
||||
"LEARNING_2": "Effektive Kommunikation und Entscheidungsfindung im Team-Stress."
|
||||
"TITLE": "Game Jams",
|
||||
"SHORT_DESCRIPTION": "Drei kleine Spiele, jedes in 48 Stunden von Freitag bis Sonntag entstanden.",
|
||||
"INTRODUCTION": "Bei einer Game Jam bekommt man am Freitagabend ein Thema und soll bis Sonntag ein spielbares Spiel abliefern. Ich habe bisher drei gemacht, alle in der BeansJam-Reihe, in Teams aus zwei oder drei Leuten. Ich war immer Programmierer und Leiter; die anderen haben Ideen, Assets und Tests beigesteuert. Alle drei Spiele gibt es auf itch.io.",
|
||||
"BULLET_1": "Peter Blue and the carnival of death (2018, BeansJam): meine erste Jam.",
|
||||
"BULLET_2": "Arkonauts (2020, Mini Beans Jam 6): Space Invaders im Weltraum.",
|
||||
"BULLET_3": "Sloth Bros (2022, BeansJam '22): Thema „wir müssen wach bleiben“, eines von 65 Spielen.",
|
||||
"BULLET_4": "Immer 48 Stunden, von Freitag bis Sonntag, in einem Team aus zwei oder drei Leuten.",
|
||||
"CHALLENGE_1": "Der Umfang. 48 Stunden sind nicht viel, und mit Schlaf sind es weniger. Am Freitag zu entscheiden, was wir nicht bauen, war in jeder Jam die wichtigste Entscheidung.",
|
||||
"CHALLENGE_2": "Als einziger Programmierer. Alles, was sich das Team ausgedacht hat, ging durch meine Tastatur. Eine Idee musste also billig zu bauen sein, sonst wurde sie gestrichen.",
|
||||
"LEARNING_1": "Eine spielbare Schleife am Samstag schlägt eine bessere Idee am Sonntag.",
|
||||
"LEARNING_2": "In einer Jam finde ich heraus, ob eine Spielidee funktioniert, bevor ich Jahre in sie stecke. El Mucho hat drei Jahre gedauert; ein Jam-Spiel dauert ein Wochenende.",
|
||||
"LINK_COLLECTION": "Alle Spiele auf itch.io"
|
||||
},
|
||||
"DIPLOMA": {
|
||||
"TITLE": "Wissenschaftliche Diplomarbeit",
|
||||
"SHORT_DESCRIPTION": "Echtzeit-Kollisionserkennung für komplexe, flexible 3D-Objekte.",
|
||||
"INTRODUCTION": "Forschungsarbeit im Bereich Computergraphik. Entwicklung eines Algorithmus zur physikalisch korrekten Simulation von Stoffen und Kleidung in Echtzeit.",
|
||||
"BULLET_1": "Mathematische Modellierung von Mass-Spring-Systemen.",
|
||||
"BULLET_2": "Low-Level Programmierung mit Java.",
|
||||
"BULLET_3": "Optimierung durch räumliche Datenstrukturen (AABB Trees, Bounding Spheres).",
|
||||
"BULLET_4": "Wissenschaftliche Evaluation der Simulations-Präzision.",
|
||||
"CHALLENGE_1": "Behandlung von 'Self-Collisions' bei hochauflösenden Meshes ohne Performance-Einbruch.",
|
||||
"CHALLENGE_2": "Mathematische Stabilisierung der Integrationsverfahren bei hohen Krafteinwirkungen.",
|
||||
"LEARNING_1": "Transfer von theoretischen Forschungsarbeiten in produktiven, performanten Code.",
|
||||
"LEARNING_2": "Präzises Arbeiten und Dokumentation nach wissenschaftlichen Standards."
|
||||
"TITLE": "Diplomarbeit: Selbstkollisionen bei Stoffen",
|
||||
"SHORT_DESCRIPTION": "Selbstdurchdringungen in simulierter Kleidung erkennen und auflösen, entstanden bei assyst für die Stoffsimulation Vidya (2010).",
|
||||
"INTRODUCTION": "Simulierter Stoff faltet sich in sich selbst. Ein Plisseerock durchdringt zum Beispiel sein eigenes Gewebe, und sobald zwei Teile eines Kleidungsstücks durcheinander gerutscht sind, kann eine normale Kollisionsantwort sie nicht mehr trennen. Kollisionen zwischen verschiedenen Lagen konnte Vidya schon; Selbstdurchdringungen innerhalb eines Kleidungsteils nicht. In meiner Diplomarbeit bei assyst habe ich Intersection Contour Minimization (Volino et al. 2006) an Vidya angepasst und so erweitert, dass die Antwort Masse und Geschwindigkeit berücksichtigt. Geschrieben in Java, im März 2010 an der FH Bingen abgeschlossen und für den produktiven Einsatz vorgesehen.",
|
||||
"BULLET_1": "Die Erkennung läuft auf Vidyas vorhandener Bounding-Volume-Hierarchie mit k-DOPs. Bei Selbsttests überspringt die Traversierung die Tests an inneren Knoten, die sie nicht braucht.",
|
||||
"BULLET_2": "Die Schnittkontur wird aus Segmenten aufgebaut. Ein räumlicher Hash verbindet sie auch dann, wenn Gleitkommafehler kleine Lücken lassen.",
|
||||
"BULLET_3": "Die Antwort ist meine Erweiterung: Sie nutzt Masse und Geschwindigkeit, sodass das Ergebnis physikalisch plausibel ist und nicht nur ein geometrischer Schubs.",
|
||||
"BULLET_4": "Der Parameter h0 wird aus der mittleren Dreiecksfläche abgeleitet und muss daher nicht von Hand eingestellt werden.",
|
||||
"BULLET_5": "Die Methode teilt sich eine BVH mit Vidyas vorhandenem TriangleSelfCollisionDetector.",
|
||||
"CHALLENGE_1": "Der Aufwand. Die Testszene hatte etwa 16.000 Partikel bei etwa 430 ms pro Schritt auf einem 2-GHz-Core-2-Duo. Eine gemeinsame BVH für meinen Detektor und den vorhandenen hat die Zeit für Update und Traversierung halbiert und den Overhead um etwa 80 % gesenkt. Zusätzlich zur vorhandenen Erkennung kostet die Methode etwa 5 %.",
|
||||
"CHALLENGE_2": "Die Wahl der Methode. Ich habe Baraff (2003), Bridson (2002) und Volino (2000, 2006) verglichen und die globale Variante der Intersection Contour Minimization genommen, weil sie auch Durchdringungen auflöst, die schon bestehen.",
|
||||
"CHALLENGE_3": "Bekannte Grenzen, dokumentiert: nahezu ebene Flächen und ein Vertex, der genau auf einer Dreiecksebene liegt, werden nicht behandelt.",
|
||||
"LEARNING_1": "Paper richtig lesen. Das gleiche Problem hatte vier veröffentlichte Lösungen, und die nützliche Arbeit war zu verstehen, wo jede davon scheitert.",
|
||||
"LEARNING_2": "Erst messen, dann behaupten. Die Methode allein war etwa 20 % schneller als der vorhandene Detektor plus Layering, und diese Zahl zählt nur, weil sie aus derselben Szene auf derselben Maschine stammt."
|
||||
},
|
||||
"CLAUDE_BOX": {
|
||||
"TITLE": "Claude-in-a-Box",
|
||||
@@ -389,17 +395,19 @@
|
||||
},
|
||||
"TBP": {
|
||||
"TITLE": "To Be Played",
|
||||
"SHORT_DESCRIPTION": "Ein Steam-Backlog-Tracker, der bei der Entscheidung hilft, was als Nächstes gespielt wird.",
|
||||
"INTRODUCTION": "Meine Steam-Bibliothek hat weit mehr Spiele, als ich je durchspielen werde. To Be Played importiert die Bibliothek, verwaltet den Backlog mit Status, Bewertung und Notizen und schlägt passend zur verfügbaren Zeit vor, was ich als Nächstes spielen kann. Dahinter stehen drei Dienste: ein Auth-Service, der die Login-Tokens signiert, ein Core-Service für Bibliothek und Statistiken und ein React-Frontend. Alles läuft selbst gehostet auf demselben Server wie diese Seite.",
|
||||
"BULLET_1": "Steam-Sync von Spielen, Spielzeit, Erfolgen und Wunschliste, von Hand und jede Nacht, dazu die Spieldauer (Time to Beat) aus IGDB.",
|
||||
"BULLET_2": "„Was spiele ich als Nächstes?“: sieben Reihen mit Vorschlägen, etwa der nächste Teil einer Reihe, dasselbe Studio oder Spiele, die Leute durchgespielt haben, denen man folgt, gefiltert nach Zeitbudget und Stimmung.",
|
||||
"SHORT_DESCRIPTION": "Ein Backlog-Tracker für Steam und PlayStation, der bei der Entscheidung hilft, was als Nächstes gespielt wird.",
|
||||
"INTRODUCTION": "Meine Spielebibliothek hat weit mehr Spiele, als ich je durchspielen werde. To Be Played synchronisiert Steam und PlayStation, importiert Listen von GOG, Playnite, Grouvee und HowLongToBeat, verwaltet den Backlog mit Status, Bewertung und Notizen und schlägt passend zur verfügbaren Zeit vor, was ich als Nächstes spielen kann. Dahinter stehen drei Dienste: ein Auth-Service, der die Login-Tokens signiert, ein Core-Service für Bibliothek und Statistiken und ein React-Frontend. Alles läuft selbst gehostet auf demselben Server wie diese Seite.",
|
||||
"BULLET_1": "Steam-Sync von Spielen, Spielzeit, Erfolgen und Wunschliste, PlayStation-Sync von Titeln, Spielzeit und Trophäen, von Hand und jede Nacht, dazu die Spieldauer (Time to Beat) aus IGDB.",
|
||||
"BULLET_2": "„Was spiele ich als Nächstes?“: sieben Reihen mit je drei Vorschlägen, etwa der nächste Teil einer Reihe, dasselbe Studio oder Spiele, die Leute gespielt oder durchgespielt haben, denen man folgt. Ein Zeitbudget filtert jede Reihe; der Stimmungsfilter wirkt nur auf die Zufallsvorschläge.",
|
||||
"BULLET_3": "Öffentliche Profile, anderen Spielern folgen mit einer Inbox zu ihrem Fortschritt und Pile Points für jedes Spiel, das vom Stapel kommt.",
|
||||
"BULLET_4": "Deutsch und Englisch, Light- und Dark-Mode, auch auf dem Handy nutzbar. Auth, Core und Frontend werden jeweils als eigenes Docker-Image ausgeliefert.",
|
||||
"CHALLENGE_1": "Login über zwei Dienste. Auth signiert die Tokens mit einem Ed25519-Schlüssel, Core kennt nur den öffentlichen Schlüssel und kann einen Login also prüfen, aber nie selbst ausstellen. Die Tokens liegen in HttpOnly-Cookies, kein Skript auf der Seite kann sie lesen.",
|
||||
"CHALLENGE_2": "Die Limits von Steam. Jeder Steam-Aufruf ist rate-limitiert und wird bei Bedarf wiederholt, und ein Sync reserviert seinen Lauf zuerst in der Datenbank, damit nie zwei Syncs desselben Users gleichzeitig laufen.",
|
||||
"BULLET_5": "Über 3.400 Tests in den drei Diensten, ArchUnit-Regeln, die die Schichten getrennt halten, und Testcontainers für die echte Datenbank. Die CI führt den vollständigen Build aus und taggt jedes Image mit dem Commit.",
|
||||
"CHALLENGE_1": "Login über zwei Dienste. Auth signiert die Tokens mit einem Ed25519-Schlüssel, Core kennt nur den öffentlichen Schlüssel und kann einen Login also prüfen, aber nie selbst ausstellen. Core holt diesen Schlüssel zur Laufzeit von Auth, gesucht über die Key-ID, und die Tokens liegen in HttpOnly-Cookies, kein Skript auf der Seite kann sie lesen.",
|
||||
"CHALLENGE_2": "Die Limits von Steam. Jeder Steam-Aufruf ist auf zwei pro Sekunde begrenzt und wird nur dort wiederholt, wo eine Wiederholung sicher ist (Spielebibliothek, Schema, Erfolge). Ein Sync reserviert seinen Lauf zuerst in der Datenbank, damit nie zwei Syncs desselben Users gleichzeitig laufen, und der nächtliche Sync berührt nur User, die in den letzten 14 Tagen aktiv waren.",
|
||||
"CHALLENGE_3": "Ein Spiel vorzuschlagen ist schwerer, als es klingt. Jede Vorschlagsreihe braucht eigene Regeln, und die Listen hinter jeder Zahl müssen dieselben Regeln nutzen wie die Zahl selbst, damit ein Spiel überall gleich zählt.",
|
||||
"LEARNING_1": "Die Aufteilung in Dienste lohnt sich nur mit einem klaren Vertrag. Die Token-Claims stehen in einer Vertragsdatei, gegen die beide Dienste testen, und ein Skript prüft, dass beide Kopien gleich sind.",
|
||||
"LEARNING_2": "Auch ein Hobbyprojekt braucht die langweiligen Teile: Backups, Migrationen und eine feste Deploy-Reihenfolge. Sie haben mehr darüber entschieden, wie stabil es läuft, als jedes Feature."
|
||||
"CHALLENGE_4": "Missbrauch beim Login. Zu viele fehlgeschlagene Logins bekommen ein 429 mit Retry-After. Auch eine unbekannte E-Mail zahlt für eine volle BCrypt-Prüfung, sodass die Antwortzeit nichts verrät. Ein Header-Schutz blockt CSRF, CORS erlaubt nur exakte Origins, und das PlayStation-Token wird verschlüsselt gespeichert.",
|
||||
"LEARNING_1": "Die Aufteilung in Dienste lohnt sich nur mit einem klaren Vertrag. Die Token-Claims stehen in einer Vertragsdatei, gegen die beide Dienste testen, und ein Skript, das ich von Hand starte, prüft, dass beide Kopien gleich sind.",
|
||||
"LEARNING_2": "Auch ein Hobbyprojekt braucht die langweiligen Teile: tägliche Datenbank-Dumps, die sieben Tage, vier Wochen und sechs Monate aufbewahrt werden, Migrationen und eine schriftlich festgehaltene Deploy-Reihenfolge. Sie haben mehr darüber entschieden, wie stabil es läuft, als jedes Feature."
|
||||
}
|
||||
},
|
||||
"IMPRINT": {
|
||||
|
||||
Reference in new issue
Block a user