Connect with us

Entwicklung & Code

Game Loops: Spiele und Animationen richtig in Takt bringen


Erfahrene Entwicklerinnen und Entwickler kennen verschiedene Paradigmen, mit Ereignissen umzugehen: Request-Response-Zyklen in Webservern, Event-Handler in GUI-Anwendungen oder die sequenzielle Verarbeitung in CLI-Tools. All diese eventgetriebenen Ansätze haben eines gemeinsam: Sie reagieren auf externe Ereignisse und kehren danach in einen Wartezustand zurück. Ein Webserver wartet auf HTTP-Requests, eine Desktopanwendung auf Mausklicks oder Tastatureingaben.

Weiterlesen nach der Anzeige


Golo Roden

Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Bei der Spieleentwicklung funktionieren diese Paradigmen jedoch nicht. Ein Spiel muss kontinuierlich aktiv sein, auch wenn Spieler gerade keine Eingaben machen. Objekte bewegen sich weiter, Animationen laufen, Gegner agieren, physikalische Simulationen berechnen die nächsten Zustände. Die Spielwelt existiert unabhängig von Benutzerinteraktionen und entwickelt sich permanent weiter.

Diese fundamentale Anforderung führt zum Konzept Game Loop: einer Endlosschleife, die kontinuierlich den Spielzustand aktualisiert und das Ergebnis auf den Bildschirm rendert. Während ein Webserver zwischen Requests untätig ist, läuft eine Game Loop ununterbrochen mit idealerweise sechzig oder mehr Iterationen pro Sekunde.

Auch für Entwicklerinnen und Entwickler außerhalb der Spielebranche bietet das Konzept interessante Perspektiven. Echtzeitvisualisierungen, Simulationen, IoT-Devices oder Robotik-Software teilen viele Anforderungen mit Spielen: kontinuierliche Verarbeitung, präzises Timing und Reaktion auf Inputs bei laufendem System. Die im Folgenden diskutierten Patterns sind direkt übertragbar.

Das grundlegende Konzept der Game Loop

Eine Game Loop besteht im Kern aus drei Phasen, die sich wiederholen: Eingaben verarbeiten, den Spielzustand aktualisieren und das Bild rendern. In der ersten Phase liest die Engine Tastatureingaben, Mausbewegungen oder Controller-Aktionen ein. Die zweite Phase berechnet die Konsequenzen: Charaktere bewegen sich, Projektile fliegen, Kollisionen ereignen sich. Die dritte Phase visualisiert den aktualisierten Zustand.

Dieser Ablauf unterscheidet sich grundlegend von eventgetriebenen Architekturen. Während dort ein Button-Click-Handler aufgerufen wird, seine Aufgabe erledigt und anschließend die Kontrolle zurückgibt, behält die Game Loop permanent die Kontrolle über den Programmfluss. Sie ist die oberste Instanz, die alle anderen Systeme orchestriert.

Weiterlesen nach der Anzeige

Die konzeptionell einfachste Implementierung sieht in Pseudocode so aus:


func main() {
    initialize()

    for {
        processInput()
        updateGameState()
        render()
    }
}


Dieser naive Ansatz hat ein gravierendes Problem: Er läuft nur so schnell, wie die Hardware es zulässt. Auf einem leistungsstarken Rechner könnte die Schleife tausende Male pro Sekunde laufen, auf schwächerer Hardware vielleicht nur dreißig Mal. Das führt zu inkonsistentem Spielverhalten.

Das Problem der unkontrollierten Geschwindigkeit

Angenommen, eine Spielfigur soll sich mit fünf Metern pro Sekunde nach rechts bewegen. Jeder Schleifendurchlauf erhöht die Position um einen festen Wert. Wenn die Schleife auf Computer A tausendmal pro Sekunde läuft, auf Computer B aber nur sechzig Mal, bewegt sich der Charakter auf A mehr als sechzehnmal so schnell – ein inkonsistentes, völlig unspielbares Verhalten.

Dieses Problem betrifft nicht nur Bewegungen, denn die Loop-Frequenz beeinflusst auch Physikberechnungen, Animationen und Timings für Spielmechaniken – also alle zeitabhängigen Vorgänge. Ältere Spiele aus den 1980er und frühen 1990er Jahren litten massiv unter diesem Effekt. Viele DOS-Spiele sind auf modernen Systemen unbenutzbar, weil sie mit mehreren tausend FPS und damit 100-fach zu schnell ablaufen.

Die Lösung liegt in der expliziten Kontrolle der Ausführungsgeschwindigkeit. Die Game Loop muss die Zeit berücksichtigen und ihre Berechnungen entsprechend anpassen. Es gibt dafür verschiedene Ansätze mit unterschiedlichen Trade-offs.

Fixed Time Step: Die einfache Lösung

Der naheliegendste Ansatz, der Fixed Time Step, ist die Begrenzung der Loop-Frequenz auf einen festen Wert, typischerweise 60 FPS (Frames per Second). Nach jedem Schleifendurchlauf wird die verstrichene Zeit gemessen. Wenn der Durchlauf weniger als 16,67 Millisekunden (1000 ms / 60) gedauert hat, wartet das Programm die restliche Zeit ab:


targetFrameTime := 16.67 // Millisekunden für 60 FPS

for {
    frameStart := getCurrentTime()

    processInput()
    updateGameState()
    render()

    frameTime := getCurrentTime() - frameStart
    if frameTime < targetFrameTime {
        sleep(targetFrameTime - frameTime)
    }
}


Bei diesem Ansatz kennen alle Berechnungen die exakte Zeitdauer eines Frames. Eine Bewegung von 5 Metern pro Sekunde bedeutet 5/60 = 0,0833 Meter pro Frame. Diese Konstanz vereinfacht die Spiellogik erheblich, da sie keine variablen Zeitwerte berücksichtigen muss.

Der Fixed Time Step führt zu deterministischem Verhalten. Bei identischen Eingaben produziert das Spiel auf unterschiedlicher Hardware exakt die gleichen Ergebnisse. Das ist besonders wichtig für Multiplayer-Spiele, Replays oder Debugging. Physik-Engines arbeiten ebenfalls lieber mit konstanten Zeitschritten, da variable Schrittweiten zu numerischen Instabilitäten führen können.

Allerdings hat dieser Ansatz einen fundamentalen Nachteil: Wenn ein Frame länger als die vorgesehene Zeit benötigt, bricht das Konzept zusammen. Auf schwächerer Hardware oder bei komplexen Szenen dauert die Berechnung vielleicht 25 Millisekunden statt 16,67. Das Spiel kann dann die Ziel-Framerate nicht halten und läuft in Zeitlupe ab – ein häufiges Phänomen bei anspruchsvollen Spielen auf Low-End-Systemen.

Zudem verschwendet das aktive Warten (Busy Waiting) CPU-Ressourcen. Moderne Sleep-Funktionen haben außerdem keine Millisekunden-Präzision, was zu Frame-Pacing-Problemen führen kann. Dennoch verwenden einige Spiele, besonders ältere oder retro-inspirierte Titel, diesen Ansatz wegen seiner Einfachheit.

Variable Time Step: Flexibilität mit Risiken

Eine flexiblere Lösung ist der Variable Time Step: Er misst die tatsächlich vergangene Zeit zwischen Frames und verwendet diesen Wert (Delta Time) für alle Berechnungen. Statt mit festen Werten zu rechnen, wird jede Veränderung mit der Delta-Zeit multipliziert. Eine Geschwindigkeit von 5 m/s wird zu position += 5.0 * deltaTime.


lastTime := getCurrentTime()

for {
    currentTime := getCurrentTime()
    deltaTime := currentTime - lastTime
    lastTime = currentTime

    processInput()
    updateGameState(deltaTime)
    render()
}


In diesem Modell passt sich das Spiel automatisch an die Hardwareleistung an. Ein schneller Computer produziert mehr Frames pro Sekunde mit kleineren Delta-Time-Werten, ein langsamer Computer weniger Frames mit größeren Deltas. Die Bewegungsgeschwindigkeiten bleiben konsistent, da 5 m/s * 0,016s und 5 m/s * 0,033s über mehrere Frames hinweg zum gleichen Ergebnis führen.

Der Variable Time Step hat jedoch ein gefährliches Problem: Er kann bei niedrigen Frame-Raten instabil werden. Wenn ein komplexer Frame 50 Millisekunden benötigt, ist deltaTime entsprechend groß. Physikberechnungen mit großen Zeitschritten sind numerisch ungenauer und können zu unplausiblen Ergebnissen führen – Objekte durchdringen sich, Kollisionen werden übersehen, die Simulation läuft komplett aus der Kontrolle.

Diese Instabilität führt zu noch komplexeren Berechnungen im nächsten Frame, was deltaTime weiter erhöht. Es entsteht eine positive Rückkopplung: Große Zeitschritte führen zu Instabilität, was mehr Rechenaufwand nach sich zieht, der zu noch größeren Zeitschritten führt. Dieses Phänomen wird als Spiral of Death bezeichnet und kann ein Spiel komplett unbenutzbar machen.

Zusätzlich erschwert der Variable Time Step das Testen und Debuggen. Unterschiedliche Hardware produziert leicht unterschiedliche Ergebnisse, was Race Conditions und Timing-abhängige Bugs schwer reproduzierbar macht. Multiplayer-Spiele haben mit diesem Ansatz erhebliche Synchronisationsprobleme, da verschiedene Clients unterschiedliche Zeitschritte verwenden.

Trotzdem nutzen viele moderne Spiele Variable Time Steps, weil sie mit Hardwarevielfalt besser umgehen können als Fixed Time Steps. Der nächste Schritt zeigt, wie sich die Vorteile beider Ansätze kombinieren lassen.



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Sulu 3.0: CMS mit neuem Content-Speicher und klarerer Architektur


Sulu 3.0 ist erschienen. Mit dem Release vollzieht das quelloffene Content-Management-System (CMS) laut Blogbeitrag eine größere technische Umstrukturierung. Statt auf das bislang genutzte PHPCR‑Repository setzt das Projekt künftig vollständig auf Doctrine ORM und JSON‑Felder – eine Entscheidung, die nicht nur die Performance heben, sondern auch die Einstiegshürde für Symfony‑Entwickler senken soll. Nach Angaben des Teams kamen rund 150.000 Zeilen Code neu hinzu, mehr als 265.000 wurden entfernt.

Weiterlesen nach der Anzeige

Das Open-Source-CMS Sulu basiert auf dem PHP-Framework Symfony und dient als Headless‑ oder klassisches CMS für komplexe, mehrsprachige Webprojekte. Es richtet sich vor allem an Entwicklerinnen und Entwickler, die flexible Inhaltsmodelle mit vertrauten Symfony‑Werkzeugen umsetzen wollen. Für Symfony sind kürzlich die Versionen 7.4 und 8.0 erschienen.

Von PHPCR zu Doctrine ORM

Mit der Abkehr vom speicherintensiven PHPCR führt Sulu ein neues Modell zur Ablage von Inhalten ein: Seiten, Artikel oder Snippets werden jetzt als reguläre Doctrine‑Entitäten mit JSON‑Spalten verwaltet. Damit greifen Developer direkt auf bekannte Tools und SQL‑Abfragen zurück, statt eine eigene Query‑Sprache lernen zu müssen.

Das System nutzt sogenannte Dimensionen, um Sprach‑, Veröffentlichungs‑ und Versionszustände abzubilden. So lassen sich nicht übersetzbare Felder in mehreren Sprachvarianten weiterverwenden – ein Ansatz, der die vorherige, tiefer verschachtelte Struktur ersetzt und sich offenbar leichter debuggen lässt.

Bessere Performance und Vereinfachungen

Nach Angaben des Teams bringt der neue Speicheransatz spürbare Leistungsgewinne. Content‑Strukturen lassen sich nun direkt in der Datenbank nachvollziehen, während Konfigurationsdaten weiterhin als XML im Repository bleiben.

Weiterlesen nach der Anzeige

Auch das Update der PHP-Bibliothek Flysystem auf Version 3 soll zur Vereinfachung der Handhabung von Mediendateien beitragen. Diese können künftig über eine einheitliche Schnittstelle auf unterschiedlichen Backends abgelegt werden, beispielsweise auf Amazon S3, Microsoft Azure, WebDAV oder Dropbox.

Entfall der Elasticsearch‑Pflicht für Artikel

Neben der Speicherarchitektur wurde das Artikel‑Bundle neu geschrieben. Es lässt sich nun ohne die Suchmaschine und das Analytic-Tool Elasticsearch betreiben, wodurch kleineren Projekten die Installation eines separaten Suchdienstes erspart bleiben soll. Für große Installationen bleibt die Option durch ein ergänzendes Bundle erhalten, das Elasticsearch wieder einbindet.

Ebenfalls neu ist SEAL, der Search Engine Abstraction Layer. Er bündelt Anbindungen an Suchsysteme wie Loupe, Meilisearch, Solr oder Elasticsearch hinter einer gemeinsamen API. Standardmäßig kommt Loupe zum Einsatz – eine SQLite‑basierte, PHP‑interne Lösung, die für mittlere Datenmengen ausreichend schnell arbeitet.

Migration und Unterstützung

Sulu liefert ein eigenes Tool, um vorhandene PHPCR‑Daten zu konvertieren. Das Migration‑Bundle überführt Seiten, Artikel, Snippets und URLs in die neue Speicherstruktur und protokolliert detailliert, wo gegebenenfalls Nacharbeit nötig ist.

Wer die Umstellung nicht allein durchführen möchte, kann laut Entwicklerteam auf Community‑Hilfe via Slack und GitHub oder auf professionelle Unterstützung zurückgreifen. Weitere Informationen zur Hilfe sowie zum Release finden sich im Blogbeitrag.

Weiterer Fahrplan

Mit Version 3.0 endet die Pflege für Sulu 1.6, während Sulu 2.6 als LTS-Version (Long-term Support) erhalten bleibt. Die neue Architektur soll künftige Funktionen erleichtern und das CMS langfristig wartbarer machen. Näheres zum Release und zum CMS auch auf GitHub.


(mdo)



Source link

Weiterlesen

Entwicklung & Code

Drupal Canvas: Visueller Page Builder für Drupal veröffentlicht


Drupal hat mit Canvas einen visuellen Page Builder veröffentlicht, der die Erstellung individueller Websites ohne umfangreiche Programmierkenntnisse ermöglichen soll. Das Werkzeug richtet sich an Site-Builder und Content-Teams, die bisher zwischen vorgefertigten Templates und aufwendiger individueller Entwicklung wählen mussten.

Weiterlesen nach der Anzeige

Weniger komplizierte Technik für Anwender

Als Open-Source-CMS kommt Drupal zwar bei vielen Organisationen zum Einsatz, die Flexibilität des Systems erforderte jedoch bislang einiges an technischem Know-how. Wie Produktleiter Lauri Timmanee im Drupal-Blog erklärt, existiere in Drupal ein Trade-off: „Entweder man ist gezwungen, eine Art Cookie-Cutter-Website zu erstellen, oder man muss komplexen Code schreiben. Wir wollen diesen Trade-off aufbrechen, indem wir bessere Werkzeuge bereitstellen, damit man tatsächlich Websites erstellen kann, die auf die eigene Marke zugeschnitten sind, ohne komplexen Code kennen zu müssen.“

Drupal Canvas 1.0 basiert auf einem React-Frontend, das mit den Core-APIs von Drupal integriert ist. Die Hauptfunktionen umfassen komponentenbasiertes visuelles Page Building mit einem Drag-and-Drop-Interface, In-Browser-Code-Komponenten zum Hinzufügen neuer Bausteine sowie die Option, mehrere Seiten vor der Veröffentlichung zu erstellen und mit mehrstufigem Undo in der Vorschau zu betrachten. Das System soll Entwicklern mehr Zeit für tiefgreifende technische Arbeiten verschaffen, während nicht-technische Nutzer eigenständiger arbeiten können.

Canvas ist als Community-getriebenes Projekt angelegt, laut Drupal-Roadmap sollen künftig möglichst alle Module im kommenden Drupal CMS 2.0 mit Canvas kompatibel sein. Die Entwickler stellen eine Demo-Installation auf GitHub bereit und sammeln Feedback über den dedizierten Slack-Channel #drupal-canvas. Das Projekt positioniert sich damit in Konkurrenz zu etablierten Page Buildern wie WordPress Gutenberg oder Elementor, setzt aber auf die Stärken von Drupal in Enterprise-Umgebungen.

Ausblick auf Drupal CMS 2.0

Drupal CMS ist eine vorkonfigurierte Distribution auf Basis von Drupal Core, die für schnelle Website-Erstellung mit vorgefertigten Modulen und Workflows optimiert ist, während Drupal Core die minimale, flexible Grundlage für Entwickler bietet. Inzwischen steht Drupal CMS kurz vor der Veröffentlichung der Version 2.0, die laut mehreren Drupal-Experten einen großen Entwicklungssprung für Webentwickler und Nutzer bringen soll. Die neue Generation der Software soll eine verbesserte Performance, modernisierte Benutzeroberfläche und vereinfachte Integrationsmöglichkeiten für KI-gestützte Tools bieten.

Weiterlesen nach der Anzeige

Neben den technischen Verbesserungen soll Drupal CMS 2.0 besonderen Wert auf Barrierefreiheit, Sicherheit und modulare Erweiterbarkeit legen. Durch ein überarbeitetes Framework und optimierte Workflows sollen Entwickler Projekte schneller umsetzen können, während Redakteure von einer klareren Struktur und KI-gestützten Funktionen wie Content-Generierung und SEO-Optimierung profitieren sollen. Das offizielle Release ist aktuell für das erste Quartal 2026 anvisiert, ursprünglich war es für den Oktober 2025 geplant.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Open-Source-Toolkit: KI-Unternehmen Anthropic übernimmt Bun


Bun wurde von Anthropic übernommen, wie der Bun-Erfinder Jarred Sumner auf dem Bun-Blog mitteilt. Das JavaScript-Toolkit, bestehend aus Runtime, Bundler, Test Runner und Paketmanager, soll die Infrastruktur für Anthropics KI-Coding-Technologien Claude Code und Claude Agent SDK sowie künftige KI-Coding-Projekte darstellen.

Weiterlesen nach der Anzeige

Bun bleibt Open Source

Laut Sumners Ausführungen wird Bun auch weiterhin Open Source und MIT-lizenziert bleiben. Auch soll das gleiche Team wie bisher an Bun arbeiten und die Entwicklung weiter öffentlich auf GitHub stattfinden. Die Roadmap soll den Fokus auf Performance und Node.js-Kompatibilität beibehalten – und darauf, Node.js als die standardmäßige serverseitige Runtime für JavaScript zu ersetzen.




(Bild: jaboy/123rf.com)

Die enterJS 2026 wird am 16. und 17. Juni in Mannheim stattfinden. Das Programm wird sich rund um JavaScript und TypeScript, Frameworks, Tools und Bibliotheken, Security, UX und mehr drehen. Vergünstigte Blind-Bird-Tickets sind bis zum Programmstart erhältlich.

Bun erschien erstmals im Juli 2022 und verfolgte bereits damals das Ziel, ein „Drop-in“-Ersatz für Node.js zu werden. Schon innerhalb der ersten Woche erzielte das Projekt 20.000 GitHub-Sterne, wie sich der Bun-Erfinder zurückerinnert. Inzwischen ist die Zahl auf über 83.000 Sterne angestiegen und präsentiert sich seit Version 1.3 als Full‑Stack-JavaScript-Runtime.

Übernahme durch Anthropic

Anthropics Claude Code, ein agentisches KI-Coding-Tool, läuft mit Bun, und bereits während der letzten Monate hat das Bun-Team die Issues des Claude-Code-Teams mit Priorität bearbeitet. Nach Gesprächen mit Anthropic folgt jetzt die Übernahme von Bun, das selbst keine Einnahmen hatte: Anthropic kauft Bun als essenzielle Infrastruktur für Claude Code, die Toolsammlung Claude Agent SDK und zukünftige KI-Coding-Produkte.

Weiterlesen nach der Anzeige

Wie Sumner betont, soll dieser Schritt Bun zu langfristiger Stabilität verhelfen. Außerdem will man nun zusätzliche Software Engineers einstellen. Laut Sumner passen die beiden Seiten auf natürliche Weise zusammen, denn: „Bun begann mit einem Fokus darauf, Developer schneller zu machen. KI-Coding-Tools tun etwas Ähnliches.“


(mai)



Source link

Weiterlesen

Beliebt