[Q] Do I Need External Scripts?

11 posts

Flag Post

Just wondering how external scripts actually work in ActionScript3. I’m only familiar with VB and I don’t use them in that.

I wrote the code for my game in one script. I drew the game on layer1, frame1. I used Windows/Actions to write the script all on the one frame.

If I want to make a title screen for my game do I need to create a new .fla then, create the title screen and make a .as for that? Then I can just integrate it into my internal script for the game?

Note: As I said Im new to flash. I know code from other languages, but I’m not familiar with flash’s IDE. Are there any tips on where to go for people that know code, but don’t understand Flash?

 
Flag Post

When you said that you drew the game on layer 1, frame 1 and that you wrote the script all on one frame, alarms started flashing in my head. Those are old AS2 practices that you should avoid like the plague if you want to save yourself some headaches as your game grows. Keep your stage clear at the start and only add objects to it through code. Don’t put code on the timeline. Instead, write all your code in classes.

There’s a sticky on this board on how to make Flash games. It has links to several tutorials, one of which is an excellent tutorial by Michael J. Williams. It was written a few years back for one of the older versions of Flash, but while the Flash interface has changed a bit, the tutorial itself is still sound. I suggest that you go through it in its entirety.

Once you’ve learned about object-oriented programming in AS3, it may be tempting to write classes around the MovieClips that you make. For example, if you had one MovieClip representing a goblin, a second one representing a troll, and a third representing the player avatar, you may write separate classes for each because it feels natural to do it in the Flash Professional IDE. Nevertheless, it is more efficient to write a class called Creature that handles the basics of all that these objects can do. If necessary, you can write two other classes that extend the basic Creature class, one called Enemy and another called Player.

I found that a good way to avoid the temptation of making classes revolve around MovieClips is to use another IDE called FlashDevelop. Not only is it a superior IDE to Flash Professional, it’s completely free. You can make MovieClips and SimpleButtons in Flash Professional then publish them as a SWC file that your FlashDevelop project can access. You’ll find links to tutorials on using FlashDevelop in the sticky thread I mentioned earlier.

 
Flag Post

Thanks for clearing that up for me. Flash Pro’s IDE is a bit confusing so I might try out FlashDevelop.

 
Flag Post

Flash’s IDE is good for all the graphics and easier embedding, and FlashDevelop is good for making actual code and debugging. Luckily there’s an option in FD to use Flash’s compiler so you won’t lose your hard work on designing graphics.

 
Flag Post

Alright quick question. I have different classes for each part of my game. Game.as and Ball.as.

If I have a function moveBall(); in the Ball.as can I share it with Game.as so for my game loop all I have to do is call the function moveBall();? Or do I need to put the code for the ball in Game.as itself?

 
Flag Post

I’m sure there is more than one valid answer to this question, but if I were you, I’d put the moveBall function in Game.as.

Consider this: The ball is not an intelligent object. It does not actively make decisions on where to go based on what its goals are and what paths are available to it. The ball moves because of forces that are applied to it from outside — the swing of a paddle, the pull of gravity, colliding obstacles, wind velocity, magical energies, and whatever else is relevant in your game’s physics. I’d say that those forces are most easily handled by your Game class.

 
Flag Post

The way I’d do it (correct me if I’m wrong) would be to have the moveBall() function inside the ball’s class. Then, your Game.as should have added the ball to stage (so it can reference the ball). So, whenever you want to move the ball, simply go ballInstanceName.moveBall();
Also, make sure that moveBall() is a public function.

The advantage of this approach is that your Game.as can handle things like collision detection, interaction between other objects and so on, while the ball only needs to know where to go.
Of course, you could just set the position of the ball in Game.as, but if you want more complex calculations to occur, I’d use the method in Ball.as.

While you can pretty much bundle everything into your Main Class, it’s easy to go a bit overboard. Classes usually help to make things more organised.

 
Flag Post

There’s no right and wrong here; it’s your code, structure it as it suits you the best.
You should ask yourself what’s the best for your application and yourself. Never do something in a particular way just because it fits some arbitrary paradigm. I’m not telling you to disregard programming paradigms, but rather to be eclectic. Coding involves two things; a human and a bunch of tools. Having that many tools available, it’s up to you to use the ones better suited for the task; combine and modify them when necessary. Never adjust yourself to the tool.

 
Flag Post

I like to make all my in game entities responsible for basic updating – movement, static forces (like gravity) rotation and state change (e.g. ‘I have 0 HP left, I should be dead’, or ’I’ve used all my fuel, change colour’) – and the game engine responsible for interactions between objects. So my game loop typically looks like this:

- ask each entity to update itself for the current frame
- manage interactions, collisions etc
- prune dead entities out of the list, and add in entities created this frame
- check for win/loss conditions for the current level
- update views (or render, if I’m custom rendering)

Or those same steps in a different order; it doesn’t really matter.

So if moveBall is just moving the ball based on things the ball knows (i.e. velocity and perhaps environment like gravity) then I would put that on the ball as part of its entity update method.

 
Flag Post
Originally posted by Elyzius:

I’m sure there is more than one valid answer to this question, but if I were you, I’d put the moveBall function in Game.as.

Consider this: The ball is not an intelligent object. It does not actively make decisions on where to go based on what its goals are and what paths are available to it.

Consider this: an object should control its own properties and behaviors, for example, a spring may not be intelligent, but it has behaviors that are not externally controlled.

 
Flag Post
Originally posted by Draco18s:
Originally posted by Elyzius:

I’m sure there is more than one valid answer to this question, but if I were you, I’d put the moveBall function in Game.as.

Consider this: The ball is not an intelligent object. It does not actively make decisions on where to go based on what its goals are and what paths are available to it.

Consider this: an object should control its own properties and behaviors, for example, a spring may not be intelligent, but it has behaviors that are not externally controlled.

There are no shoulds here. An object could

I’d go with Elyzius on this one.
First of all, the performance is way better: It saves you the overhead of calling ball[i].move() N times/loop and having each ball run a bunch of loops for pathfinding, collisions and other stuff.
Also, it would make your Ball class easier to reuse, since it will only know the mandatory information for it, such as position and radius. If you start adding game-specific logic to each object, they become useless for future projects.
ie;

     public function move():void{
           calculateVector(); /* Update the movement data (angle, velocity, etc)
           based on environment changes such as wind. */
           findPath(); 
           collisions();
           updatePosition();
    }

Then you make another game and you can’t reuse that class because your new game has no wind, or no gravity, or no path to find; you just want a ball updating its position based on an arbitrary value.