Tricks of the Trade

One thing I've always found very useful in both C2 and CC, and something I commonly do when I code, is exploit the Event Cycle. That is writing code that take advantage of the fact that nothing gets drawn on screen until all the events are done and that said events are always executed top to bottom. For example,

If you write an event like this

Every tick set Object Y to Self.Y+8

And lower/later in the event sheet write an event like this

Every tick set Object Y to Self.Y-8

Then the player won't see anything change on screen BUT everything in between those two events will act like the object is 8 pixels lower on screen then it appears (and you can also do it with other things like disabling and re-enabling collisions, so collision events in-between ignore certain objects). This can be super useful when dealing with plugins and behaviors that have limitations like a lack of precise origin placement (Most non-sprite objects) or object picking (Custom Movement's "Push Out Solid" Command), or want objects to be in different states at different points in a tick (Like increasing enemy sizes, and thus collision areas, when dealing with their collisions against each other, but otherwise want them to be normal sized).

And of course you can turn this inside out so things on the outside (Including the player and I think behaviors) see the change and things on the inside don't.

One thing I've always found very useful in both C2 and CC, and something I commonly do when I code, is exploit the Event Cycle. That is writing code that take advantage of the fact that nothing gets drawn on screen until all the events are done and that said events are always executed top to bottom.

Aw man! That's the kinda stuff I'm looking for! That inside-the-mind-of-C2 info. I wanna know every "gear" and "cog" on the INSIDE of this 2D engine. Because I'm pretty sure I've been with the (false) understanding that events updated upon completion. For example...as soon as an event is proven true, it runs the action, when the action is done, that's it! It's out there for the player to see and interact with. But your new info is going to help me be all the more mindful of testing for bugs and setting up my events.

THANK YOU!

Here's a sorta Capx version of what I was talking about, in case anyone is interested.

I usually use a dummy layout to hold all graphics/sprites, so they don't clutter up my actual game layouts. Of course, some sprites are actually on the game layouts, but many I just place with System->Create Object. I also agree that using Groups and small amounts of comments help to keep everything organized.

— - I think I know what you mean, but would you explain what you mean by "Dummy Layouts"?

Rhindon - I just mean a layout created for nothing else than to hold a bunch of sprites/objects for me to use. I usually just call in Graphics Holder or something like that. It is really just a way for me to organize everything and keep my other layouts cleaner.

— - OH! Okay. I thought that's what you meant. Yeah, I've started using that a little more often lately, too. Just so I have objects ready to spawn if they're not initially part of the set-up. Certainly is handy.