Showroom - Aktuelle Arbeiten und Projekte

[Schrompf]

Bomben :-)

Kommt drauf an. Für den Spaß brauchst Du Multiplayer, Netzwerk oder lokal. Und dann paar Extras, weil's sonst schnell langweilig wird. Aufm Amiga gab's damals Dynablaster, glaube ich, das hatte auch nen Story-Modus mit ner Levelprogression und verschiedenen Gegnertypen. Oder Du machst ein Zelda draus und lässt in ner isometrischen Welt mit Bomben Steine rumschieben, Schalter betätigen und kleine Rätsel lösen.

[edit] Dynablaster Orginal SingePlayer:

[Jonathan]

Bomben :-)

Hahaha, ja, das klingt nach einer guten Idee, hehe.

Ich denke ich werde bloß lokalen Multiplayer einbauen. Netzwerk wäre cool aber ist schwierig zu implementieren, ich hab damit zumindest noch quasi keinerlei Erfahrung. Ich hab aber mal irgendwo gelesen, dass man die ganze Engine von Anfang an darauf auslegen muss, weil es später nahezu unmöglich ist das noch obendrauf zu pfropfen - das Beweisen ja auch Beispiele wie Anno 1503 für das immer ein Multiplayermodus versprochen wurde, der dann aber einfach nie kam.

Und zweitens - mal ehrlich, wer spielt das online? Man kann sich ja vom Harald die Online-Highscore anschauen, das haben sehr selten zwei Spieler weltweit zum selben Zeitpunkt gespielt. Klar könnte man am zfx Stammtisch was organisieren, aber für realistisch 1-3 Event in der Lebenszeit des Spiel mach ich mir die Mühe halt nicht.

Lokaler Coop hingegen - warum nicht. Es können ja 2 bis theoretisch 4 Spieler auf einer Tastatur spielen (haben wir früher in Vorlesungen mit Achtung die Kurve! so gemacht), oder man steckt einfach noch ein paar Controller an. Und mit Leuten die man persönlich kennt zu spielen macht ohnehin mehr Spaß :)


Allerdings: Um einen Singleplayermodus komme ich wohl nicht herum, zumindest Bots muss ich wohl einbauen. Denn Spieler müssen das ja erstmal alleine testen, bevor sie ihre Kumpels anstiften das auszuprobieren, denke ich. Man will ja zumindest wissen ob es gut läuft und die Steuerung flutscht und so.

[NytroX]

Also Upgrades auf jeden Fall.
Neben den Klassikern wie Explosions-Vergrößerung, mehr gleichzeitigen Bomben, Durchdringung von Wänden und kürzere Zündschnur zählen dazu auch Bomben-Ketten, kicken, werfen und die Superbomben (wenn man 2 oder 3 ineinander kickt). Und werfen kann man auch andere Spieler.

Skills sind auch nice, wie z.B. ein Raketen-Rucksack, Item-Klauen, kurz unsichtbar machen, etc.

Reittiere sind auch cool, weil sie einem ein 2. Leben geben (beim ersten "Tod" stirbt nur das Reittier). Die können dann auch noch Skills haben, wie z.B. Musik (eine Note schießen) bei der man dann eine Weile tanzen muss, wenn man getroffen wird.

Und den Harry am Ende, der einen überfährt, wenn man zu lange braucht ("hurry!" - und das Spielfeld wird kleiner. Der Vorläufer jedes modernen BattleRoyale-Spiels)

Und natürlich das Feature, dass man nach seinem Tod von außen Bomben reinwerfen kann und wenn man jemand damit tötet dessen Platz im Spiel wieder einnimmt.

Und wenn du dann noch Spass dran hast mehrere Level, z.B. mit Eis wo man ein wenig rutscht, mit Förderbändern, die die Bomben transportieren, mit Teleportern/Portalen, und was dir sonst noch so einfällt :-)

Dann steht einem spaßigem Multiplayer mit Freunden nichts mehr im Weg, der dann auch wesentlich länger als nur 5 Minuten Spass macht.

[antisteo]

Einfach mal simples Phong Shading in hardlife.io dazugebaut.

die Normale eines gl_Point bekommt man ganz easy per

Code: Alles auswählen

vec3 normal = vec3(gl_PointCoord.x * 2.0, gl_PointCoord.y * 2.0, 1.0 - 2.0 * dist); // screen space

Danach braucht man noch die Koordinate der Lichtquelle im Screen Space und fertig

[Schrompf]

Ja, nice! Zusammen mit ner hinreichend genauen ShadowMap könnte das auch Deine "woher krieg ich ne Normale"-Probleme lösen.

[antisteo]

Ja, nice! Zusammen mit ner hinreichend genauen ShadowMap könnte das auch Deine "woher krieg ich ne Normale"-Probleme lösen.

Die Normale hab' ich ja. Das war easy.

Jetzt muss ich mich aber noch in die Three.js-Shadowmap-Codes reinlesen, um in meinem Shader den richtigen Schnipsel zu aktivieren dafür. (Naja und noch ein Jammer-Topic: Ich muss mal wieder deren komplettes System aufbohren, damit die Points auch so wie ich es will in die Shadow-Kamera gerendert werden)

[antisteo]

Hat zwar nix mit Spieleentwicklung zu tun, aber ich habe mal einen hübschen E-Rechnung-Betrachter gebaut:

In dem Online-Validator lädt man wahlweise ein Zugferd-PDF oder eine XML-Datei wahlweise im rsm:- oder im cbc:-Format hoch. Der Validator liest die Daten dann ein und stellt dar, was er herausfinden konnte.

Zu bestaunen unter:

https://launix.de/launix/e-rechnung-validator/

[joeydee]

Prototyp für Elemente von Puzzle-Games: Polygonzug tesselieren, anfassen, verschieben, drehen. Hier in Winkel- und Rasterschritten, damit man z.B. richtige Endpositionen besser vergleichen kann.
Die Anfass-Logik: Am Rand bedeutet Drehen, weiter in der Fläche Verschieben, beim Hovern ändert sich der Gizmo-Cursor entsprechend. Also ohne Shortcuts oder Werkzeuge oder selektionsbasierte Gizmos. Einfach direkt reinklicken und bewegen.

Ziel ist, mein Framework mit einem spezifischen GUI zu erweitern, welches u.a. auf solchen interaktiven Polygonen basiert, um möglichst beliebige einfache grafische Minigames damit basteln zu können. Also z.B. Teile sortieren/zuweisen, Streichholzrätsel, Symbole mit drehbaren Scheiben einstellen, etc., mit verschiedenen Constraints (nur drehbar, nur 60 oder 90 Grad drehbar, nur verschiebbar in Rasterschritten, nur verschiebbar auf eine Liste gültiger Endpositionen, ...)
Erstmal nur auf Polygonbasis; auf Pixelmaskenbasis wäre später auch noch denkbar, aber ist erstmal nicht vorgesehen.

[joeydee]

Für so Zeuch und so.

[Schrompf]

Kollisionstest Kreis gegen Bitmap: Zusammenfassung aller Überlappungs-Pixel durch ein bis zwei Kontaktpunkte, weil Box2D maximal 2 Kontaktpunkte pro Kollisionspartner-Paar zulässt.

kreis_vs_bitmap.png (10.11 KiB) 2028 mal betrachtet

Ich lege dazu eine Ausgleichsgerade durch alle überlappende Pixel, teile die Punktewolke anhand dieser Gerade in zwei Hälften, und bilde jeweils den Durchschnitt der Punkte auf beiden Seiten.

[TomasRiker]

Ich lege dazu eine Ausgleichsgerade durch alle überlappende Pixel, teile die Punktewolke anhand dieser Gerade in zwei Hälften, und bilde jeweils den Durchschnitt der Punkte auf beiden Seiten.

Klappt das auch, wenn sich der Kreis in einer Art Tunnel befindet, wo es oben und unten Kontakte gibt? Was machst du am Ende des Tunnels, wo es dann Kontakte oben, unten und vorne geben müsste, aber Box2D nur 2 Kontakte zulässt?

Die Begrenzung auf 2 Kontakte kommt wahrscheinlich daher, dass Box2D nur konvexe Formen zulässt, aber deine Bitmap wird in der Regel konkav sein - ich fürchte, da sind Probleme vorprogrammiert ... Eine mögliche Lösung wäre, bei Bedarf mehrere Shapes zu verwenden, dann wäre die Anzahl der Kontakte unbegrenzt.

Alternativer Ansatz: Du erzeugst echte konvexe Shapes (Rechtecke) "on demand" für den Bereich der Bitmap, der gerade relevant für Kollisionen ist und löschst sie anschließend wieder. Dazu könntest du nebeneinander liegende Pixel zu Blöcken zusammenfassen. Vorteil ist, dass du dich dann zu 100% auf die Kollisionsbehandlung von Box2D verlassen kannst und nicht dein eigenes Süppchen kochen musst.

[Schrompf]

Ja, das könnte Probleme geben. Ist mir bewusst, nehme ich in Kauf. Sie sind aber seltener, als man glaubt, denke ich. Dein Beispiel mit der Kugel im Tunnel z.B. - die Kugel wäre da nie hingekommen. Wenn sie sich in einen immer engeren Tunnel hinein schiebt, wären dann die Kontaktpixel alle vorn, und dann gibt's ne Ausgleichsgerade durch die Mitte und einen Kontakt links davon und einen rechts davon. Passt.

Problematischer wird's eher später dann, wenn ich dann auch Bitmaps bewegen lasse. Und da kann man ja z.B. auch ein 'm' kriegen und durch die Gegend schubsen... mal gucken.

Wenn ich konvex zerlegen muss, hab ich aber eh verloren. Das hätt ich nämlich gleich ab Start machen können, wie Noita es gemacht hat, und hätte mir diesen ganzen Pfad erspart. Find's jetzt trotzdem gut, dass ich es gemacht habe, hat bisweilen Spaß gemacht und mir paar schöne Tools ins Framework gebracht. Aber wär doch ne ziemliche Zeitverschwendung, wenn man am Ende eh doch wieder nur konvexe Polys rumschubst.

[TomasRiker]

Problematischer wird's eher später dann, wenn ich dann auch Bitmaps bewegen lasse. Und da kann man ja z.B. auch ein 'm' kriegen und durch die Gegend schubsen... mal gucken.

Oh ja, das könnte schwierig werden. Dann musst du auch Kollisionen Bitmap vs. Bitmap behandeln.
Was aber noch viel schwieriger werden dürfte, ist Continuous Collision Detection für Bitmaps zu implementieren (insbesondere bei Bitmap vs. Bitmap). Box2D kann das ja für die eingebauten Shapes. Das verhindert, dass Objekte bei hohen Geschwindigkeiten durcheinander durch fliegen (z. B. ein Geschoss durch eine dünne Wand).
Auch da würdest du enorm profitieren, wenn du deine Pixel in Rechtecke verwandelst und Box2D seine "Magic" machen lässt.

[Schrompf]

Tomas, hör auf. Ich mach das jetzt so :-)

[TomasRiker]

Mach bitte vorher und nachher eine Bestandsaufnahme deiner grauen Haare :)

[Schrompf]

Naja, wir haben den Thread hier jetzt eh schon hart derailed, aber:

Einerseits beruhige ich mich die ganze Zeit selbst: hey, ein Großteil der Arbeit ist auch dann nicht umsonst gewesen, wenn ich das in Box2D nicht reingeklöppelt kriege. Dann zieh ich halt meine eigene Physik auf, mit Kartenspielen und Leichten Personen. Und für's Tauchspiel wird das auch klappen, ich mach hier keine elaborierten Konstrukte aus Motoren, Federn und Zahnrädern. UND alles passiert unterwasser-gemächlich. Geht schon.

Andererseits könnte mich der Bitfield-Ansatz auch in den Hintern beissen. Ich kann z.B. keine ordentliche Eindringtiefe angeben, weil mir Subpixel-Genauigkeit fehlt. Hätte ich ab Start auf Päckchen gesetzt, hätte ich ganz banal hierarchisch reinbohren können - zuerst nen 8x8-Pack, als Quad oder Kugel, wenn der kollidiert als nächstes 4x4-Päckchen und so weiter. Quasi implizite Boxen oder Kreise für jeden Pixel, nur halt nicht explizit millionenfach instanziiert. Hat immer noch die Konkav-Probleme, aber wär auch kontinuierlich machbar. Das krieg ich dann aber nicht mehr in Box2D reingepatcht, dazu ist deren interne Struktur allzu festgelegt auf Paare aus Körpern.

[TomasRiker]

Das krieg ich dann aber nicht mehr in Box2D reingepatcht, dazu ist deren interne Struktur allzu festgelegt auf Paare aus Körpern.

Evtl. liegt da ein Missverständnis vor. Es gibt bei Box2D einerseits Bodies und andererseits Fixtures. Die Fixtures bestimmen die geometrische Form, die Verteilung der Masse und die Materialeigenschaften. Ein Body kann beliebig viele Fixtures haben. Deine Bitmap hätte einen einzigen Body, aber sehr viele Fixtures. Im einfachsten Fall für jedes Pixel ein Quadrat, wobei du dann größere komplett gefüllte Flächen zu größeren Rechtecken zusammenfassen kannst, um die Performance zu verbessern. Optimierungstechnisch wäre das sicherlich auch ein interessantes Problem, an dem man sich austoben kann: Wie fasst man die Pixel möglichst schnell zu möglichst wenigen Rechtecken zusammen? Auf die Schnelle mal ein Paper dazu: https://library.utia.cas.cz/separaty/20 ... images.pdf

Wenn du wolltest, könntest du für das "Welt-Bitmap" auch die Fixtures dynamisch erzeugen und löschen, um nur die Bereiche abzudecken, die gerade für potenzielle Kollisionen relevant sind, und um Box2D nicht permanent mit tausenden von Fixtures arbeiten zu lassen. Da sollte man aber gucken, ob das wirklich nötig ist.

[Schrompf]

Jetzt häng Doch nicht am deutschen Wort "Körper" auf. Irgendwann ist einfach mal gut.

[joeydee]

Im Zuge meiner letzten Polygon-Experimente (Tesselation, Polygon-Puzzle-GUI), und auch inspiriert von Schrompf's Baustellen, habe ich mal das "Physics of JellyCar"-Video wieder hervorgekramt und Lust bekommen, einen Teil davon umzusetzen.
Konzepte daraus:
a) Es gibt nur Massenpunkte, die die Polygone formen.
b) Es wird nur "Punkt in anderem Polygon" gegenseitig getestet, der kürzeste Weg für den Punkt hinaus ermittelt, und das Ergebnis auch anteilig auf die Massenpunkte des betroffenen Liniensegments angewendet.
Heißt auch, alles muss mit einem gültigen Zustand starten, und die Schritte müssen klein genug sein dass keine Kollision verpasst wird.
Dazu meine vorhandene 2D-SDF-Polygon-Distanzfunktion von Inigo Quilez so aufgebohrt, dass sie neben der Distanz auch Segment und anteilige Lage auf dem Segment zurückgibt, worüber auch Kontaktpunkt und Normale direkt bestimmt werden können.
c) Auf Springs ganz verzichtet, stattdessen nur die Idee mit der Referenzform umgesetzt. Dabei statt Winkelberechnungen nur Dotprodukte verglichen und gemittelt, da diese dem sin und cos des Winkels entsprechen, und man die beiden Werte sowieso gleich wieder zum Drehen der Referenzform benötigt. Also Trigonometrie komplett vermieden.
Außerdem statt dem deformierten Softbody am Ende nur die Referenzform gezeichnet (deshalb tauchen die Formen im Video auch leicht ein bis alles wieder "relaxed" ist).

Was noch fehlt ist ein ordentlicher Euler-Integrator, mit korrektem Aufteilen der Massepunkt-Geschwindigkeiten nach Winkel und Masse bei Kollision. Hatte ich früher schonmal gemacht (Partikelkollisionen, Springs), aber beim Abrufen des ganzen mal eben schnell aus dem Kopf gestern Abend doch etwas verhaspelt ;) Demnächst dann doch nochmal "richtig", mit INet-Unterstützung.

Bisher habe ich also nur Positionskorrektur nach Kollision drin, keine Physik. Daher fühlen sich auch die resultierenden Drehungen falsch an. Gibt außerdem noch Grenzfälle die ich nochmal anschauen muss, aber prinzipiell läufts.


Viel Text, unspektakuläres Video. Trotzdem Freude.

[Jonathan]

Ahjo, das sieht ziemlich nett und robust aus. Wäre dann interessant das mit Graviation und ggf. schnelleren Objekten zu sehen, aber das ist so schon echt nett, wenn man bedenkt, wie komplex die Objekte doch sind.

[joeydee]

Wäre dann interessant das mit Graviation und ggf. schnelleren Objekten zu sehen

Jupp, da waren nur per-Frame-Positionskorrekturen bei Detection drin, keine Geschwindigkeiten oder irgendein Timestep.
Aber jetzt habe ich mal einen Verlet Integrator mit festem Timestep draufgeworfen. Nur ein kurzes Video, aber Spielwiese eröffnet. Es ist trotzdem noch viel zu tun bis man damit was Sinnvolles anfangen kann.


Bisher hatte ich immer nur mit Euler Semi-Implizit rumgepfuscht(d.h. das intuitive v+=a*dt; p+=v*dt;).
Verlet soll gerade für solche gegenseitig voneinander abhängigen Sachen numerisch stabiler sein. Die Berechnung selbst mag auf den ersten Blick unintuitiv sein (pos = 2 * pos - opos + acc * dt * dt;) aber mir gefällt hier auch das Handling besser (man ändert von außen z.B. bei Kollision nur noch Positionen, keine Geschwindigkeitsvektoren).
Die Erklärungen von Pikuma waren dabei sehr hilfreich: https://www.youtube.com/watch?v=-GWTDhOQU6M
Zu seiner Frage bei Miunte 55:xx zur ordentlichen Reflektion an einer Plane wäre meine Antwort: Einfach pos und oldpos auf die andere Seite der Plane spiegeln. Das funktioniert dann auch mit beliebig ausgerichteten Planes. Meine im Video ist so eine.
Und noch ein Pro-Tipp: Für mehr Spaß die automatischen engl. Untertitel anschalten und bei jeder neuen "Verlet"-Übersetzung einen Schnaps ;)

[Schrompf]

Nice, sieht echt solide aus! Und Danke für den Link.

[joeydee]

Hier gibts jetzt mehr zu sehen :)

Zwischendurch wechsle ich zwischen Rigid und Soft, das ist kein eigener Modus, sondern die Wiederherstellungskraft der Bodies. Im Moment nur als Lerp-Faktor implementiert, nicht als Feder, d.h. ich bin da noch nicht frameunabhängig, ist noch die letzte Baustelle vorerst.
Mit Verlet kann ich den Lerp direkt auf 1 setzen für Rigid Bodies; am Ende des Verlet-Videos wurden "Sticks" vorgestellt, "Springs" ohne Federkraft, die immer ihre Länge halten, nicht federn. Bei Euler war mir sowas gern mal explodiert. Aber wahrscheinlich hatte ich da früher auch andere Fehler gemacht.
An manchen Stellen sieht man auch, dass die Körper sich durchdringen können, vor allem die spitzen Zacken des Sterns sind da anfällig, wird auch im Jelly-Video erklärt. Natürlich kann das hier vor allem auch beim Umschalten von Soft auf Rigid passieren, aber an sich löst sich das Gewusel meist schnell auf.
Ich habe einen kleinen SDF-Radius von wenigen Pixeln drin, bei einer Physik-Framerate von 240 (0-1 Steps/Bildframe ohne VSync, 4 bei 60Hz), da läuft das relativ stabil bei den gezeigten Geschwindigkeiten und Größen.

Fazit: War am Ende gar nicht so schwierig wie ich zuerst dachte, und der "schmutzige" Kollisionsalgo reicht für viele Anwendungen.
Knackpunkte für mich waren die Kollision und Wiederherstellung von Polygonen (s. Jellycar-Video), und ein ordentlicher Integrator für Massenpunkte (s. Verlet-Video).
Für die eigene kleine 2D-Physikengine fehlt jetzt noch Friction, Broad Phase Collision Detection, Massen-Management, Joints, ... aber nicht heute, und morgen nicht gleich ;)

[Schrompf]

Meinen Surface-Generator auf den aktuellen Stand gebracht. Sieht echt fies aus mit so großer Simpel-Geometrie als Eingabe. Zugrunde liegt immer noch ein 2mx2m Grid für einen DungeonCrawler. Gibt noch viel zu tun.

[Andy90]

Habe die letzten tage begonnen, ein Beispiel Projekt für mein Framework zu erstellen. Ziel wird ein kleines Jump 'n Run game, indem man münzen einsammeln muss um das Level abzuschließen.

[joeydee]

Neu: Tesselation (wird nur einmalig bei Start gemacht, wird für Softbody nicht geupdated, i.d.R. reicht das aus) und Texturing, sowie Friction (im Moment nur für die Plane eingestellt, die anderen Körper haben keine Reibung). Dadurch können Körper jetzt auch rollen, nicht nur gleiten.
Eine ganze Verwaltung mit Materialparametern und -Paaren (wie hieß es nochmal in der Führerscheinprüfung? "Kraftschlussbeiwert"?)

An einer Stelle liegt die Box mal schräg auf der Plane - da habe ich einen einzelnen nicht gerenderten Massepunkt in der Sim vergessen, mit 5 Pixel Toleranz.

Langsam wird es brauchbarer :) Für echte Projekte reicht es aber so noch nicht, die Tests sind noch Brute Force, da geht noch nicht viel gleichzeitig.

[mtorc1]

Die Soft Body Physics schauen richtig gut aus. Das macht wirklich Spaß, zuzuschauen. Überlegst du, das für ein konkretes Projekt einzusetzen?

[joeydee]

Überlegst du, das für ein konkretes Projekt einzusetzen?

Nein, noch kein Projekt. Es war eher umgekehrt, ich musste kürzlich an das Jelly-Video denken das ich schon lange in den Lesezeichen hatte, und wollte das einfach mal versuchen umzusetzen (die Tech, nicht das Spiel).
Aber natürlich gehen jetzt die Rädchen, was ich daraus mal basteln könnte.

[mtorc1]

Ich finde es echt schwierig, mir ein Szenario auszudenken, wo Soft Body Physics ein Teil der Spielmechanik sind. Jelly Car hat das gut umgesetzt aber darüber hinaus?
Möglicherweise ist das aber etwas, was abseits der Spielmechanik das Ambiente bzw. look-n-feel von einem Spiel ausmachen kann. Ich denke da bspw. an einen 2D Plattformer-Shooter. Die Vorstellung, ein Alien abzuknallen, was nach dem Tod als soft body in eine Maschine fällt und zwischen zwei Zahnrädern durchgemangelt wird / aus der Arena herauskatapuliert wird, hat etwas. Wäre auf jeden Fall ein Alleinstellungsmerkmal.

[Jonathan]

Ich finde es echt schwierig, mir ein Szenario auszudenken, wo Soft Body Physics ein Teil der Spielmechanik sind. Jelly Car hat das gut umgesetzt aber darüber hinaus?

Ich denke da an Chaos-Party-Games. Spiele die man zusammen auf dem Sofa spielt, bei denen es nicht um präzise Mechanik sondern um lustige Ereignisse geht. Spiele wie Totally Reliable Delivery Service oder Octodad oder Goat Simulator oder Garry's Mod. Ist halt eine spezielle Art von Spiel, aber man kann schon sehr viel in die Richtung machen, denke ich.

In eine leicht andere Richtung ging Gish, damals war die Physik noch als ernsthafte, aber eben komplizierte, Spielmechanik gedacht. Es ging weniger um emergentes Chaos sondern darum mit großem Geschick ein kompliziertes System zu meistern. Mir ist dann aber glaube ich lustiges Chaos doch meistens lieber.