Hello fellow developers.

So, we have begun making an adventure game on Flash AS3. We're just at the beginning and some annoying issues came up. At first we created a starting screen/menu and another screen (first room) which came up after clicking new game. These are both seperate scenes in a single swf file, but the codes in the first scene (menu) are tampering with the second one (room) and it just didn't work properly. Then we thought about creating each scene in a seperate swf file. This is our first question: Is it plausible to make such a game in seperate swf's and maybe linking them in a main swf file? Even from the beginning, "scenes" seem to be a pain in the ass..

After that, bigger questions came to our minds: Is Flash suitable for a big game like this? As if goes planned, the game will be a long and rich one. Not just some basic browser game. Well, I'm sure C++ and derived langs are probably more suitable for this task but we're not in position to learn new langs or engines to work on. So it's unlikely for us to change platforms. Besides, titles like Machinarium gave us the courage to make such a game on Flash in the first place..

And finally, when we're finished with our game. Will it be a one big swf (or exe) file and nothing else? I mean, wouldn't it be a burden for a PC to load and run a single big executable? Would it be efficient? Can it create some other unknown issues?

What do you suggest?

[quote name='ExCx' timestamp='1323320422' post='4891703']
Hello fellow developers.

So, we have begun making an adventure game on Flash AS3. We're just at the beginning and some annoying issues came up. At first we created a starting screen/menu and another screen (first room) which came up after clicking new game. These are both seperate scenes in a single swf file, but the codes in the first scene (menu) are tampering with the second one (room) and it just didn't work properly. Then we thought about creating each scene in a seperate swf file. This is our first question: Is it plausible to make such a game in seperate swf's and maybe linking them in a main swf file? Even from the beginning, "scenes" seem to be a pain in the ass..

After that, bigger questions came to our minds: Is Flash suitable for a big game like this? As if goes planned, the game will be a long and rich one. Not just some basic browser game. Well, I'm sure C++ and derived langs are probably more suitable for this task but we're not in position to learn new langs or engines to work on. So it's unlikely for us to change platforms. Besides, titles like Machinarium gave us the courage to make such a game on Flash in the first place..

And finally, when we're finished with our game. Will it be a one big swf (or exe) file and nothing else? I mean, wouldn't it be a burden for a PC to load and run a single big executable? Would it be efficient? Can it create some other unknown issues?

What do you suggest?

Personally i would suggest ignoring the entire scene/timeline/etc system flash has as that is more suitable for animations than games, Just write the game using Actionscript instead.
[/quote]

We actually put all the elements (background scene, character sprites, items, etc.) programmatically, if that is what you mean. But, shouldn't we use timeline for at least, different scenes? Do you mean that, when we gotta change the scene, we'll just remove all the stuff (again programmatically) and put the new stuff afterwards? Wouldn't it be much more confusing and messy that way?

[quote name='ExCx' timestamp='1323327268' post='4891727']
[quote name='SimonForsman' timestamp='1323323695' post='4891715']
[quote name='ExCx' timestamp='1323320422' post='4891703']
Hello fellow developers.

So, we have begun making an adventure game on Flash AS3. We're just at the beginning and some annoying issues came up. At first we created a starting screen/menu and another screen (first room) which came up after clicking new game. These are both seperate scenes in a single swf file, but the codes in the first scene (menu) are tampering with the second one (room) and it just didn't work properly. Then we thought about creating each scene in a seperate swf file. This is our first question: Is it plausible to make such a game in seperate swf's and maybe linking them in a main swf file? Even from the beginning, "scenes" seem to be a pain in the ass..

After that, bigger questions came to our minds: Is Flash suitable for a big game like this? As if goes planned, the game will be a long and rich one. Not just some basic browser game. Well, I'm sure C++ and derived langs are probably more suitable for this task but we're not in position to learn new langs or engines to work on. So it's unlikely for us to change platforms. Besides, titles like Machinarium gave us the courage to make such a game on Flash in the first place..

And finally, when we're finished with our game. Will it be a one big swf (or exe) file and nothing else? I mean, wouldn't it be a burden for a PC to load and run a single big executable? Would it be efficient? Can it create some other unknown issues?

What do you suggest?

Personally i would suggest ignoring the entire scene/timeline/etc system flash has as that is more suitable for animations than games, Just write the game using Actionscript instead.
[/quote]

We actually put all the elements (background scene, character sprites, items, etc.) programmatically, if that is what you mean. But, shouldn't we use timeline for at least, different scenes? Do you mean that, when we gotta change the scene, we'll just remove all the stuff (again programmatically) and put the new stuff afterwards? Wouldn't it be much more confusing and messy that way?
[/quote]

Why would it be more messy ? you only have a few lines of code there anyway to initialize the main game class, everything else is then handled in the same way as you would with a game written in any other language. (The rooms are data, if you are writing separate code for each room you are doing something fairly wrong imo, if you need extremely specialized behaviour in some rooms you should let your room class have a few configurable functions instead)
[/quote]

Ok, I talked with my staff about this and we're pretty convinced with your idea. But we would definitely need some seperate swf files. Like, one for the menu, one for rooms, one for each puzzle, one for each minigame, one for each cutscene, etc. Wouldn't it be more appropriate like that?

Thx for your attention btw..

Ok, I talked with my staff about this and we're pretty convinced with your idea. But we would definitely need some seperate swf files. Like, one for the menu, one for rooms, one for each puzzle, one for each minigame, one for each cutscene, etc. Wouldn't it be more appropriate like that?

I would suggest not being too quick to jump to the use of separate SWF's for this sort of thing. It's not necessary for the types of things you're describing. SWFs aren't going to get huge just by having lots of code in them. If you embed all of the graphic and audio assets for a large game, then it might start to get large. If you're creating an RPG that will have tons of assets, you might consider loading in assets as they're needed (You have the Loader and URLLoader objects for that).

One workflow that a lot of people like is to use the free FlashDevelop IDE for coding and loading in compiled SWCs with visual assets from Flash CS5. You might for example build the UI for a menu screen in Flash, make that screen a Library symbol (I'm not talking about using the timeline at all), and publish the movie as a SWC. You can then link that SWC into your FlashDevelop project and access the menu screen library item according to the class name you gave it when making it a library item (something like MenuScreenUI). You would then build the code for that MenuScreen in FlashDevelop as its own class that extends Sprite, and you would add an instance of your MenuScreenUI as a display child to your MenuScreen code class.

There are many approaches you can take for moving between screens and program functionality. One approach I often use is to have a sort of Coordinator class that gets instantiated when the program is launched. The Coordinator is responsible for adding and removing screens from the display. For example, if my game needed to have a menu screen pop up upon launch, my Coordinator would first instantiate a MenuScreen object, add it to the display, and add an event listener to the MenuScreen object to listen for when the MenuScreen is finished. When the user is finished with the MenuScreen, that screen would fire off an event so that the Coordinator can respond, get the necessary information back from the MenuScreen, and load the next screen.