[Projekt] 2D Game-Engine mit Javascript

[Sacume]

Hallo allerseits! Ich wollte euch mal ein Projekt vorstellen, bei dem es sich um eine Engine zur Entwicklung von 2D-Spielen handelt.

Download der finalen Version 0.5

Die aktuelle Version ist 0.5 - Integriert sind hierbei
- Einfache Nutzung
- Canvas-Rendering
- Animationssystem für Sprites
- Gameobjects
- Plugin-System
- Frameskip-Integration um eine konstante Aktualisierungsrate bei aufwendigen Projekten zu sichern

Geplant für die 0.6 (welche stark Cross-Plattform wird) sind:
- Font-/Message-Syystem
- Fallback-Renderer (gedacht für ältere Geräte oder Mobilgeräte, funktioniert allerdings auch auf Wii ^^)
- Überarbeitetes Input-Plugin
- Performance-Verbesserungen

Ein paar kleine Demos findet ihr hier:
http://zero.screensports.de/demos/050/panorama/
http://zero.screensports.de/demos/050/tiles/
http://zero.screensports.de/demos/050/train/

Zusätzlich haben wir hier noch ein kleines und sehr simples Beat em' Up, welche nur dazu dient, die Stabilität und Nutzbarkeit der Engine zu demonstrieren!
Die "Fighter"-Demo

Wir würden uns sehr über Kritik/Vorschläge/Meinungen freuen.
Bei Interesse auch einfach mal bei http://www.screensports.de vorbeischauen! ;)

Liebe Grüße

[Chromanoid]

Sehr interessant!

Ich habs mal in den Vorstellungsbereich verschoben :)

Auf dem Blog steht, dass ihr jetzt auch Touchsteuerung drin habt, benutzt ihr dazu die Api von HTML5?

[Sacume]

Nein, das ist mit Javascipt gelöst :)

[marcgfx]

was mich interessieren wurde ist die umstellung auf canvas. heisst das ihr verwendet nur noch canvas oder doch noch andere html elemente? bin selbst auch mit javascript am arbeiten, verwende aber noch divs/bilder und html tags. eine umstellung auf canvas wäre denkbar, die frage ist wirklich ob es sich lohnt. bin noch etwas skeptisch :) ... wie viel performance habt ihr dadurch rausgeschlagen?

[Skarge]

was mich interessieren wurde ist die umstellung auf canvas. heisst das ihr verwendet nur noch canvas oder doch noch andere html elemente? bin selbst auch mit javascript am arbeiten, verwende aber noch divs/bilder und html tags. eine umstellung auf canvas wäre denkbar, die frage ist wirklich ob es sich lohnt. bin noch etwas skeptisch :) ... wie viel performance habt ihr dadurch rausgeschlagen?

Morgen. Als Coder des Projekts kann ich dir hier denke ich die beste Auskunft geben ;)
Wir differenzieren zwischen verschiedenen "Render-Plugins", die alle eingebunden werden können. Standardmäßig ist der Canvas-Renderer dabei, ein Weiterer (Fallback, läuft ebenfalls mit DIVs für ältere Systeme) kommt mit Version 0.6 wieder dazu. Der Umstieg auf Canvas kostet durchaus ein wenig Performance, allerdings ist der Verlust bei weitem nicht so hoch wie man es eventuell befürchtet.
Bis Version 0.5 wurde mit jedem Durchgang stets die komplette Szenerie gezeichnet, was bei größeren Zeichenflächen und vielen Objekten Leistung kostete. Mit der kommenden 0.6 wird Multi-Layer-Canvas eingeführt, was in der hier gezeigten Fighter-Demo (getestet mit der aktuellen Dev-Version) eine Beschleunigung um Faktor 10 (!!!) bringt. Der große Vorteil an Canvas ist allerdings, dass man auf einfache Weise deutlich mehr aus der Szene rausholen kann, sei es durch mitgelieferte Zeichenfunktionen, der Möglichkeit der Per-Pixel-Manipulation oder anderen Dingen, wodurch sich optisch eine deutliche Verbesserung erwirken lässt. Schon mal versucht, im Internet Explorer (6 oder 7) ein Bild zu rotieren? :)

Laut Benchmarks liegt der Unterschied zwischen DIV/Bilder-Darstellung und Canvas-Darstellung bei der Fighter-Demo derzeit bei knapp 1ms im Gesamtdurchgang (getestet mit Core2Duo P7350, 3GB RAM, Firefox 3.6), was bei knapp 40-50ms pro Aktualisierung durchaus annehmbar ist ;)

[marcgfx]

Schon mal versucht, im Internet Explorer (6 oder 7) ein Bild zu rotieren? :)
Laut Benchmarks liegt der Unterschied zwischen DIV/Bilder-Darstellung und Canvas-Darstellung bei der Fighter-Demo derzeit bei knapp 1ms im Gesamtdurchgang (getestet mit Core2Duo P7350, 3GB RAM, Firefox 3.6), was bei knapp 40-50ms pro Aktualisierung durchaus annehmbar ist ;)

Im IE6-8 läuft Canvas doch gar nicht? Oder gibt es dafür ne Lösung.
Versteh ich das richtig mit dem Performancegewinn von ~2.5%? In dem Fall würde ich mir die Umstellung mal für später vornehmen. Bei komplexen Szenen könnts dann aber schon deutlich schneller werden, wenn nicht mehr alles angezeigt werden muss.

Danke für die Infos :)

[Skarge]

Schon mal versucht, im Internet Explorer (6 oder 7) ein Bild zu rotieren? :)
Laut Benchmarks liegt der Unterschied zwischen DIV/Bilder-Darstellung und Canvas-Darstellung bei der Fighter-Demo derzeit bei knapp 1ms im Gesamtdurchgang (getestet mit Core2Duo P7350, 3GB RAM, Firefox 3.6), was bei knapp 40-50ms pro Aktualisierung durchaus annehmbar ist ;)

Im IE6-8 läuft Canvas doch gar nicht? Oder gibt es dafür ne Lösung.
Versteh ich das richtig mit dem Performancegewinn von ~2.5%? In dem Fall würde ich mir die Umstellung mal für später vornehmen. Bei komplexen Szenen könnts dann aber schon deutlich schneller werden, wenn nicht mehr alles angezeigt werden muss.

Danke für die Infos :)

Die 2,5% beziehen sich auf 1ms Unterschied im 40-50ms Durchgang? Dann hab ich mich falsch ausgedrückt, sorry ^^
Die 40-50ms beziehen sich auf die Zeit, die jedem Aktualisierungsdurchgang zur Verfügung steht (bei eingestellten 20/25 fps). Mittels Canvas komme ich hierbei auf etwa 2 - 2,5ms pro Aktualisierung (je nachdem was aktualisiert werden muss), mittels DIVs auf etwa 1-1,5ms. Arbeiten direkt am DOM ohne Canvas usw. sind halt immer schneller ;)
Allerdings steht bei DIV-Nutzung der Aufwand für gewisse Dinge (wie halt eben die Sprite-Rotation im IE) in keinerlei Relation zum Nutzen, andere kann man gar nicht umsetzen. Von daher lässt man dort viele Dinge von vornherein wegfallen. Und Canvas sieht, abgesehen von Randeigenschaften, wirklich mal in jedem Browser gleich aus.

[RazzMeNot]

2.5% Unterschied von Canvas zu DOM-Elementen? Das halte ich für ein sehr überzogenes Gerücht. Dann muss bei euch das lokale Caching und Scoping schon stark überladen sein, dass der Unterschied dermaßen gering ist. Man muss nicht für alle Elemente den DOM penetrieren - dafür gibts das Konzept von Compositor und Renderer =)

Ein schöner Ansatz, aber ich würde im Quellcode sehr viel ändern. Alleine die fehlenden lokalen Variablen zwecks Caching in den Funktionen machen das Teil langsam. Schwerwiegender ist wohl die fehlende Nutzung von Links (zu den Objekten) anstelle des kompletten Cachings. Dadurch wird die Performance stark angekratzt.

Auf Mobilgeräten funzt das? Ohne translate3d Tricks? Sicher? =)

Liebe Grüßel von einem skeptischen JavaScript Ninja =D

[marcgfx]

also canvas ist langsamer? das ist jetzt schon eher was ich erwartet hatte :), hab doch auch ein paar sachen in canvas gemacht und es ist immer ziemlich lahm. dann lass ich vorerst wirklich lieber die finger davon, will ja schneller werden nicht langsamer. engine funktioniert eh schon, da ist mir auch IE wurst.

wie viel kann man denn noch durch das caching rausholen (verwende es selbst dauernd, auch weil ich lange zusammengesetzte variablen hasse)?

[Skarge]

Nach einigen Monaten nochmal ein kurzes Status-Update:

Die Entwicklung lief einige Wochen in reduzierter Geschwindigkeit, wurde inzwischen aber wieder voll aufgenommen. Dementsprechend gibt es auch einige erfreuliche Neuigkeiten zu verkünden:

- 0.6 ist fast fertig (Features: Fallback-Renderer, Font-Plugin, neues Input-Plugin u.a.)
- Team ist angewachsen
- Bugtracking-System wurde eingerichtet, erreichbar unter http://www.screensports.de/bugs/ (englisch)

Zudem befindet sich eine kleine IDE in der Entwicklung, über die künftig eine Erstellung von Projekten usw. mit der Engine möglich sein soll. Diese wird zur 0.6 nicht verfügbar sein, aber dennoch Einzug finden. Eines der Features der IDE ist die Live-Preview, über die alle Änderungen unmittelbar und ohne neuladen sichtbar werden.

Hier noch ein Screenshot zur aktuellen IDE-Version, auf dem eine Bearbeitung der Train-Demo aus v0.5 zu sehen ist:

[Chromanoid]

Damit Bilder in den Showroom auf der Frontpage kommen muss in Projektthemen das Bild in einem Beitrag vom Themenersteller liegen. Falls ihr also auf die Frontpage wollt, sollte das Bild entweder von deinem Kollegen noch mal gepostet werden oder du kannst es im Showroom-Thema posten.

Sieht auf jeden Fall chic und recht bequem zu bedienen aus! Habt ihr euch mal angeschaut, ob man eure Engine und ihre Management Funktionen in Maqetta einbinden könnte? Ich glaube das Teil bietet wirklich viele nette Funktionen...