Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Bug fixes have never felt so good.

Sign in to follow this  


Skirmish Online

Today marks the day that two of the big bugs that have plagued me throughout the majority of development -- you know, those annoying vague ones that leave you scratching your head wondering how you'll ever solve them -- have been fixed. While it's not a giant step towards v0.04's completion, it both makes the game more stable, and makes me feel infinitely more relieved. I can sleep easy tonight, that's for sure. :)

Bug 1: The player's velocity is governed by two variables, an X velocity and a Y velocity. Rather simple, but since I checked for each velocity to be within a range seperately, it was possible to move diagonally faster than horizontally or vertically. That is, if the max X/Y velocity is, say, 10, then you could move horizontally (10,0), or diagonally (10,10). When you do the math you see that diagonally is considerably faster! This was solved just a couple of days after our unit on Vectors began in my Discrete Math/Geometry course. I realized, "Duh! This is a vector! I should judge overall speed by magnitude! Doh!".

Bug 2: This was the killer, which I actually just recently posted in the Math forum about. Essentially, my frame-independant motion code was fudged. One of my testers who ran the game at about 25FPS (rather than the ideal 60FPS) has been able to move faster than everyone else since nearly the beginning. It's been quite annoying as he was able to defeat all of us with ease. Now I update the game 60 times per second irregardless of the framerate. For example, at 60FPS I update logic, then draw. For 30FPS I'd update logic twice, then draw. This way the logic rate stays consistant with everyone else's.

Sure the fixes sound simple now that I've already implemented them, but darnit I know that the rest of you developers can empathize. :)

Next up on the Roadmap is Tools. Tools are items like grenades, mines, melee weapons, and the like. Explosions are definitely an area I'm going to have fun with!
Sign in to follow this  


Recommended Comments

So how many times will you update at 17 frames per second?

(There's a point to this question, honest [smile])

Share this comment

Link to comment
You'll notice that all of my games so far suffer from Bug #1; I still have to fix that problem for Glow before the next Windows beta of it. [grin]

Share this comment

Link to comment
@Apoch: ~3.5 logic updates per second at 17FPS. Each frame it would add ~3.5 to the update counter, and perform the floor(update_cntr) number of updates, and leave any decimals left in the counter, so you aren't getting jipped on the total number of updates per second.

Share this comment

Link to comment
Glad those bugs are fixed. :D And the shot gun fix is great to. You don't know how glad I am. :D Once friday is over I'm free to draw again! :D

Share this comment

Link to comment
Cool. That means there's still a very gremlinish bug I can use to do things like QuakeIII-style bunnyhopping and wipe the floor with everyone. All I have to do is lock my framerate at a specific "magic number" that leaves a fractional update missing, and I can get a lot of updates "lost" in the realm of fractions. Then, when I want to go into ultra-fast mode, I flip a hotkey that locks to a different framerate and clears out the backlog of updates. Voila, I move fractionally faster than I should be able to, including gunfire if your update loop handles rate-of-fire logic.

It's a far more subtle bug than before, to be sure. It is definitely harder to exploit (I'd have to do some brain-hurting math to figure out the magic framerate to abuse this with). But there's still a chance it might cause rogue "glitches" even without the element of malicious intent to make things interesting.

True framerate-independent movement is done based on time elapsed since the last update, and will always stay in sync regardless of how long it has been. If something is moving at 2 m/s, and 0.3 seconds have elapsed, then it's moved 2 * 0.3 = 0.6m. That way you totally escape the possibility of framerate-related glitches, which are especially bad to have lurking around in a network-centered game.

Your solution will certainly work, and given sufficiently powerful hardware, should not cause any real problems in the long run - but you never know. Some really weird stuff can happen with framerate-dependent behavior. Just a heads-up [smile]

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!