GAME DESIGN || FLASH DEVELOPMENT || GAME ENGINE DEVELOPMENT

For high performance animation i used an oldschool technique known from many old 2D games. This technique is called spritesheet. The main point in a spritesheet is that you have only one picture for a whole animation sequence of pictures. The renderer switches between the output area of this image to make the picture “move”.

To debug my Actionscript projects in Flex or Flashbuilder i have decided to create my own Debugging Console. There are some reasons for this decision:

• Debugging in Flex often ends in bluescreen and dataloss on my maschine
• Debugging in Fullscreen Mode doesn’t let you see traces on runtime
• it’s important for me to check framerate and ram usage on runtime

It allows me to use Console.print(“hallo world “+value); everywhere in my project, after i have set the MainLayer as reference for my Console.

More soon!

Yesterday i had a really hard working session on my game engine, handling dynamical loaded fonts. To embed fonts at runtime you have to put them into a container-swf, but i didn’t realize that there are different ways for the Flexbuilder to import them. My font container was successfully loaded, but the font wasn’t visible in the used textfields.  So after hours of searching for a fault, i found the problem inside of the container-swf. For embedding Fonts Flex can use 3 different Managers.

My best friend google told me that a Manager called AFEFontManager (which isn’t the standard manager) has the best chance to embed a font sucessfully.

Et voilà…after forcing the compiler to use AFEFontManager, my font was accessable & visible in any textfield.

You can change the standard Font Manager in your flex-config.xml file or use the additional compiler arrguments if you want to change it only for the current project:

-managers=flash.fonts.AFEFontManager

Stay tuned!

Vor einiger Zeit habe ich damit begonnen eine Game Engine in ActionScript 3 aufzusetzen, die dazu geeignet sein sollte Flash Games vom Browser auf den Desktop zu holen. Keine 600 x 300 großen Spielfenster mehr, bei denen man immer aufpassen muss, dass man nicht daneben klickt oder es versehentlich schließt.

Alter Stand der Drachensturm Engine || Anfang 2009

Dank Adobe Air ist es ja auch möglich Anwendungen oder Spiele für den Desktop zu entwickeln, lokal Daten zu speichern, etc.

Da ich ein großer Strategiespiel Fan bin, ging die Entwicklung in die Richtung einer Engine für 2,5D Strategiespiele.

ISO Editor der Drachensturm Engine || Anfang 2009

Ich fing bei 0 an, machte tausende Fehler, bekam enorme Performance Probleme. Aber dadurch lernte ich viel über Actionscript und Performance, da ich immer wieder neue Strukturen ausprobieren musste um meine Algorythmen zu beschleunigen. Vor ca. einem Jahr stiess ich dann auf die Bitmap-Rendering Methoden, die der ganzen Engine einen Geschwindigkeitsschub gaben.

Nun, 1,5 Jahre nach den ersten versuchen hab ich die alten Codefetzen wieder aufgegriffen. Es gibt noch viel Optimierungsarbeit zu machen, aber langsam wird die Engine zu einer ganz schicken Sammlung von Klassen.

Ich weiß nicht ob ich wirklich Pionier in der Entwicklung einer Flash Fullscreen-Gaming-Engine bin, aber ich weiß eines: Die Zukunft von FlashGames wird sich bestimmt auch in diese Richtung entwickeln, da Flash plattformübergreifend einsetzbar ist. Ich will diese Entwicklung auf jedenfall nicht verpassen.

Ich werde in Zukunft immer mal wieder neues zur Engine und den internen Mechanismen posten, wenn es interessante Erkenntnisse gibt.

Herzlich Willkommen auf meinem Entwicklerblog!