Recently I've noticed so many threads where the coder is working to such a bad structure that helping them would open a whole can of worms, and actually be more work than it's worth ( I'm not highlighting anyone, but all these threads like "Once it goes back to the title screen after a game over all my variables are reset" or mc's left on stage etc. ).
Recently done a very simple template fla in work, so I thought I'd post it up here to see if it's any use for anyone ( All my games work to this structure, obviously just bigger ).
so, what do i have to do to make this template into a MMORG? I need to know pretty soon too, cos I've sorted out this, like, totally sweet sponsorship deal, that just owns.
chris 'teh falsh games p1mp' error
ps. remember what Mr.Wilde said "No good deed goes unpunished"
Yeah, that looks good - Hopefully a lot of people will adopt this.
1 thing though: I often place the functions before the variables as I tend to use alot of get() functions when setting vars. Many a time I've re-organised code and found the game screw up because of that.
Squize, I'm very interested in your programming structure, but could you please explain a little step by step about your template? I assume you also did this for the noobs, like me, but a noob doesn't get the point out of your template alone I guess. Would be great! Thank you.
Sorry guys, forgot all about this thread, hence this delay in replying.
Ifritt I use that 2 frame approach in the main scene just so that all the vars ( In the Vars layer ) are defined first, and then the init() function just kicks everything off.
Walnoot I'll try mate. The template is kinda aimed at people who have tried making a couple of games and always hit that brick wall of not being able to reset things correctly after a game over / still using seperate frames for different levels etc.
Hopefully I've already covered off why there's two frames in the main scene, so all the vars are declared first.
Any non-local variables ( ie vars defined outside of functions ) should go in that Vars layer. Think of variables in there as "global" ( Although not the same as Flash's _global ). 'Cause all our code will be on one frame ( Just on seperate layers ) all the code can access those variables ( Idealy you want to code without too many _parent or _root references ).
So score, lives etc. will all sit in there nicely.
In the Functions layer we've got the init() call. This should just be all one-shot functions ( ie, they will only ever be called once, so for example you'd create any bitMaps that were going to be used throughout the game here ). So init() is the kickstart to get everything going.
Next is attract(). For those of you not as old as me, the title screens on arcade games used to be called attract modes, basically they were looping through the title / hi-scores / rolling demo to attract you into spending money. Hence the name.
This will handle all your title screen stuff. I do it quite a wierd way, but it works really well. I always have a mc located at 0,0 on the main stage for the title screen. Frame 1 is always a parking frame ( ie
Code:
_visible=false;
stop;
) and then frame 2 is the actual title screen. I just find it really simple to put all the top and tail stuff in this one mc ( So not only will it have the title screen, it'll have the get ready prompt, the game over, level done, enter your hi-score etc. Everything that's presentational rather than game related ).
It's just handy being able to spread things like this out over as many frames as you like, and because the first frame is empty it doesn't clutter up your main stage. You're either in there working on the title stuff, or you're not and it's not bothering you.
So somewhere in the attact mode mc you'll have a test for fire or a button press to start. This will call the startGame() function.
Here you set everything up for a new game. Lives=3, level=1, score=0 etc.
It's just a method of making sure everything that needs to be reset is.
From that you get continueGame(). This set's everything else up needed to trigger a game. Also, this is the function you call after you've lost a life.
To try and clarify, in your game Pac man just got eaten, so you run the dying animation and then call the lifeLost() function. This'll just be a simple:
Last thing is the enterFrame layer. This is the master() function ( Or mainloop ). We only want one onEnterFrame running in the whole game, so this'll be it. Within this master function you'd have all the usual calls, eg
- playerInput
- playerMove
- baddieMove
- collisionChecks
And that's about it really. Anyone with any further questions don't be shy. I've only quickly skimmed through it 'cause I'm not sure if anyone is listening
I put it in the first scene. I didn't include one 'cause it stops being a clean template then, I didn't want to add stuff that people would just have to delete ( The fps counter can just be guided out ).
I always leave the first 5 keyframes free to stop the preloader bug ( I wish all sites did that ), and I put the linkage container in there ( Just to explain to those who haven't used one, when you export you knock off the export to first frame option and just drop a copy of the mc into that linkage container mc. It stops the issue of your preloader not appearing til about 30% has loaded. Also I shove all the sounds in there too ).
If I do an example game I'll drop a simple preloader in there.
Hey squize i am new to this whole forum thing. Anyway i tried to download your version 2004 template but my version of flash wich is the newest before eight gave me an unexpexted file format. I dont know if it is just my computer but let me know what i might be able to do.
Even though i havnt been useinf flash very long they way i set up my code in the final game is almost exacly the same. Im am guessing that is a good thing.
I recon the only difference is that attrack mode thing. Its a bit weird and i didnt understand the concept of it but oh wells.
92.7 Fresh FM for all your South Aussies - Doof Doof music FTW people!
I keep getting an error when trying to load in mx as well.
I would like to look at how a pro sets out their work though.
To be honest gloopot I dont think you have to copy squizes exact style to be considered a good programmer as I expect different people in different studios have different layouts. As long as the code is set out in an easy to understand mannner and any other coder can see what your code is doing then that is fine.
Of course ill look at squizes style and pick up on some things to improve my layouts as im sure I can learn something.
If our body is a clock ticking away and if while we experience all that this world has to offer time has still continued to pass, are we living or just experiencing a slow death?
Lack of replies from me 'cause I've been at the Grant Skinner bootcamp all w/end. btw, that guy just rocks so much.
It's cool just being blown away by someone so much better than you.
Anyway, Gloopot glad to hear you use a similar structure ( Now if only you'd preview your posts to cut out some of the worse typos, you'd be well on the way ).
The attract mode is just the title screen and the game over screen, that's pretty much it. They're in a seperate mc 'cause it's neater and easier that way.
Most people think it's kinda weird way of doing it I must admit, but for things like that it's nicer to be able to use a bit of timeline, and put labels on keyframes.
When you get to work with designers you'll find they'll want a ultra cool transition between everything, if you've got everything spread out on a timeline it's nice and easy to just drop that stuff in ( Check out our Static Shock game on cartoon network. All those fiddly little transitions came to me late in the day. 'Cause all the attract stuff is just spread out on keyframes you can just drop those animations in there, and use a simple bit of code to see if it's _currentframe==_totalframes and if it is, move on to the next thing ).
There's no great secret to coding you know. There's no "pros" way really. I'll use code that a lot of people here would wince at, but it gets it done, and you don't ever get marked on your code.
Sorry, slipping into a slight rant here, but it's like a lot of people frown upon tweaning, "It should be done in code". Well, not all the time. Take a starfield for example. Each star can be a simple twean from point A to point B. When it hits point B you just move it's postion, and let it start again from A. Next to no code at all, so it runs ultra quickly.
Just make things modular to a certain degree, and for everything you use, make sure you clean it up after yourself. You attach 10 mc's on the screen for the baddies, have a houseKeeping() function in there to remove them. Simple. Then that function can be called when a levels cleared, when the players lost a life, when it's game over or if they've quit the game. One routine and it covers all those different events.
"I dont think you have to copy squizes exact style to be considered a good programmer"
To be perfectly honest mate, I still don't consider myself that good a programmer. Getting better, but still a long way to go.
Yep, my way is one of dozens. I only posted my way here 'cause so many people were using the really badly dated tutorials as their blueprint and then getting stuck when trying to add any level of complexity to them.
).
Reply With Quote
), and I put the linkage container in there ( Just to explain to those who haven't used one, when you export you knock off the export to first frame option and just drop a copy of the mc into that linkage container mc. It stops the issue of your preloader not appearing til about 30% has loaded. Also I shove all the sounds in there too ).
