Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make missiles not collide unless z is similar #52

Closed
nwinter opened this issue Jan 3, 2014 · 5 comments
Closed

Make missiles not collide unless z is similar #52

nwinter opened this issue Jan 3, 2014 · 5 comments

Comments

@nwinter
Copy link
Contributor

nwinter commented Jan 3, 2014

Our Collision System currently lets Thangs with collision category ground_and_air collide with each other. This means that missiles like Arrows and Spears will knock each other out of the air. This is pretty cool sometimes, but most of the time it doesn't make sense. (Or if they don't collide, it's because I turned it off somewhere I'm not seeing--we don't have a lot of arrow-heavy levels right now, so I haven't double-checked.)

Collision detection in CodeCombat is handled by Box2D, which as one might guess only does collisions in two dimensions--the x- and y-dimensions. CodeCombat wants just about all of the gameplay logic to stay two-dimensional, since for most programming environments, it just makes more sense and it is simpler for gameplay. Our graphics are 2.5D to make things look better. Our positions and shapes are actually 3D, but in most cases we don't determine behavior from the z-dimension.

I think in this case we should, since when there's a rain of missiles, they all bounce off of each other whenever their shadows would touch. If two Thangs are firing at each other at nearly the same time, then this always happens, and sometimes they can never kill each other! It's kind of funny if two identical units are shooting each other's arrows out of the air by firing at the same instant and angle and speed, but if an Arrow Tower is going up against a Fangrider, those trajectories are totally different and shouldn't result in a collision.

Since Box2D can't natively handle z, we'll have to reach in and use its ContactListener PreSolve to stop the collision if the z distances don't touch. I hope this will work. Perhaps if not, we can resort to another more clever or more hacky way to do it.

We would modify the Collision System from within the level editor, and perhaps work with or look at the collision.Collides Component, the combat.Arrow Component, and the CollisionCategory class remnant.

@nwinter
Copy link
Contributor Author

nwinter commented Jan 31, 2014

@sderickson We'll need this soon to make archer vs. thrower battles work. Either of us could dig into it, but it'd also be a nice Archmage task if anyone felt so inclined, so keep your eye out for someone who likes missile collisions.

@nwinter
Copy link
Contributor Author

nwinter commented Mar 12, 2014

I made missiles never collide with each other a while back until we can figure out the z-index collision stuff properly.

@bhargavvader
Copy link

@nwinter , how did you do it? Does the collision problem still happen? I think I may have a solution.

@nwinter
Copy link
Contributor Author

nwinter commented Sep 30, 2014

I just set the ground_and_air_humans and ground_and_air_ogres collision categories to not collide with each other in the Collision System and Component. I want them to collide with each other, but to dynamically check and cancel certain collisions in the collision contact listener.

@nwinter
Copy link
Contributor Author

nwinter commented Apr 10, 2015

Now that I think about it, it would mess up a bunch of things with the game balance to make similar-z-height missiles collide now, and be less performant, so let's just not–no shooting missiles out of the air, and no standoff duels.

@nwinter nwinter closed this as completed Apr 10, 2015
MichaelRevell added a commit to MichaelRevell/codecombat that referenced this issue Jul 27, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants