[disc/question] How do you organize your code?

I don't think any two people so far have used the same method.

Flash is aces.

My next game, which currently looks like it will be a top-down car racing game, will be 99% runtime generated, and made from 1 frame.

While I've been working on my 'big' game, I take breaks to mess around with stuff I think up during the day, and I have recently been doing a lot of '1-frame' swf's. And in the last couple of weeks, started using includes. (And SciTE|Flash (omg, HOW good is that?))

the stuff I learn from the trinkets, I usually find some way of applying to the game, to enhance, or speed up certain areas.

It took me a while to get to grips with function/prototpye usage, but now I have, I'm having trouble helping other flashers out, as my solutions are always AS-based, now, and more than likely a prototype. Simply because I can't think of any better way of doing most things.

Once I get the next game underway, I'll start up a WIP thread, which should help trace the development of a game.

As for a 'formula' for making games... That might work if all your games are scrolling shooters, or point&click games, but most people will try different types of games altogether, rather than stick to one style.

When I made my swinging ninja game, I started with the level, and getting it to scroll around in the main window. Then I worked on character movement. Once that was partly done, I had enough code to do the enemy movement.

Things like scoring/levels were done ad-hoc.

eg. The level system for my game became a huge stumbling block, as it was merely an array of coordinates for the platforms and pickups. This made creating new levels a drawn-out and horrible affair.

After my break (MMORPG addiction-break, tbh) the first thing I made was a level generator, where I only needed to give it the platform locations/sizes, and it would generate the pickups automatically. This made level editing/creation a cinch.

Things like that have been turning up left and right since the game started.

The only things I planned were the things I thought were integral to the game (characters/levels/scoring/powerups/intro/endgame/options/etc.). And by 'planned' I mean 'wrote on some paper I found'. Everything else in the game just sort of turned up. One of my favourite features so far had never entered my mind until I showed a test to my flatmate. He said 'make him run up the walls'. Three days later, running up walls is second nature, and also great fun.

It's wierd how this sort of thing works, eh?

Personally I don't think this needs to be a sticky.
All we've found out is that we all work totally differently :)

Should still be a good addition to the knowledge base though.

"Dynamic stuff can be great, but can also really slow your workflow due to the constant testing."

Yep totally, although I've also got this really bad habit of testing the swf after nearly every little change. It must double my dev time. I think I must be hoping for it to work first time... just once.

"I tend not to comment stuff"

I'm pretty good when it comes to commenting, and I use dividers, like

code:

---

//---------------------------------------

//---------------------------------------

---

between every function, and shorter ones between key parts of a function.

"my variable naming is obscure to say the least"

See, I'm murder, but in the opposite way.

var numberOfPointsToCollect;

isn't unheard of in my code. I must lose about 5fps just cause of my labeling :)

Squize.

Quote:

---

var numberOfPointsToCollect;

isn't unheard of in my code. I must lose about 5fps just cause of my labeling

---

made me laugh out loud

I have some good ideas for variables and stuff that I always follow:

_x,x,xpos,xp = _x position of something
same as above for y and z
diff, xdiff, xd = difference
len = length of something
toRad = Math.PI/180

I also tend to put a V in front of variables (eg Vheight or Vcount):

V = Variable, eg Vsomevar
S = Sound, eg Spunch
M = Movieclip, eg Mmenu
F = Frame, eg Fgameover

The good thing with that is that I will never run into a problem of using names that are already beeing used.

here is how i always have my 'arrangements':

2 layers in _root
LAYER 1 : as
LAYER 2 : grapics n preloader MC etc

frame 1, 2 and 3 : preloader
1 is play();
2 is the preloader code
3 is gotoAndPlay(1);
the preloader MC all 3 frames long.

frame 4 : THE GAME mc (instance name is always 'game'
stop();

once in the game MC i define all the default variables in frame 1
(lives=3, score=0 etc)
frame 2 is the menu
frame 3 help
frame 4 options
frame 5 game over screen
frame 6 --
frame 7 ALL code for the game
frame 8 gotoAndPlay(6);


I always put the code in the frames and not on the objects. (except for hitTest etc) [dont know whay tho lol]


Also, when using simple variables i sometimes put a letter before to identify what it is and so its easy to remember
EG. in the tPong game im making at the moment some of the var's are:

dballPOS_x (default x-pos of ball for gameover // restart)
dballPOS_y (default y-pos of ball for gameover // restart)
dbatPOS_x (default x-pos of bats for gameover // restart
dbatPOS_y (default y-pos of bats for gameover // restart)
ySPEED (ball speed on the y-axis)
xSPEED (ball speed on the x-axis)
bSPEED (maximum speed of the bat(s) )
-->>all in a seperate MC
bSCORE (number of bounces)
sSCORE (score)
lSCORE (level)


hope you understand all this,
and i hope im not the only one who does it, as i dont like being 'the odd one out' :confused:


:doughnut:?



jag

Squize, don't fear, you're not the only one who tests stuff after like every little change. I also save after like everything. Even if I havnt changed anything, I still save it - just a habit, with everything I work on.

Quote:

---

Originally posted by Squize
Should still be a good addition to the knowledge base though.

---

Yeah, that's what I was meaning! DOH - stupid mistake :):o

Anyway, I do have a habit, which I actually do like, that I use in every flash thing that I make. Up the top of the layer stack of the main timeline and of movieclips (that have more than 1 frame), I have two frames: actions, labels. The actions frame is up the top, and the labels frame is underneath it.

But hey, that's just me :)

Quote:

---

Originally posted by leight
Squize, don't fear, you're not the only one who tests stuff after like every little change. I also save after like everything. Even if I havnt changed anything, I still save it - just a habit, with everything I work on.

---

Yeah, same. I'll even test things while I'm half way through implementing them. It usually helps me get the logic right as I can see what's already happening and what needs to happen.

I also have a habit of saving very often, and without even making changes. I'll sometimes go as far as saving twice, because there was one time when I hit ctrl-s and thought it saved but it actually didn't, ever since I've had that habit.

I also have the habit of testing after every line of code, but because my current project is an epic, it can take up to 10 seconds to publish even on my 2.4ghz box, so I am forcing myself to write a little more code before testing.

Not to fear though... it usually works!!!...usually

:)

p.s been trying MX 2004 demo on and off and I must say I love the way it remembers your cursor pos in the code allowing you to go check something and then come back. MX simply takes you back to the top. :(

Format i usually follow:

variables
//-------
functions
//-------
other raw code

i'm terrible at commenting my code, and sometimes have to go back just to add in some comments. As for variable names, they follow general reason i have them, i usually try to stunt them a bit:

var dead = false;
var str = 10000;

things like that
i dont like having variables under 4/5 letters long unless i really have to

I save very regularly. I can't remember the last time I've hit CTRL+Enter without hitting CTRL+S first. And yes, I test/tweak my code so many times, I'm thinking of getting a foot pedal for CTRL+S/CTRL-Enter.

Strange thing is, I've taken the habit across to other applications. If I'm in notepad (my professional HTML editing tool ;)) I'll hit CTRL+S to save, and hit CTRL+Enter out of habit, expecting it to 'do' what I just wrote. I do it in SciTE|Flash too :)

Kinda silly really.

Also, I backup my entire project folder to zip file about 3-4 times a night (if I'm working on it), and dupe the backups to another drive nightly. And every week I write the whole lot to an external HD.

As you may be able to tell, I've lost source code in the past, and I do not want it happening again. The last time I lost a weeks worth of undocumented bugfixes and improvements, and didn't even open the fla for almost a year. I was properly disappointed.

On top of that, I'm stipping all the author-time content out of my game and converting (read: breaking) it to runtime, and it's extremely valuable to be able to look at how it was before I started dissecting it with my club fists of doom.

lol, when I wan't to test something I always hit Ctrl + Shift + F, Ctrl + S and Ctrl + Enter, and just like Drunk above me, I also hit this in other programs :D

I've also found myself hitting ctrl+enter on reflex when saving files on photoshop and word, and when sending email. I think it's my body trying to tell me something.

I was going to say. One huge advantage of using include files is that they can be used by more than the 1 swf, so you can build up an as folder of useful function, then just include then as and when you need.
Also, if you change that file it's changed for everything that uses it. This can be really useful. For example, I'm messing around with a tile based engine at the moment, and I have my tile definitions in tileDefinition.as and my levels in levels.as. Both files are included by the game, and the editor, so if I make a change it shows up in both. Much easier, and with less potential for little typos.

Has anyone used the file management system in MX2004? I'm really bad with backing up (Once every week or two to CD) and I was thinking about giving it a go.

Include files are great. If the ability was taken away, I'd probably cry for weeks.

I wrote an include the other day of a full 100+ character 8bit pixel font (in array form), and another script that basically just fills the dots to create letters, etc. like this

The best bit is, if I need that fancy dot text in any other project, I just include those two .as files, and call something like:

dottext("Include this!",50,200);

and BLAM! Job's a goodun.

Previously, I had to rip chunks of code and movieclips out of previous projects. And aside from the time taken, it was rather prone to bugs.

Includes and functions have improved my movies no end.

But you have to compile it again, right?

Including has the same advantages as functions, don't they :)

Quote:

---

Originally posted by drunkenmaster2000
Strange thing is, I've taken the habit across to other applications. If I'm in notepad (my professional HTML editing tool ;)) I'll hit CTRL+S to save, and hit CTRL+Enter out of habit, expecting it to 'do' what I just wrote. I do it in SciTE|Flash too :)

---

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. :(

Looking down quickly I notice that my left pinky is permanently on CTRL, with my other three fingers on Z,X,C *any* time I use my mouse.

I guess it's partly an FPS throwback (a lot of UT back in the day) and partly because I copy/paste a hell of a lot.

and make mistakes, ofc.

Or maybe I just need some sort of wierd tactile connection to my keyboard. who knows?

I think we need a good holiday :)

Yes, I frequently go Ctrl+Alt+Shift+S to save as in Photoshop :O

And now I have this awfull habit of going Alt+Tab instead of Shift+Tab!!! DOH :rolleyes:

this is going a bit off-topic...

i always comment every variable setting etc.


i have short variable names. Might use ihoss V,M,S,F idea... to stop me making daft names.

I often press ctrl-Enter as well.

Just gonna toss my two cents into the mix as I seem to be one of the only OO whores on this board. :)

My main timeline includes one frame with a bunch of initialization calls to set up certain variables (socket connections, initialize input, etc.) otherwise everything is as "logically" modularized and oriented as possible in external classes. This is the best way to have reusable maintainable code. Functions, in general, are never cut-pasted if they can instead be accessed from a single interface.

Anything that is logically separate from other entities (ie: Users versus Units versus Terrain) has a separate class.

I try to keep the visual representation of everything absolutely distinct from the logical organization.

For example: If I have a panel in game that displays information (like the Briefing Panel in Battalion) there is generally a BriefingPanel class in my battalionUI package that contains all the "logic" for organizing the briefing information. Then in my library I have a "briefingPanel" MC that implements some functions for displaying that data. Ie: So if I want to set the Briefing Panel to have a Turn Limit of 30 turns, I do something like this:

battalionUI.BriefingPanel.setTurnLimit( 30 ); // the "battalionUI." is not necessary

Inside the BriefingPanel::setTurnLimit function I generally have a reference to the movieClip instance of my graphical BriefingPanel so the call tends to invisibly fall through to calling briefingPanel_mc.setTurnLimit( 30 );

The nice thing is that this provides an insane amount of modularity and things are easily modified down the line without breaking anything. Because I have a logical interface, I don't break old code when I update the way I happen to load the briefingPanel_mc, and because the actual briefingPanel_mc implements the work, I can change the way the number 30 is displayed without needing to change anything else in the code. So, if for some reason I want to change the turn limit to be represented by a bar graph instead of a number, there is only one place I go to change it.

Might sound complicated and take a little longer to set up, but considering I change all those movie clips regularly, it sames me *tons* of time in the end.

sand858

I think I press Ctrl+Enter in every program I use. But only test movies every 20-30 minutes. There have been times where I've coded 500 lines in notepad at university (while passing the time)

Naming Convensions

The Macromedia Flash MX ActionScript editor has built-in code completion support. In order to take advantage of this, variables must be named in a specific format. The default format is to suffix the variable name with a string that indicates the variable type.

Supported suffix strings for code completion:

Code:

---

Object type            Suffix string      Example
String                _str                myString_str
Array                  _array              myArray_array
MovieClip              _mc                myMovieClip_mc
TextField              _txt                myTextField_txt
Date                  _date              myDate_date
Sound                  _sound              mySound_sound
XML                    _xml                myXML_xml
Color                  _color              myColor_color

---

Commenting

// :TODO: topic
Indicates that there is more to do here.

// :BUG: [bugid] topic
Shows a known issue here. The comment should also explain the issue and optionally give a bug ID if applicable.

// :KLUDGE:
Indicates that the following code is not elegant or does not conform to best practices. This comment alerts others to provide suggestions about how to code it differently next time.

// :TRICKY:
Notifies developers that the subsequent code has a lot of interactions. Also advises developers that they should think twice before trying to modify

Keep actions together
Whenever possible, all code should be placed in one location. This makes the code easier to find and debug. One of the primary difficulties in debugging Macromedia Flash movies is finding the code. If most of the code is placed in one frame, this problem is eliminated. Usually, the best place to put the code is on frame 1.

When large amounts of code are located in the first frame, make sure to separate sections with comments to ensure readability, as follows:

Code:

---

/*** Button Function Section ***/


/*** Variable Constants ***/

---

Avoid attaching code to Movie Clips or buttons

Don't attach code to movie clips and buttons unless it's absolutely necessary to do so. When code must be attached to a movie clip or button, only use a minimal amount of code. It's preferable to employ a function call, as follows:

Code:

---

myButton.onMouseDown = function() { _parent.doMouseDown(this); }

---

The use of the function call redirects all the functionality into the main timeline of the movie clip.

Initialization

Initialization of an application is used to set the starting state. It should be the first function call in the application. It should be the only call for initialization made in your program. All other calls should be event driven.

Code:

---

// frame 1
this.init();
function init(){
if ( this.inited != undefined )
return;
this.inited = true;
// initialization code here...

---

top stuff token, particularly the commenting tips...

Quote:

---

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. :(

---

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 :p

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?

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?

---

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.

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.

Quote:

---

Originally posted by Squize
Bad habit to get into mate ( And I don't just mean double posting ;) ).

Squize.

---

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).

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