top stuff token, particularly the commenting tips...
Printable View
top stuff token, particularly the commenting tips...
During my exam I suddenly looked around for the save button, and I've also tried to pick up stuff on my desk with the mous :pQuote:
Originally posted by DancingOctopus
haha yes! I do that too! What's worse is in real life, when I'm writing or drawing or doing just about anything and I make a mistake, my first reaction is "CTRL-Z!" When I realise I can't "undo" real events, I'm bitterly dissappointed. :(
My coding practices are similar to others that have been mentioned so I wont rehash it all.
I'm the same when it comes to over CTRL + S and CTRL + ENTER'ing aswell as occasionally trying to CTRL + Z when sketches character designs.
When it comes to commenting though, I go all out! I comment everything that isn't blatantly obvious. I do that because in order to pass my JAVA, C++, Oracle, unix, JavaScript classes (I think that's all the coding ones), for my Diploma, we need good commenting practices. That isn't to say my commenting is messy! It's very organised :)
One question about that though which might be slightly off topic:
Since long variable names have a perfomance hit (albeit the tiniest) and leaving Trace()'s within your code, come compile time, also has a performance hit (again, only small), does this mean lots of commenting will have a hit aswell?
I might be wrong here, so don't quote me on it. But I think the compiler removes commented lines, meaning it shouldn't hit performance at all. I'd also think that even if they're not removed, flash would simply pass over them without too much ado.Quote:
Originally posted by StenFLASH
Since long variable names have a perfomance hit (albeit the tiniest) and leaving Trace()'s within your code, come compile time, also has a performance hit (again, only small), does this mean lots of commenting will have a hit aswell?
You could always try adding 5000 lines of commented gibberish and see if it hits performance.
The compiler remove Trace() commands, if you tell it to. There is a check box which you can select in the publish settings. (Ommit Trace)
Furthermore, long variable names do not make a difference in FlashMX2004 if you define them as a 'var'. Come compile time they are replaced with _local1, _local2 etc. and the variables are used in the internal registers
I know my method has most likely been mentioned already, but here's a quick run-down:
Three Scenes:
- Loading
- Main Menus
- Game
For the Game Scene, It's only 1 Frame, multiple layers. Whichever frame I start in automatically becomes the AS frame :D. The code in this frame contains:
- All starting variables (ints, Strings, Arrays, etc)
- All Functions
The functions are all broken down into their own respective groups for organization, such as movement, shooting, HUD, etc. If I ever need to add a certain function, I simply add it at the end of its respective group.
As for the OnEnterFrame function, this is done on a blank MC. I could easily have everything in the AS Frame, but it would be dreadfully long. This blank MC takes care of every single thing that needs to be done during every frame. I have tons of if statements (to help reduce the time taken for each iteration), and make use of the short circuit commands like && and || (as opposed to leight, I believe). I found that Flash can't handle too many of these within one if statement, so sometimes I'm forced to break it up. These things aren't really given respective groups for organization. They're just added to the end whenever I get to them :rolleyes:.
On the Stage, I have basically nothing (95% attachMovie()), aside from things that would never leave the screen (HUD, hero, etc).
Like many other people here, my finished games always have a battlefield of traces throughout the code, most of which are commented out. I should look into the "Omit Trace" option at publishing :cool:
Other than that, I suppose it's relevant that I also share my method for coding. In general, I add one thing, and then tweak it until it works the way I visioned originally (or until something happens to look cool =P). I know some people like to code for hundreds of lines before testing anything, but I find the baby-steps method of coding to be more efficient when it comes to tracking down a runtime error. The only downside I suppose would be that it takes much longer, because you're compiling and testing the game much more often. Not a problem for those of us who can't help but admire our own creations :).
Great discussion, everyone. This seems well for the Knowledgebase. A lot of questions are answered and we get to hear the methods of the programmers we wish we could be like ;). The only flaw to this textual paradigm is that many of the same methods are reiterated by various posters, which introduces repetitiveness and ultimately raises the post count into the [now] double digits (almost triple). Still, a great read for the programmer with a few minutes on his or her hands.
- OneMrBean
That's why I love OBP (object based programming)
Is like create a creature and write the code inside to give him life
For me is the best way to organize mi coding, I just have to drag from the library and it works, every object in my games has its own code, is like having living creatures that react to other objects or the stage
I really don't know how to make a long coding in a frame to make a game work, is dificult to change something and for me is easy to do mistakes, but if I'm programing every object is an easy task (for me, lol)
Regards
PIT
I code very sloppily.
I tend to have all the enterFrame actions for the entire movie on a single frame, using if (_currentframe == x) { lines to decide when the script is happening. I don't use that many functions, and I NEVER use comments (except when deactivating certain parts of the code). As far as I'm concerned, nobody else will be looking at my script, so I don't bother putting in comments.
They get in the way, too, and they make it take longer to scroll. Plus, I can never be bothered to type them all out. Also, I try to have as much actual code as possible within view, (I have a built-in 1024 x 768 monitor), and I have to resort to a full-screen Actions panel whenever I'm using big scripts. I usually have hundreds of lines of script in a massive pile, not having a clue where any of it is.
Bad habit to get into mate ( And I don't just mean double posting ;) ).
Squize.
Since I last mentioned "how I arrange code", I've switched it up a bit. I've started working on a more complicated project than some previous ones. I've been breaking out monster functions onto their own layers, commenting them well. I also switched to spelling out vars to exactly what they are the majority of the time, when not working on something for a week or two and having to go back or even longer, my memory isn't always up to the task. When the project is complete it is easier for me to go back and optimize once everything is running 100%. I'm working my way up to MX2004 and a more object oriented approach. Is it worth upgrading yet from regular MX?
The only code that is ever inside an mc is stop(); and that is for animations only.
I worked on several bigger projects and mostly had my code on frame 1 of the master timeline in the first picture. Additonally I use SciTeFlash and lot's of as-files. Grouping your code by "actions" amkes most sense to me. i.e. in one file you host the code for collision detection, in one for the movement of the main character etc.
Also I only use one enterFrame-function per game, in special cases sometimes two.
It said the server couldn't be found or something, so I clicked the submit button again. When that "didn't work", I copied the message to send it again later (but forgot to in the end).Quote:
Originally posted by Squize
Bad habit to get into mate ( And I don't just mean double posting ;) ).
Squize.
Functions. If something isn't working I know what function its from so I go back and look at where I messed up.
i used to make games in game maker. i swapped to flash 4 days ago, and i'm still learning. game maker was really object orientated, so i tend to want to write nearly all the code in the MC's. player control in the player mc etc. but i was wondering. everyone here talks about wanting to do code in runtime. why? doesnt that make the game slower?
Object oriented programming is sure alot easier. i would want to make a frame for every situation. (different level, menu, etc). i don't really know how i'd have to make more than one levels in one frame.
ps. I don't quite understand the authoring tool enviorment(or however it's spelled). i know flash is ment for more than just games, but does anyone know a tutorial that points out all the things you need to know, just for game creation? mc's are the flash equivalent of objects, right? stuff like that, I dont quite understand yet.
Unless i'm hacking something together quickly, then I do it like this:
I make all my component classes, then I make managers or extend other managers to control them and give them there content. Then I make a game manager class to plug it all together and sequences the events etc.
RipX
Good thread! (but it's been a few years now)
What about using several files? It seems not to be recommended, and game portals often only want one file (?). What to do with level data, maps, big chunks of text? Would you use a layer to write huge chunks of arrays and/or text? Or a separate file to load from? Would that somehow become one file after compilation anyway?
Lol. this is the second time this thread has been brought back from the dead.
I'm trying to stick to classes as much as possible, begin with a base class and break it up as the codebase gets bigger. Not the prettiest way to approach design patterns but it works for me.
4 years is a long time in coding...
"I still put the player code on the actual player mc, which is kinda lame I know, but I find it's a really nice way to code"
Ha, the good old days. Now before I even get the player sprite just to appear on screen I have to code 4 classes.
Squize.
I went to put some code directly on an mc the other day and forgot the onclipevent syntax.
Only had the art director sitting next to me have to help me out....
I'm supposed to be coding an as3 project for them too.
What I use to organize code is projects, packages, classes and interfaces
So usually I have the src folder where I have Main.as or whatever and below that are the packages in biz.hatu.gamename.whateverpackageitis