Questions about how to make games in Flash

[Silicon14]

Hey I'm interested in making something for Flash Forward 22 but I don't know how to code a game in Actionscript2. I have experience in Lua and Python. Can someone point me towards some resources to help me get started? (I already have flash 5.5)

[Gimmick]

Good luck with the jam!

You can find versions of flash 8+ (before it was rebranded to Animate) on AnimateArchive, and most people use flash 8+ for programming in AS1 or AS2.

If you have knowledge in Python, then this is easier because AS1 is essentially a scripting language, and AS2 is object-oriented but few people use AS2 for the FF jam (although you can -and should- use it if possible).

I assume you know the basics of using flash - if not, then I can elaborate in a later post. But as far as resources go, you can view the AS2 language reference and experiment with things here and there. AS2's syntax is very similar to JavaScript, fwiw.

This can be very confusing for a beginner, so feel free to ask away for clarification on a specific topic(s).

[Silicon14]

At 1/6/22 02:31 PM, Gimmick wrote: Good luck with the jam!

You can find versions of flash 8+ (before it was rebranded to Animate) on AnimateArchive, and most people use flash 8+ for programming in AS1 or AS2.

If you have knowledge in Python, then this is easier because AS1 is essentially a scripting language, and AS2 is object-oriented but few people use AS2 for the FF jam (although you can -and should- use it if possible).

I assume you know the basics of using flash - if not, then I can elaborate in a later post. But as far as resources go, you can view the AS2 language reference and experiment with things here and there. AS2's syntax is very similar to JavaScript, fwiw.

This can be very confusing for a beginner, so feel free to ask away for clarification on a specific topic(s).

Thanks! I know how to do stuff like how symbols (though I wish I knew more about how and why you do nested symbols and how do them with ease) and what's the difference between graphic and movie clips.

[Nabella]

Here's two old YouTube channels with tutorials that have helped me a lot. Namely with basic stuff like calling movieClips from your library and onto the stage, as well as giving them super basic physics.

RADTUTS

DANSCOURSES

I hope this helps!!

[Gimmick]

At 1/6/22 04:15 PM, Silicon14 wrote: (though I wish I knew more about how and why you do nested symbols and how do them with ease)

Nested symbols are basically for convenience purposes. Any transforms that are applied to the outer symbols are also carried forward to the inner symbols. Also, nested symbols can be used to establish a hierarchy.

One example of the above is a skeleton - say, an arm.

Let's say you have three separate, individual movieclips such as "hand", "forearm" and "upperarm" which together comprise an arm. They could be nested, or they could be flat. If they are flat, then the hierarchy would be:

stage
|_upperarm
|_forearm
|_hand

While this does work, it's not ideal. Let's say you're trying to animate a throwing action - then, you'd have to keep track of all three symbols, and make sure that they stay in the same position relative to each other (or else it could end up looking like the hand has suddenly dislocated from the forearm!).

On the other hand, let's say you have a nested layout:

stage
|_upperarm
  |_forearm
    |_hand

here, the maximum level of nesting is achieved, as each symbol is nested within the other. You could have the hand and the forearm on the same level, but those have similar drawbacks to the "flat" hierarchy, just less pronounced. The advantage of nesting it is that, as mentioned earlier, all the transforms applied to the "upperarm" symbol are also applied to anything below it - in this case, to the "forearm" symbol, and by induction, to "hand" as well. This means that if the upper arm shrinks, then the forearm and the hand also shrink; if the upper arm rotates, then the forearm and hand will automatically be moved so that they retain the same relative position! This makes it much easier to animate, because there's no risk of "disconnecting" the two visually.

Which should you use? That depends on the situation at hand. Do you need to maintain relative positions and transforms (size, rotation, etc.)? If so, then go with a nested layout. Otherwise, a flat hierarchy is fine. There's no discernible performance difference regardless of which you choose, so it really depends on which is more convenient. If you want to achieve an effect where the hand stays the same size while the forearm grows, though, then you'll have to shrink the hand symbol at the same rate that the forearm symbol grows, so that can get a little tricky (e.g. forearm doubles in size => hand has to halve in size in the same time)

and what's the difference between graphic and movie clips.

I assume you know about the differences but I'll mention the main one at hand just in case: movieclips have scripting enabled for them, whereas graphics cannot. This means that a movieclip can have linkages (so you can use them with classes), it can have frame scripts in its timeline, and when you select a movieclip and open the actions panel, then you can use clip events (i.e. onClipEvent(...)) there.

The other difference being that movieclips play independently on their own timeline, whereas graphics require a 'parent' timeline to play - so a movieclip on the stage with 60 frames in its timeline will play those 60 frames on loop, even if the stage has only 1 frame. On the other hand, a graphic with 60 frames in its timeline will only play the same number of frames as the stage, and only if the stage is also playing at that time. That is, a stage with 30 frames will only play the first 30 frames of the graphic, and if the stage is paused at frame 29, then the graphic will also be paused at frame 29.

[Silicon14]

At 1/6/22 07:11 PM, Gimmick wrote:

At 1/6/22 04:15 PM, Silicon14 wrote: (though I wish I knew more about how and why you do nested symbols and how do them with ease)

Nested symbols are basically for convenience purposes. Any transforms that are applied to the outer symbols are also carried forward to the inner symbols. Also, nested symbols can be used to establish a hierarchy.

One example of the above is a skeleton - say, an arm.

Let's say you have three separate, individual movieclips such as "hand", "forearm" and "upperarm" which together comprise an arm. They could be nested, or they could be flat. If they are flat, then the hierarchy would be:
While this does work, it's not ideal. Let's say you're trying to animate a throwing action - then, you'd have to keep track of all three symbols, and make sure that they stay in the same position relative to each other (or else it could end up looking like the hand has suddenly dislocated from the forearm!).

On the other hand, let's say you have a nested layout:
here, the maximum level of nesting is achieved, as each symbol is nested within the other. You could have the hand and the forearm on the same level, but those have similar drawbacks to the "flat" hierarchy, just less pronounced. The advantage of nesting it is that, as mentioned earlier, all the transforms applied to the "upperarm" symbol are also applied to anything below it - in this case, to the "forearm" symbol, and by induction, to "hand" as well. This means that if the upper arm shrinks, then the forearm and the hand also shrink; if the upper arm rotates, then the forearm and hand will automatically be moved so that they retain the same relative position! This makes it much easier to animate, because there's no risk of "disconnecting" the two visually.

Which should you use? That depends on the situation at hand. Do you need to maintain relative positions and transforms (size, rotation, etc.)? If so, then go with a nested layout. Otherwise, a flat hierarchy is fine. There's no discernible performance difference regardless of which you choose, so it really depends on which is more convenient. If you want to achieve an effect where the hand stays the same size while the forearm grows, though, then you'll have to shrink the hand symbol at the same rate that the forearm symbol grows, so that can get a little tricky (e.g. forearm doubles in size => hand has to halve in size in the same time)

and what's the difference between graphic and movie clips.

I assume you know about the differences but I'll mention the main one at hand just in case: movieclips have scripting enabled for them, whereas graphics cannot. This means that a movieclip can have linkages (so you can use them with classes), it can have frame scripts in its timeline, and when you select a movieclip and open the actions panel, then you can use clip events (i.e. onClipEvent(...)) there.

The other difference being that movieclips play independently on their own timeline, whereas graphics require a 'parent' timeline to play - so a movieclip on the stage with 60 frames in its timeline will play those 60 frames on loop, even if the stage has only 1 frame. On the other hand, a graphic with 60 frames in its timeline will only play the same number of frames as the stage, and only if the stage is also playing at that time. That is, a stage with 30 frames will only play the first 30 frames of the graphic, and if the stage is paused at frame 29, then the graphic will also be paused at frame 29.

Thanks!

[Silicon14]

At 1/5/22 04:40 PM, Silicon14 wrote: Hey I'm interested in making something for Flash Forward 22 but I don't know how to code a game in Actionscript2. I have experience in Lua and Python. Can someone point me towards some resources to help me get started? (I already have flash 5.5)

Also have some ideas what type of game to make. Going to probably be a point and click type game with puzzles and such.

[Gimmick]

At 1/6/22 07:22 PM, Silicon14 wrote:

At 1/5/22 04:40 PM, Silicon14 wrote: Hey I'm interested in making something for Flash Forward 22 but I don't know how to code a game in Actionscript2. I have experience in Lua and Python. Can someone point me towards some resources to help me get started? (I already have flash 5.5)

Also have some ideas what type of game to make. Going to probably be a point and click type game with puzzles and such.

Good luck! Point and click games can be satisfying to make but they can also involve a LOT more programming than initially expected, because you need to keep track of rooms and states (e.g. if a puzzle is solved). This is doubly true if you're using an inventory system, because you then need to keep track of what items you have, how to display them and how to have them interact with the environment. But this isn't meant to discourage you - rather, to manage expectations (that is, if you're making a point and click game because it's simple, then there's the off chance you may end up having bitten off way more than you can chew at the moment).

Rooms are somewhat easy to manage because the flash timeline system makes it easy (e.g. 1 frame = 1 room). However, when you're going back and forth between rooms, then your movieclips will reset, and you have to set them to the correct frame (e.g. a safe being on the "open" frame if it's already unlocked, rather than it defaulting to "closed"). If you're going to add an inventory system, then you might want to learn about dynamically adding movieclips (look up "attachMovie") and using arrays (look up "Arrays" in the as2 reference).

[Silicon14]

At 1/6/22 08:51 PM, Gimmick wrote:

At 1/6/22 07:22 PM, Silicon14 wrote:

At 1/5/22 04:40 PM, Silicon14 wrote: Hey I'm interested in making something for Flash Forward 22 but I don't know how to code a game in Actionscript2. I have experience in Lua and Python. Can someone point me towards some resources to help me get started? (I already have flash 5.5)

Also have some ideas what type of game to make. Going to probably be a point and click type game with puzzles and such.

Good luck! Point and click games can be satisfying to make but they can also involve a LOT more programming than initially expected, because you need to keep track of rooms and states (e.g. if a puzzle is solved). This is doubly true if you're using an inventory system, because you then need to keep track of what items you have, how to display them and how to have them interact with the environment. But this isn't meant to discourage you - rather, to manage expectations (that is, if you're making a point and click game because it's simple, then there's the off chance you may end up having bitten off way more than you can chew at the moment).

Rooms are somewhat easy to manage because the flash timeline system makes it easy (e.g. 1 frame = 1 room). However, when you're going back and forth between rooms, then your movieclips will reset, and you have to set them to the correct frame (e.g. a safe being on the "open" frame if it's already unlocked, rather than it defaulting to "closed"). If you're going to add an inventory system, then you might want to learn about dynamically adding movieclips (look up "attachMovie") and using arrays (look up "Arrays" in the as2 reference).

Yeah considering I'm new to AS2 I might make a smaller/easier game to make so I might put off the point and click game till I can make something easier to build on. What would you say would be an easier genre to deal with making?

[Gimmick]

At 1/6/22 08:55 PM, Silicon14 wrote: Yeah considering I'm new to AS2 I might make a smaller/easier game to make so I might put off the point and click game till I can make something easier to build on. What would you say would be an easier genre to deal with making?

By far I would say platformer games are the easiest to make. They just require knowledge of a few basic concepts, each of which are but a few lines of code in their most primitive form:

• Collision detection (enemies, walls, finish line)
• Keyboard events (key presses, releases)
• Updating coordinates every frame (moving, jumping, gravity)
• Keeping track of states (powerups)
• Changing frames (levels)

You'll note that I haven't included arrays there! While it is recommended to make platformers in a more structured style that often involves arrays, most beginners often just wing it with individual movieclips for coins, walls, etc. and make it work somehow; I did the same thing back when I was first starting out!

The next easiest would be visual novels. These actually require fewer concepts than platformers, as they're effectively point and click games without the inventory management, and without the puzzles built in, so most of what you need is just:

• Changing frames (dialogs)
• Keeping track of state (past choices that influence a particular branch) - this isn't technically needed but it prevents a LOT of duplication

Viewed from an extreme, you can even take the original Pico's School to be a type of visual novel, and that was implemented even before variables existed in Flash at the time! So why do I rank it more difficult than platformers, even though it requires far less technical know-how? It's because it's so tedious - making a visual novel with a story worth telling requires a LOT of dialog, and a LOT of options. Reduce the options and it feels less like a choose-your-own-adventure and more of a "short story but more drawn out". Reduce the dialog and it'll feel way too short. Finally, the writing plays a much larger role here, whereas it's less so in platformers - you can play Mario and still have fun without giving a damn about the plot (which is already very generic - "save the princess" was not exactly original even in 1985).