Actionscript 3
Ok, im gonna try and give AS3 a go, and would appreciate any help... Im making a flash header for a website, which will scroll through different graphics advertising and providing links to different sections of the website. I figured I would make a frame.swf which would be placed in the webpage, and then make several section.swf, and have the frame.swf load them externally, i.e. at the start load section1.swf, then after 8 seconds, replace it with section2.swf... hopefully that makes sense. What would be the best way of going about this in AS3? Or what functions should I be looking to use? Thanks in advance.

Ok, I managed to work out the importing swf thing using Flash Help, but im confused about something else now... button controls. In AS2, to make a button play when it was clicked I just did playButton.onPress = function() { play(); } simple enough, if the button is pressed, it calls play() function, and if I wanted to, I could change onPress to onRollOut or several other things. NOW however, its telling me that THIS is the way I need to do it... function startMovie(event:MouseEvent):void { this.play(); } playButton.addEventListener(MouseEvent.CLICK, startMovie); First, I have to create and name a new function, called startMovie, which contains the play() function... and then use an event listener on the button, see if its clicked, then call the function. It just seems like im using more lines of code to do the exact same thing, and with no benefit... why??

Chris... Event listeners are ungodly more powerful. They ARE more cumbersome, but in the relative scale of what you can do with them, they rock. Basically, AS2 had done this all for you. The exact same scenario was going on under the hood, and was just hard-coded within flash to call the "onWhatever()" method. So, yes... event listeners. Get to know them, get to love them. Because EVERYTHING uses events in AS3. So, the first thing to get used to it the listener/handler scenario. import flash.events.MouseEvent; myButton.addEventListener(MouseEvent.MOUSE_DOWN, this.handleMouseDown); function handleMouseDown(evt:MouseEvent):void { trace("Button Was Pressed"); } So, we imported the MouseEvent class (very important as you go along... you have to import the classes that you use into external scripts). We added a mouse down handler to the button, and pointed it at our event handler function. Then we set up the event handler... a handler is just a plain old function, but is specifically made a handler because it receives an event as the sole input parameter. When the mouse event is called, it is sent to than handler function for interpretation. I'm finding that it's an extremely good practice to isolate your event handlers from your concrete functions. Say you wanted something to happen on click that might happen in another scenario other than just a click. Isolate the action into it's own function that the event handler just calls. Then other things in your script can call it too without requiring an even be pushed in.

Erm, right. My last post was just a technical reply. I guess you were also after the practicality response. Yes, event listeners/handlers make more lines of code in your minimalist example than a simple "onRollOver" (etc...) action did in AS2. However, in the bigger picture, the collective gain from event listeners/handlers is mammoth, and they make an application much less complex in the long run. AS2's biggest weakness was scope and delegation. You've heard me talk about scope before... it's a relatively abstract concept which takes some OOP (Object Oriented Programming) experience to truly realize. So, let's think of this in terms of cardboard boxes... better yet, pet crates. You have a bunch of pet crates with little critters inside them. The critters in each crate are not aware of what's going on in all the other crates, because (for our example) these are sealed boxes (but with air holes, of course). So, when a puppy yawns in one crate, the kitten in the crate next door is unaware of it. The puppy's actions happened within the sealed box of its "scope" which means that it's the only one that knows that this happened. In AS2, events transpired exclusively within an object's scope since the only way to receive them was with the hard-coded Flash handlers "onWhatever()". To work around this, you could do a few things; all of which were ugly. You could: :arrow: (A) have the puppy specifically tell the kitten that it yawned. However, this requires that the puppy know that the kitten exists and where the kitten's crate is located so that it can communicate with it. And if the kitten's crate ever moved, the puppy would have to be updated with this new information. Also, this all assumes that the kitten even cares and WANTS to know that the puppy yawned in the first place. :arrow: (B) If the kitten wanted to know about the puppy's actions, it could get a mouse to run over into the puppy's crate and spy on it, then whisper this information back to the kitten. This is the good old "delegate" hack that OOP in AS2 relied on. It's good application design, but this was an ugly execution. Thankfully, this system was expanded upon and implemented natively within AS3 in the form of "event listeners". So, in AS3 we have enlarged the air holes on the pet crates so that a bit more sound comes out of the boxes. The kitten no longer needs to send a mouse over to the puppy's crate to spy on it. Now, the kitten can just listen to the puppy's crate to find out when the puppy yawns (that is, assuming the kitten cares and wants to know). This is what good OOP is all about... everything in a program exists within its own scope and does its own job and ONLY its job. It acts totally independently of everything else in the program to avoid "dependencies" (which are BAD). If certain objects in a program do need to interact, they should just listen to each other. With the kitten listening to the puppy, the puppy is totally unaffected. However, back in example A, the puppy would have had a dependency on knowing where the kitten was in order to inform it of the yawn event. And that, in a nutshell, is OOP.

that has got to be the coolest explaination i've ever read, if more people did that in tutorials life would be a lump easier.. half the time they give you a lump of code to copy and paste and tells you it'll make the character move and not explain what it actually does and why

Thanks Nige... and yes, I agree. There's a common misconception as to what programming really is; I know because I once just though of programming as weird text that whispered secrets to computers in some foreign syntax that only nerdy computer geeks would bother to understand. However, the literal syntactical skill of writing code is only a very small portion of the art (and it IS an art) of programming. Where an artist designs lines and shapes on a canvas to paint a picture, a programmer designs statements of logic and mathematics to all fit together into an interactive application. When I think of what I do professionally, I see myself much more as a designer than I do a programmer.

That was great, Greg! Thanks for that very cool explanation. I'm only just learning AS 2, and now I understand much better why I constantly get the feeling that what I'm trying to do is somehow 'ugly'...! As a noob, I'm not too good at programming yet but somehow I keep thinking when writing Actionscript 2, 'That can't be it now, can it? All this tweaking that needs to be done because the little pet crates are so dependent of my input!' Don't know when I'm going to take the plunge into AS 3 yet, but some OOP books are on their way to my desk right now...who knows, you might convince me yet :wink:

Yes indeed... the journey into programming inevitably starts with dependencies. It's the most obvious way to both teach and learn since you can see literal targets with direct interaction. However, it is laborious and limiting. Programs with heavy dependencies eventually collapse under their own weight... which is one reason that LassieAS development tapered off. It got the point where everything in LassieAS was so dependent on so many other things that a small change could potentially collapse another totally unrelated portion of the program. Bug fixes and updates were just teeth-pulling painful; and a bunch of stuff I have just never been able to find a way to fix within breaking something else. And on the note of learning AS2 – I'll tell you the same thing I told Chris: if you're just learning now, learn AS3. Learning will be a challenge in either of the two languages if you have no background, but the advantage of AS3 is that it's not a sinking ship. If you struggle through learning AS2, it just means you'll have to struggle through converting over to AS3 later.

Thanks a lot Greg, makes a lot more sense now! I wonder how far you can push the analogy... :P I guess initially it will be a pain to do things the AS3 way... but ur right it is better to build things in a way thats sustainable, rather than just making do. As for the programmer/designer thing, to be honest im kind of scared of ever becoming a programmer! You can tell when something has been done by a programmer... it may work ok and have lots of features... but it looks like crap and isnt particularly enjoyable to use. I'd much rather be a designer who just knows how to program. :D

Okay, then I'm really interested: how do you feel about Lassie Adventure Studio? I'm not asking in hopes of a compliment – I'd like your honest and uncensored opinion. I ask because I've long shared those same feelings. I went to school as a designer and have roots in fine art. I never wanted to become a programmer, but somehow my path has led to a job that is most predominately application design; and I love it. So, somewhere along the way I made the swap. As a result, I am curious about how other people with my background would view something like Lassie.

Well in my opinion Lassie doesn't feel like its just been thrown together by a programmer, like right from the off its obviously been put together by someone with visual taste, I remember when I first came across it being impressed by how professional it looked and felt, considering its effectively a hobby project put together by one guy! So dont worry, id say ur still very much a designer :D I have to admit though, I havn't ever really spent long with it, any time I sat down to try and fiddle with it I found it very intimidating... I was suddenly faced with lots of options and terms that I didn't understand. I'm sure with Nige's tutorial I could work it out eventually, but I wonder if the application, and the editing process, were rearranged slightly, could it be made less intimidating to a brand new user? Don't get me wrong now, Im not knocking it, its a brilliant program! I just wonder would there be a more intuitive way of leading a user through the game-building process, without sacrificing any of the control that advanced users require? Then again, maybe im just stupid, and everyone else finds it fine! :D

No no; you're not the only one who has reported confusion while getting started. Many others have said the same. I think that's something that needs to be addressed with better documentation. I acknowledge that the LassieAS docs are more than a little lacking. However, like everything that just takes time; and given that I can only devote just so much to the project, I generally press forward on the program over the docs. Documentation is something that I'll be looking to you guys for help on in the future and would really appreciate anyone who will step up to the plate and write some documentation / tutorials the way Nige has done in the past. His tutorials have been the magic bullet for a lot of folks out there. Also, having built the app; I really suck at creating useful documentation. I find all the tech points the noteworthy ones since they're what's more relevant in my mind. I have a very hard time reducing my mind set to a fresh set of eyes and thinking, "hmm. What would someone who has never seen this need to know?" Developers write good tech documentation, not tutorial documentation. LOL, I'm building a massive adventure-esueq game at work right now for an upcoming kids site (this thing rocks, BTW. It goes live in March and I will definitely post a link). I've built a series of game editors that are very similar to Lassie editors to aid my coworkers in laying out the game world, and they have proven to be clueless when it came to using it. And here I thought these were the simplest controls in the world!

:D

I think that's something that needs to be addressed with better documentation. Yeah, better documentation would help, but you would still have to read through it all before opening Lassie. I just wonder if the program could be built in a way that needed LESS documentation to get started, because it just made sense to begin with... Ok, ignoring for a moment the way Lassie or any other editor works (which I can do because I dont actually know!), I figure an adventure game needs roughly 4 things... 1. A world (or room, or scene, etc.) 2. Characters (Player characters, NPC's) 3. Objects/items 3. Puzzles and Story (Dialogue, cutscenes, etc.) So, for a single room game with say 2 characters and 3 puzzles, what would be a natural way of going about it? First I want to make the room for the game to take place in, add background animations, sounds, walkable areas, interactive background objects, etc. Then I need to create the characters, all their sprites, animations, properties such as text colour, etc. Now I want to create create the inventory objects which the player can pick up or be given, their animations, descriptions, etc. Finally, I need to tie it all together with the puzzle/story editor... Where I create the acts of the game. For act 1, I select the room I want the player to start in, and place the characters in it. I then add the objects/items to the room. I then link all these things together into the puzzles (when player picks item A up, and gives it to character B, event C happens) and story (when player talks to character B, and selects dialogue option D, dialogue options E, F and G become available). Now, thats all very vague and off the top of my head... (and maybe doesnt even make sense to anyone else) but thats how I would LIKE to be able to make a game. I have no idea how you'd go about programming that, or even if thats what Lassie basically does... all im saying is that using a process like that I could create a game in 4 straightforward steps. Now the steps i've laid out may not be the most intuitive either, or may not fit with the Lassie way of working, but I just wonder could the editor be designed in such a way so the process of creating a game was streamlined into a few main steps (which you could jump between obviously, and which give you as much control as you currently have)? Just a thought :D

I really should go back and fine tune the tutorials, there was a heap of stuff i skirted around.. mainly because i hadn't done it or was problems myself.. but It probably isn't going to worth it. i might as wekk wait until the new version arrives.. but then i have to learn how to use it myself! A basic template would be a good idea, AGS, Wintermute do it that way, i learnt Lassie Director by pulling the demo apart.. the PDF's went Whooosh over my head lol Its very hard to explain your job and how something works.. you can see the glazed eyed look appear when you try and explain something to someone, you can rattle on for ten minutes only to get "ok............. which button do i press again?" or "whats a fuse for.. can i use a nail?"