I'd like to automatically generate ActionScript classes for a flash client side of one of my projects. (These projects have a formal way of describing my models that is already used to generate SQL and a admin interface).
Now, the ActionScript should/could be compatible with ActionScript 2 and 3. Is there a description of a maximal common subset of features available somewhere?
I think you will be stumped right of the bat, because AS2 and AS3 declare there classes/packages differently.
If you are looking to create Classes from templates, then I would suggest using FlashDevelop. It has a get templating system.
ActionScript 2 Class/Package example:
class com.yourpackage.YourClass extends MovieClip {
function YourClass() {
//contructor
}
}
ActionScript 3 Class/Package example:
package com.yourpackage {
public class YourClass extends MovieClip {
public function YourClass():void {
//contructor
}
}
}
But this is all just syntax. There are a lot more fundamental deferences between the languages than just formatting. There is also a different way of thinking.
One possible alternative to enable you to do this, would be to use Haxe.
Related
So being new to AS3 but not development in general, during a recent project that I just started I hit an immediate snag where my normal method of OOD is causing errors in AS3.
I created a layer in Adobe Flash called code just to keep everything separate and in frame one under actions I used the following code to get started:
var GameContainerSize:int = 400;
class GameInfo {
var GameID:int;
var HomeTeam:String;
var VisitingTeam:String;
function GameInfo()
{
}
}
This simple code immediately causes an error though
Scene 1, Layer 'Code', Frame 1, Line 4 1131: Classes must not be nested.
And my best guess is this is because the timeline and all code on it exists within a class already. So what should I be doing if I want to develop this program using class objects, or is this even possible in flash?
You can't define classes on the timeline. Each timeline is exported as a class, var and function declarations become members of the class, and frame code is moved to its own frame functions which are called when the timeline reaches that frame. Thus the error is saying "you can't put a class in a class" because the timeline already is a class.
To define classes you must use external .as files with package blocks:
// GameInfo.as
package {
public class GameInfo {
public var GameID:int;
public var HomeTeam:String;
public var VisitingTeam:String;
public function GameInfo(){ }
}
}
In Flash Pro you can link a class to a timeline (document or symbols). Such a class must extend Sprite or MovieClip.
You can also refer to any of your classes from any frame script. For example, you could put on frame 1 of your main timeline:
var gameInfo:GameInfo = new GameInfo();
Typical OOP would involve using external .as class files for almost everything, with only minimal function calls on your timeline frames, like stop() at the end of a timeline or calling a custom function you've added to the class linked to the timeline.
I created a layer
That's not ideal. The problem is that it will not get you any closer to understanding the code, because it isn't code. It's a feature of the flash authoring environment. You might as well spend a day with the drawing tool drawing something.
to keep everything separate and in frame one under actions
Organisation is important, but layers aren't the way to go. As each class definition goes into its own external file, you have to create additional files anyway if you want to create more classes. And you want to create more classes because having only one is horrible object oriented design. Being consistent here is important. That's why people in the comments suggested to use a document class and have no code on any frames. All code is organised in classes. No exceptions1.
Having said all that, I highly advice against using Adobe Flash to learn As3. There's too much obfuscation going on behind the scenes. If you want to learn how to code As3, use a code editor. (or plain text editor + compiler if you prefer). Learning what settings dialog has to be adjusted in order to get what you want is not going to get you any closer to understanding OOD in As3.
I also see package, is this kind of like a namespace and does it need to be named, if not what is its purpose?
No, packages are packages and namespaces are namespaces. Apples and oranges.
Packages are used to organize classes just like a structure of
folders is used to organize the .as fiels of those classes. In fact,
the package is pretty much exactly that folder structure, for example:
flash.display is for all display related classes
flash.events is for events
A namespace allows you to control access to members of a class. Namespaces are very rarely used in As3. Here's an article from grant skinner about namespaces. Personally, I never needed to use namespaces. If you are jsut getting started, you can very well ignore them for now.
That sounds perfect! except I cannot get it to launch on my Win10 machine. I may just end up outsourcing this at this ratio
flash develop is the alternative editor. It's free, fast and lightweight.
my normal method of OOD
You want to extend your definition of normal with
always explicitly specify the access control modifiers
member names start with small letters
public class GameInfo {
private var gameID:int;
private var homeTeam:String;
private var visitingTeam:String;
function GameInfo()
{
}
}
1admittedly, there are top level functions that are pretty much free floating functions without a class. If you want to do oop, this is not what you want. It's for the occasional independent utility function. Stick to classes for now.
I want to make new .AS files for each and every object in my game for the sake of versatility, dynamism, and organization. I mean, in the case of a shooter game, I want to make a new class file for every type of bullet with all of their unique properties all spelled out in their respective classes. I want to do the same thing for every type of enemy in the game.
This is all assuming there may be 10+ different types of enemies/bullets.
Some people have been pushing me to keep the values of each type of, for example, bullet in one class and then just change the variables depending on the type of bullet being fired. That doesn't sound too fun to me and I would rather just create a bunch of different class files and just push all of the bullets into a common array(which works so far), but I would really like to know if I have the right, or even good, idea by doing so.
In my opinion, since bullets (or enemies, for that matter) represent the same family objects, it would make sense to have a common interface, or an abstract class, which is implemented, or extended by each concrete class. Is this a good idea? Let's think about it this way:
When you are creating the classes that will be used throughout your application, you essentially building an API. Good practice suggests that you should always program to an interface rather than an implementation. What this means is that your top-level classes, should not depend on low-level ones, but rather they should use abstractions. That way, the different-level components are loosely coupled and the overall code is more flexible. This principle is known as Dependency inversion, and is one of the five principles of the SOLID design.
The links provided should give some additional information on how to structure your code.
Have a great day!
You'll want to use inheritance to make it cleaner and more flexible with changes. Then even on multiple projects you can just extend the same generic base class.
Start with a base class (or interface) - Bullet.as for example - and put all the functionality and properties that are common to ALL bullets in that class. Anytime you have groups of bullets that share the same properties, keep making sub-classes. So if you had multiple kinds of bullets that all explode on contact, you could have the following kind of setup:
public class Bullet {
public function fire():void {};
public property size:int;
public property strength:Number;
public property label:String;
public property maxDistance:Number;
}
public class ExplodingBullet extends Bullet {
public property blastRadius:Number;
public function explode():void {
trace("Kaboom");
}
}
public class BazookaBullet extends ExplodingBullet {
public function BazookaBullet():void {
blastRadius = 10;
label = "Bazooka";
size = 5;
maxDistance = 120;
}
}
This would give your bazooka bullets all the functionality of the class it extends. There are a great many benefits to doing it this way as opposed to recreating all the same properties and methods in all your bullet classes.
I'm trying to figure out how best to setup a kind of universal game element class for my game. What I want to try and create is a structure similar too..
GameElementPositionMovement (root class)
->GameElementVisual (handles all the graphics)
->GameElementPersonality (handles game logic)
I then want to be able to set up different personalities (monster, hero, icon etc) just by creating an instance of GameElementPersonality, but in it's constructor also be able to setup the visual and positioning/movement aspects as well.
I mentioned this in another question, and the answer that came back was...
It seems that you need kind of 'data model' class to store logic and a
visual ('view') class. Visual class shouldn't inherit from data model,
it should use it. This is OOP related problem: IS vs HAS (inheritance
vs composition)
But I'm not sure if I understand that. The position/movement without any visual data, seems a good first root class, and then you add to that the visual aspects (GameElementVisual), and then finally you add in personality "traits" (GameElementPersonality) such as armour, damage, health etc
Therefore I'm keeping, the positioning/movement, visual and logic separate, and I presumed the heirachy that I've laid out would be the best way to do that, but is this not a good way to do this? should it be more flat? with the GameElementPositionMovement, creating both a visual and logic instance and storing that in itself?
You could create a structure similar to this:
(pseudocode)
ElementData
//it doesn't have to extend any particular class
//however it would be nice if it could dispatch events and register listeners
class ElementData implements IEventDispatcher
{
public function ElementData() //constructor
{
//do some stuff
}
public function setSomeProperty(value:int):void
{
//
}
public function doSomeCrazyStuff():void
{
//
}
}
ElementVisual
class ElementVisual extends MovieClip //or just Sprite or even DiplayObjectContainer
{
public function ElementVisual(elementData)
{
//constructor takes an instance of ElementData class
elementData.addEventListener(CHANGE, onDataChange)
elementData.doSomeCrazyStuff();
if (userCliked)
{
elementData.setSomeProperty(15);
}
//you can have here some interactions with user (keyboard, mouse)
//then it can communicate with elenemtData and 'listen' what it says.
}
function onDataChange
{
//react accordingly
}
}
some visual representation (you may need many of these)
class Monster extends ElementVisual
{
//do all the graphic, animations etc
}
Then you need a class to set up all the data, visuals etc… In simplest implementation it can be the 'document class'.
It's not a proper MVC model - it's a simple example to show the concept of decoupling logic from visualisation.
MVC is not the only solution, there are other so called 'design patterns' which may be useful...
Yeah the idea with MVC is to keep things decoupled, in your case you're ultimately smashing everything into one chain of inheritance where you'll end up with one type of object that inherits all the properties from another object that inherits all the properties from another object, so you'll have an instance of this thing that represents everything, which is why this isn't a great pattern to go with.
If instead you have a GameElementPositionMovement class (Your main class) create an instance of the GameElementVisual and in instance of GameElementPersonality (or multiple instances if need be). Then any time a change to a property is made in GameElementPersonality (or any in the collection if you choose to make a collection) could dispatch an event, the main class GameElementPositionMovement could listen for the dispatched event and when it gets it can set/pass the GameElementPersonality instance or array to the GameElementVisual. Then in the GameElementVisual you're just dealing with drawing based on the current model all the time, the model is separated from the view logic, you'd also probably want to handle control in a separate class or in GameElementPositionMovement. (control being the modification of the model, in this case it would probably also be where you register listeners for user events, keyboard, mouse whatever)
This way the model remains clean of control logic and view logic, it's a clear separation of what goes where and really only the view sort of depends on the model and the controller sort of depends on the view but if interfaces are established for what the model view controller each need to communicate with each other in this way you can swap out any of those parts with a new class that implements the interface (not likely an issue in a small game, but the design lends itself to this ability and therefor future scalability).
I am having trouble incorporating graphical assets created in Flash with my Haxe code.
In the Flash IDE, I've created a symbol with the linkage name "MySprite". I compile this into assets.swf. I know that to use symbols in this .swf from my Haxe code, I need to add the following option when using the Haxe compiler:
-swf-lib assets.swf
I'd now like to write a class called "MySprite" which is associated with this symbol, like so:
class MySprite extends Sprite {
public function new() {
// ...
}
}
Basically, I'd like to achieve something similar to the technique presented in this tutorial:
package {
import flash.display.*;
[Embed(source="assets.swf", symbol="MySprite")]
public class MySprite extends Sprite {
public function MySprite() {
// ...
}
}
}
It's unclear from the Haxe documentation whether this can be done, or what the syntax is for doing it.
I think so, but I'm not sure, Haxe doesn't override classes from assets.swf with the classes you declared. There was a discussion about it on the mailing list (the old one, not in the Google groups), and this was the decision... I don't know why this decision was made.
You could still do it with SamHaxe. At least back in the days I was able to. Unfortunately, SamHaxe was abandoned, and if there are bugs or something not working as you need it - you are pretty much on your own. The good thing about Sam is that it's relatively small project. It's written in Haxe and I was able to build it from sources.
You could also try: http://code.google.com/p/hxswfml/ The project seems to be functional and the author used to reply to users. It might be a tad more complex though. I'm quite sure it was possible to do, but you will probably need to ask the author / figure it out yourself.
I'm try to put together a bare bones robotlegs-signals project but all the samples I've seen are flex ie
Index.mxml
<context:SignalCafeContext contextView="{this}"/>
SignalCafeContext.as
public class SignalCafeContext extends SignalContext
{
override public function startup():void
{
injector.mapSingleton.... etc etc
}
}
Is this possible to replace the mxml with another .as file - normally I would pass from the main class
context = new MyContext(this); // where this is DisplayObjectContainer
however super() takes no parameters in SignalContext so I might be missing something.
More Info:
libs:
as3-signals-v0.5.swc
robotlegs-framework-v1.03.swc
signals-extensions-SignalsCommandMap.swc
What you're trying would work in the current RobotLegs v.1 release (v.1.5.2). Context and its subclass SignalContext take optional params. The first param is your context view:
contextView:DisplayObjectContainer = null
Here's the SignalContext class extending Context.
Note, Context in Robotlegs 2 does not take parameters (source).
I imagine you need to start with a actionscript project instead of a flex project in FlashBuilder first.
Yes, your right, you just extend the Context class, as you can see in the basic HelloFlash robotlegs demo
mxml tags are just shorthand for actionscript classes. So I'd imagine you could start by taking a look at the auto-generated actionscript code. There is a flash builder compiler option that will let you see this. Using that as a template, you probably can't go too far wrong.