About following good programming practices in Construct 2 Part 1: Encapsulation

Why should you learn good programming practices when using a graphical "game maker" type interface that boasts you can "make games without coding."   Because the boast is a lie.  If you do anything much more complex than the most basic demo, You ARE coding.  It really "holds your hand" as far a coding interfaces go, but there's no mistaking it.  Before you know it, coding is going on.

If you had the patience to watch my bungling 24 minute Construct 2 first attempt at a "Tutorial," you'll know I love using groups.

I love groups and I want to marry them.

Here's my event sheet for the main game layout in Captain Zero (where all the real action happens) so far --that's right I'm letting everyone see my source code!:

See it's all there!   Grouping your code not only makes it really easy to read and isolate different parts, but the ability to turn off or on a group makes them act like sort of asynchronous methods  --which are sometimes more clumsy to make in traditional languages.

It's a method that keeps happening until you tell it to stop instead of terminating at the end of it... unless you tell it to stop at the end of it --which you can in which case its just like a method.

Here... I'll open up the "Star" Group and you can see the events in it...

What the heck?  More groups!  Because all the effect events associated with the star are in the Star group, I can turn off that whole group if the star is behind something or off the screen and turn it back on when it's back in view.  When it's all in one place you can keep it under control.  This is the heart of what computer science calls the rule of "Encapsulation."

One of the first rules in Object Oriented Programming is the rule of encapsulation.  It's normally talked about in terms of Object Oriented Programming, but it's really a larger concept that should be remembered in procedural programming as well.  Since Construct 2 is very object oriented in most ways you want to pay attention to following the rules of encapsulation.

People often include the concept of "information hiding" (i.e. public and private variables etc.)  when talking about encapsulation, but that's not what it's really about.  restriction does help enforce encapsulation but really all encapsulation is, is keeping data and functionality bundled together and all in one spot for one thing.

I don't, for example spread events that affect the star all over the event sheets or have other events affect the star except in a very controlled way.

They can either turn the whole thing off or whole thing on.  No where in the fighter events for example, can you change the disposition of the star's lense flare... because the star's lense flare is the star's job and the section of code dedicated to the star should handle it.   And that's the real spirit of encapsulation.

"AYE AM THE SPIRIT OF ENCAPSULATION!"

Turns out the spirit of encapsulation is kinda creepy at first, but you get used to it.