What is a Sprite?

Mr_Fulano
Mr_Fulano used Ask the Experts™
on
Hi, I'm new to programming with ActionScript 3 (CS5). I've been trying to learn how the code all comes together and have made some progress, but have also come across a term that is not defined in the material I've been reviewing. The term is "Sprite". The context it's used in is something like this:

import flash.display.Sprite;
public class Projectile extends Sprite {...

So, what exactly is a "Sprite" (other than a soft drink) and how does it work and why would the Projectile class want to extend it?

Thanks,
Fulano
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
According to the Adobe ActionScript Reference:

The Sprite class is a basic display list building block: a display list node that can display graphics and can also contain children.
A Sprite object is similar to a movie clip, but does not have a timeline. Sprite is an appropriate base class for objects that do not require timelines. For example, Sprite would be a logical base class for user interface (UI) components that typically do not use the timeline.

The Sprite class is new in ActionScript 3.0. It provides an alternative to the functionality of the MovieClip class, which retains all the functionality of previous ActionScript releases to provide backward compatibility.

See http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Sprite.html?filter_flash=cs5&filter_flashplayer=10.2&filter_air=2.6
Commented:
A sprite is an interactive DisplayObject, which means it can detect mouse and other events.  It's different from a MovieClip in that a Sprite doesn't have a timeline. Basically think of it as a lightweight MovieClip. It's ideal for drawing into, just don't try to tell it to "play"or "goToFrame."

The easiest reference is to search Adobe livedocs. I just google "flash.display.sprite" to get their reference page. http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e3c.html is also from the site, and gives a good overview of all the display objects in Flash.

Hope this helps!

Author

Commented:
OK, so based on what you both are stating, a Sprite is somewhat like a layer in Photoshop. It is a container of sorts that holds a graphic of some kind. Its interactive, so I can click on it and get a response or it can listen for events, which in tern may affect its state.

Fulano

Commented:
There are actual layers in Flash, as well, and on each layer you can add multiple sprites.  I would recommend thinking of a sprite as any single item you can display on any layer that is on the stage.

For example, think of a game like Angry Birds. There would be at least two layers- one showing the background, and one showing the birds, pigs, slingshot and defenses. I would make the slingshot and the defenses sprites. They can move and be interacted with, but other than movement, they are not animated. The pigs and birds would have to be MovieClips, though, because they make faces and blink as well as simply moving.

At your introductory level, it may be easiest to think of a Sprite as "any single thing you put on the screen", but use MovieClip instead. You can think of them as essentially the same; the MovieClip is more powerful but less efficient.
I can't really add much to what anyone is saying other than to answer your initial question which was that your projectile class would extend Sprite rather than MovieClip because A) it will need to be updated often, quickly and there will likely be many of them on the stage at any given time, so it needs to be lightweight B) there's no animation within the projectile graphic itself so the extra stuff (scenes, frames, timelines) that it has aren't necesary so it will take up less system resources whenever one is used.

If you understand the OOP concept of inheritance (which you seem to do because you're talking about your projectile extending Sprite) then you should know that MovieClip extends Sprite. So a MovieClip is a Sprite with a bunch of timeline stuff added in. This makes it useful if you're trying to access an object and you're not sure whether it's a Sprite or a MovieClip - you can simply cast it as Sprite unless you specifically need the timeline properties and methods, eg:

var unknownObject;Sprite = Sprite(this.getChildAt(1));
unknownObject.graphics.lineTo(100,100);

Open in new window


Since I'm on the topic and haven't had my coffee yet this morning, allow me to ramble on some more. Sprite inherits from DisplayObjectContainer, which is your base "container" class, and likely all the parent-child stuff you need to do are actually found in the DisplayObjectContainer class. In my code example above I show us using the graphics property of the Sprite object because that's one of the few things that a Sprite actually adds over top of the base DisplayObjectContainer. The complete list of stuff a Sprite does that a DisplayObjectContainer can't do is:
- become a button
- draw in it with ActionScript using the graphics class
- have sound
- drag and drop

That's it. All the other stuff we usually think of when we think of "MovieClips" and "Sprites" is actually bundled in the DisplayObjectContainer class. In fact, if you take a moment to browse the AS Docs as the other guys have suggested, and you look at the inheritance chain starting at MovieClip, it's butt-ass long! We've got InteractiveObject and DisplayObject and EventDispatcher all inheriting from each other like a senior citizen's death pact cult. It's crazy.

So yeah. What the other guys said.

Commented:
2 quick things to add to tomaugerdotcom's response:

The code he gave has a typo in line 1.  I wouldn't normally nitpick it, but since you're new at Flash, wanted to be sure you caught it:

var unknownObject:Sprite = Sprite(this.getChildAt(1));

Open in new window


Also, most components like text fields, text input boxes, dropdown lists are descendants of Sprite instead of MovieClip - they can handle keyboard input as well as mouse.  Again, it's for the same reason as tomaugerdotcom explained - they themselves aren't animated, so don't need any part of a timeline.
@Carnou Ay caramba! Thanks for catching that one.

Author

Commented:
First and foremost, thank you both for the detailed explanations. They have helped me a lot. I'm beginning to see the use for Sprites and how they differ from MovieClips now that you've both given me such good information to consider.

I am learning Flash and ActionScripts 3 from a book and some tutorial videos. They have been very helpful, but there are always questions that remain unanswered and the Sprite issues was beginning to haunt me. I can program in other languages like most of the .NET languages and some Objective-C, PHP and of course XHTML and CSS, but ActionScripts is different. It's a lot less verbose than most of the other languages I've used and its a bit tough to wrap you head around. However, as most other languages, I think there will be am A-Ha moment where everything becomes much clearer...I think I'm getting closer to that moment, but I'm definitely still not there yet. Although, I did pick up Carnou's typo about the ";" instead of an ":".

Thank you both again for the good explanations. I find little use when someone copies and pastes a definition from documentations (which I can read for myself) without offering some sort of layman's version of it or examples, like you two have done.

I suspect that as I move forward with my studies, I'll have a lot more newbie questions for you.

Thanks,
Fulano
I"m sure we'll see you around! For what it's worth, my "AHA moment" came when I actually started to find the ASDoc useful. Up to that point, I couldn't really wrap my head around it and every new thing I tried to do involved what seemed like hours of wasted time researching on Google.

The problem with the documentation is that if you don't know what class you need to do a job, you won't know where to look because the entire thing is ordered by class, and the search function is pitiful. So the best thing you can do (IMHO) is to set yourself some bedtime reading and just try to at least scan through the classes one by one to figure out what they do and how they can be used. Like, would you intuitively think to look at the SoundTransform class to change the volume of a sound? Maybe, maybe not. But it may take a bit of digging before some example code you come across mentions it. So, get a head start and make note of the classes you think will come in handy in the future (like URLRequest, for example, or Loader) and refer back to that list when you have a real-world project!

Good luck!

Author

Commented:
Thanks Tom, I appreciate the advice. The best way I can describe the stage I'm currently in is like when you forget some one's name...you begin to dig though your mind to remember what that person's name was and you begin to recall clues...their name began with an "S", it sounded something like "valley"...oh, yes - her name is "Sally."

I'm at the point where I think I know what the name began with, but I can't yet grasp the rest of it, although it's close...

I don't know if that makes sense, but its actually a similar feeling.

I'm sure I'll have more questions as I continue with my studies. I've been spending at least 2 hours per evening on understanding how to code a simple game. Sometimes it's intuitive, other's its far from it.

Thanks for the help!
Fulano

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial