This content has been marked as final. Show 3 replies
good for you - you're on your way :)
I would recommend that you keep all of your game elements within a single swf file - this is best to call them to the timeline at need. additionally, most game companies (if you plan on submitting your game) will 'prefer' that there be only a single swf file.
sounds like you are referring to a 'preloader' bar - and there are many types, you can actually make a perload indicator from any type of animation really. and the 'need' for this will depend on the 'size' of the end swf file. 'where to' and 'how to' do this is a matter of preference - there are several ways. many will include a looping type of code on the first two frames on a movie and use the 'getBytesLoaded()' and 'getBytesTotal()' methods to determine a percentage of the file loaded - however this can become a problem when loading certain things like for instance 'class' files, or items in the Library that are set to 'export in first frame' which you will need to utilize when constructing a application as complex as a game. Therefore a much better method of 'preloading' is to have a 'wrapper' (as you'd mentioned) swf file or 'master' loading swf - and then use the MovieClipLoader class to load the swf file of the game. the MovieClipLoader class has several handlers which make loading easy to monitor, control and initiate methods with in the loaded file when loading is complete. however - it does sound as though you are using CS3 - and therefore you may be coding in AS3 which has a 'new' and different system of handling loaded assets. but it is also likely that your splash screen may be sufficient, and the size of your file should be kept as small as possible anyway.
importing graphics - if you have your 'new' master game doc open - you can use the File>>Import>>Open external library command to open the library of another fla file - then just simply click and drag the symbol from the 'other' file lib - to the one your working on.
just a few thoughts for you to work with.
So for each of the screens above, is it best practice to put them on their own Scene?
actually no - scenes and programming are bad, bad ,bad ... lol! there are reasons - and scenes are really meant to assist animators in producing long straight line animations - but when it comes to scripting, they are trouble.
there are several other ways to 'containerize' your elements however, and if you're getting into producing games, i would recommend that you use MC (movieclips) and become fluent in attachMovie() and removeMovieClip() methods. using these you can bring an item to the stage at need, position it and then remove it from the stage when called for.
one can also do this using the timeline and frame labels, and on a button press navigate to a frame label using the gotoAndPlay or gotoAndStop methods. sometimes this is best depending on the situation - like for instance if you have several instruction screens that the user progresses through, or a series of character speaking (text) sequences durring a transition between levels or something. however as a general rule when constructing a gameloop you should use mostly script, and have very few timeline elements, to retain complete control of the system and game events.
another method would be to have your 'screens' set on different layers within the main timeline first frame - all of them as MCs (with instance names, always) and 'toggle' the needed screen's _visible property. in this way everything kind of 'exists' right there and all you need to do is 'show' the correct screen. but this also will depend entirely on the type of game you are making.