Jump to content
  • entries
    32
  • comments
    50
  • views
    46084

Update on Non-Euclidean physics

Sign in to follow this  
CulDeVu

1693 views

Oi there!

Sorry, I haven't really been working on things as much as I have been the last couple months/weeks/things, on the non-euclidean game thingy. Finals are now over, and thus completes my first semester of college!

In other, less important news, I just reached the 1000 rep point club! I got there with slightly dishonorable means, like grinding rep in the Screenshot Saturday showdown for the last couple weeks, but I'm there! biggrin.png
https://www.gamedev.net/sm/member/175326-culdevu

So onto some real talk.

The non-euclidean prototype/thing is having some major issues with the physics. Here's a screen (again, sorry for clip art textures, I'm trying to iron out some other issues before I tackle artwork)

Screenshot 2014-12-22 16.05.52.png

See, the way everything works is kinda hack-y. Because it's hard to predict at runtime exactly how geometry in the levels will deform, given a set of distortions. And even if I did, collision normals would still be an issue, because they wouldn't be preserved. So what I do right now is I segment all edges into little line segments in the physics code, warp them separately, and then apply the physics to that.

This leads to MASSIVE amounts of edge bugs of all sorts. Getting stuck on corners is the worst. It's mitigated a lot by getting better physics culling, but it won't go away. It wouldn't be that big of a deal, but it affects jumping near vertical walls. SAT doesn't really like to play nicely when it comes to collectively deciding how much to displace an object after collision. And it's too bad, because a Minkowski difference isn't what I need right now.

And the big issue is that I can't see a way to fix it. I mean, in a normal physics platformer, you can assume that stage geometry isn't going to change, so you can batch and simplify the hell out of collision objects. However, in this prototype, nearly type of wedge-star-pentadecahedragon is possible, so taking shortcuts and cutting corners to fix edge bugs isn't acceptable, and would probably break the game in many ways.

Oh well. I'll have to think on it some more. Maybe I could try to pre-predict what vertices will be distorted, and only segment those. That would get rid of almost all the edge and corner bugs.

Or, I could always ditch this project and work on, say, a space combat game. They look fun to make! biggrin.png

But I'm probably not going to.

No video this time, unfortunately. I'm in the middle of installing a lot of software onto my new laptop right now, so I'll probably have a video next time!

Cheers!
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!