Also I have updated “My Name is Poncho” the Demo. Now it includes 3 scenes, mouse navigation ( showing the new A* pathfind method ) and keyboard navigation. You can download its sources from the download area and use them as tutorials.

You can also browse the new API reference from the link in the sidebar.

So what’s new ?

NEW

• Nicer object shadows, that fade away as the object moves away from the plane. Try jumping in the demo to see it in action.
• The Grid is now generated on-demand, only used cells are generated. No longer we create a huge array that covers the whole scene. This has a huge impact in both initialization time and memory usage, and makes possible to have much bigger scenes. Overall a great improvement in my opinion.
• Added Mouse translation coordinates and an A* pathfinding: all you need to program point-and-click  adventuring and Diablo clones.
• Added shadowQuality settings. Shadows are the main bottleneck of the engine, therefore there is a need to have quality options to adjust them to your requirements.
• Added the fMaterialTypes class, where you can find info on the available materials and how to use them
• Added the “fence” material
• New zSort algorythm. It is cleaner and faster, and I hope this one will work properly.
• You can now destroy unused scenes via fEngine.destroyScene(). This will allow you to free system resources.
• Added the “xmlObj” property to elements
• Added the “window” material.
• Added the “animated” property to fObjects, which allows some optimization.
• Added the fHole class, which gives control over holes in fPlanes. Now holes can be opened and closed.
• Added a Building Generator
• Moved generators to new package “helpful” outside the engine, as they really do not belong there.
• Sprite hierarchy is properly setup so you can add Mouse Events to fElements and the appropiate element receives the event.
• Materials now tile seamlessly along adjacent surfaces.

FIXES

• Fixed: The engine now assigns an internal unique ID to each element, and uses that id in internal hashtables instead of relying on the IDs you assign. This was causing lots of trouble.
• Fixed: “BOX Tag” from generators were ignored
• Fixed: Exception caused by shadow projection trying to calculate intersection between paralel lines.
• Fixed: Several shadow projection bugs.
• Fixed: Some collisions between objects were missed.
• Fixed: mathUtils.getAngle now returns values consisten with the engine’s coordinate system.

On an unrelated note, development of the engine ( and my personal life in general ) is being treatened by an insane addiction to La Mulana. Stay away while you stll can…

Also, I received feedback from several people trying to have big maps and complaining about the grid initialization times and memory usage. This got me thinking: generating a grid at initialization is very inneficient (stupid) and makes impossible to have big maps. So, why don’t we make it work as a real cache, and cells are generated on-demand ?

So I have done it. Now a cell is only created when it is needed. I think this is a big improvement. You can extract the latest code via SVN and tell me how it works.

So after a few weeks of desperation It seems that everything stays the same, but I think I have more solid foundations now. Next: pathfinding (at last !! ), character-character collision and bullets. Sounds easy after all I’ve gone through lately.

Also the new zSort algorythm is slow when the scenes have this level of complexity: sorting all planes in 3D becomes a non-trivial operation that involves lots of calculations. I plan to work on optimizing it or at least provide a way to include the sort result into the scene’s XML so it doesn’t have to be recalculated every time you load it. But at least it works now.

Here’s a list of the engine’s changes that are shown in this demo. They are not available as a release, but you can always checkout the latest sources via SVN.

Changelog

• Added the fMaterialTypes class, where you can find info on the available materials and how to use them
• Added the “fence” material
• New zSort algorythm. It is cleaner and faster (it really is, but this particular demo is very tricky to sort), and I hope this one will work properly.
• Added the “xmlObj” property to elements
• Added the “window” material.
• Added the “animated” property to fObjects, which allows some optimization.
• Added the fHole class, which gives control over holes in fPlanes. Now holes can be opened and closed.
• Added a Building Generator
• Moved generators to new package “helpful” outside the engine, as they really do not belong there. Thnx to Jason Booth for the wisdom.
• Sprite hierarchy is properly setup so you can add Mouse Events to fElements and the appropiate element receives the event.
• Materials now tile seamlessly along adjacent surfaces.
• Fixed: The engine now assigns an internal unique ID to each element, and uses that id in internal hashtables instead of relying on the IDs you assign. This was causing lots of trouble.
• Fixed: “BOX Tag” from generators were ignored
• Fixed: Exception caused by shadow projection trying to calculate intersection between paralel lines.
• Fixed: Several shadow projection bugs

It has happened to me countless times during the years: you start with a given algorythm to solve your objective, see how it turns out to be more difficult than you expected, add a lot of obscure if clauses here and there to cover tricky cases when this is parallel to that and you divide by 0, just to end up with three hundred lines of cryptic garbage and nested functions even you don’t fully understand. You exhale in satisfaction, think to yourself “wow, that was more difficult than expected but I am so good I solved it”. Two days later you emerge from the shower feeling an idiot, delete the work from the last two weeks and write it again in one hour unsing two nested loops and one helper function.

This is what has happened to me ( yet again ) last week. Originally, way before I made it public, the FFilmation engine was two dimensional, you had a floor and walls and you moved things along the X and Y axis. Perfect for Diablo clones an Habbohotel look-alikes. So I programmed the zSorting algorythm in 2d. More precisely, I thought it in 2D. And it was clear, not easy, not trivial, but clear. Then, one day, I realized It wouldn’t take much to transform the engine to be fully 3d. Still isometrically rendered, but with freedom to place and move stuff at different heights. Instead of rethinking the zSort in 3D, I patched what I already had, adding more conditionals, functions, loops and whatever I needed to solve every new situation I encountered when testing my own examples.

It worked. At least I thought It did. I’m sure 90% of the people playing with the engine will be building “flat” scenes, without much vertical complexity. But I am not. I am building a complex town scene with tall buildings, similar to the environment in Assassin’s Creed. Ok, not even remotely similar due to obvious technological limitations, but you get the idea. Such scenes need real 3d zSorting of all planes and cells inbetween, and I have painfully discovered that the engine does not provide that. Even more painful is trying to figure out what is not working, tracking obscure variables and method calls I no longer understand. To put it short: currently we have a crappy 3D implementation of a 2D algorythm that doesn’t work well. If you stick to 2d spaces you’ll be fine, but you can’t go very far beyond that.

I’m already in the process of rewritting the zSort algorythm. Several classes are gone (the API doesn’t change, no worries), as they added a lot of bloat and little help, and the result is way smaller, way cleaner and way more understandable. And works well. The repository is already updated.

I hope next time I take my own advise.

In the FFilmation engine there’s an added complexity, as occluded elements ( those that were made transparent so you could see behind ) should also be transparent to mouse events, but If one alement inside that occluded element had a Mouse event (a door in an occluded wall) , that particular event should be accessible.

It took me more than expected, but finally sprite hierarchy is properly setup so you can add Mouse Events to fElements and the appropiate element receives the event. Also I added the fHole class, which gives control over holes in fPlanes. Now holes can be opened and closed.

I have updated the demo to reflect this new developments, try approaching a door and clicking on it to open it. You can checkout the code from Googlecode.

I am very happy with the response I have received so far, and this has encouraged me to continue my work on this. My previous post contains detailed info on what I have been working on. Here’s a summary of what’s new.

NEW

Added coordinate-translation methods to fScene, so you can easily map Stage coordinates into game coordinates, or viceversa
Added camera occlusion
Added Scene controllers
Added enable/disable methods to the scene
Added Element controllers
Added Perlin Material
Added Door Material
Added Generator interface + SCATTER Generator
Implemented fScene.removeOmniLight

FIXES

Fixed fObject.hide() causing a zSort exception
Fixed createCharacter()
Fixed false shadows from floors to higher walls
Fixed a big performance botteneck that affected character movement

TODO
. Finish fObject shadowing models
. AI helpers: isElementVisibleFrom(), findPathTo(), findAmbushPathTo()

I have updated the download page with the new release and the sources for the My Name in Poncho demo, where you will find examples and explanations on how to use the new features. Also, the new API reference is up. The new release should be backwards-compatible.

SVN

Yep, everybody was asking for this, so I have put the project on Google Code. You can checkout the latest source there and do all kinds of cool SVN stuff. To be honest I have no idea how this works. I managed to get this TortoiseSVN working after three different tutorials and I’m still not sure I didn’t screw.

Here’s the link: http://code.google.com/p/ffilmation/

Have fun !

I have been working on a new demo for the FFilmation engine. I thought that the best way to decide which features were most important was to simulate making a “game” and see what was I missing the most along the way.

The demo will be updated continuously with the new features so I can see how everything works together. Besides, more complex scenes push the engine and the processor to its limits, and makes it easier to find performance bottlenecks.

The demo can be accessed here. Please note that It uses heavy lighting and a big scene. Slowdowns are to be expected in older machines. Here is a list of the new features showcased.

Materials

Perlin Material

Perlin materials are procedural materials formed by a base material and unlimited layers of other materials, each one rendered from a perlin noise definition. The perlin noise for each layer is used as the alpha-mask for that layer. With perlin materials, you can create more natural-looking environments without extra effort.

In this case, a 2-layer perlin material is used as ground for the forest scene.

Door material

The door material is not a big deal, but It has made my life a lot easier. It works as an standard tile material, but it draws a door of given dimensions in the middle of it. You can specify a base material, a material for the door itself and a material for the frame. The doors in the demo are defined like this:

<materialDefinition name="MNIP_ForestMaterials_Door" type="door">

<!-- Base "tile" material for the wall -->
<base>FFMaterials_woods2_Wood2_13</base>
<!-- Frame material -->
<frame>FFMaterials_woods2_Wood2_11</frame>
<!-- Door material -->
<door>FFMaterials_woods2_Wood2_13</door>
<!-- Door position, as percent of wall size, from -100 to 100.
The default 0 value centers the door in the wall -->
<position>0</position>
<!-- Door size, without frame -->
<width>150</width>
<height>200</height>
<!-- Frame size -->
<framesize>15</framesize>

</materialDefinition>

A subtle dropShadow filter is used to give the frame a bit of thickness, making the result less flat and quite convincing.

Controllers

Both elements and scenes can be assigned a controller object. Controllers are an elegant and scalable way of adding behaviours to your applications.

A typical element controller can be one that reads mouse input and moves a character, or the AI for the enemies in you game. For scenes, the controllers can control daylight or program specific behaviours such as the train arriving to the station every X minutes.

Controllers have an enabling/disabling methods. Disabling an scene disables its controller and controllers of all elements in that scene. This is useful to pause you game, bring in an options screen, launch a cutscene, load another scene, etc etc

An piece of the controller for the forest:

public function assignScene(scene:fScene):void {

   this.scene = scene

   // Follow Poncho
   var p:fCharacter = this.scene.all["Poncho"]
   this.scene.createOmniLight(”light_poncho”,p.x-20,p.y-20,p.z+10,200,”#ddffdd”,50,00,true)
   this.scene.all["light_poncho"].follow(p)

   // Look for all Money Bags and add a light above each of them
   for(var i:Number=0;i<this.scene.objects.length;i++) {
     var obj:fObject = this.scene.objects[i]
     if(obj.definitionID==”MNIP_MoneyBag”) {
        this.scene.createOmniLight(”light_”+obj.id,obj.x,obj.y,obj.z+25,300,”#ffffff”,100,0,true)
        obj.addEventListener(fRenderableElement.HIDE,this.hideListener)
     }
  }

}

private function hideListener(evt:Event):void {
    // Delete corresponding light
    this.scene.removeOmniLight(this.scene.all["light_"+evt.target.id])
}

A light is created and attached to the main character. For each money bag in the scene another light is added on top of it. When the money bag dissapears, the light is removed.

I could program this behaviour in my main game class, but what if I only want it to happen in this scene ? Instead of ugly conditionals, I use an scene controller. The generic Money Bag retrieve event is in my main game class, because I want my character to pick up money bags in all scenes where they appear. But I only want the lights on top of them in this scene.

Generators

A generator is a class that given some data from an scene XML, returns extra xml elements that are added to that XML at load time. This allows to use procedural methods to generate more complex scenes effortlessly. The scene looks for generators in the XML and calls the appropiate class to retrieve the extra elements.

In the demo, I use a scatter generator. The scatter generator is used to randomly fill an area with objects. You specify the area to cover and a list of candidate object definitions. Elements from these definitions are randomly selected and placed along the surface.

Optionally, a noise definition can be used. If so, the element’s positions are restricted to the area covered by the noise. This is useful for example if you have a Perlin ground and want to distribute trees only in the green areas of the material.

Here’s an example:

<generator>

    <classname>org.ffilmation.engine.generators.fScatterGenerator</classname>

     <data amount="8" minDistance="200" randomizeOrientation="true" noise="Ground_noise_1">

         <!-- Area covered by the objects -->
         <area>
            <origin x="0" y="1400" z="0"/>
            <end x="1000" y="4000" z="0"/>
         </area>

         <!-- A Weighed list of candidates, so you can define which types appear more -->
         <candidate definition="FFTrees_misc_tree5" weight="4"/>
         <candidate definition="FFTrees_misc_tree8" weight="2"/>
         <candidate definition="MNIP_MoneyBag" weight="1"/>

     </data>

</generator>

Camera occlusion

You can now specify an alpha value for elements in front of the camera. This will make walls and objects transparent as you walk behind them, and you will be able to see what you are doing. I found out that for walls and floors, using the OVERLAY blending mode gave the nicer results. This can be changed using the API of the fCamera object.

Finally…

Also, a several bugs have been fixed and I have optimized some of the algorythms. Adding new features has been less painful than I thought: the core of the engine is responding quite well. I hope I can release a 1.1 version with all these soon.

There are a couple of key features I haven’t finished yet, and this is why I’m not putting the source on google code (many people has asked for this) or sourceforge yet: I have a very clear idea of how they should be done and I prefer to wait until I finish these key features. Then I’ll setup a svn repository for the engine.

One of these features is an abstract controller interface that assigns a controller class to any element on the scene: controlllers can be anything: AI controllers, keyboard controlled or network-controlled for example, allowing easy multiplayer applications. This should make integration with any server-side technology reasonabily easy. This is already done.

Another recent obsession I have is procedural scene generation: I was creating some test scenes to evaluate how the engine performed with big scenarios and found out that creating even the most pathetic and unnatural forest took me hours of copy-pasting XML lines. And I though that anyone that doesn’t have an army of level designers behind would drop its project simply because creating all the gfx and scenarios would take way too much time.

So I have added a procedural terrain generator that uses perlin noise to simulate natural textures and uses similar noise functions to place trees along the surface, or objects in the scenario. This allowed me to gererate realistic-looking forests of any size withous any effort. Adjusting the parameters of the perlin noise you can create very diffeerent scenarios. I’ll update the site with an example soon.

Also these big scenes have shown several performance bottlenecks that I didn’t notice with the smaller examples. These have already been solved so the next release will perform way better, specially with bigger scenes.

My next step will be a xml-based procedural “dungeon” generator (something like http://www.aarg.net/~minam/dungeon.cgi). Once both parametric exterior and interior generators are done I think the engine will cover a wide range of games/applications.

Stay tuned. If real life is kind to me all these will happen soon.

I have setup a forum for all FFilmation users to use. You can access it from the sidebar links. Just be kind to each other, I’d rather be spending my time programming than moderating.

Bye