I am trying to build the foundations for a platformer game in Actionscript 3. I'm still fairly novice at AS3, but I'm hoping this will help build my knowledge.
Anyway,
I understand that I can create Actionscript files that are associated with something such as a Sprite or a MovieClip by extending the Sprite/Movieclip class. I also know about Actionscript files that work as the 'Document class'.
Each level in my game will have different properties that vary such as gravity. Where should I store these variables? Obviously not in the player... Not sure if they're supposed to go in the timeline or the document class, or if they have a separate AS file of their own. I've been told that having global variables is generally bad, so I'm not sure what to do.
You can make levels as separate files that are even not Actionscript, but XML or JSON, since your levels are basically data structures with different starting values. And you can make a Level class that can take such a file, parse it and initialize an in-game level structure based on what's read. Yes, such data should not go to timeline, because should you need to change one piece of that data, it could implicitly affect other game processes. Also, one simple right click can ruin such a game :) I myself use JSON files as my level data holders, and I parse them at the initialization time, you can do like this or say when your level is being loaded.
In short, if something is different by initial data, but common in methods, it should reside separately from main code, or entire code, and be included as data.
I think this similar question and answers will help you somewhat:
As3 OOP game structure (class architecture)
Basically, "What you want to do is to separate what changes in your game from the game itself". So definitely do not include the code in the timeline.
Related
I guess this is a question for real gurus only..
I'm using the Flash Authoringtool to create MovieClips, yet I play them using my own engine (which behaves better for mobile).
Yet, for proper behaviour, given a DisplayObject, I need to know if its parent is tweening it inside the MovieClip it is part of.
I've already come up with Brute-force and non-elegant ways to do that:
In the authoring tool, add a prefix to the name of any movieclip that is subject to tweening. That name prefix can be checked lateron at any moment. Of course, as this prefixing is a manual process, it's easy to forget or mistype one.
In the code, play each sub-movieclip of the main movieclip for all of its frames, and for all of its children, detect if the transformation matrix changes at any of these frames. If so, automatically prefix their names. Although automized, this solution may take up noticable time for larger movieclips.
So what I'm hoping for is that some other way exists like:
if((dpo.parent) as MovieClip) != null)
{
bDpoIsBeingTweened = ((dpo.parent) as MovieClip).someProperty;
}
Looking forward to any elegant solution.
The solution is quite simple: stop using Adobe's tweening library.
Use TweenLite which is hundreds of times faster, easier to code, and has many other benefits. For example being able to use isTweening to determine if some object is being tweened or not.
Here's the documentation.
To include external libraries in the Flash IDE you can do it in 2 ways.
1) Copy the folder of the external library in your project folder (where your .fla file is)
2) Define a folder in "File > Actionscript settings" where you want to put external libraries files in your hard disk.
Then in your code you just need to import those classes with import. For example:
import com.greensock.TweenLite;
what is the meaning of this interfaces? even if we implement an interface on a class, we have to declare it's functionality again and again each time we implement it on a different class, so what is the reason of interfaces exist on as3 or any other languages which has interface.
Thank you
I basically agree with the answers posted so far, just had a bit to add.
First to answer the easy part, yes other languages have interfaces. Java comes to mind immediately but I'm pretty sure all OOP languages (C++, C#, etc.) include some mechanism for creating interfaces.
As stated by Jake, you can write interfaces as "contracts" for what will be fulfilled in order to separate work. To take a hypothetical say I'm working on A and you're working on C, and bob is working on B. If we define B' as an interface for B, we can quickly and relatively easily define B' (relative to defining B, the implementation), and all go on our way. I can assume that from A I can code to B', you can assume from C you can code to B', and when bob gets done with B we can just plug it in.
This comes to Jugg1es point. The ability to swap out a whole functional piece is made easier by "dependency injection" (if you don't know this phrase, please google it). This is the exact thing described, you create an interface that defines generally what something will do, say a database connector. For all database connectors, you want it to be able to connect to database, and run queries, so you might define an interface that says the classes must have a "connect()" method and a "doQuery(stringQuery)." Now lets say Bob writes the implementation for MySQL databases, now your client says well we just paid 200,000 for new servers and they'll run Microsoft SQL so to take advantage of that with your software all you'd need to do is swap out the database connector.
In real life, I have a friend who runs a meat packing/distribution company in Chicago. The company that makes their software/hardware setup for scanning packages and weighing things as they come in and out (inventory) is telling them they have to upgrade to a newer OS/Server and newer hardware to keep with the software. The software is not written in a modular way that allows them to maintain backwards compatibility. I've been in this boat before plenty of times, telling someone xyz needs to be upgraded to get abc functionality that will make doing my job 90% easier. Anyhow guess point being in the real world people don't always make use of these things and it can bite you in the ass.
Interfaces are vital to OOP, particularly when developing large applications. One example is if you needed a data layer that returns data on, say, Users. What if you eventually change how the data is obtained, say you started with XML web services data, but then switched to a flat file or something. If you created an interface for your data layer, you could create another class that implements it and make all the changes to the data layer without ever having to change the code in your application layer. I don't know if you're using Flex or Flash, but when using Flex, interfaces are very useful.
Interfaces are a way of defining functionality of a class. it might not make a whole lot of sense when you are working alone (especially starting out), but when you start working in a team it helps people understand how your code works and how to use the classes you wrote (while keeping your code encapsulated). That's the best way to think of them at an intermediate level in my opinion.
While the existing answers are pretty good, I think they miss the chief advantage of using Interfaces in ActionScript, which is that you can avoid compiling the implementation of that Interface into the Main Document Class.
For example, if you have an ISpaceShip Interface, you now have a choice to do several things to populate a variable typed to that Interface. You could load an external swf whose main Document Class implements ISpaceShip. Once the Loader's contentLoaderInfo's COMPLETE event fires, you cast the contentto ISpaceShip, and the implementation of that (whatever it is) is never compiled into your loading swf. This allows you to put real content in front of your users while the load process happens.
By the same token, you could have a timeline instance declared in the parent AS Class of type ISpaceShip with "Export for Actionscript in Frame N *un*checked. This will compile on the frame where it is first used, so you no longer need to account for this in your preloading time. Do this with enough things and suddenly you don't even need a preloader.
Another advantage of coding to Interfaces is if you're doing unit tests on your code, which you should unless your code is completely trivial. This enables you to make sure that the code is succeeding or failing on its own merits, not based on the merits of the collaborator, or where the collaborator isn't appropriate for a test. For example, if you have a controller that is designed to control a specific type of View, you're not going to want to instantiate the full view for the test, but only the functionality that makes a difference for the test.
If you don't have support in your work situation for writing tests, coding to interfaces helps make sure that your code will be testable once you get to the point where you can write tests.
The above answers are all very good, the only thing I'd add - and it might not be immediately clear in a language like AS3, where there are several untyped collection classes (Array, Object and Dictionary) and Object/dynamic classes - is that it's a means of grouping otherwise disparate objects by type.
A quick example:
Image you had a space shooter, where the player has missiles which lock-on to various targets. Suppose, for this purpose, you wanted any type of object which could be locked onto to have internal functions for registering this (aka an interface):
function lockOn():void;//Tells the object something's locked onto it
function getLockData():Object;//Returns information, position, heat, whatever etc
These targets could be anything, a series of totally unrelated classes - enemy, friend, powerup, health.
One solution would be to have them all to inherit from a base class which contained these methods - but Enemies and Health Pickups wouldn't logically share a common ancestor (and if you find yourself making bizarre inheritance chains to accomodate your needs then you should rethink your design!), and your missile will also need a reference to the object its locked onto:
var myTarget:Enemy;//This isn't going to work for the Powerup class!
or
var myTarget:Powerup;//This isn't going to work for the Enemy class!
...but if all lockable classes implement the ILockable interface, you can set this as the type reference:
var myTarget:ILockable;//This can be set as Enemy, Powerup, any class which implements ILockable!
..and have the functions above as the interface itself.
They're also handy when using the Vector class (the name may mislead you, it's just a typed array) - they run much faster than arrays, but only allow a single type of element - and again, an interface can be specified as type:
var lockTargets:Vector.<Enemy> = new Vector.<Enemy>();//New array of lockable objects
lockTargets[0] = new HealthPickup();//Compiler won't like this!
but this...
var lockTargets:Vector.<ILockable> = new Vector.<ILockable>();
lockTargets[0] = new HealthPickup();
lockTargets[1] = new Enemy();
Will, provided Enemy and HealthPickup implement ILockable, work just fine!
Can anyone tell me whether code on the timeline is harder or easier to steal/decompile?
Or is it all just the same?
There's no real difference. A dedicated programmer can always get to and reverse engineer your ActionScript. Bear in mind it's not just 3rd party apps like Sothink that can be used. Even Adobe have a tool for 'inspecting' a swf: http://labs.adobe.com/technologies/swfinvestigator/.
If your code is genuinely special enough to warrant stealing, then you would want to use a platform other than Flash (or put your sensitive code into an external C/C++ assembly and run that using something like Alchemy).
Are you really doing something so unique that people are going to try to steal it, though? Is it so special they couldn't just figure out what you've done and copy it?
The difference is essentially nil. In AS3, timeline code will end up inside classes anyway. The code for the main timeline will appear in *filename*_fla.MainTimeline. The code for Symbol1 will appear in *filename*_fla.Symbol1, and so on.
Timeline code can be slightly easily to understand, since variables not explicitly declared as local variables will become class variables. The names of class variables are preserved in a SWF, whereas local variables are not.
Check out my online ActionScript dissembler if you're curious about how your code is stored inside a SWF.
We're making a Flash browser game with a few reasonably complex animations. Our designer is making the animations in Flash Professional while I'm wiring everything up and adding some logic through AS3 (using FlashDevelop).
In one of our more complex animations a "bonus item" moves around the screen. It tweens hither and tither, there special effects and as such, it disappears for a few frames and then reappears later.
From AS3 we want to be able to dynamically decide which bonus item (say a mushroom or a star) to include in the animation. We don't want to have to ask our designer to replicate the entire animation for each of our bonus items.
This is what we've tried:
Created a two frame (1 mushroom frame, 1 star frame) "BonusItem" movieclip in FlashPro and Exported for ActionScript.
Created the complex animation movieclip in FlashPro and added the BonusItem movieclip to the relevant frames. Gave the BonusItem instance an instance name on all necessary KeyFrames. Exported entire movieclip for ActionScript (exported as "ComplexAnimation").
Intention:
The intention was to be able to do this:
var complexAnimation:ComplexAnimation = new ComplexAnimation();
complexAnimation.bonusItem.gotoAndStop("star"); // Frame labels have been added in FlashPRo.
this.addChild(complexAnimation);
This would play the complex animation with the star and we could easily call gotoAndStop("mushroom") to play the same animation with the mushroom.
Problems:
The first problem was that complexAnimation.bonusItem was null on line 02 above. I solved this by handling ADDED_TO_STAGE for complexAnimation and putting line 02 above in the handler.
The next problem was that each time the bonusItem movieclip started tweening, or if it was not present in some frames and was subsequently re-added the complexAnimation.bonusItem attribute/reference was reassigned to a new bonusItem instance. I then had to find a way to know when this was happening and call gotoAndStop("star") on the new instance.
I've found two ways to do this:
1) Listen for ADDED events on complexAnimation with a target.name of "bonusItem". It's a bit crap in a strongly typed language to have to resort to matching strings, but this works. Btw, when the ADDED event is fired new frame object references are still null.
2) Listen for FRAME_CREATED events. This happens later than ADDED at a point where new frame references have been initialized. As such I can check if complexAnimation.bonusItem is non-null at then call gotoAndStop("star") on it. One problem with this is that calling gotoAndStop actually triggers another FRAME_CREATED event to fire, so I need to guard against infinite looping. Again, it works but I don't have a great feeling about it.
Conclusion:
Well I don't really have a conclusion other than I feel like I'm working really hard to do something relatively simple. I'm hoping there's an easier & more robust approach. I have a strong feeling that I'm going crazy. Anyone know a better way to do this?
If you have an object that exists on a timeline and it has an instance name, and you need to be able to maintain a reference to it through the duration of the timeline, then it must exist on every frame (and in the same layer!) of the movieclip. I grant you, your workarounds get the job done but you have already experienced the pain involved in doing so.
The path of least resistance is to just have the object exist at all times. If the user shouldn't "see" it, just hide it offscreen somewhere. Just make sure it always exists, contiguously, on that timeline layer from frame 1 all the way to the final frame.
The other thing I'd suggest is to stop deeply nesting movieclips in the hopes of using those nested clips as state representations. This is one of the things that sadly was very easy to do in the AS2 days, but has been rendered impractical to the point of madness in AS3. Anything deeper than 1 layer is getting into some dicey territory. 3 layers deep and you need to rethink your strategy. Perhaps instantiating different movieclip instances from the library and adding/removing dynamically instead of relying on frames.
I thought I'd update this post with our current (and hopefully long-term) solution.
First of all, I made an error in the above post:
The next problem was that each time the bonusItem movieclip started tweening ... the complexAnimation.bonusItem attribute/reference was reassigned to a new bonusItem instance.
This was incorrect. Flash was indeed assigning a new instance of BonusItem, but it was caused by a Mask layer keyframe rather than the tween.
I had been keen to try to avoid having any logic which relied on string comparisons, but in the end I swallowed my pride to make life easier.
Our designer gives all relevant objects (stuff that we'll need to access from AS3) instance names on each keyframe in the timeline. If the object is nested within other objects our designer must assign those parent objects instance names too. We must coordinate those instance names so that dev know what the accessors are called - we would've had to do all this anyway. Our designer also still has to "Export For Actionscript" a class for each relevant movieclip (e.g. BonusItem).
In AS3 we're using Robotlegs for dependency injection and as the basis of our MVC framework. Robotlegs suggests that application-specific logic should be separated from view-specific logic. It allows us to specify a logic class (called a Mediator) to be associated with each and any of our views. As such we can do the following mapping:
BonusItem -> BonusItemMediator
This means that every time Flash creates a BonusItem on the timeline Robotlegs somehow knows about it and creates a new instance of BonusItemMediator (which we write ourselves and have full control over). In addition, Robotlegs can easily give us a reference from our BonusItemMediator to its associated view instance (the BonusItem instance). So inside my BonusItemMediator I can ask the view reference what its instance name is. I also walk up its parents to the stage and record each of their names to generate a resultant string of instance names that uniquely specified this instance of the BonusItem.
e.g.
"game.complexAnimation.bonusItem"
Once I know this I can ensure that the bonusItem is showing the correct image (star or mushroom) with the following code:
var frameLabelName:String myGameModel.whatTheHellShouldThisBeShowing("game.complexAnimation.bonusItem");
this.view.gotoAndStop(frameLabelName); // where view is the BonusItem instance
So now regardless of how or when Flash seemingly randomly decides to destroy and recreate my bonusItem I'll hear about it and can ensure that that new BonusItem instance is displaying on the correct frame.
The main weakness with this solution is that we're relying on string comparisons. Our designer could easily mistype an instance name and we wouldn't hear about it until that code was hit at runtime. Of course tests mitigate that risk, but I still feel that it's a shame that I'm using a strongly typed language, but then not making use of the compile time type checking.
I'm wondering what is the best practise for gamedevelopment for actioncript 3.
I'm currently in the progress of creating a tile-based game, but I'm already having some troubles using seperate classes.
This is the current situation:
Main class
Generates the tiles
Adds player class
Adds interface class
The interface class contains all interface elements. For example, there is an option to spawn an object into the game. This object could be placed on a selected tile.
Now the problem is a followed: The spawned object is placed within the interface class, how should the spawned object be able to communicate with the tiles?
This same problem arises with several other parts in the game. Like how should the player be able to interact with the spawned object? Everything is in different classes making the communcation between all these things so difficult.
Is there any standard procedure regarding game development which handles this problem?I was thinking of making a "world" class where every object should be placed somehow. But it's hard for me to actually make this with the little knowledge of this sort of structure that I posess.
This is all sort of new to me, so I would appreciate it if the explanation would be as noob proof as possible.
Thanks in advance!
You can use event dispatching for your objects to communicate with one another, there are several approaches available, one of the simpler approach would be for you to create a controller class whose sole responsibility would be to dispatch & listen to events, in order to inform the relevant classes of what's occurring within your game
A better approach could be to use a framework such as Robotlegs, the learning curve is a bit steeper but worth the extra effort.
http://www.robotlegs.org/
You should easily find examples & tutorials for Robotlegs.
Try to imagine the organization of the parts of your game in a slightly different way. In the first place this World class you mention could contain both the Map object also contain the Unit objects for the spawned player or creatures. The Map object which also contains Tile objects which each one have its own information as terrain and attributes. Also the Unit objects would contain the information related to each spawn. For the interaction with your player you could have a Game object that contains both the World and a representation of your player, namely a Player object, and this Game object would communicate the instructions from the player towards the World as to make things happen. As you can see each object contains other objects of finer detail, the World contains the Map that contains the Tile's, this way the higher object uses the lower finer objects and makes them all communicate between them.
This could be a good approach to start something quickly or to learn while you experiment. More complex situation require other ways of arranging all the information of the game like the Model-View-Controller structure, but you probably should not worry to much about it until you have learned enough as to know you need a better solution.
I would suggest to read a little about design patterns. A singleton Dispatcher class can help in your case, you just bind everything to it and send events from one entity to another.
The reason why not use the built-in events is that you would need your objects to be on the display list.