Code organization for large projects

[starvingindie]

There isn't a shortage of games that inspire me within the community. I'd love to make a game on the scale of Not A Hero, Concrete Jungle, Fistful of Gun, Rock Rock Rocket, The Escapists, and the countless other amazing projects that are out there. My question is:

What are some general best practices for organizing your events for large projects? I've been making a lot of prototypes and practicing everyday, but right around the 75 - 100 lines of code I start to lose track of what's going on. I'm using groups and comments to guide me along the way, but it still feels like it gets out of hand.

I've heard some say everything should be in Fast Loops or Groups shouldn't be longer than 5-10 lines of code, but I'm not sure what's good advice vs. personal preference. If you've worked or are currently working on a large scale project, I'd love to hear your approach to managing your code. Also, is there any form of Version Control for Clickteam projects? If not, how do you manage your project without a dedicated version control system?

Thanks Clickers!

[Klownzilla]

I have groups with several hundreds of lines and it works perfect! Inserting a comment here and there can help you as well :-)

[Klownzilla]

Pressed send too soon :-D i have several scenes in one 1024*768 frame and all rooms are contained in groups...so a variable decides which room/group to load...the beauty with that is that the same objects you have in the frame can have multiple uses...one active picture can serve as the background object for every frame...i'm just loading different graphics :-)

[King_Cool]

Some of the biggest projects ive worked on ( see my signature) is maybe at 3000 Events, and i can definitively relate to your remark about conFusion ( )

"I've heard some say everything should be in Fast Loops"
^ This is bullocks, avoid Fastloop whenever you can. The more fastLoops you use, the slower your App potentially becomes

"Groups shouldn't be longer than 5-10 lines of code"
^ This statement doesnt make any sense, of cource you can have as may Events as you wish in Groups

...
Organize your code. This will come automatically by following below advice.

MY #1 ADVICE
Comment Evenrything!!!
- Not nessesarily every single Event, but to the degree you are able to quickly navigate your code and identify the structure and purpuse of the code
- Color the background of your Comments, and personalize it to your liking ( bold text, text size etc ) so it stands out and you ar comfortable looking at it
- Create sub-comments 'within' Comment sections ( where applicable ) for better organization and overview. Have sub-Comments be of a 'lighter' color than the main comments, like a hiarchy ( look at any of my examples for an...example )

MY #2 ADVICE
- Create a Comments at the very top of the Event Editor, 'explaning what each Objects Flag is or does' ( preferably using a special bg color etc ). Sounds silly maybe, but if comming back to an old project where this is not done, the though of giving up or starting over will shortly enter your mind ( effect amplified, more or less, by the number of Flags your using ). Looking at a bunch of code with Flags you have no idea whats doing is highly demotivating, and time consuming if your gonna delv into the code to understand what they do all over again.

MY #3 ADVICE
- Dont take shortcuts and dont give up, untill its very clear you aught to do so or have to take a shortcut



Another piece of advice, i wont emphasize this as much as the above but its good that you know this, is to split your code into Groups and activate/ deactivate Groups as they are needed.
Let me explain:

Say the code for your Level is about 2000 lines, and the code for the Boss ( at the end of the Level ) is about 1000 lines.
^ From beginning to end, your App will run through 3000 lines of code every frame

Say you put the Boss code in a Group, and only activate the Group as you encounter the Boss.
^ App will only run 2000 lines of code untill it reaches the end of level
( note that the number of code-lines above are only examles to get the point across )

I wont impose any further guidelines about this, as its up to you and the specific project to take advantage of this however you want, if you want or need to.
The point is... by activating and deactivating Groups in this manner you gain a processing/ speed advantage ( avoiding potential slowdown/ frame dropps ). If your project/ Application is very small, this advantage might be negligible.

And off cource, this community is a gold mine

[starvingindie]

King_Cool, this is all great advice, thank you so much. I think being less lazy with my commenting will probably go a long way in making sure I know what's going on. @Klownzilla, it never occurred to me to try creating multiple levels in a frame through activating/deactivating groups. I'm going to have to try this too.

[PBarwick]

My first method is to use groups hierarchically as much as possible so it's easy to collapse whatever is not relevant to what you are currently doing.

I'm not in agreement to what was said above about fastloops, as far as I can tell the overhead is minimal - and what's more you can design them to run like functions which makes them fantastically useful.

This goes hand in hand with my second main principle - do not duplicate *any* code. Copy and pasting some code to apply it to a different object the same way only means that if you need to edit something, you need to edit it twice. It means that if it needs to happen more than once, you're wasting time in the future debugging the same thing over and over.

My simple solution - make it a fast loop. If the event needs to be called twice - then you can just call it twice! Don't duplicate events!

[UltimateWalrus]

I agree with most of King_Cool's advice, but couldn't disagree more about the fastloops. First of all --- though they may have been slower at first, Clickteam has optimized the hell out of fastloops to make them go as fast as possible. Secondly, as far as I'm concerned, premature optimization is the root of all evil. If you are avoiding something that vastly simplifies coding and makes it cleaner and more maintainable, because you're afraid it might slow down your game a bit, you are sabotaging your own code base, and it you will eventually have to deal with bugginess/slowness because of how chaotic your codebase is. That's the irony of trying to optimize prematurely --- unless you are coding a well-trodden algorithm whose performance concerns are widely understood (e.g. quadtree collision detection), there is no way for even the most experienced programmers to guess ahead of time what random sections of code are going to cause problems.

Clean, maintainable code is easy to optimize, so why not write good code first and foremost, and optimize later?

[CeriJC]

My first method is to use groups hierarchically as much as possible so it's easy to collapse whatever is not relevant to what you are currently doing.

Agreed; when thinking up a set of related actions (EG, Player hit by bullet, reduce player's health, if health is 0 then die and drop items), I always put these under a single heading, for example "Dealing with player being hit". If nothing else, it makes it quicker to collapse and more legible. Where it gets even more useful is where you can make the enabling/disabling events (which is a great practice, but very time consuming and easy to do wrong if you don't approach it in a structured way) just disable the 'top level' group, rather than each of the sub groups. Of course, you can't always do this. So, in order to make it more legible, I have a comment (in a particular comment) at the top of each group and sub-group that details whether this is "self-disabling" or not.

It's one of those things that slows you down writing the code, but it saves so much time when bug-fixing or revisiting old code that overall it saves you time.

[King_Cool]

My advice about avoiding FastLoops was kept short to not be confusing or unessesarily complicate things.
And i cant dismiss the notion the FastLoops are now vastly faster than in the past either.

@UltimateWalrus ( ...or based of UltimateWalrus' post )
"If you are avoiding something that vastly simplifies coding and makes it cleaner and more maintainable..."
^ This part of your sentance explains my position on fastloops very well. All i am saying is dont throw FastLoops about like its candy.
Many functions that dont require fastLoops can be solved by using fastLoops, and if getting locked into the fastLoop mentallity ( using fastloops for everything ) youll miss the easier methods to achieve your goal/s. One might argue it doesnt mater due to the optimization of fastLoops, but i would argue that it potentially could or at the very least could make one miss other solution that are simpler and easier.

For example, when adressing the issues of 'Pairing Objects' or 'Pushing Object out of defined Obstacles' fastLoops maybe spring to mind by defaut, but theese methods could and can be solved without Spreading Ids and running loops ( through summoning a handfull of Events ).

My 'hidden' point in my advice about avoiding fastLoops is that, by using fastLoops only when you have to you will automatically learn where they are best usefull and where they would be unessesarily cumbersome in contrast, as opposed to using them to overcome any obstacle you encouter ( where using fastLoops would be applicable ).

[cosmos]

I agree with everything king_cool said. Not everything needs a fast loop, and on mobile devices if fastloops are used excessively it can slow things down. But in the end its all about how you use fast loops and optimization.