Tricks of the Trade

Discussion and feedback on Construct 2

Post » Wed Mar 05, 2014 4:18 pm

@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.
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,583

Post » Wed Mar 05, 2014 9:19 pm

@BluePhaze - I already understood the concept from your last description, but now that you've broken it down further, man, I'm just STOKED! :D 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...
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
139
S
22
G
8
Posts: 777
Reputation: 14,830

Post » Wed Mar 05, 2014 10:44 pm

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.
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,583

Post » Wed Mar 05, 2014 11:51 pm

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...
As long as I can move left, right and fire, I'm Happy...
B
42
S
15
G
11
Posts: 655
Reputation: 12,260

Post » Thu Mar 06, 2014 2:02 am

@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.
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
139
S
22
G
8
Posts: 777
Reputation: 14,830

Post » Thu Mar 06, 2014 3:49 am

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.
B
52
S
10
G
7
Posts: 184
Reputation: 6,850

Post » Thu Mar 06, 2014 4:35 am

Yarfapet wrote: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! :D :!: :idea: :ugeek: 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! :D
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
139
S
22
G
8
Posts: 777
Reputation: 14,830

Post » Thu Mar 06, 2014 6:45 am

Here's a sorta Capx version of what I was talking about, in case anyone is interested.
You do not have the required permissions to view the files attached to this post.
B
52
S
10
G
7
Posts: 184
Reputation: 6,850

Post » Fri Mar 07, 2014 6:32 pm

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.
B
33
S
7
G
8
Posts: 312
Reputation: 8,528

Post » Fri Mar 07, 2014 8:56 pm

@Manley23 - I think I know what you mean, but would you explain what you mean by "Dummy Layouts"?
I'm seeking Narnia. Who wants to come with me! Aslan is on the move!
B
139
S
22
G
8
Posts: 777
Reputation: 14,830

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: LaDestitute and 38 guests