Invictus Deus Ex Machina
Das mittlerweile mit CSS Dinge wie Logos und Formen abgebildet werden, hat sich sicherlich schon herumgesprochen. Witzig wird das ganze immer dann, wenn neue Grenzen ausgelotet werden, wie dies auch bei den „CSS Creatures“ geschieht.
bennettfeely.com/csscreatures/
Dort werden kleine Monster gezeigt, welche vollkommen in CSS erstellt wurden. Daneben kann man sich auch eigene Monster erzeugen. Zu finden ist das ganze unter http://bennettfeely.com/csscreatures/.
Bei melonJS handelt es sich um eine Javascript Engine zur Spieleentwicklung im Browser mittels HTML5. Möchte man dort ein Level laden, so geschieht das in Form einer TMX Datei. In melonJS gibt es dabei zwei Methoden zum laden der entsprechenden Daten. Diese sind „me.loader.preload“ und „me.loader.load“. Alle Beispiele welche man im Netz so findet nutzen dabei immer die „preload“ Methode:
var g_resources= [
{ name: "desert1", type: "image", src: "desert1.png" },
{ name: "desert", type: "tmx", src: "desert.tmx" },
{ name: "player_male_base", type: "image", src: "player_male_base.png" },
{ name: "fog", type: "image", src: "fog.png" }
];
...
me.loader.preload(g_resources);
Das Problem ist das man bei größeren Spielen mit ein paar hundert MiB Spieldaten, das ganze schlecht komplett in den Speicher laden kann. Hierfür gibt es die „load“ Methode. Allerdings enthält diese einige Fehler welche das ganze erschweren. Die „preload“ Methode trägt jede TMX Datei in das Array „levels“ im „me.levelDirector“ ein. Bei der „load“ Methode passiert genau dies nicht. Deshalb muss man hier anders vorgehen (bis der Fehler behoben ist). Ein Minimalbeispiel zum laden eines Levels sieht damit so aus:
<!DOCTYPE html>
<html>
<head>
<title>melonJS minimal sample</title>
<meta charset="utf-8" />
</head>
<body>
<script type="text/javascript" src="melonJS.js"></script>
<script type="text/javascript">
var jsApp = {
start: function() {
if (!me.video.init('jsapp', 640, 480, false, '1', false))
{
alert("Sorry but your browser does not support html 5 canvas.");
return;
}
me.loader.onload = this.loaded.bind(this);
//lade manuell
me.loader.load({name: "desert1", type:"image", src: "desert1.png"}, this.onload);
me.loader.load({name: "desert", type:"tmx", src: "desert.tmx"}, this.onload);
//zeige Ladebildschirm
me.state.change(me.state.LOADING);
},
onload: function(data) {
me.levelDirector.addTMXLevel("desert"); //Bugfix
me.levelDirector.loadLevel("desert");
},
loaded: function() {
me.state.set(me.state.PLAY, new PlayScreen());
me.state.change(me.state.PLAY);
}
}
var PlayScreen = me.ScreenObject.extend({
});
//starte wenn der Browser bereit ist
window.onReady(function() {
jsApp.start();
});
</script>
</body>
</html>
Damit lädt man ein Level dynamisch, ohne auf die „preload“ Methode angewiesen zu sein. Möglich wird dies durch den kleinen Bugfix in der „onload“ Methode:
me.levelDirector.addTMXLevel("desert"); //Bugfix
Dieser sorgt dafür das der levelDirector über die entsprechende TMX Datei informiert wird und somit die Datei beim laden des Levels auch findet.
Über Websockets kann man Binärdaten verschicken, leider ist dies nicht ganz so einfach wie es sein sollte. Das erste Problem ist, das es in JavaScript bis vor einiger Zeit keine „Binärtypen“ gab. Aber dank einiger Dinge ist es mittlerweile möglich Binärdaten per JavaScript und Websockets zu versenden. Mein Problem an der binären Datenübertragung war bisher, das es augenscheinlich nirgens ein komplettes Beispiel gibt, welche diese einfach mal demonstriert. Dabei ist das ganze relativ einfach:
<!DOCTYPE html>
<html>
<head>
<title>Websocket Binary Test</title>
<meta charset="utf-8" />
</head>
<body>
<script type="text/javascript">
websocket = new WebSocket("ws://echo.websocket.org");
websocket.binaryType = "arraybuffer"; //Binärtyp auf arraybuffer setzen
//OnOpen verdraten
websocket.onopen = function (e) {
//Array zusammenbauen
var message = new ArrayBuffer(9);
var dataViewMessage = new DataView(message);
dataViewMessage.setInt8(0, 25); //Command ID
dataViewMessage.setInt16(1, 11); //Account ID
dataViewMessage.setInt32(5, 43333020); //Anzahl der Credits
//message per Websocket wegschicken
websocket.send(message);
}
//OnMessage verdraten
websocket.onmessage = function (wsPackage) {
//Datentyp ermitteln
if(wsPackage.data instanceof ArrayBuffer) alert("ArrayBuffer");
else if(wsPackage.data instanceof Blob) alert("Blob");
else if(typeof wsPackage.data === "string") alert("string");
//Daten empfangen und auseinander bauen
var dataViewPackage = new DataView(wsPackage.data);
alert(dataViewPackage.getInt8(0));
alert(dataViewPackage.getInt16(1));
alert(dataViewPackage.getInt32(5));
}
</script>
</body>
</html>
Im den ersten Zeilen im Skriptteil wird zuerst ein Websocket angelegt, welches sich mit „ws://echo.websocket.org“ verbindet. Dieser Server gibt immer genau das zurück was er empfängt und eignet sich somit ausgezeichnet für diesen kleinen Test.
Danach wird der „binaryType“ des Websockets auf „arraybuffer“ gesetzt, da wir mit einem solchen arbeiten wollen. In der verknüpften „OnOpen“ Methode wird ein „ArrayBuffer“ mit der passenden Größe angelegt und mit diesem ein „DataView“ initialisiert. Mit diesem ist es dann möglich problemlos möglich die entsprechenden Werte in den „ArrayBuffer“ zu setzen.
Dies geschieht dann mit den Zeilen:
dataViewMessage.setInt8(0, 25); //Command ID dataViewMessage.setInt16(1, 11); //Account ID dataViewMessage.setInt32(5, 43333020); //Anzahl der Credits
Am Ende wird das ganze weggeschickt und anschließend wieder in der „OnMessage“ Funktion empfangen. Dort wird der Datentyp ermittelt (für den Fall das man mit mehreren Typen arbeitet) und anschließend wird das Paket wieder Binär auseinander genommen.
Weitere Informationen gibt es unter:
http://www.websocket.org/echo.html
http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/
https://developer.mozilla.org/en-US/docs/JavaScript_typed_arrays
http://msdn.microsoft.com/de-de/library/br212463%28v=vs.94%29.aspx
https://developer.mozilla.org/en-US/docs/JavaScript_typed_arrays/ArrayBuffer
http://stackoverflow.com/questions/11390021/transferring-files-with-javascript-through-websockets
In den Zeiten von HTML5 wird uns eine neue Webtechnik nach der anderen um die Ohren geschlagen und da sitzt man nun als Entwickler und überlegt welche Techniken man davon einsetzen kann. Sehr hilfreich bei diesem Problem ist die Seite http://caniuse.com bei welcher man nach der entsprechenden Technik suchen kann (z.B. WebGL) und dann sehen kann, in welchen Browser und Versionen die jeweilige Technik unterstützt wird.
Das ganze wird dabei in einer übersichtlichen (tabellarischen Form) serviert. So sieht man dann z.B. das die Unterstützung für WebWorker aus Android ab Version 2.2 entfernt wurde, es in anderen Browsern aber problemlos nutzen kann.
HTML und Spieleentwicklung ist etwas was vor ein paar Jahren nicht wirklich zusammenpasste. Mittlerweile ist dies dank HTML5, Javascript und Co. möglich und es gibt auch schon einige Spiele welche dies eindrucksvoll zeigen. Ein interessanter Blog der sich rund um dieses Thema dreht, findet sich unter http://www.html5gamedevs.com/. Dort werden neue HTML5 Spiele und interessante Neuerungen aus diesem Bereich vorgestellt.
Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/HTML5
Rollenspiele in Javascript sind an sich eine schöne Sache. Man muss keine zusätzliche Software installieren und das Spiel als solches ist auch immer aktuell. Gezeigt hat dies neulich Mozilla mit dem MMORPG BrowserQuest welches komplett im Browser läuft. Möchte man RPGs selber schreiben so sollte man sich mal die Bibliothek RPG JS anschauen, welche unter http://rpgjs.com/ zu finden ist. Die Engine ist dabei unter MIT und GPL dual lizenziert.
Weitere Informationen gibt es unter:
http://www.guido-muehlwitz.de/2012/02/rollenspiele-in-html5/
http://www.golem.de/news/browserquest-mozilla-startet-browser-mmog-in-html5-1203-90802.html
Nach einigen Monaten ist es Zeit den Zwischenstand für den neuen Invertika Server und den Client vorzustellen. Invertika soll somit auf einer neuen technischen Basis stehen. Diese neue technische Basis sieht so aus, das der Server in C# geschrieben wird und somit unter Mono und .NET läuft. Für den Client ist eine Implementation als Webapplikation angedacht. Das ganze hatte dabei mehrere Gründe:
Neben diesen Gründen sind es auch einige Dinge wie „typedefs“ welche nicht unbedingt zum Verständnis beitrugen oder mehrere Klassen und Strukturen in einer Datei, welche das ganze ziemlich unübersichtlich machen. Auch die Abhängigkeit von zu vielen Bibliotheken wurde verringert.
Der Invertika Code in der Entwicklung
Nach einer kurzen Planungphase ging es dann am 3. Januar los mit der Entwicklung. Zuerst wurde damit begonnen den Accountserver zu portierten. Dabei wurden im Gegensatz zum Original einige Dinge verändern:
Am 13. Januar (einem Freitag 
) waren die größten Portierungprobleme beim Accountserver gelöst und es wurde begonnen den Gameserver zu portieren. Am Gameserver ist die einzige größere Änderung die Anpassung der Skriptschnittstelle, damit diese mit den CLR Sprachen kompatibel ist. Die Roadmap für die Portierung sah dabei so aus:
Wie sich das für eine ordentliche Roadmap gehört wurde sie nicht eingehalten. So ist einiges noch nicht fertig und auch am Client muss noch viel getan werden. Der Client sollte ursprünglich auch in C# geschrieben werden und es wurde damit auch begonnen. Theoretisch ließe sich diese Clientvariante auf die Plattformen Windows, Linux, Mac OS X, iOS und Android bringen, praktisch ist es mit kleineren und größeren Problemen verbunden.
Ein generelles Problem an einem solchen Client ist, das er auf der jeweiligen Zielplattform erst installiert (oder auch kompiliert) werden und außerdem vom Nutzer aktuell gehalten werden muss. Schöner wäre es, wenn man diese Hürde aus dem Weg geschafft wird. Mittlerweile ist es dank Techniken wie Websockets, Webworkern und Canvas möglich, den Client komplett als Webapplikation zu schreiben.
Die Anfänge des neuen Clients basieren dabei auf der Techdemo „mana.js“ welche unter https://github.com/bjorn/mana.js zu finden ist. Der Vorteil der webbasierten Lösung ist dabei die große Kompatibilität mit unterschiedlichsten Geräten solange sie über einen aktuellen Browser verfügen.
Die Techdemo des Clients auf einem iPad
Während der Entwicklung bekamen die einzelnen Teile auch Namen die wie folgt lauten:
Der Quelltext sollte in den nächsten Tagen im Repository (http://source.invertika.org) erscheinen und zur Mitarbeit einladen
Weitere Informationen gibt es unter:
http://invertika.org
Wer ein Spiel für ein Mobilgerät schreiben möchte hat das Problem das es eine ganze Menge dieser Systeme gibt. Die bekannteren sind sicherlich Android und iOS. Möchte man für diese Systeme ein Spiel schreiben, so wäre eine Abstraktionsschicht eine feine Sache. Eine solche bietet Google mit „PlayN“ unter der Apache Lizenz an. Mit diesem Framework wurde unter anderem die Google Chrome Version von Angry Birds geschrieben. Aktuell werden folgende Plattformen unterstützt:
Auch Flash wird unterstützt, wobei das Backend dafür im Moment einen Maintainer sucht und deshalb in dieser Liste nicht auftaucht. Herunterladen kann man sich PlayN unter http://code.google.com/p/playn/.
Weitere Informationen gibt es unter:
http://code.google.com/p/playn/wiki/PlatformStatus
http://www.schockwellenreiter.de/blog/2012/03/12/playn/
Gestern gab es einen Artikel über einen Gameboy Color Emulator und schon lese ich bei Golem (http://www.golem.de/1106/84265.html) etwas über PDF Rendering in Javascript. Es handelt sich dabei um die Javascript Bibliothek pdf.js.Mit dieser Bibliothek kann man PDF Dokumente im Browser ohne Plugins oder dergleichen rendern. Sie ist dabei bei weitem noch nicht Feature komplett aber schon ein sehr schönes Proof of Concept. Der Quellcode ist dabei unter https://github.com/andreasgal/pdf.js zu finden.
Stefan Münz, vielen bekannt durch SELFHTML brachte vor einiger Zeit ein 744 Seiten starkes HTML5 Handbuch heraus. Dieses kann nun kostenlos unter http://webkompetenz.wikidot.com/docs:html-handbuch gelesen werden. Viel Spaß beim lesen 
Weitere Informationen gibt es unter:
http://www.golem.de/1103/82248.html