Bad processing is good for cheating?

0 favourites
  • 8 posts
  • 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!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

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

  • 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

  • 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 unplayable

  • .__. all right, thanks for the answer but... XD the link brings me back here... you're just teasing me ;__;

  • Oh I see, I cant use "" in the link. Fixed now

  • All right! thanks, man! I'll check it out right away!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)