Timeline for How can I predict player-to-projectile collisions in Box2D?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 2, 2014 at 14:57 | answer | added | Tom 'Blue' Piddock | timeline score: 2 | |
| Jul 2, 2014 at 5:59 | comment | added | NauticalMile | No problem. Glad I could help. | |
| Jul 1, 2014 at 19:32 | comment | added | Arch1tect | (2/2)@NauticalMile wait..I think I can grab the speed of the stone and setup a threshold about speed, so if the speed is very high, I know it may cause really high damage and because this doesn't happen very often so I can do the zooming stuff. Thanks again for this interesting idea :) | |
| Jul 1, 2014 at 19:29 | comment | added | Arch1tect | (1/2)@NauticalMile hey, that's a very good idea too!! I'm afraid it may not directly apply to my game because the player is hit too often, so zooming in and slow motion may interrupt the on-going game too much. | |
| Jul 1, 2014 at 14:37 | comment | added | NauticalMile | Further to the 'near-misses' concept, there's a chapter in Malcolm Gladwell's book, David and Goliath, that talks about how people feel empowered and exhilarated when they feel they have cheated death. If you can use near-misses in your game, I'll bet it will be a lot more exciting. | |
| Jul 1, 2014 at 14:32 | comment | added | NauticalMile | (2/2) This will kill two birds with one stone (word play not intended): you won't need to do any 'looking into the future', and the players will experience the thrill of near-misses as well as direct (or grazing) hits. In fact, I could argue that your effects will become boring if the player knows that, every time the camera zooms in and the game slows down, he's doomed. He will want to skip the 'animation' immediately and try again. But if there's a chance he can evade the stone, you can bet he will be biting his nails waiting to see the outcome. | |
| Jul 1, 2014 at 14:26 | comment | added | NauticalMile | (1/2) IMO it would be much more interesting if you used a raycast to see if a collision has a decent chance of occurring, then start the camera zoom and slow the game down. For every frame, re-do the ray cast to see if the stone is still on a collision course. If the stone is intercepted, the camera should just zoom back to its normal state, but for every frame the collision is still likely, zoom the camera a little more. | |
| Jul 1, 2014 at 2:00 | history | tweeted | twitter.com/#!/StackGameDev/status/483792268894433281 | ||
| Jun 30, 2014 at 20:56 | history | edited | Anko | CC BY-SA 3.0 |
Clarified based on comments that Box2D is the specific target. Retitled and retagged matchingly. Added note about raycast limitations.
|
| Jun 30, 2014 at 20:48 | comment | added | Arch1tect | @Anko very interesting idea! I've never tried that. But the player can still move so where he go or how far he go is not predictable. Yet I know the player's move speed so when the stone is close enough, I know it won't miss... | |
| Jun 30, 2014 at 20:46 | comment | added | Anko | Theoretical note: The future of non-deterministic systems is by definition unpredictable. See Schrödinger's cat, mentally replacing "cat" with "player character". | |
| Jun 30, 2014 at 20:42 | comment | added | Anko |
Are those those blocking items also part of the physics simulation? If so, you could clone the b2World and step the whole lot a few frames into the future.
|
|
| Jun 30, 2014 at 20:34 | comment | added | Arch1tect | @Anko Box2d, I can use its raycast to predict trajectory. But something may suddenly show up between the stone and player. | |
| Jun 30, 2014 at 20:31 | comment | added | Anko | What physics engine are you using? How is it calculating the position of the stone every frame? (You could stack that same calculation a few times more every frame, to check where the stone will be in the future.) | |
| Jun 30, 2014 at 20:02 | history | asked | Arch1tect | CC BY-SA 3.0 |