Hey, just thought I'd let you know I got a job yesterday (a year's internship) at a multi-disciplinary design firm that does print, web, environment, etc... just what I wanted! I got it because they had a lot of applicants who were strong at print design, and a lot that were strong at digital, but I was apparently the only one who had both... so I owe you a heck of a lot! 6 months ago I knew squat about any sort of coding, and though I still aint superb at it, thanks to you I have an edge over my contempories. So thanks :D

Hey, congratulations! Glad to hear you found what you were looking for. Does said agency have a name and website?

Thanks! Yeah its called Positive Design. Their website doesnt have anything on it but their work is quite good, they actually designed the crest for the police over here (not an easy task considering all the politics involved). http://www.positivedesign.co.uk/

Hey Greg, am starting to tinker about with AS3 again (have been learning a bit of CSS and Jquery in the meantime, also quite fun!) :D Remember you said something about being able to build a working model of Photoshop with Flash? Well im not QUITE attempting that, but I am wanting to be able to export JPEGs from flash, like basically export a MovieClip as a JPEG... any advice on where I would start? How was the conference? Or is it not started yet?

Came across this technique for OOP, thought you might appreciate it :D "object oriented programming starts with writing out a paragraoh of what the app does. Then you find the nouns, those are the objects, and then find the verbs. Those are the actions"

Hey, that is an excellent guideline for thinking about OO! Just be mindful that this rule applies on a very micro-level: every object in your application should be broken down into sub-nouns and verbs for best granularization (which maximizes OO). In my own experience, the absolute best one-liner anecdote about OO theory is this: "Program to an interface, not an implementation". If you're up to it, look up what an "interface" is. In quick summary, you can think of it as one of those old-school phone switchboards. You have a switchboard operator on one side receiving calls and plugging wires into the appropriate call slots, then a jumble of wires on the other side that connects calls. The physical "interface" is the panel full of plug holes... each hole points a call to a different region. Let's say that they want to upgrade the system... say, replace all the copper wires with fiber-optic cables for better connectivity. Well, they can do that entire update on the back side of the panel without the operator ever knowing that the change happened. The switch board operator can keep on interacting with the control interface, despite how the wiring on the back end is implemented. This real-world example is true about pipes that deliver water to your house or electric sockets in your walls. They're all the same... they are an interface into a bigger system that can be changed and upgraded without you as the user ever being affected, so long as the interface its self never changes. If ever there was a gospel to OOP, that's what it would be... again: "Program to an interface, not an implementation".

As for the image save-out thing: how ironic that you ask about this now. I just built a code library for this last week given that we've had several projects come in recently that list this as a possible feature, so I wanted to make sure we had a handle on the technology before promising it to clients. So, it's a little advanced... you first need Adobe's corelib (free on google code) JPG and PNG encoder classes. You can feed them a BitmapData object and they'll take care of encoding and compression, then spit back a ByteArray. From there, you have to send the ByteArray off to a web server with a PHP script (or other web technology) ready to catch the binary and write it as a file. If you want them, I'll be more than happy to send you the code library that I wrote to automate the process of all this. You will need a PHP enabled server to go with it, or else you'll need to translate my PHP script into another server-side language (don't panic, it's only about 5 lines of PHP).

Yeh that'd be great thanks! I looked into that corelib thing but couldnt work out how to impliment it... I've done a little bit of php (for contact forms) so I will hopefully be able to handle it! :D BTW, did I see you got a Webby for the Peace Corps site? Nice one!

Jus reading through your blog post now, thanks very much! Great idea to use the blog. I got the RSS feed notification on my iPhone :D By the way, have you seen this...? http://www.25lines.com/ ...Should be interesting.

...iee, yeii, yei. They're counting open and close block braces as individual lines of code? Sheesh... tough judges. But yes, that should be interesting. I'll have to watch the submissions.

Im gonna have another go at getting my head round OOP :D I had a bit of free time at work today so started trying to dynamically creatE a deck of cards. I have a few things, like OOP and physics, that I want to try in Flash, and so I decided that a card deck was the perfect thing to try and mockup - it has a simple, clear structure that can be used in lots of different ways, and its easy to do a real-life mockup of whatever im trying to make. I figure the OOP will be very handy for the physics in particular, where I can add and take away different rules easily. Ill keep you posted on how I get on!

Sounds like a great exercise! Out of curiosity though, what are you going to make your deck of cards do? Are they movable, shuffleable, playable in a game? Either way: yes, OO is a logical way to go with anything that involves that much conformity and extension of a central concept. You'd start with building a card abstract... that's a rough template object that will never be instanced itself, but will be extended into all the permutations that make up the "concrete" (implemented) classes of actual cards. Actually, you'd probably define one "Card" abstract and then extend that into four "Suit" abstracts, and then extend those into ...what, 14 concrete card types for each suit? Either way, my best advise on OO theory is just to go granular. While sometimes it becomes cumbersome, it does usually pay off in the end to have broken everything down into bite-sized pieces. I'm doing still MORE election maps at work right now, and the election-night data models are insanely complicated. To try to display that data has gotten me to the point of breaking every little thing down into discrete objects so that I can keep my head wrapped around it all... otherwise it's just some massive blob of generic data that I have to figure out what to do with. OO is a live saver in these circumstances.

Yeah basically I want to create a working model of a pack of playing cards, and in the process learn lots of different things like physics, OOP, and gameplay principles. First stage is to create the cards themselves, stage 2 is to add physics to them so they behave like real cards (I think it'd be cool to work in a few card tricks or something :D) and stage 3 is to add gameplay/rules to make them playable. So this afternoon I got started on stage 1, without really considering OOP. I created 4 arrays (one for each suit) containing the strings . I then created an array which contained the four suit arrays , and then created 2 functions, drawDeck() which has two for() loops to go through all 52 items and calls the drawCard() function, which creates a rectangle on the stage with the cards indice (A/K/2) on it. So, at this stage, I have 52 rectangles piled on top of each other on the stage :D Already though, I can see it starting to get complicated. If I even want to add drag and drop functionality to the card, thats about 5-10 more lines within the drawCard() function that starts making things look... untidy :) So Im guessing at the end of the day the only thing that should be on the main swf's script is the arrays, and a line calling the createDeck class, which in turn loops through the arrays and calls the drawCard class 52 times, which creates the card object, and calls classes such as cardDrag, cardThrow, cardShuffle etc to add functionality to the card objects themselves?

What did you mean by abstract btw? Is that a specific way of setting up a kind of template for the cards in Flash?

So I've managed to dynamically create an entire deck of cards (sans dots) using no library objects except an embedded font... quite chuffed with myself :D However, I did it all in one file, no OOP, to try and get my head around the maths before trying to get my head around OOP :) Next stage is to try and recreate what I've done with an OOP structure, so I'm going to look over your past comments about OOP and give that a go tomorrow... might have a few hundred questions for you if you get a chance then :D The script for what I've done is below, it should work if you copy and paste it into any Flash file, so long as you have an embedded font in your library that exports to AS3 with the class name 'indiceFont' :) Like I said, the script works... but I'd say a lot of it wasnt done in the BEST way, so if you see anywhere I can improve let me know! //Deck var clubs:Array = new Array('A','2','3','4','5','6','7','8','9','10','J','Q','K'); var diamonds:Array = new Array('A','2','3','4','5','6','7','8','9','10','J','Q','K'); var hearts:Array = new Array('A','2','3','4','5','6','7','8','9','10','J','Q','K'); var spades:Array = new Array('A','2','3','4','5','6','7','8','9','10','J','Q','K'); var suits:Array = new Array(spades, clubs, hearts, diamonds); var suitIndex:Number = 0; var cardIndex:Number = 0; //Measurements var centreX:Number = stage.stageWidth/2; var centreY:Number = stage.stageHeight/2; var inch:Number = 100; var cardWidth:Number = 2.5*inch; var cardHeight:Number = 3.5*inch; //Draw Card function drawCard(suitIndex:Number, cardIndex:Number) { //Card Shape var card:Sprite = new Sprite(); card.graphics.beginFill(0xffffff, 1); card.graphics.drawRoundRect(0, 0, cardWidth, cardHeight, (2/8)*inch) card.graphics.endFill(); //Card Shadow var cardShadow:DropShadowFilter = new DropShadowFilter(); cardShadow.distance = (1/32)*inch; cardShadow.angle = 25; cardShadow.blurX = cardShadow.blurY = (1/8)*inch; cardShadow.alpha= 0.25; card.filters = [cardShadow]; //TextFormat var indiceTypeface:Font = new IndiceFont(); var cardTextFormat:TextFormat = new TextFormat(); cardTextFormat.font = indiceTypeface.fontName; switch (suitIndex) { case 0: cardTextFormat.color = 0x000000; break; case 1: cardTextFormat.color = 0xff0000; break; case 2: cardTextFormat.color = 0xff0000; break; case 3: cardTextFormat.color = 0x000000; break; default: cardTextFormat.color = 0x00ff00; } //cardTextFormat.color = 0x000000; cardTextFormat.size = 60; //Card Face var cardFace:Sprite = new Sprite(); cardFace.x = 10; var cardIndiceTop:TextField = new TextField(); cardIndiceTop.text = suits[suitIndex][cardIndex]; cardIndiceTop.setTextFormat(cardTextFormat); cardIndiceTop.embedFonts = true; var cardIndiceBottom:TextField = new TextField(); cardIndiceBottom.text = suits[suitIndex][cardIndex]; cardIndiceBottom.setTextFormat(cardTextFormat); cardIndiceBottom.embedFonts = true; cardIndiceBottom.rotation = 180; cardIndiceBottom.x = card.width-20; cardIndiceBottom.y = card.height; addChild(card); card.addChild(cardFace); cardFace.addChild(cardIndiceTop); cardFace.addChild(cardIndiceBottom); //Place Card var cardSpacingX:Number = 0.5*inch; var cardSpacingY:Number = 1*inch; var cardRotation:Number = 1; var errorMargin:Number = 5; card.x = centreX - ((((suits[suitIndex].length-1)*cardSpacingX)+card.width)/2) + (cardSpacingX*cardIndex) + (Math.random()*errorMargin); card.y = centreY- ((((suits.length-1)*cardSpacingY)+card.height)/2) + (cardSpacingY*suitIndex) + (Math.random()*errorMargin); card.rotation = - (((suits[suitIndex].length)*cardRotation)/2) + (cardRotation*cardIndex) + (Math.random()*errorMargin); } //Draw Deck function drawDeck(){ for (suitIndex = 0; suitIndex < suits.length; suitIndex++) { for(cardIndex = 0; cardIndex < suits[suitIndex].length; cardIndex++) { drawCard(suitIndex,cardIndex); } } } drawDeck();