Game-Developer aufgepasst! => Canvas Game Engine

Sehr coole Idee. Wenn ich schon Plan davon hätte würde ich es glatt mal ausprobieren.
Hoffe du findest hier noch ein paar "Fans" von deiner Engine.

Gruß Kevin

gibts schon howto start oder sowas?

Klingt sehr interessant, werde die ganze Sache mal beobachten!

Habs mal ausgecheckt. Was auffällt ist das kein TAG im SVN gesetzt wurde um einen ersten Stand zu sichern.


Einige Anregungen:

Dann fällt auf das dass Interface Renderer und die renderables hier declariert wurden, das macht in Interfaces meist keinen Sinn! Abgesehen wird das auch nirgendwo verwendet!


/**
* The list from where the Renderer get its Sources.
*/
public ArrayList<Renderable> renderables = new ArrayList<Renderable>();

Die Klasse AdvancedRenderer ist überflüssig momentan!


Im SurfaceRenderer hast du ebenfalls eine List mit renderables, implementierst hier aber auch das Interface Renderable:

private ArrayList<Renderable> renderables = new ArrayList<Renderable>();


Von Thread zu erben ist eher kontra produltiv, besser ist Runnable oder Callable zu implementieren, gerade wenn man ein Framework schreiben möchte:

public class GlobalClient extends Thread{


Deine Konstanten sind nicht final:

public class Constants {



hth,
Mac

Ein Interface ist eine Schnittstelle, keine konkrete Klasse! Schnittstellen sind daher flexibler.
Zweitens gibt es in Java nur einfache Vererbung und keine Mehrfachvererbung wie z.b in C++!
Man ist als gezwungen von deiner Klasse zu erben wenn man etwas verändern möchte, das ist eher unschön!
Ich würde daher davon abraten von Thread zu erben, stattdessen ihn nur lokal zu erzeugen, und zu verwalten. (damit hast du auch mehr Kontrolle über den Thread)

BSP: Erbst du von Thread können andere auf die Idee kommen und ihn direkt verändern da seine API frei zugänglich ist.

— geändert am 14.05.2010, 00:28:48

Hab das Gefühl du hast dich was von Rokon inspirieren lassen
Rokon ist in Sachen Design leider kein so gutes Vorbild.
Man kann es sich aber anschauen, wenn man OpenGL lernen möchte.

Die einzigen die sich lohnen genauer anzuschauen sind meiner Meinung nach zZ nur:

Cocos2d
Eine Portierung der beliebten Engine vom IPhone (urspünglich Python).
Leider noch etwas uncomplete und buggy. Seit Wochen leider keine Aktivität mehr in dem Projekt.
Als Lehrbeispiel aber im Prinzip vom Design geeignet, so lang man im Hinterkopf behält, dass hier mit Object allocation nur so um sich geworfen wird.
Um es produktiv zu nutzen, muss man auf jeden Fall selber noch Hand anlegen.
http://code.google.com/p/cocos2d-android/

Libgdx
Dieses Framework ist eher für Fortgeschrittene. Ist aber absolut flexibel und vollständig (+ box2d wrapper).
Anfänger sind vll erstmal etwas verloren, weil kein Design-Gerüst (wie zB einen scene graph in cocos) aufgezwungen wird.
Man merkt hier, das Mario (Entwickler von libgdx) es einfach drauf hat.
Er ist unter anderem auch der Author von dem Spieleentwicklung 101 hier im Wiki (https://www.nextpit.de/de/android/wiki/view/Spieleentwicklung_101)
Großer Vorteil von libgdx: man kann es auf dem Desktop entwickeln und es läuft genauso auf Android.
Das ist ein enormer boost für die Entwicklung.
http://code.google.com/p/libgdx/

Rokon
Für Anfänger ok, wenn man schnell was einfaches auf dem Screen haben möchte.
Ein komplettes Spiel würde ich selber nicht damit machen. Ich hoffe Richard hat mit Version 2 aus dem ersten Entwurf viel gelernt.

Ansonsten gibts viele kleine und halb fertige Projekte, die man (noch) nicht ernst nehmen kann.

Bei einer Game-Engine/Framework ist es aber auch besonders schwierig einen guten Kompromis aus Design,Speed und Usability zu finden.

Eine Canvas-Engine ist aber auf jeden Fall auch sinnvoll. Nicht jedes Spiel ist so umfangreich, dass OpenGL gebraucht wird.

Mal eine kleine Frage dazu: Wenn die Engine alle Exceptions fängt, woher soll dann die Anwendung wissen, dass etwas nicht funktioniert hat?

Ein Beispiel:
Ich will den GlobalClient instantiieren. Ich als Anwendungsentwickler habe z.B. keinerlei Kontrolle mehr darüber, ob der Port belegt ist.

Ein Framework/eine Engine sollte IMHO keine Exceptions fangen, da diese mit ihnen gar nichts anfangen kann.

Hi Dominic,

ich bin mal über den SourceCode geflogen. Also ich bin mir nicht sicher welche Art von Spiel die Engine unterstützen soll, aber bei Echtzeit Spielen wirds schwierig, da Du viele Pattern / Klassen benutzt die erwiesendermaßen un-performant sind.

Bei Spielen sollte man drauf achten:

a) keine Collections zu benutzen (Hashmap, ArraList , ....)
b) keine String Erzeugung zur Laufzeit : Alles was zwischen 2 Hochkommas steht ist ergo schonmal schlecht.
c) Methoden auf Interfaces aufzurufen ist um den Faktor 2 x langsamer als auf einer Konkreten Klasse
e) advanced Loops mit for(String bla: blaList) erzeugen zur Laufzeit Iteratoren die wiederum den GC triggern
f) Texturen zur Laufzeit zu Skalieren ist auch ein wenige Un-Performant
g) "new" sollte gänzlich zur Laufzeit weggelassen werden


als Randinfo: Der Garbage Collector lauft in der Regel 50-500 ms je nach Device, was soviel bedeutet wie: Deine Animationen ruckelt oder hängen. Für Real-Time Game ein No-Go, PuzzelSpielen macht sowas wiederum nicht viel aus.

Grüße

Möcht mich nur kurz dazuschalten auch wenn die letzte Antwort schon einen Monat alt ist

@a dem kann ich nicht zustimmen. ArrayList ist durchaus sinnvoll und macht keine Probleme mit dem GC, vor allem wenn die maximale Größe schon am Anfang angegeben werden kann. HashMap ist da schon eher ein Problem
@b Strings zur Laufzeit zu erzeugen ist keine gute Idee, da geb ich dir Recht. String Literals zu verwenden, also alles was zwischen 2 Hochkommas steht ist absolut kein Problem weil die als Konstanten abgelegt werden. Strings konkatenieren ist ein Problem. Dafür kann man aber einen StringBuilder einmal instanzieren und überall wieder verwenden (hint: clear killt nur den Zeiger auf die aktuelle Position im gebauten String. Der backing array wird nicht verworfen).
@c ist leider ein Mythos den der Herr Chris Pruett in seinen wenig aussagekräftigen Tests auf Android 1.1 "entdeckt" hat. Der stimmt so schon lange nicht mehr. Zwecks gutem Design kann man daher ruhig auf nicht Interface Methoden aufrufen.

Ansonsten gute Info. Auf der Android Developer Seite gibts auch einen Artikel zum Thema Performance Tipps. Auch wenn einige der Dinge nicht ganz der Realität entsprechen sind einige hilfreiche Sachen dabei.

Ciao,
Mario