Tricks of the Trade

Discussion and feedback on Construct 2

Post » Mon Mar 03, 2014 8:45 pm

Any programmer knows that you can accomplish the EXACT SAME result using virtually any variation of commands. Some will use the smallest number of commands, others will use more. Some will rely on variables, others will refer directly to properties of a given object. Nuances aside, of course...

The more I learn about programming - and especially while learning to use C2 - I'm discovering new (and often better) ways to accomplish the ends I have in mind. As you have learned your craft/hobby in programming (again, particularly with using C2), what have you found to be most helpful? If you could pass on a helpful hint, behind-the-scenes information on how C2 works, a QUICK tutorial...you name it...what would it be?

Be as precise and descriptive as you can be. Short of being too wordy (that's a fault of mine) how would you describe your ways of programming? Name an instance where you helped a newer C2izen (C2 + citizen) learn how to use C2 effectively. What works best for you in organizing your events? Such as organizing variables, groups, and so on. Do you find the Comment line helpful?

Go to town, people!
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
139
S
22
G
8
Posts: 774
Reputation: 14,822

Post » Mon Mar 03, 2014 9:36 pm

I'm pretty new at this but since I hate coding and despite of that I picked up something useful from object oriented programming class we had years back...

And that is... to group functions as entities. :) I accomplish this by using comments on my C2 events.

I also use global variable rather excessively since I use them very often to trigger events. I rarely have used local variables, however using local variables for hitpoints on an object was a great idea - since there could be more than one of the same object spawned and they would then have their own hit points.

So try to organize the events you have into groups that handle a specific function, for example spawning enemies, collision with objects, user input, game victory/lose conditions and so forth.

Also... if you ever duplicate your layout and want those objects to act differently than on the previous or other layouts... rename those objects so that if you modify their behaviour they won't get broken in the layout that it was copied from.
B
4
Posts: 26
Reputation: 250

Post » Tue Mar 04, 2014 1:03 am

@Mancini - Great points.
I actually started using Comment lines to group my events, too. Now I'm starting to use Groups more often with comments for more intimate detail. But using Comments surely does work.

When you're using local variables for specific objects, why not use instance variables, instead? Can you explain on that further?aaa
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
139
S
22
G
8
Posts: 774
Reputation: 14,822

Post » Tue Mar 04, 2014 4:04 am

Group objects into families. This helps a LOT! For example in one of my games I had a lot of different types of terrain (Desert, Volcanic, Jungle, Ice...) and I needed to allow for wall sliding and other behaviors to occur on most wall types, but not on Ice. So I created a family called SlideWalls and put them all in it, except for the ice tiles. Now in my logic I no longer have to test for each type of wall, it automatically works for any wall type that is added to the family. The same type of logic carries to enemies, bullets, hazards, etc... anything with similar behaviors or similar events should be grouped in families to simplify your logic. It really reduces the amount of redundancy in your events. And remember that objects can belong to more than one family. For example I have some enemies that can be shot and some enemies that can be jumped on. So I have a family for each, but some enemies fall into both categories so instead of doing special logic for those ones, I just add them to both families.

The other major tip I have is to use variables to track the state of just about everything. For example in my logic I have some pretty crazy tests that have to be done as certain moves can't be done when wall sliding, or when bouncing off a bounce pad, etc... so I create variables to track each of these "states". isWallSliding, isBouncing, etc... that way when I have to check if they can do a certain move, etc... I just test to see what state they are currently in. This allows for much more complex interactions without having to add a ton of extra logic, you use variable to track the state of objects that you may need to test for in your logic. By thinking ahead a bit you can make things much easier on yourself this way.
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,583

Post » Tue Mar 04, 2014 10:49 am

Rhindon wrote:When you're using local variables for specific objects, why not use instance variables, instead? Can you explain on that further?aaa


My bad... I meant to say I use instance variables :D

And like BluePhaze pointed out, tracking with variables is the thing - I do the same to trigger events or enable/disable stuff.

I haven't tried that families thing yet - if there's a good tutorial somewhere, please link it here.
B
4
Posts: 26
Reputation: 250

Post » Wed Mar 05, 2014 4:29 am

@BluePhaze - I'm trying to become more adept at using Families. Just when I think I've got them "fully" understood, I find a bug related to them. LOL But yeah, I definitely need to use the more often. Families and Functions.......I "hate" Functions right now.

@Mancini & BluePhaze - I do use instance variables for things like that. But perhaps not enough.
Do you guys think a variable name can be TOO long? I mean, if it helps describe the variable at a glance... How do you go about naming your variables?
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
139
S
22
G
8
Posts: 774
Reputation: 14,822

Post » Wed Mar 05, 2014 6:04 am

@Rhindon .. Quick answer: I think most (if not all) of my variables are below 20 characters/numers/special characters long.

Long answer:

I usually keep them short and sweet.. but I won't make them garbled or too short... Because I want to find those variables and know with a glance what they are used for :) For example if I'm making some portion of a game with variables today and I come back to that portion a week or two later, I want to know what I was doing earlier and not spend time figuring out what I was thinking back then. :D

Not totally sure of how C2 internals function but at least I know this: renaming objects in canvas view updates them in events too. So I would say with some confidence that the same goes for renaming variables. Why is this relevant? Weeeeeeeell - you can use as long variable names (and object names) as you wish during development but when you are ready to publish I would suggest to saving your project under another name for safekeeping and then rename all those long variable names and object names to something shorter (or making them incoherent for fear of pirates).

For example I do use some systematic things for my objects and their related (global) variables (I use 'score' for both object and variable names) and all my enemies start with 'enemy_' and spawning is done with spawn boxes that are beginning with(surprise surprise) 'spawner_'.
B
4
Posts: 26
Reputation: 250

Post » Wed Mar 05, 2014 7:16 am

The point of variables is for YOU to easily tell what it is for. I keep them short and abbreviate where possible because I don't have to worry about anyone else ever seeing them. So I make them short, but also very logical. Like: playHealth, isPaused, isWallSlide, etc...
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,583

Post » Wed Mar 05, 2014 8:32 am

@Mancini - I actually use the same method for naming similar objects... the objects associated with each other "Enemy[this]" and "Enemy[that]"... Keeps them all together in my object bar.

@BluePhaze - I really like the idea of using variables as their own events checkers. I assume you find that expands on what C2 can do as far as available pre-made events/actions?
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
139
S
22
G
8
Posts: 774
Reputation: 14,822

Post » Wed Mar 05, 2014 10:34 am

Mostly: I program in a waythat is oriented towards quick edition, I put stuff that are not needed every time inside groups to deactivate them, I use functions a lot, I love local constants (since it can help edit quickly while knowing what you are doing)

In most: organisation, keep your project clear, easy to read, to understand, but It should not be something that you force yourself to, it should become slowly but surely a natural way of programming, I can have a C2 base of 50 events just for organisation's sake (as a reminder, C2 counts variables, includes, groups, etc.. as events), functions are great with a descriptive name, for 3 things IMO:

-isolate some tricky events
-be more clear with less repetition (if your ennemy spawnage is create ennemy, then set it's angle, then set it's basic values, I am pretty sure It'll be clearer to say : Call function "Spawn" (Self.UID,..)
-do mathematic calculation (using the Function.Call() expression, Function.Call() will take the value of the Returned value of the function)

I've constated that the easier it is to read, the easier it is to edit, and to optimise
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 6 guests