As I am tossing ideas at construct when they strike me, I end up recreating the same event chains over and over again (adjusting old prototypes and rebuilding them). At this point I think it might be better to have a custom behavior to implement this movement to

a) save time

b) save events

c) keep the event code clean

I had a look at rexrainbow 's 8wayMP Behavior to see if I was able to build a custom version of his custom version to support the grid movement I want for some of my games / prototypes. I was about to jump into randomly changing parts of the js code when a thought struck me...

What about performance?

I know that in web development implementing the wrong js plugin, carelessly using jquery selectors (in loops) and stuff happen to have a large impact of performance. On the other hand, all events generate js code anyway (optimized, I am shure. Thanks Ashley).

What are your experiences when working with custom behaviors vs. events. I plan to switch to the paid version soon so the number of events isn't a factor for me (or won't be soon). Should I wait and stick to events or would it be better to try and build a movement behavior (or hope that someone else creates one)?

MC

What about PlayMobi from AppMobi{!} ?

I like what I read on their homepage and the API seems to be pretty solid from what I read. There's ongoing communication between Scirra and appMobi (for exporter functions if I recall correctly) so implementing playMobi would be a double win.

rexrainbow & Velojet ?

Works like a charm. I just tested your CAPX and implemented the changes in my game.

Thanks alot!

1) Thanks a lot! I'll have to learn all expressions and stuff, it will help me alot along the way.

2a) Thats an elegant way. I like it! I'll only change the angle to something like this to get rid of negative angles

(angle(0, 0, joyx, joyY)+360)%360

2b) This is the part where I'm still unsure. I had a look at your capx on a friends computer.

Set DistanceToMove to 16*distance(0,0,self.joyx,self.joyY)

I added a bunch of 32*32 sprites to your example like a chessboard. When I start moving around, the player sprite looses his position within the grid and ends up a bit off the grid cell he should end his movement. Happens both with straight as well as diagonal movement. Maybe there is some weird rounding error or it has to do with the movement itself (100*dt)?

I would upload your modified capx from you but I don't have access to my dropbox from this pc.

By the way: I changed the value to 16 because my Player has a height of 16 and a width of 32. All objects snap to a 16*16 grid but may vary in size (using steps of 16). My collision handling is doing well so far.

I checked with your original capx but the movement is still a bit off.

Thanks for your help so far. Now it's only the DistanceToMove that I have to get right.

/* edit: changed title */

I think mentioning math in the title might turn some people away...

/* edit: changed title */

Hi,

I'm currently toying around with ideas to calculate movement input and create movement functions (using Rex' function plugin).

(I can't post a cap right now as I'm on the go and can't access my pc for a while.)

Question 1

I have a LineOfSight for my Moving OBjects that connects to possible targets. In my current solution I check the angle of the LOS and use a switch case to determine the next movement (on a tiled grid with grid movement).

The move function is the same for my player MOB as well as NPC MOBs.

some pseudo code for my current 4way movement

switch LOS.angle

• case angle > 315 & angle < 45
• => call function(move, right, {distance})
• case angle > 45 and angle < 135
• => call function(move, down, {distance})

and so on...

As the move function translates right and down into the correct angle again, it would be easier to call the function with the correct value. I'm working with grid movement, so there are only 8 valid angles. I need a formula that takes the LOS angle and "snaps" it to the nearest valid angle for movement.

Is there a way to get this behaviour:

x = input -> output

x = 00.0 ->   0

x < 22.5 ->   0

x >= 22.5 -> 45

x = 45.0 -> 45

x < 67.5 -> 45

x >= 67.5 -> 90

x = 90.0 -> 90

...

I've seen formulas with ((X*Y)+Z)/N or something like that but except for the one time I copied a formula (i didn't understand but that magically worked anyway) I never worked with those in C2. It would save me a lot of events for my movement logic, when going from 4way to 8way movement.

Question 2a

I'm currently using 5 events to get the user input for movement (4way).

When enabling 8way movement, I'd need at least 9 events

some pseudo code for my future 8way movement

left pressed

• => set parameter movementAngle to 180
• => set parameter movementDistance to 16
• down pressed
• - => set parameter movementAngle to 135
• - => set parameter movementDistance to 22
• up pressed
• - => set parameter movementAngle to 215
• - => set parameter movementDistance to 22

right pressed

• => set parameter movementAngle to 0
• => set parameter movementDistance to 16
• down pressed
• - => set parameter movementAngle to 45
• - => set parameter movementDistance to 22
• up pressed
• - => set parameter movementAngle to 315
• - => set parameter movementDistance to 22

down pressed

• => set parameter movementAngle to 90
• => set parameter movementDistance to 16

up pressed

• => set parameter movementAngle to 270
• => set parameter movementDistance to 16

NOT up pressed

NOT down pressed

NOT right pressed

NOT left pressed

MOB.DistanceToMove = 0

• => idle stuff

Is there a way to simplify this?

Question 2b

For my 4way grid movement, I'm using the following

some pseudo code for my current 4way movement

MOB.DistanceToMove > 0

• => MobSprite: Set animation to MOB.MobType & "Walking"
• => MOB: Move 100*dt pixels at angle MOB.AngleToMove
• => MOB: Substract 100*dt from DistanceToMove

MOB.DistanceToMove < 0

• => MOB: Move 100*dt pixels at angle MOB.AngleToMove
• => MOB: Set DistanceToMove to 0

MOB.DistanceToMove = 0

• => MobSprite: Set animation to MOB.MobType & "Default"

As I'm using a 16 pixel grid, I simply set the MOB.DistanceToMove to 16 and I'm fine. If I implement 8way movement now, I don't know exactly what DistanceToMove I have to use. Pythagoras tells me it should be 22.62741699..... I think that might lead to problems on the long run. <img src="smileys/smiley2.gif" border="0" align="middle" />

I appreciate any help I can get that leads to cleaner code and less events. I'll be at my home pc again in 2 days, I'll add a capx then in case there's no good solution by then but judging from the stuff I read here, there ought to be someone smart enough to help me.

Pretty please? <img src="smileys/smiley9.gif" border="0" align="middle" />

Would it be possible to pause the game and load another c2 game inside the div?

Construct2Ception...

Main Game

-> div with Character Creation / Development Game

-> upload to roar, playmobi or whatever

-> close and back to main game

-> refresh data via ajax from roar, playmobi etc