Hey also, good looking coverflow system! The animation is very smooth, and you've done a good job with crafting the interaction-versus-transition behavior. I'm really quite impressed and proud, Chris! This is a huge step from where you were with your photo-based portfolio design, and worlds away from where you were when we first started talking action script! Let me know what you think of CS4. I haven't bothered downloading the trial yet since I have no way to keep it after the month currently (so it's not worth updating current project files with it yet). However, I do plan on purchasing a copy within the next year given that Matt and I are getting into some commercial publishing. So, I'll need my own license. I'm just dragging my feet on ponying up the $2K for the full CS4 Web suite (which is a way better deal than Flash by itself).

Thanks! I dunno why but they've been kind enough to let me tinker away at it for the last week so I've been working out quite a lot. Yeh I know, its nearly a year since I was doing that walking-man thing in AS2 ( http://www.pigstylearts.co.uk/vernacular.html )... makes me wonder what Im gonna know in a years time! Really owe you big time, not only were you willing to help me, you're a fantastic teacher too, so thanks. Only got a brief look at CS4 2day, but the 3D stuff looks pretty cool, as does the inverse kinematics. Commercial publishing...? ANything you can talk about publicly?

Chris, LOL... you'll be saying that "I wonder how much more I'll know in a year" for the rest of your career. I look back at what I was doing a year ago and shutter; and I have AS3 to thank for a lot of that. I really feel like I've started understanding computer science through AS3's outstandingly logical code structure. Keep plugging away, and keep asking questions. As you get more practice, I may start asking you for advice and opinions of weird script things :P As for the commercial publishing thing... we're dabbling with the idea of getting some professional Lassie production going. However, without anything definitive at the moment, it's still a bit early to be worth talking about.

Yeah I've started to kinda enjoy the challenge to programming, its seems kinda like doing a soduku using hebrew numbers or something... beyond the language barrier theres a really addictive logic puzzle! Im still having trouble getting my head round preloading... I've got the cards simulation to the stage where Ive got a pack of 63 cards, each with a different image and info on them. It works ok, besides the big problem that it takes ages to load, and at the moment theres no way of telling that it IS loading. If you take a look you'll see what I mean http://www.pigstylearts.co.uk/cards/Testing.html (p.s. the very last logo, for the fried chicken chain, is mine :D). The current structure is pretty similar to how I planned it back when I started thinking of this card project... Theres a main Deck class, which runs through the XML data and puts it into an array, then creates individual instances of the Card class for however many <Card> nodes there are in the XML, passing through the appropriate information. It also handles my interface, like what happens when you click on a card, where it should go and how etc. The Card class basically just draws the card shape, adds a shadow, and draws onto its faces the appropriate information which is passed to it from the Deck class. This includes the project image, which I create as an instance of my ImageLoader class (I got fed up writing out URLLoader things for every image) which basically takes the url the card passes to it and loads the image into a Sprite container. Still with me? :D My problem is that at the moment its just doing things i whatever order they load, so the deck draws 63 cards, then the cards go about loading in the images, which takes an age. I need the ImageLoader to say 'Im done' to the Card class, then have the Card class say 'Im done' to the Deck class, then have the Deck wait until all 63 or so cards are done before adding them to the stage, and preferably showing some kind of percentage loader while its at it.... Does that make sense? I know I can do things add an event listener a URLLoader to see if its complete, but can I do something similar to just any class, i.e. add an event listener to a class that listens for the class doing all it needs to do, before calling the appropriate event function? Oh and Lassie as a product doesnt sound like a bad idea at all, even besides hard-core adventure games it could have a use for creating some interesting websites...

Hey Chris – sorry for the delay in reply. For the record, my lack of presence is generally proportional to how hard I'm working on the Lassie engine itself. When I'm in engine programming mode, I generally don't take time away to browse the forums. So, I've been working on Lassie a LOT recently; despite my silence probably implying otherwise. The plan is to have Shepherd/Supersheep running by first-quarter next year, and it's going to take a ton of work to get there. Anyway... concerning your question. First, let me point out that you're addressing a matter of Flash ethics that is almost as fiercely debated as politics. When to load assets is a pretty touchy subject. One school of thought says that you should load everything up front and make the user wait through it all. Another says that you should space out loads so that images are loaded as needed. Personally, I fall on the side of loading as needed for several reasons. For one thing, huge loads up front are tedious. Also, nothing says that the user will be consuming all the content that you've loaded... so you're probably making them wait for stuff that they're not even going to look at. Also, using the load-in-sequence method gives you the option to set up a background loader queue that will pull in unloaded assets ahead of time while there is nothing else going on... and that trick gives the best of both worlds: preloading AND not making the user wait. So, I'd say that it's not worth doing the full load up front. Just request the asset when the user clicks the card, and then add the loading feedback within the card's image area. For making a trick little background-loader, think of doing this: build a class who's job it is to iterate through cards and start each one's load, wait for it to complete, and then move on to the next. If it hits a card that has completed loading or is in the process of loading, then in moves on. Your gallery is looking great!

Heya Greg, great to hear Lassie development is still going strong, cant wait to check it out! Out of interest, I take it it will be straightforward to incorporate custom scripts into a game still, like for instance you could build on the standard adventure-mechanics with a few physics-based puzzles? Thanks for the advice on the preloading, your way makes sense. Its funny when I ask a question where I think the answer is going to be technical, but it turns out its more of a logic problem! Havn't had a chance to look at the cards since, been working on a wee gallery site for a local signmaker, its at http://signflair.positivedesign.co.uk if you're interested in taking a peek. Its still a bit glitchy, I think I need to go through it and add a few event listeners/dispatchers to make sure not too much is happening at once, making d animation jump.

Hey Chris, of course Lassie will still support including your own custom scripted media. They'll need to be included within a room layout using a specific layer type that is designed for scripted media, but it really won't be a whole lot harder than previous Lassie releases... just slightly different. That sign website looks great! Seriously, your work keeps getting exponentially better in its execution. Great work! My only design feedback would be to left align the main nav menu, and then tab in the portfolio list sub-nav that spawns from it. I was so busy looking at the main screen transition when I entered the work section that I didn't notice the menu changing... then when I looked back at the menu, it had gone from three options to MANY and I was confused. I think just adding that tiered visual hierarchy would eliminate confusion as to what had happened there. Otherwise, really a flawless execution. The site has style, nice animation, and a cool-but-not-over-the-top system of slick Flash menus.

Thanks, glad you like it! Yeah I'll take on board your point about the sub-nav, there does need to be more differentiation between its open and closed states. Out of interest, was it glitchy at all when you used it? Sometimes the content slides jump about a bit before going into position, and the first one kind of appears with a jump, I think its not loading properly before being added to the stage or something. Thats good about Shepherd supporting scripted media, does that mean I could hypothetically write a plug-in kind of script to add more functionality to the engine? I've nothing in mind like just wondering.

Nope, the site was not buggy when I viewed it... although being a fresh user, I could have encountered bugs without knowing that they WERE bugs. Hence the reason the technician is almost always the best detective of bugs or failure potentials. As for the scripted plug-ins for SuperSheep... I certainly want developers to be able to extend the engine's functionality. That will remain a goal, although I can't yet fully assess how that will work since I haven't yet built the application controller. SuperSheep is being built with a very tight implementation of an MVC pattern (Model, View, Controller), which means that the data model and the graphics display are programmed as two very separated systems that play off one another, and then a third controller system floats in orbit around the two and instructs them how to behave. While the new LassiePlayer data model and graphics engine are mostly built, they don't have that governing entity yet. I'll be building that in the coming weeks, and once I have something solid for that, I'll have a lot better idea as to how new script commands can be injected into the player. One thing is most definitely decided though: There will be substantially more conditional logic supported in the new engine build. I'm moving the engine's scripting system over to use XML, because 1) XML is easy to write, understand, and a background in simple HTML is all you need to be a master of it, and 2) Script commands will be able to be organized into an XML tree, at which time the engine can parse simple conditionals which will run (or not run) different branches of the script tree.