Tricks of the Trade

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

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

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.

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

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.

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?

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

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_'.

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

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?

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

Rhindon Exactly, I have had some cases for example where I want to know if a person jumped. While the built in events have a detection method to tell if jumping, it is really just looking for the sprite moving upwards. Which also means at the apex of the jump it stops counting as jump as you start your descent. There is also the on floor event which you can invert to test if they are in the air, but that isn't the same, falling off something would also trigger that. So I created a variable isJumping and when they jump I set it to true. When they land I set it back to false. The beauty of this is that I can now differentiate between actually jumping, or falling off of something or being launched out of something. As the latter two events would not trigger the isJumping to true. This can be very useful especially in a game where you need to keep track of the exact state a sprite is in. In my case certain moves or abilities or actions should only take place if the person actually jumped as opposed to falling off an object.

This is just one small example but you can see from it that it can make really complex logic much easier to implement. It also simplifies my events so that instead of saying if the player did A, B, and D but not C the do something. Instead I just say if isJumping is true do this... Since I track all the important states with variables, I can also use those variables as conditions for other events. It is now easy to put a test for isJumping into any of my other events/conditions if they should not be enabled when a jump is occurring, or if they should only be enabled when a jump is occurring. You can also take this further and use your state variables to enable and disable groups as needed.

BluePhaze - I already understood the concept from your last description, but now that you've broken it down further, man, I'm just STOKED! That reasoning is beautiful and I'm going to start doing that from now on, too.

On one hand, it might seem like overkill, especially when C2 has similar/the same events/actions already built-in. But as you said, there are precise states/actions that an object can be in that C2 doesn't have a account for. I think the trick will be, first of all, to be clear in one's own mind as to what those states are compared to any other state it can be in...isJumping vs isNotOnFloor vs isFalling vs walkedOffLedge...

The best way I have found for doing that is writing out a sentence that describes what the player should be able to do. It may seem like extra work, but you would be surprised at how much easier it is to put together conditions in C2 when you have a statement written out already C2's visual event system is a natural extension of how we normally think about things. If you can't state what you want to happen in a sentence, chances are you are going to have issues trying to get it to happen in C2.

I second what bluephaze is recommending, with good use of variables and events alone, you can create virtually any game mechanic, Using no plug ins.

Boolean's seem over used as you are locking your variable to only two states, when an instance variable can be that, plus more...

pixel perfick - Aye. I only use Boolean when I know that I only need two different states to check. That way alternate, unwanted values can't get accidentally added.