Small LoDGameBox update

I’m here to release a short update about the condition of LoDGameBox, and to say happy birthday to myself.

Yep it’s my birthday… weeeee. Ok back to work Duct!

So for the past month I’ve been working on a videogame for a company using the LoDGameBox as the framework for it. It’s coming along beautifully and also is letting me pull apart the entire framework and getting it into a real life implementation. This has been accelerating the building of the framework and I am happy to say Alpha version 0.1 will be out very shortly.

That’s right guys, a version that can actually be used will be out very soon. Please check out the code at my google code project and expect some great stuff soon.

Some things that are working right now:

Physics – there is a functional physics engine. It’s not exact yet, but it can actually be used. I’m using the main backbone of it in a game right now, but I coded my own custom Arbiters and Resolvers. Which yes you can do by extending and implementing the Arbiter and Collision classes.

AI – At the moment I have an A* monotonic algorithm and the main interface for AI and pathfinding set up. Right now you can have some fun with the well known A* algorithm… more algorithms to come.

AssetManager – I set up a management system and support classes for loading assets into a project. It creates a central place to load and store external assets like sound, swfs, bitmaps, etc. I am also making simple methods for accessing SWF Libraries for use.

LoDTweener – the LoDTweener is in very early stages right now. It supports container transitions and the SimpleTween right now. Don’t expect the robustness of TweenMax or even TweenLite right now, but it’s on its way. Of course, per usual, it is extensible for your sake, you can create your own custom tween types for complex animations. Just implement the com.lordofduct.engines.animation.ITween Interface and go go.

SFXManager – Sound effects are at a very functional level with support for playlists, overlapping sounds, and simple sound effects. At the moment it is based on CS3 / Flex 3.0, but I hope to be updating this to CS4 / Flex 3.4. I’m a bit hesitant though because it kills flash9 functionality, but the new data sampling options can make for simple audio syncing and the sort. Please let me know what you think about upgrading it to Flex 3.4?

UI – the user interface package is coming along very nicely with Mouse Cursor controllers, Keyboard controllers, pop windows, and other cool stuff. Check it out.

Utils – also the utils package is building up nicely with simple methods for performing numerous actions. There are tools for random values, math, strings, matrices, timers, etc.


LoD AS3 Game Framework – update 3

This update is small, but important.

I’ve moved the source of my project onto Google Code for easy sharing. It also allows me to easily update it through SVN and for you to checkout the entire project out easy. Or you can just sift through each individual file on google code through the directory tree. In the end this will streamline my blog entries about it, I can post and share new stuff so much easier!

Furthermore I’ve changed the name of the project, from now on I’ll be referring to it as “LoDGameBox”. Please come on over and check it out. Version control and comments are available to see what changes have been occuring.

LoDGameBox at GoogleCode

LoD AS3 Game Framework – update 2

So I return with another update about the LoDGameFramework. I know I said I’d have the physics part done by now, but it isn’t… sorrz. It’s really close though. And that’s what I’m here to show an example of. Above is an example of a collision detector using Separating Axis Theorem, along with a resolution algorithm devised from the same algorithm used in FOAM (credit given in source). To show the point you can easily swap in and out different algorithms. There are 3 other algorithms for collision resolution and 2 other for collision detection.

Furthermore, though you can’t visually tell, the collision meshes used for all the objects vary here. The red shapes use my IGeometricShape interface describing circles, ellipses, and polygons. Where as the black blocks are described by regular Rectangle objects in flash. You can mix and match all of these collision meshes at the same time. I still want to get the Bitmap ones running, but I have some other work to do as well.

If you want to play with this example below, just click it with your mouse and 10 new geometric shapes are generated and set to collide against each other.


You can still download the library in its current pre-alpha state in the link bar. Or here!

LoD AS3 Game Framework – update 1

So I’m here to update everyone on the status of the “LoD Game Framework”. I’ve been adding all kinds of interesting objects into the library since the last time I posted and I’m happy to say a big release is coming soon. This release doesn’t particularly mean the whole library will be functional, but a section that I bet a lot of people want will be up and running.

Before we get to that nice little surprise, let me discuss some of the interesting things I’ve been adding.

For starters, I contacted Jim Armstrong aka Singularity, author of the AS3 parametric curve library at I wanted to abstract the algorithms from his library for use in my parametric curves and requested permission from him. The interface for the version I’ll be releasing is going to be heavily trimmed down. I’m removing a lot of the stuff that deals with ‘drawing’ curves to DisplayObjects and just keeping anything dealing with the math of curve. Instead another set of objects will assist drawing the curves along with other geometry I’m including.

And there’s another one! Geometry, right this very moment (I’ve been up all night… vamp!) I am coding up a set of objects called IGeometricShapes. These shapes are for mathematically representing complex geometry, and allowing you to extend and create your own special geometry. There are two basic types of IGeometricShapes at this time: convex smooth edged shapes, and polygons. Convex smooth edged shapes include stuff like circles and ellipses, where polygons represent stuff like triangles, quadrilaterals, pentagons, hexagons, etc.

I’ve also started work on a more robust Tweening library then that garbage one I posted here months back. Now that might not make most of you happy, and at this moment it is very much in its infancy. But what I’m going to be doing in turn is setting up an interpretor class that will allow you to inject your own tweening engine into the entire framework. What this means is that you can easily wrap the LoDTweener around lets say TweenLite or the likes, and any part of the framework dependent on the LoDTweener will utilize your favourite tweening engine instead. No need to change code inside the framework to coerce it into using a different engine… further more I plan to let you swap this stuff out on the fly. This means you can code your entire project around the LoDTweener and then just simply update the interpretor class with what engine to use (no this is not implemented yet, that’s for the future). Some might ask WHY I don’t just include TweenLite, or why I just don’t use any Tween Engine at all. Well I need tweens for different parts of the framework, so that’s that, I can’t go with out. But not all Tween engines out there are free, for instance my favourite one ‘TweenLite’ has a very restrictive license on it that doesn’t fit into my open MIT license I’m sharing this under. So instead I’m giving any of you the choice to use whatever you want with ease.

I’ve also got a large portion of the tiling system set up. This is what lets you create 2D cameras and scroll scenes. The tiles allow you to layer your scenes and create panning effects like parallax scroll. There isn’t a lot I have to say about it at this time as I’m not sure exactly how much I’m going to be putting into it. I have this issue where I want to balance it between being light weight for those who don’t need everything, and having great options for those who do want everything. Please, let me know what kind of layering, camera, and scrolling techniques you want included!

Lastly in this literary update, the most exciting part (for me…). My Physics Engine is nearing completion, I hope with in the next 2 weeks to have it out on the table with some demos for everyone to check out. Now again I’m taking an interpretor style design with the physics engine. That’s right, I’m not going to force you to use only one style of collision detection, or one style of collision resolution. I’m not going to hand you a restricted list of geometry or leave you out of the loop of the whole process. Instead there is several small sectors of it that you the user get to control.

1) IPhysicalAttrib – meaning “Interface of a Physcial Attributed Object”. This interface exists soulily for you designing your own physical bodies into the PhysicsEngine. There are a couple ways to implement it. You can directly just pass a PhysicalAttribute object into the engine and update via this object, or you could implement the IPhysicalAttrib and expose the inerface of the PhysicalAttribute through it (similar to implementing IEventDispatcher), or you could implement the interface your own special way creating you own effects inside the engine. This allows you to directly add any class you want to the PhysicsEngine just by implementing the interface.

2) IPhysicsCollection – this interface describes collections of objects for manipulating the physics of. This allows you to create independent groups of objects that interact internally only, or you can combine groups to create global conditions. The collections range in functionality to allow you to describe all kinds of scenarios and keep processing power down. For instance, say you have a level filled with static rigid bodies that don’t react to forces or anything, yet the player can collide with them. There is a style of IPhysicsCollection to describe this situation easily. This way the physics engine completely ignores these static objects interacting with each other but still allows the player to collide with them.

3) CollisionMesh – the collision mesh is a property of IPhysicalAttrib, it’s one of the most important object interface uncovers for any physical body. Through the CollisionMesh you describe the collidable area of any object. There will be a couple different types of CollisionMeshes that come default and you have the ability to define your own. The planned ones as of right now include:

  • Simple CollisionMesh – used for describing a basic OBB
  • GeometricCollisionMesh – adapts the earlier described IGeometricShapes to describe a convex hull
  • BitmapCollisionMesh – describes a DisplayObject as a BitmapData object for pixel perfect collision (with a performance hit though)

Of course again there is the ability to make your own types of meshes.

4) CollisionDetectorAlgorithm – a CollisionMesh allows you to attach any algorithm to it for detecting collisions. There are a couple of algorithms included directly, and of course an interface for you to add your own. You can easily swap out algorithms with a line or two of code, and you can even allow different objects to use different algorithms at the same time!

5) CollisionResolverAlgorithm – when a collision occurs it is passed along to the engine to be resolved. Any given IPhysicsCollection can have a unique resolver algorithm set to it (or just use the global default set in the engine Singleton), this allows you to pick and choose how objects react when colliding. For instance you can use a simple resolver algorithm that just doesn’t let objects intersect, or you can use more complex once that simulate friction and elasticity, or you can even more precise and include angular velocity and other fun stuff.

6) CollisionEvents – when collisions occur two events propogate. One informing the entire project that a collision occured and another for when it is resolved. You can hault the collision once it’s occured for any reason and stop it from being resolved. Lastly the event is dispatched from 2 places. You can listen to the PhysicsEngine itself to capture all collisions that occur, or each object that is part of the collision also dispatches the event themself. This also means that if the object implementing the IPhysicalAttrib interface is also a DisplayObject, the event will bubble through the DisplayList.

So be ready guys, I’ll be updating again in the near future with a fully functional physics engine for everyone to tinker with. Instead of trying to go for a fun realistic engine, I went for something that is useful. You can still create the really interesting accurate physics, but you can also just create simple physics that are more useful in most videogames. You don’t always need angular velocity, or elasticity, so instead the choice is there, but not necessary.

You can still download the library in its current pre-alpha state in the link bar.

AS3 Right-click functionality

I have heard much talk over the last couple years about “Right Click” functionality in Flash. I never paid puch attention to it as I never really needed it ever. Just the other day though it came up yet again and someone linked an article to this guy Uza’s blog who had a JScript for getting the functionality in AS3. The original code project can be found here caught my interest for some reason that I can’t explain. It probably had to do with the game library I’m coding, I figured some developers might actually want this in their games, so why not add it in!?

Unfortunately his script only informed flash of when the right mouse button was pressed over the Flash video. So I tweaked the script some to add release functionality as well.

To make this right click functionality blend well I created a Singleton class that emulates normal Flash MouseEvent protocols. You get a lot of the normal features you may already be used to with left-click all wrapped up nicely in this Singleton.

  • MouseEvents are dispatched into the event pool like other events in flash
  • MouseEvents are dispatched by the top most InteractiveObject that was right-clicked
  • MouseEvents bubble through the DisplayList like usual
  • Three Special events are registered and act just like left button events: rightMouseDown, rightMouseUp, and rightClick
  • An optional ability to check if the object is mouse-cancelled via its mouseEnabled property or any parents mouseChildren property

The final option may be considered processor intensive in some situations and can be optionally turned on/off. When off then the top most InteractiveObject is just returned as the target no matter if it is enabled or not. Unless you have tons of overlapping InteractiveObjects though, it really shouldn’t matter either way.

So lets introduce you to the script!

First we have the javascript which is necessary. I need to nod my hat at Uza as it really is his script with some modifications and tweaks. As for using in your project, well it’s done nearly the same exact way as Uza’s script is, only difference is the name of it slightly different. So here’s the script:

All you need to do is import LoDRightMouseButtonTrap into your html document and initialize it. When you initialize it you tell it what SWFObject to pay attention to:

LoDRightMouseButtonTrap.init( “idOfSWFObject”, “idOfFlashContainer” );

This way LoDRightMouseButtonTrap.js knows how to locate the SWF and communicate to it. At this time you can only support one SWF per page at a time. I’ll be changing that in the future of course. But lets get this out the door right now for you guys.

Now lets take a look at the Singleton that handles this thing:

There it is, yes it’s a little long. But that’s ok, it all runs fine and for you to utilize it is really freakin’ easy.

import com.lordofduct.ui.RightClickManager;
RightClickManager.instance.start( this.stage );

And there, it’s up and running. Keep in mind, the SWF MUST be running in an html container and have the .js script running at the same time. If this isn’t settled then it doesn’t work at all. So no, this does not work on locally running SWFs via a projector. If you want local running access, run it via a browser locally, OR just create an AIR app which gives you RightClick functionality out of the box. That was one of my drives for writing this, if you wanted to port your internet app to an AIR app, you just don’t start up the RightClickManager and just keep on going. The events are dispatched with the same MouseEvents that AIR would be dispatching… actually seeing as the manager check for the ExternalInterface at “start”, if it isn’t there, it just doesn’t run. So really you don’t have to change ANYTHING to port an app using this to AIR.

So who wants an example!?

Here I draw 3 boxes named child1 through child3, and stick them in various containers, then I listen to the root for right clicks and display some text for it. Note how everything bubbles and the correct displayObject is picked up here in the example running:



Please check out my game framework for the classes needed. You are intereseted in:

com.lordofduct.ui.RightClickManager – this is the actual manager
com.lordofduct.util.Assertions – needed for nil checking
com.lordofduct.util.SingletonEnforcer – needed to assert the Singleton instance

The latest version of it is available in the right hand link bar.


LoD AS3 Game Framework

I’m sorry I haven’t been around in several months. I’ve been off doing a whole lot of stuff and completely lost track of the site. My apologies to everyone… I guess I’m kind of new to this whole blogging thing and haven’t quite gotten a hand of setting time aside for updating here. Along the same lines I’ve been doing a lot of contractual work which I couldn’t share any drop of due to agreements and really had nothing to talk about in consequence.

What I have in return though, for those of you who actually waited around for me, is the preperations for a nice little library some of you may find helpful.

This library is being released “AS IS” at this moment and is under severe development. Think of it as a pre-alpha non-build version with very little functionality. It’s more or less to show you some of the fun tools I hope to include in it.

But wait… what kind of library is it LoD??? Well it’s a Game Library. It’s to be a nice collection of different tools for creating 2D games in Actionscript 3. It’ll include many things like:

AI engine
Physics engine
Game Controller interfaces
Tweening engines
Game View Manager
Parametric Curves (at this moment it is a reskinned version of Jim Armstrong’s Singularity Parametric Curve library, used with his permission)
and much more

There is much work to come, and it won’t be done for some time. But I’ll be updating with majour points along the way for you guys to look at. Furthermore I’d like input on what kind of features you want added (please no 3D requests, I’d like too, but I want to first see where Flash goes with their built in 3D first). When you review what I have to offer right now, keep in mind I’ve yet to test full scale test runs on anything in here and much of it could crash your application. Some of the classes are completely barren and unuseable as I’ve only started to write their interfaces. Lastly a lot of it will probably be moved around a bit to meet stronger demands.

Check it out, tell me what you think!