Printable View
yep, thats what i was talking about.
I have though about making a toplevel clip like that before, but I though having it onscreen all the time might take a performance hit I guess not though.
Well, thanks for the replies so far. This seems to be a fairly popular post.
Dave :domo:
You do get a performance hit for having any mc on stage, but if it's parked on a blank frame ( I even set _visible=false ) then it's so minor as not to even worry about.
These days ease of development gets priority over 100% all out speed for me :)
Squize.
Do you guys ever add features "ex post facto"? Or is everything mapped out 100% before embarking upon development? If you add features later, do you find it difficult to implement them?
Generally everything for my actual game is in one frame in one scene in one layer, i find having loads of layers tend to get in the way. The preloader and menu also each get their own scene. Also until recently everything would be on the stage, and even now i dont like to attack movie clips at run time if i can help it.
My codings possibly some of the worst ever seen in terms of structure. Functions get put all over the place, often in movie clips which they dont even effect. Almost all my variables are _root. variables for no reason, just a habit. Also i never use arrays, just tend to make hundreds of seperate vars, im not sure why. I never use any external files to hold actionscript either. I just find its nicer to have everything in one place.
"Functions get put all over the place" & "I just find its nicer to have everything in one place." Can you clarify this? Not too sure if I understand.
Sorry, yea that is kinda of contradictory. Anyway what i mean by everthing in one place is all in the same frame, layer etc, so i can see all the movie clips.
My functions are all in that frame, i just tend to put them in random movie clips, generally not where they belong. Its kinda like a messy room, everythings all over the place in the room(the one frame), but you know where to find everything when you want it. Some kind of finding comfort in chaos. Im not sure really, just how i work best.
I always try to map stuff out %100 before starting, always add loads of features later, and always find it really difficult to make the changes.
Kind of like everything in my life.
The format i use for my recent projects is:
frame1: loader
frame2: holds all clips to be attached at run time (so you dont need to click 'export in first frame')
frame3: game
frame4: error page
All of the variables and functions are in one or more AS files imported into the 'game' frame. Thats it.
hmm. My style is mostly "ex post everything" I sort of make most of it up as I go along. Because of this, I normally leave space if I think something might fit in later down the line, and I make my code as portable as possible too, so any changes of that nature aren't as much of a chore.Quote:
Originally posted by kendude
Do you guys ever add features "ex post facto"? Or is everything mapped out 100% before embarking upon development? If you add features later, do you find it difficult to implement them?
For example, I reorganised my game this evening, and have managed to get the whole thing onto one frame. I never expected to do this, but, as most (haha) of my code was well-written, it wasn't too much of a bind. Had to add some 'this.''s and '_root.'s here and there, but other than that, plain sailing.
Now I just have to go through all my functions, and see where I can strip out a few commands. I want to launch it as a web game, but I think the processor load is too high for a browser-showing. :sigh:
I don't think unless you're doing a client game or an exact port you can really plan the whole game.
I think if you were to do that, it would play that way, very pre-planned.
imho good games evolve during development. A game should almost be an organic process.
I find adding new features and functions not too hard at all, it's the silly little things that seem to take forever, like adding extra animation frames in the middle of an existing animation.
Hmmm how many paragraphs starting with "I". Must be an ego thing.
Squize.
I am still pretty wet behind the ears with all this. The majority of stuff (recently power ups) in my games are afterthoughts, usually from feedback solicited here. I've gotten a lot better at writing (I notice that when I peep some older stuff (a few months ago)) but I still have soooo much to learn, I realize how little I know every time I try to do something new, then I realize a more efficient way after it's already working and try to remember it the following time I want to implement it. Sometimes I feel like these games are similar to a spider web, everything tied to everything and it's all got to balance at the end. I wanted to make sure I wasn't working all "ex post facto" if it was not normal, being new and all. Thanks.
I have a bit of a method for starting/evolving games.
I start with a basic concept. That is, topdown/side scrolling/puzzle/action/whatever: A very basic, very general game concept. I then go find a whole bunch of games that fit into this concept, however loosely, and make a list of all the features from these games that I like. From there i'll add, remove and derive new ideas for the game as I work on it.
At some point, I think it's important to know when finalise the list of stuff you want to include. If you keep adding and revising stuff, you're never going to finish what you're working on. And I think everyone's been there.
Hehe, no mate - it would be nice though :p I just showed it so people see how I code, and if newbies want to learn how you professional's do it, they may come across the attachment :)Quote:
Originally posted by Squize
leight, do you get a percentage every time someone gets a copy of your scroller ?
Has anyone actually tested which is the fastest for the flash player? Whether it is OOP, code in multiple movieclips or code in one frame.
Ps: This is a great thread, we can discuss ways of coding. Tom, maybe you want to add this to a sticky.
we want a sticky, we want a sticky...Quote:
Originally posted by leight
Ps: This is a great thread, we can discuss ways of coding. Tom, maybe you want to add this to a sticky.
anyway, i generally have a scene for the preloader, then 1st frame:title screen, and 2nd instructions etc, 3rd game and 4th gameover screen.
I put all the code on the frame, and if it gets a bit too overcrowded and messy, i occasionally use external files. I only ever use one layer.
hmmm. I might start doing that, it looks nicer. what i do at the moment is put init(); etc at the bottom of my code...Quote:
Just habit mainly.
The first frame has everything defined on it, prototypes / functions / classes etc and then the 2nd frame is just the actions layer with:
init();
attractMode();
stop();
and that's it. It just my way of making sure everything is initialised for when I start running things.
It's prolly not needed, but another one of my quirky little habits.
Squize.
I dont know if it would, but wouldent that affect file size quite a bit???Quote:
In my current game template I have 300 frames, not all used, I space the sections out every 20 or so frames. the sections go as follows (frame labels):
*preload *logo *error *splash *menu *controls *options *instructions *highscores *gameInit *game
*gameInit is 5 frames long and holds all the code that is needed in the actual game
*gameInit frames 1 and 2 contain globals, prototypes, here I place all movieclips that will be attached at some point during the game.
*gameInit frame 3 contains all variables used in building the game, this may be tilesize, worldwidth / height, buildspeed (used for eye cany in the games); things that will directly change the gameplay
*gameInit frame 4 contains level information
*gameInit frame 5 containg all the code functions used in the game, these may be seperated into sections and stored as seperate .as files (to make finding and changing code easier), depending on the number of lines.
the game frame simply contianes two lines used to set the ball rolling
stop ();
newGame (0);
any other code used in the game is generally imported as packages (classes), if possibl I make it a point never to directly attach scripts to buttons and movieclips. all code is put onto frames > myButton.onPress=function(){}. and where possible; I try to keep code on the main timeline (apart from the obvious stop() commands)
A game I'm currently re-writing has code on two frames, and 1 class. that's all (and the gameplay is complete)
Having said all that, go with what works best for you!
always comment your code : )
Oh yeah, i do code buttons "on" the buttons, not in the frame.
sorry for the long post....
interesting thread, didn't know there were so many different ways of going about it!
For a typical self-contained game, I use 4 frames: init/preloader/movieclips-to-attach/game. The game frame is split into many layers to organise code (if the code is not external) eg. code for: in game, setup, info screen etc. I then have an 'index' layer with a case/switch list that defines and directs the main sections of the game. All movieclips and sounds are attached in runtime.
I can't say that I've done conclusive testing using the same code for both methods, but I've found that developing games with everything in one frame is faster then using multiple movie clips. This can probably be put down to a couple of reasons.Quote:
Originally posted by leight
Has anyone actually tested which is the fastest for the flash player? Whether it is OOP, code in multiple movieclips or code in one frame.
First, it's much faster to call everything from one main loop, then to have a bunch of enterframes executing code. And secondly, because everything is in the same place, it (for me at least) promotes better coding practises resulting in cleaner, better optimized code.
I've never used oop in flash, but I've often heard that it's slower then more traditional flash coding.
"interesting thread, didn't know there were so many different ways of going about it!"
I'd consider that one of the perks of flash development. Because there's never any set in stone way that you have to do somethings, if you get bored doing things one way you can try something different. Of course, some people would prefer to stick with their methods for every single game they make. For me as a hobbiest, rather then a pro, that would be like taking up building models and makign the the same thing every time.
I want to be part of a sticky! :p
I tend to have many frames with many layers and all having frame labels. This means that I can move the frames around without worrying about the gotoAndPlay()'s. (see attachment). I also have most of my code in the main timeline with a few stop()'s and such in other MC's.
I tend not to comment stuff, but I do add the //DO NOT DELETE or //this is for the little variable on line 217 and such. I sometimes (when I have finished the engien) add comments to divide my code. like I have a //MOVEMENT STARTS code here //MOVEMENT ENDS and such. It makes it much easier to search and find stuff.
Oh, and my code is littered with trace()'s :D
I must say I have never really stuck to any kind of practises for organising code in the past, but there comes a time..
My current project has now reached over 10,000 lines of code and has now twice called for some serious tidying up. I did find myself wasting time hunting snippets of code.
I still don't really have a formula, I just put all the functions together until the code hits a 1000 lines and then make more specific function layers. (e.g Level functions, powerup functions, player functions)
So my only advice is functions, functions, functions. :)
My current project by it's very nature needs to generate everything dynamically, but like Squize I do prefer to have more author time content. Dynamic stuff can be great, but can also really slow your workflow due to the constant testing.
I usually stick preloaders and the movies to be attached in a seperate scene and any high score systems in their own scene too. Just because it is easier to append it to other games.
You are all better off not listening to me anyway. My programming is not logical to anyone but me and my variable naming is obscure to say the least. When questioned I simply claim it is an ancient security technique to prevent other coders easily pulling apart my code. :)
As for planning games.. nope..planning for the most part is pointless. You cannot plan playability. Games are all about "test and tweak". Hmm.. starting to sound like a carry on film.
Anyways, I just start with a quick sketch, the main objective, any powerups and extras I can think up off hand and then just throw myself into it. A bit like a night out on the pull. ;)
o.k, I have finished rambling now.
Countdown until I get broadband : 7 days. :)
:)
when i do have movieclips on the stage already(as apposed to attaching everything) i put them in a separate layer from the AS, although i tend to make mistakes and put pictures in the actions layer etc.
Yay! I (may) have started a sticky! :mrt:
Anyway, I am glad this is such a popular thread.
murraymint: yea, sometimes, my code can be perfectly readable to me, but anyone else thinks I am practicing my Latin. edit: I am sorry you all had to hear that Latin joke.
Also, when I have a lot of code, I seperate it into layers named based on what code is in them.
I never include files, but I think it might be a good practice. Maybe put all the initialization code in an include, then just have the main loop in the frame in the fla.
Sometimes, I just start coding the main loop right off the bat, and then later on add the initialization code. Does anyone else do this? I just find it useful to fingure out what I need to initialize, then code it.
Sorry to jump around from topic to topic there. (Only five more posts!!!!)
Dave :domo: