The official Dii games programming thread

[raspberry jam]

Then there shouldn't be any bouncing... If you did all the math correctly, that is. And check the collision in every frame.

[Alaris]

Ok, I figured out the problem, and in the process of fixing it. I fixed the bouncing at edges, now I need to fix the bouncing when moving to a new surface that is at an angle.

The problem was that I thought I was doing the intercept of a sphere with a triangle, but my sphere had missing parts. If for example, my trajectory just missed the triangle, my "sphere" would go on but a real one would hit the edge anyway.

Also, I freaked out when my game completely stopped working. Undid the code etc, nothing helped. Restarted the computer, now it's fine. Go figure.

[Alaris]

Ok, here's a puzzler.

I got the weapons working (mostly), and the jumping works too. I also got the foes to aim at where I will be if I continue moving straight (which is nice, because I need to work more than just strafe to avoid shots).

But...

I jump a lot less high if I set the maximum number of shots in the scene to 1000 than if I set it to 10. Also, I jump higher if I set the graphics details lower.

I figured out the problem, but I figured some of you might want to test your programming skills.

[Alaris]

Answer to above:

Spoiler

The problem was with the changing framerate, and how acceleration was calculated. This is a general problem with any type of acceleration (including turning rate). I subtracted a constant*dt where dt was the time since last frame, but that value was bigger if the game slowed. Because I subtracted before the movement, you could end up having smaller jumps. The same issue was present in the Descent series... so, not a noobie mistake.

Update: got shots to bounce off of walls, and almost got the "walking on walls" mechanic functioning properly.

[Alaris]

Walking on walls works. I still have to implement a second mode of it (more like Aliens) but the current mode works as intended.

Melee needs to be done... but shots work as intended, including ones with special effects like exploding, bouncing, or reacting to gravity.

I'm soon adding in effects like portals, forces like wind etc, and protective shields. A lot of the ground work for these is already implemented.

And I got the editing in-game to work ok. I can edit the walls fairly easily, but there's still a lot of work to be done there, and also to edit other stuff. It's also pretty trivial to edit stuff outside the game, like statistics for shots, in Excel.

[shawn]

Walking on walls?

It's Portal mixed with Relativity! :O

[Alaris]

And flight. Don't forget flight.

[athariel]

Kinda old reply but still.

About the framerate thingy, the dt thing can be fine, because if the frame takes longer to draw, you want to move further to keep the distance per second constant. But there's another solution, which is even better, it's called fixed timestep. It works like this: you say you want your game PHYSICS at 100 fps (render fps is irrelevant now). That means you want a physics tick every 10 ms. Then, if the frame took longer than 10 ms, eg. 30 ms, rather than updating all movements by 3x the amount (like you'd do with dt), you run the physics tick three times, 10 ms worth each. This way you won't have big jumps no matter the framerate. The drawback is that if you get a really big spike in frame length, eg. 3000ms, the physics update would run 300 times, which would slow the game even further going into downward spiral freezing the game. To prevent that you add an upper limit.

http://gafferongames.com/game-physic...your-timestep/

[Alaris]

Wow thanks for the link.

I thought about fixing the timestep (but didn't think of a good way to prevent the spiral, so abandoned it). I think I have a better solution though, even if it involves a bit more advance work, it will help long-run by being useful in other places...

Basically, I will make a function that takes position, motion, and acceleration, and updates both position and motion properly over the time difference. The math is pretty simple, I just need to do it properly.

edit:

nice, found the equation I needed off your webpage:

s = ut + 0.5at^2

That is, given a constant acceleration a, and an initial velocity u, we can work out how much distance (s) is travelled over the time t.

I'm not sure why he himself does not use this, seems simpler (and more accurate) than what he's using.

[Lensor]

Got this link in my ArenaNet google alerts, and though it might be interesting for you game developy people :)

http://altdevblogaday.com/2011/11/12...ystems-part-1/