Bad processing is good for cheating?

Discussion and feedback on Construct 2

Post » Sat Jun 23, 2012 10:41 pm

Well, this is not a bug so I came to comment it here.

My game is coming along pretty good so far, I'm learning a lot of stuff and having tons of fun while I'm at it but I've noticed that even though most of the time it works great, when I'm doing lots of things (shooting a lot, playing music and having lots of movement at once on the layout, etc) the game kinda skips events like "set gravity to 3878789 when this happens on the air" and then my character can almost fly instead of just jumping...

Is there a way to prevent this kinda thing from happening? Or the way would be to ask the gamers to not do anything else while playing and to buy new super computers? :(

I don't want people with slow computers to be able to cheat through the whole game... -___-

Thanks in advance to whoever gives some advice :P
Later!
B
43
S
14
G
8
Posts: 47
Reputation: 7,556

Post » Sun Jun 24, 2012 12:02 am

I don't think events "skip", only thing I can think of, is the classic fail to detect collision, due to the sprite moving by steps when lagging. What you can do is use Delta-Time to account for the framerate drops when setting things such as movement speed of a sprite.
B
83
S
21
G
15
Posts: 1,039
Reputation: 15,134

Post » Sun Jun 24, 2012 2:35 am

Events don't skip.
Using timedelta is actually the cause of most failed collisions. Using frame based logic will slow down the game when it lags, as opposed to moving the objects further when the frame rate is low. What you have to do to stop collisions from failing is run a loop which steps the objects 1 pixel at a time and checks for collisions incrementally during the loop. For example, if an object is going to move 100 pixels on the x axis this frame, you must run a loop from 1 to 100, and move the object one pixel at a time, and check for collisions after every 1 pixel movement. The loop can also be less accurate (a fixed number of steps moving the object a percentage of it`s required distance each iteration, as opposed to 1 pixel per step), which saves cpu time. This stepping method is how many behaviors work.
B
25
S
3
G
6
Posts: 1,197
Reputation: 5,620

Post » Sun Jun 24, 2012 3:32 am

Sorry, maybe I explained myself incorrectly. Events don't "skip" as in "they didn't happen", they just take longer to happen, eventually the player will descend, it will just take a long time to do so, and in that time you can jump over big obstacles that you were intended to tackle in a different manner. This is a problem with the platform behavior and the "key is down" condition, as far as I can tell... can this still be resolved with the methods mentioned above? :S
B
43
S
14
G
8
Posts: 47
Reputation: 7,556

Post » Sun Jun 24, 2012 4:59 am

Yes. Let's say the player moves 10 pixels each tick to the left. That's at 60 fps. Now let's say the frame rate drops to 30, that means he will be walking 50% slower, because the event will only run 30 times each second instead of 60. To counter that, you multiply the speed by delta-time, which will be low if the fps is high, and high if the fps is low, bringing consistency to the game.
I was supposed to have linked this tutorial in my previous post, but I got it wrong
Not to forget you can't expect the game to run the same way at say, 20 fps. If it's that low you can say the game is unplayable7Soul2012-06-24 06:51:13
B
83
S
21
G
15
Posts: 1,039
Reputation: 15,134

Post » Sun Jun 24, 2012 5:37 am

.__. all right, thanks for the answer but... XD the link brings me back here... you're just teasing me ;__;
B
43
S
14
G
8
Posts: 47
Reputation: 7,556

Post » Sun Jun 24, 2012 6:51 am

Oh I see, I cant use "" in the link. Fixed now
B
83
S
21
G
15
Posts: 1,039
Reputation: 15,134

Post » Sun Jun 24, 2012 7:48 am

All right! thanks, man! I'll check it out right away!
B
43
S
14
G
8
Posts: 47
Reputation: 7,556


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 15 guests