Jan 172014

Tetragon Racetrack Extension

One of my jobs in the last year was to work on a racing game for a client who wished to run it on the web and on iPads. We had to make a decision of whether to develop something in realtime 3D or to use a pseudo 3D engine (think Outun, Lotus Esprit Turbo Challenge) to portray the racetrack of the game and after some research it was clear that the second option was the more practical for us. Back then Code inComplete had already written a useful demo game in JavaScript that was just what we needed so I took the JS code and ported it to AS3, rewrote vast swathes of it to turn it into a re-usable engine and on top added several additional features. The result of this work is the Racetrack Extension for Tetragon.

Continue reading »

Jan 172013

It has been very quiet here for over half a year which might have given rise to rumors that the Tetragon Engine is dead. But these are luckily only that, rumors. Unfortunately, due to profoundly tragic events in my life in the last year, I had to freeze all my activities and projects, except for my daily job. This included development on the Tetragon Engine as well which however was continually being used by myself for my job. There are a couple of good news I have for anyone who is interested in the engine, however …

  • Tetragon is now licensed under the MIT license again and as that distributed as Open Source.
  • Development on Tetragon continues steadily. Sometimes faster, like now, and sometimes slower, like when I’m very busy on my regular job dealing with client work.
  • The Tetragon Engine is now company-backed by Nothing Interactive.
  • The Tetragon project and source code is now hosted on Github.
  • There is now a wiki for Tetragon which can be found at wiki.tetragonengine.com. At the moment it’s still small but there is now a Beginner Guide available and eventually the wiki will become the main documentation source for Tetragon, containing docs and tutorials that cover all aspects of the engine.

So if you are interested in a Flash/AIR-based game engine to use as the basis for your next game project you may want to give Tetragon a shot.

Apr 012012

The Tetragon Engine has so far been released as open source under the MIT License but since today is distributed under a new, custom dual license that was defined to allow us better control of how the engine is distributed while it still can be offered freely to almost anyone who likes to use it for developing games.

But don’t be scared away now by the word dual license! The license change has zero impact on indie developers and small to most medium-sized businesses and most of you will be able to use Tetragon just like any other open source software. The new license can however have an impact on larger companies that exceed a certain annual gross revenue.

You can review the dual license on the License Page where you can also find a fully detailed version of the EULA, which additionally is included with the source code distribution of the project.

Mar 192012

While it currently seems to be very quiet on the surface here, the truth is that it’s buzzing with Tetragon development in the development labs. The engine changes and improves by leaps and bounds with every step. All the time the entity system is being worked on, which proves to be quite a challenging beast. There are plenty of improvements and bug fixes that have been done recently, the FPS Monitor has been replaced by a more useful Stats Monitor which displays a lot more information (more in-depth info on that later!). The build process now allows to define it’s own build properties per build target (think different width/height/fps/etc. for each target platform), the resource folder has been restructured to allow for per-platform dedicated resources, a Fallback Resources feature has been added (mainly for image resources), and right now a layer for hardware-accelerated (Stage3D) 2D rendering is being worked on (based on Starling but highly optimized and tailored for the engine).

I’m pushing intermediate builds live every now and then on the public repository but don’t hold too much onto them as they are usually already outdated the next day. It will probably go on like this until the v.1.1 “Centauri” milestone is reached in which the basic Entity System should be ready and some other systems are integrated (e.g. 2D rendering, audio system) to allow for the development of a demo game that can be used to showcase the engine’s abilities better.

With Adobe’s plans for the Flash platform to become a major player for game development (read Adobe’s roadmap here) these are indeed exciting times to build a versatile game engine for Flash and AIR.

Dec 182011

As you might probably know Tetragon uses zipped resource packages that are used by it’s AIR builds. These resource packages contain all the asset files, which can be images, XML files, SWF files, etc. etc. and also MP3 files. The only way to load MP3 files directly with AS3 so far has been to use Sound.load() but in the case of Tetragon MP3 files need to be loaded as raw byte data since this is the only way how it works to read  MP3 files that are stored in a packed zip file (remember Tetragon streams in data from zip files via random access, which is quite cool and something I explained here).

Since the AS3 Sound class had no methods to accept any byte data the workaround to load MP3 files as raw byte data so far has been to load them with URLLoader and then wrap the MP3 data into an in-memory SWF that is created with the help of AS3SWF. This works fine on desktop- and on Android builds. But enter iOS where it’s strictly forbidden to execute any non-native scripts and the whole idea falls apart as not even the creation of an in-memory SWF structure is allowed there, you will simply get an exception thrown and end up with no sound in your application.

However with the release of Flash Player 11 and AIR 3 there was a promising solution for this problem glittering at the horizon of Flash development: two new methods for the AS3 Sound class named loadCompressedDataFromByteArray and loadPCMFromByteArray! This new API was something I’m sure many audio-related Flash devs have been looking forward to since a long time and so I too was looking forward to finally be able to change the audio file loading in Tetragon to something that is natively supported and works on all supported platforms.

The disappointment was great when I sat down to implement the new sound API, in particular loadCompressedDataFromByteArray which as the (very terse) API documentation claims can be used to load MP3 files into the Sound class as byte data, just as we need it. In truth this obviously means that an MP3 file can be streamed in with this method and it’s audio played back only IF it’s played right after a call to the method. Trying to keep the loaded audio and play it back later results in an invalid Bytearray. This is how it’s done here. Check the onComplete handler in the script and you see how loadCompressedDataFromByteArray() is called and right after it sound playback is started. If you would try to play the sound later it’s not going to work. The audio data is lost!

UPDATE: I have filed this bug on Adobe’s new bug base! Please follow the link and vote for it! https://bugbase.adobe.com/index.cfm?event=bug&id=3072682

So either the new sound API is completely bugged or way too limited to make good use of it. There has been similar complaints from Andre Michelle about the other new method, loadPCMFromByteArray which seems to be quite buggy. Read more about it here http://bugs.adobe.com/jira/browse/ASL-281 (and please do log in and vote for the issue, if you can!). Unfortunately Adobe’s so called Bug and Issue Management System seems to be quite bugged by itself. I’ve been trying to register there, by now with three different Email addresses but never got any confirmation Email back from them, so I can’t log in. Trying to contact the admins doesn’t work either. Clicking the “contact the administrators” link will result in the following adequately useless page:

Find any admin link there? Right, me neither. Seems Adobe doesn’t want to be bugged about bugs, haha.

This is all a very sad state of affairs! whoever implemented (unplemented suits better here) the new sound API was either not given any time to finish it, or had absolutely no sense or concept on how to do this right. Seems it wasn’t even tested properly. If you can please go to Adobe’s Bug report site and make some noise about this! There is a lot of potential in the new sound API, if it only would work!

Nov 152011

As you know, Adobe dropped the Flash Player for mobile platforms last week which caused a great uproar in the Flash community and in part in the wider technology community so I think it’s important to let you know where Tetragon is heading from now and what my thoughts are about the whole mess that Adobe has caused with their announcement.

The problem isn’t really that the mobile Flash Player was terminated, it’s the loss of trust in Adobe that comes with it. Adobe’s de facto monopoly claim on the Flash platform has always been a risk lurking at the horizon and now it has come close enough to bite us in the rear end. Adobe, keen on HTML5 like the rest of the internet committee, by now seems quite willing to throw Flash out of the window easily in exchange for jumping on the bandwagon of HTML5 hype. The signs that they are giving are quite clear. But have they asked the Flash programmers if we actually want to have Flash exchanged with HTML5. Of course they didn’t! All of a sudden some Flash devs seem to be strangely attracted by HTML5 and Javascript while others have a more exotic view toward the nature of the internet. I however have to be completely honest with you, I never will be attracted by HTML5 as a programming solution.

For the last ten years I have been a Flash developer, Flash made me learn programming, it made me learn OOP, then it made me learn to hate the Spaghetti coding of ActionScript 1 and love ActionScript 2 and then it made me learn to love ActionScript 3 a loathe ActionScript 2. Flash gave me easy access to learn a professional programming language for creating games. That’s what I always wanted to do. I learned to love ActionScript’s clean and typed syntax and it’s compact distribution form as compiled and compressed binaries. Flash and in particular AIR provided everything I ever wanted for game development, sans hardware 3D but we got that recently, too.

Now enter HTML5 and Javascript! It’s a bunch of untyped, loose and inconsistent stuff at best. It’s the most farthest away thing from a classic programming paradigm and it’s everything I never wanted to touch since I learned programming. With Javascript you get something that is at the level of ActionScript 1 without strong typing, loads of dynamic object access, no classes or packages and a clutter of files that lie around openly on your server. HTML isn’t even a programming language, it’s a markup that reminds me back in horror on the early days of the internet where there was an era during that I used this stuff. I don’t really care whether the code files are easily accessible and can be stolen, that can be done with Flash too. I just don’t like the awkwardness and fragmentation of HTML5′s and Javascript’s nature.

Instead, the reason why I love working with Flash is because of the clearness of ActionScript 3 and because it’s a brilliant write-once distribute anywhere multi-platform approach with a nicely compiled release format. You don’t get this with HTML5, nor with any other platform.

Another big deal is the Open-Sourcing of the Flex framework. Quite honestly I’m not sure what to make of this one. Flex for the web is clearly unsuitable by now. HTML5 is taking over the RIA world and I have no problem with it. The Flash platform isn’t accessible enough to provide well integrated apps on the web. It’s strength are clearly defined in other areas. But the Flex framework is a very attractive solution for building desktop and mobile apps via AIR and Adobe has added several mobile-optimized UI components to the framework just recently. The open-sourcing of the Flex framework in my opinion is far more concerning than the end of the Mobile Flash Player.

How will all this affect Tetragon? For now this doesn’t affect the development of Tetragon at all. The Desktop Flash Player is still with us and hopefully for quite a while longer. But it’s easy to see where Adobe is heading with this. They are following suit with the popularity of the HTML5 dictate and want to jump on the band-wagon as quick as possible. Collateral damage doesn’t seem to matter for them. Neither does it seem to matter for their CEOs and marketing managers that JS and HTML is one giant jumble of incoherent, unoptimzed mess that lacks any OOP structure and that no decent game developer on earth wants to code with.

After that we still have the AIR platform for desktop and mobile apps and as long as the AIR platform continues to exist there is absolutely nothing in the way of Tetragon’s development. AIR is extremely attractive for game developers who want to deploy to the desktop and mobile platforms with the same code base and that is clearly one of Tetragon’s goals. Time will tell how Adobe progresses with the AIR platform but I hope they don’t spoil that one too.

But what if Adobe messes up completely and kills AIR and with that the whole Flash platform (as stupid as this may seem)? In that case I guess for me it’s either time to step back from this all for a while and concentrate on some other game design- and game development-related things or concentrate wholly onto another technology like C#, C++, haXe or even Objective-C, maybe even Python. The problem however remains: None of these technologies provide an attractive and compact multi-platform solution like the Flash platform does.

There is one thing that I can guarantee you that is never going to happen: me starting to develop with HTML or Javascript.

Oct 282011

Just a quick note for anyone who is linking or following this website or it’s RSS feed … this site has now been moved to it’s official URL www.tetragonengine.com so I recommend to update your bookmarks.

A quick info on the development state of the engine in case you’re wondering why it’s so quiet over on the engine’s GIThub repository … Do not worry! The engine is under constant development, however the dev build is – for the time being – under private hosting. For one, this is because with this we have a trac coming along with it where we can more easily track issues, bugs and feature todos. And the second reason is that Eclipse’s Egit plugin is shaky at best when it comes to merging repository branches.

There’s still quite a bit of work ahead to get Centauri ready so please be patient, we’re working on it!

Oct 152011

This diagram provides an overview of the architecture layers that Tetragon’s runtime engine follows. It shows all the major components that Tetragon consists of. Upper layers depend on lower layers, but not vice versa.What follows is a brief overview of the layers and their various components, from bottom to top.

  1. OS: This one is obvious. The underlying operating system.
  2. Flash Player / AIR Runtime: Tetragon is fully written in AS3 and so the Flash Player or AIR runtime act as a layer between engine and operating system. All compability intricacies for the various supported platforms are handled by the Flash runtime so here is nothing we need to (or can) take care of.
  3. Third-party Libraries: Tetragon makes use of third-party libraries and frameworks where it makes sense. For example all 3D rendering is provided by any of the supported 3D engines. Tetragon provides API interfaces that conveniently integrate these engines.
  4. Tetragon Base Engine: This represents the base engine of Tetragon which – if required – can be used on it’s own without the Gameplay Foundation or any of the other add-ons. The base engine is further divided into the following layers:
    1. Core Systems: This layer contains all the core systems of the engine.
    2. Resource Management: This layer represents Tetragon’s resource manager which is responsible for loading and conditioning all supported resource files and making them available for use inside the engine (some of the supported resources are listed as examples, but the diagram shows only a part of eventually supported media resources).
    3. Additional Base Systems: These are systems that belong to the base engine but are built on top of the core functionality. This includes the audio system, GUI and front-end facilities, networking systems and the (almighty) entity system.
  5. Tetragon Gameplay Foundation: This layer covers the game add-on that ships with Tetragon by default. It provides standard functionality to be able to develop basic games with Tetragon, such as standard render systems, entity systems and entity components that provide a default set of supported entity definitions, as well as standard data parsers and data processors.
  6. Game-specific Subsystems: This layer represents a set of subsystems for a specific game or game type add-on. Tetragon will ultimately provide some of these add-ons, named for example rpg (role-playing game) and tbs (turn-based strategy). These are add-ons (also called ‘Extras’) that can be added on top of the base engine and gameplay foundation to provide specific systems for a specific type of game. Such a subsystem can for example provide their own data- and entity definitions, custom entity systems that might manage the game A.I., custom render systems, etc.

This diagram is a work in progress and will be updated when required.

Sep 102011

When launching an AIR desktop build of Tetragon the position and size of it’s main window will automatically be stored and recalled the next time the application is launched. Additionally the system chrome extra width and height are being calculated and the stage size is adjusted accordingly.

The reason for the extra width/height calculation is that the stage size of an AIR desktop application comprises the width and height of the system chrome which means that you typically end up with a smaller stage size than expected. To that problem adds that the system chrome can have different sizes depending on the OS and the visual theme. To solve this problem Tetragon calculates the size difference and adjusts the stage size accordingly during startup. Imagine you define your application stage size to be 640 x 400. By default your stage size on web builds would still be 640 x 400 but on desktop builds (that use the system chrome) the actual stage size would be smaller because the whole window incl. the chrome would be 640 x 400. But thanks to Tetragon’s adjustment the AIR stage size will remain 640 x 400 and not 630someting x 380something. This is great because you don’t have to fumble around with this issue.

However there is a pitfall to be aware of: Be sure to set your AIR window minSizes to something large enough that can handle your application’s default width and height! By default Tetragon’s build properties set the AIR window minSizes to the same as the default sizes so it will work correctly but be wary if you change the minSizes! Setting these to anything below the default sizes will give you wrong window sizes and not only that, the window size will grow with each launch.

If you want to reset the window bounds to it’s defaults, Tetragon provides a console command to do just that. Open Tetragon’s console and type in resetwinbounds (or the shortcut rwb) and the position and size of the window will be reset.

Ultimately there might be situations where you want to remove the file where window bounds are stored. This file is a Local Shared Object residing in the application’s application storage directory. On Windows this path is for example:

C:/Users/username/AppData/Roaming/com.hexagonstar.tetragon/Local Store/#SharedObjects/tetragon.swf/localSettings.sol

After removing this file the application’s window will be reset to it’s default bounds at the next launch. Keep in mind however that, depending on the application, the window bounds might not be the only data the sol file stores.

Sep 102011

There’s an interesting tidbit of information on jacksondunstan.com about using casts when accessing data from a data structure to gain performance. As tests show this is true for all tested structures (Array, Vector, Dictionary, Object and Dynamic Class) but what is even more impressive is the difference of how to cast. As the results below will show it’s always significantly faster to use the “as” operator for casting than the conventional method of using braces “()”. This comes as somewhat of a surprise for me as I’ve been always under the impression that the opposite is true. However that might have been still based on outdated tests done on older Flash runtimes.

Note that this performance gain will only show in the release Flash Player. In the Debug player you will likely get the opposite result that using the “as” operator is slower so be sure you are testing in the release runtime.

Get Adobe Flash player

Here are my results:

*** Casted Lookup Performance Test ***
Runtime: 11.0.1 (60), PlugIn, WIN, Debugger: false

Click to begin test!
Running 10000000 iterations ...
Finished! All results in milliseconds, smaller is better.

TYPE             NO CAST    CAST AS    CAST ()
Array            75         42         249
Vector           71         37         244
Dictionary       219        182        382
Object           202        172        380
Dynamic Class    212        178        377
SUM              779        611        1632