http://www.youtube.com/watch?v=tgwi0lWgX8w

The demo was coded by the guys who maintain Alternative3D, one of the the few software-rendered 3D engines for Flash that are better suited for 3D game development. The engine has recently been made free of charge for commercial development. The makers only require a back link to their product website in your game now.

I find Alternativa3D quite attractive, in particular after seeing videos and screenshots of War.ru, an online multiplayer Role-playing game that reminds me of RPGs classics like Wizardry, just with better graphics. Unfortunately the whole game is in Russian only for now and so far I haven’t been able to log in, the load procedure is very slow and always gets stuck at some point for me.

Still the game looks very promising with some nice looking 3D environments. The actors (NPC’s and creatures) seem to be inanimate billboard sprites though so they only look impressive on a static screenshot but imagine what would be possible with the newly achieved 3D power! I’m looking forward to create vast 3D environments with autonomous actor AIs a’la Oblivion or Fallout 3! The only bottleneck will – yet again – be the content creation.

Either way, many classes have been updated and improved (and many still need too *ugh*) and what is particularly worth mentioning are the file IO classes which provide a unified way to work with different file formats. Basically the way how files work in hexagonlib is that you can create file objects of any specific file type (like text, binary, image, XML, etc.), give them a path to a physical file and then add them to a loader (BulkLoader, FileLoader, ZipLoader) which then loads the data of the physical files into the file objects.

While you can use the BulkLoader class to load a collection of arbitrary files in one go with all sorts of comfort (priorities, weighted loading, load retries, multi-connections etc.) the newest addition to the library is the ZipLoader class which can be used in AIR development to access a standard zip file using Random Access. What does that mean? It means that you can create a zip file (a very large one if you want), pack all your resource files that can be loaded by your application and then open it with your app and ‘load’ (= extract) files from it without ever needing to load the whole zip file completely into memory. This makes accessing a large zip file very efficient because only the chunk of the requested, zipped file is loaded.

This is especially interesting for us game developers who desire to use large, nicely packed resource files like they are utilized in a similar fashion in most current day commercial games. For a while I was promoting to add such functionality to AIR over at Adobe Labs but that was before I knew that this can actually be done in AIR since 1.0 thanks to the FileStream class and the position property of it (alas, the property is not available in the URLStream class so random access is not possible on web-based Flash). The ZipLoader uses asynchronous loading to open a zip file as well as ‘loading’ files from it because I don’t like the idea of having the application at the mercy of the file system which would be the case with synchronous access (and which is used in way too many examples on the web).

You can download the hexagonlib distribution over at Google Code, which includes the SWCs and documentation and of course the source code is available for access via SVN. I’m updating the library on a irregular basis. There are already some Wiki pages too with code examples showing how to use the BulkLoader and ZipLoader here but I will hopefully get to write some more in-depth tutorials soon.

hexagonlib at Google Code
File API Wiki
Documentaion

I could go on and make this project an oldschool-style game with 2D graphics like some other indie devs are doing but I feel that going 3D would be the best bet to convey atmosphere and tactical gameplay at the same time (you could use switchable first-person and third-person views). This makes me think if ActionScript is actually sufficient for this but the experience of some of my recent coding tests with Away3D which already start to bog down the CPU with a few hundred polygons on the screen tend to say “no!” to my ambitious plans.

Since this is a desktop game my platform choice is AIR which offers more freedom that the Web Player but there are still many let-downs that make you grind your teeth …

Hardware 3D

Without a doubt the biggest problem is the lack of hardware-accelerated 3D rendering. With the current software-rendering engines you could make simple 3D games where you try to always keep down poly-count to an absolute minimum. Basically your game will then look like anno 2000, if not worse. I remember most games of the late nineties to early two-thousands as having these “wood  puppet”-appearing character models, both in terms of look and animation. I must admit that some games achieved quite good quality for the technology they were running on, for example Metal Gear Solid on the first-gen Playstation. Would that be possible in Flash? Probably yes, with a lot of trickery but who wants to make games that look that outdated? As I mentioned in another post, I’d be better off with well designed 2D instead.

Not sure what Adobe is doing regarding 3D but sure is if if they are sleeping on this, the competition will not sleep and we might see developers wander over to Silverlight or Unity3D.

Full-screen Resolutions

There are several other painfully missing features in Adobe AIR which I hope Adobe will care about. One such feature would be the option to change the screen resolution! As it is currently if you switch your game to full screen it will run at the same resolution in that the player runs the OS in. Screens have become larger and with that screen resolutions have too. If you now switch your Papervision game – which was running fine in a 640 x 480 window – to fullscreen in 1920 x 1200 you can watch how your game is being degraded into a slideshow! Fullscreen games would profit a lot from being able to change screen resolutions.

The fullscreen mode brings me to another bugger: The Escape key! Adobe has the opinion that the Escape key must not be remapped and that it should solely be used to close a full screen mode. I guess they did this for security reasons so that an ill-intended coder cannot hijack your screen. However I disagree with this rationale! Such a coder could use C, Java or Python or any other universal programming platform for that matter in a much more suitable way. Some security restrictions go too far and the Escape key is one of them. It’s more of a blocker than a help!

Resource Files

Most modern commercial games use what is called Resource Files; large compressed archive files which contain all of the game’s media and data files. These files are often in the hundreds of megabytes up to several gigabytes. While I doubt that I will make a game anytime soon that has an assets library of several gigabytes I can imagine that my current project could go easily up into several hundred megabytes of assets.
The commercial developers use resource file formats to organize their asset files into nicely compact files. These resource files house many advantages over just simply having your naked files on the harddisk. Among the advantages are compactness, protection, easy file distribution and better structural organization.

With ActionScript you could load compressed Zip files that store all your games’ assets but there’s a tiny but important catch to this: Most of those commercial games which are written in C++ and which utilize the file system have the ability to access any of the packed files quickly and right at their position in the resource archive without the need to load the whole resource archive into memory first. In fact you wouldn’t want to load a 4Gb file into memory completely but how about a 200Mb file? While that’s possible it’s not a best-practice.

ActionScript currently provides the URLStream class that can be used to stream a file in but it still does so only in a linear way. You could start loading your Zip file, check which assets from it is available, abort loading and use the asset but this is sub-optimal! Imagine your file is somewhere at the end of the Zip file you’d still have to load the whole Zip file first. ActionScript (or in particular AIR) would go nicely with a URLStream class, or even a completely new API that could make optimal use of a Resource File format which houses compressed media and data files. Maybe Adobe could even introduce a specific new file format for this purpose. That would be ultimately nice!

I have no idea where Adobe stands with the future plans for Flash and whether some or all of the above mentioned points are resolved at some time or if they are never resolved in which case I’d get the impression that the Flash platform is a sinking ship for me – which I do not hope for!

Currently we as Flash game developers (I hate that name!) are standing at the fence which borders on that green and juicy meadow of professional game development and we can only hope that things improve in our favor so we too can graze on that green grass where the big cows are reveling.

[ad#ad_content]ActionScript developers are a poor bunch! Internet Applications have become more and more complex and require you to plan your architecture carefully. In fact you need to be not only a programmer but also a full-fledged OOP architect if you want to achieve complex applications or otherwise two weeks later when the client asks for changes you will be in code chaos hell. On the other side the customer can’t care less and asks you to finish their product within two weeks just like it was in the old days of  Flash 5 where you could churn out some wonders quickly (but dirty under the hood) because, hey, does the client care how well your code is organized? The hell he cares! I feel kind of like: first we all yelled for better code management, now that we have it people start to complain that it’s too OOP.

Being a game developer who has a few more ambitious projects on the shelf I’m all for OOP and coding-best-practices. The artsy-fartsy Flash Designer hype from yesteryear had it’s show but now please move along, it’s time to advance!  Personally ActionScript was what has taught me OOP practices and I would be nowhere today if it wasn’t for ActionScript. Sure, I could have probably learned it from C++ or Java too but ActionScript’s prevalent support and documentation made it a lot easier.

I’m all for strict typing and seeing some people wishing back dynamic typed features makes my stomach turn over. Instead I’d rather like to see more data structures that allow strong typing just like the recently introduced Vector does. Really, there’s no way that 10 horses can pull me back to dynamic typed programming! Sometimes I find AS3 code examples on the web which are all untyped and dynamic, obviously by some coder who completely neglected strong typing because he either didn’t fully understood it or was too lazy. This is what Nicolas Canasse got right when he stated that ActionScript lacks expressiveness. It leads to people falling back to dynamic typing if they see that all this extra stuff required for the correct approach. I use FDT which has an excellent template system so I don’t really care if there’s a tad more code to write to achieve good code. In fact OOP stipulates more code. At first I worried too but I’ve learned to live with that.

I think Adobe should loosen the grip of ECMA 4 on ActionScript which it already has broken anyway by not being fully compatible to it anymore. haXe is doing many things right where Adobe fails with ActionScript, advanced OOP features like Generics, typed Arrays with auto-casting, in-lining, Enums etc. To stay up to competition ActionScript needs these and then some. Others have already listed their feature hopes which I reflect but here are they once more:

• Method Overloading (because writing Open-Source frameworks and libraries often is a travesty without this).
• Generics
• Threading (Oh yes!)
• Multi-CPU-Support
• Private Constructors (bring them back!)
• True Abstract classes/methods
• Enums (has been a long time wish. Don’t know what the problem is!)
• Hardware rendering (PV3D etc. are great and all but whats the point if you hit the wall with under 1000 triangles?!)
• Compiler performance (Seriously MXMLC needs to hide in the corner if the haXe compiler shows up!)
• And last but not least I’d like to see a lot more love for the AIR runtime like better OS-integration (changing screen resolution for example) and better performance and resource management (the way how AIR wastes up RAM is not from this planet!)

After a lot of research it turns out that there seems to be no way in an AIR app to use the GPU mode that is otherwise supported by Flash embedded in HTML via wmodes parameter. In fact the docs state it’s not even supported by AIR …

… Flash Player 10 introduces two window modes, direct and GPU compositing, which you can enable through the publish settings in the Flash authoring tool. These modes are not supported in AIR …

While this is a definitive must for a hopefully soon appearing update there’s another issue with fullscreen modes … AIR doesn’t really feature any decent solution for fullscreen! You can have your app to be either in fullscreen OR in windowed mode but trying to be able to switch between both looks very ugly because the system chrome isn’t being disabled automatically when switching to fullscreen which results in that the window size will simply get maximized. So creating applications where you could let the user switch between fullscreen and windowed mode seems to be impossible at the moment with AIR 1.5.

I can understand that the Flash player on the web needs it’s security restrictions in this regard but AIR should definitely not be touched by this! I hope Adobe will improve this for a future update, AIR is a great platform for (complex) game development but these two issues are serious limitations to that!

Besides that Alcon is now code-signed there is exactly one new feature in v3.1 which I called Key Tracer. You can toggle Key Tracing Mode from the Log menu. If you enable it you are able to press any keys and their key code (and if available character code) will be listed in Alcon’s output window which is a useful feature if you want to know the codes for some specific keys quickly.

More features where planned (and already started) like a Search function, Log Level Filtering and even a Calculator but these haven’t made it finished yet into v3 so most of them will come with version 4, which is – yet again – a complete re-write (I do loathe my source code that is over one year old ).

The newest version can as always be found here.

I recommend to check out the Alcon Page for more details and of course the download link. Enjoy your debugging!

Then there’s the Options dialog with Trace options opened where you will be able to set font, colors etc. On the File Loggers Options you will be able to optionally enable up to two File Loggers that can be used for example to log the flashlog.txt to see output made by ActionScript’s own trace method.
There’s of course the new Object Inspector and a new Help panel for Quickstart Help and API Docs. Alcon 3 is being written 99% in ActionScript 3 using FDT (the 1% left being the Main.mxml that is necessary to compile a Flex application). It’s only a matter of a few days now until release, some bug fixing, finishing touches and a few more documentation to write and it will be out so please endure!

Some of the new features besides the already existing Trace Command and File Loggers are a Memory Consumption and Frames-Per-Second Monitor, a completely new and improved Object Inspector that is finally useful for Debugging, an Options dialog to comfortably configure Alcon, proper AS2 support and a couple of other minorities here and there.

The progress moves on quick enough that I dare to say that the release date is only a few weeks away from now so sit tight, it’ll be there in a heartbeat.