Introducing new concepts
I'm going to start posting some introductions to new Lassie concepts that you will probably be hearing about in the coming months. Yes, Lassie is evolving a bit and while there are going to be some differences, the general concepts aren't changing all that much. Keep reading...

Layer Getting started, let's get to know a "Layer". A layer is going to be taking over the role of our good friend, The Sprite. The evolution is two-fold... for one thing, ActionScript3 has introduced a Flash asset called a "Sprite" so that creates conflicting name space (and Flash names will always take priority). However, Lassie sprites are also evolving a bit in their transition to layers. The idea of layering will place more emphasis on the concept of a layer stack. The idea is that layers will serve as a top level canvas that can be extended into a few different graphical assets. More on that later...

Float Following up, lets meet "Float". Float is the new model replacing Z-shifting, and will (hopefully) alleviate some of the frustrations that went along with the remedial logic that powered z-shift. Floating will extend the concept of Layers. Each layer will have a native depth in the layer stack. To enable a layer to float will push it behind all other floating layers on screen that have a lower y-coordinate and a lower native depth. Hmmm. That probably sounds complicated. What's cool about floating is that all layers still abide their native depth. A layer will never shift upward in the stack, only down. This should avoid some of the wonky results that people experienced while trying to tweak their room to make all z-shifters work together without exploding out of the stack. Also, this will allow floats to have graphics layered over the top of them without also needing to float. In previous Lassie builds, two overlapping sprites would both need to z-shift if the character was to walk behind the lower one. Now the bottom layer will just need to float and the top layer will be unaffected.

Puppet This concept goes back to a metaphor from Lassie's roots in Director. Director had "puppet" everything... and now, they're back! A puppet is a type of layer, specifically the type that can be (extensively) manipulated by the Lassie engine. Puppets are clickable room objects that can be dynamically animated, support room matrix effects, and can have interaction responses specified. The character layer is an extension of a puppet layer and is probably the best example of what puppets are capable of.

Plane Planes are the counterpart to puppets. While puppets support full interactivity and dynamic engine effects, planes are non-interactive objects that just build the graphical structure of a room. Planes have fewer customizing options and are intended for static graphics like a room's foreground. They offer an alternative to the old technique of adding an ambient sprite. Planes can also be enabled for parallax shifting against room scroll.

Parallax For those unfamiliar with the term, parallax shifting is the visual relationship between objects as the observer's point of view changes. In 2D gaming, it's been the long-standing visual trick of scrolling graphics layers at varying speeds, which gives the impression of spatial depth. Plane layers can have parallax shifting enabled. When active, a plane will shift based on total room scroll relative to the difference in size between the room's background and the plane graphic.

Interaction Models Plain and simple, an interaction model is the way in which a player controls the game. For those of you who are addicted to nostalgia, you'll be pleased to hear that Lassie will be supporting a few major models, currently including: Selector Model The selector model is that which is currently used in LassieAS. The model relies on an action selector that the player accesses by clicking and holding on an interactive puppet layer. Once the selector appears, the player chooses their action and the selector is hidden again. Classic P&C Model The classic point-and-click model (or just "classic" for short) was seen in the old Lucas Arts games like Monkey Island 1&2 or the Indiana Jones adventures. This model uses a set of action words (or icons) displayed on screen that the user can click to select an action, then click a puppet layer on which to execute the action.

The Queue Perhaps the most dramatic new change taking place within the Lassie architecture will be the overhauled event queue. In simple terms, the event queue is a list of TIMes lined up for the engine to run through sequentially. Developers should be vaguely aware of this concept from the legacy technique of calling "_root.runActions();" following a TIMe called from a Flash timeline. That command was needed to prompt the processing of new actions that were added to the queue. However, the overall model was flawed. Some events processed within the queue, others transpired independently of it. In the end, it became somewhat of a mess as to what was accountable to what during sequential playback... Many of LassieAS's known playback errors are a direct result of the weak queue architecture. New Lassie development has put far more emphasis on The Queue. Infact, the engine will live and die by it. The new architecture uses a passive processing model rather than an active one like the current LassieAS. Where the current queue will keep actively running TIMes until being told to stop, the new queue will only run one event at a time before needing explicit instructions to process again. So, where actions were previously told to "suspend" (stop processing), they will now be told to "hault" (or to not proceed). Slowing the queue down makes it much easier to programatically control playback. Also, in the event of a bug (heaven forbid!), the engine will err on the side of stopping playback (which can manually be prompted to restart if needed) rather than blasting forward and skipping over events. Also, ALL events (TIMes) will operate via the queue. No exceptions. This is particularly noteworthy when calling TIMes from a Flash timeline... TIMes will no longer be called directly. Instead, TIMes will be passed into the queue. All TIMes will be called via four functions: stackAndRun(); stackAndHold(); queueAndRun(); queueAndHold(); The "stack" methods will push the TIMe command into the front of the queue (as the next action to process). The "queue" methods will push the TIMe into the back of the queue as a follow-up action to all existing events. The "AndRun" methods will fire the queue upon call. The "AndHold" methods will leave the TIMe in the queue to process when playback reaches it. The "AndHold" methods are really slick since they can make insertions into playback regardless of delay. For example, if you want to fire an event from a Flash timeline that will take place after the current dialogue has played out, just stackAndHold it! The TIMe will fire after the current dialogue line has expired. Finally, this also means that the look of TIMe's will be evolving. While this isn't definitive yet, it's probable that all TIMes will be formatted as arrays, such as: <"playDia", 1> While this may seem clunky, it's a good move. For one thing, the current TIMe formatting is just fake scripting -- post-processing is required by the editor to format TIMes into the context in which they will be consumed. Also, this post-processing creates some slight differences in some TIMes as to how they need to be written between the editor and from a Flash timeline. Anyway... big write up I know; but it's an important concept to understand. Knowing something of HOW the engine works makes it much easier to use.

playDia I'll include this one as a fun note for those of you who I know include a "wait" TIMe after all playDia commands to add a breather between statements. playDia will now have an inherent playback delay wired in to provide this pause for you. It will most likely become the second argument of the playDia command.

Keyboard I know there is a long history of grumpy developers who've come to despise the LassieAS keyboard control (or the lack there of!), and the fact that it can't be disabled. Well good news... the future of LassieAS will implement a brand new keyboard model that is pretty darn cool. Not only can the engine's keyboard response be toggled on and off with a TIMe, individual keys will be configurable to call game actions. This is done by tagging ascii key codes with TIMe scripts... basically making anything that can be called with a TIMe accessible as a keyboard function. For example, there will be a new TIMe for toggling the inventory display open and closed. By attaching that TIMe to a key, the user will be able to control their inventory display via the keyboard. And of course, these tagged keys can be enabled, disabled, and reconfigured on the fly.

Dialogue Parsing New Lassie developments include a parser to process dialogue text at run-time. This allows special notation of protected characters (like quotes) that will be caught at run-time and used to format the text properly. So, the following equate: Say <%quote%>Hello World<%quote%> Say "Hello World" And since dialogue is being processed, this notation syntax will also allow the insertion of custom data fields that can render into dialogue. For example, let's have our Santa Clause sprite give useful information in his dialogue: There are <%daysUntil=12/25/2007%> days until Christmas There are 8 days until Christmas The list of available parsing methods has not been devised yet nor the decision as to how much game-specific data will be available for parsing. Also it is undecided if field-nesting will be supported to allow render methods to feed one another.

Matrix-based Filters Matrix filters will be taking over for our old friend the FX Matrix. While the results will look similar in final appearance, the application will be handled differently to maximize flexibility, performance, and (quite possibly) expansion. There are currently three filters implemented: Scale, Light, and Speed. As the application design solidifies, additional filters may be included that tap into Flash's native filter engine (glow, blur, shadow, etc.). We'll see... this is a work in progress. However, here's a few points to get excited about: speed matrix gradates dynamic layer motion around the room. It's a cool effect (so good idea to whoever suggested it). Also, matrix calculations support a new axis: in addition to X and Y there is now "R"... which is "Radial". Any matrix filter can render on a circle where the polar effects will be applied at the circle's center and its outer radius.