choas
-
Oof, this reminds me of a personal experience.
Me: Oh this grapple system is easy, we'll just push the player's vector towards the destination vector.
Game: Oh but there's a small object in the way that cannot be moved. This will make an immense amount of collision data per tick.
Me: Can't we just ignore-
Game:
As another mod maker/game tinkerer...
Genuinely, how did you fix this?
If I understand this right, the problem would be... ignoring certain collision meshes/hulls while in grapple movement mode... but then if you stop your grapple while basically inside or intersecting with those meshes/hulls, now insane nonsense happens, right?
...
Assuming this is an OoT hookshot style, just throw the player directly at the grapple end point thing, and not a more complex and realistic 'throwing and climbing a rope like a mountain climber' style grapple... the way I would try to address this would be:
Give the grapple movement mode some kind of shut down mechanism/recovery.
Like... oh the player is still trying to grapple toward point A... but they aren't moving at anywhere near the speed they would be if they were unobstructed, cancel the grapple mechanic.
Or: oh, the player is in grapple movement mode, but they collided with something, and they're nowhere near the grapple end point, stop the grapple mechanic and stop moving them.
For either (or both) of these, at the end now transition the player into some kind of specifically designed 'grapple mode has failed due to an obstruction' state, where the player now gets some amount of damage, a 'collided into object' animation, during which the player gets repositioned into a 'collison safe/no collision violation' nearest position, like a 'get unstuck' check in an mmo or something.
Or another way would be: before the player actually begins being moved by the grapple... do the vector trace from the player, to the end point, and around that vector, quickly draw a large box, rectangular cuboid, perhaps with endcaps of some kind... that just projects what the straight line movement of the player's collision hull would be... maybe make it a bit bigger than the player's collision hull just to be safe...
...just 'draw' that real quick, if it intersects with anything, no can do chief, grapple attempt fails, doesn't engage.
That would at least work for static world objects that don't move, you'd still also need one or both of the above methods to handle colliding with things that can move, npcs, other dynamic objects.
-
This post did not contain any content.
And don't even get them started on doors.
-
I just want a game that lets my avatar be left handed.
As a gameplay programmer, I got anxiety from reading this (and I think the animators are already in a fetal position on the floor)
-
Game director : we’re gonna add interact-able doors with proper door opening animations for the characters
The game designers:
The programmers and artists:
The producers:
Okay, okay. No doors but stairs instead
-
Well yeah, we have a character model for the giant demon and the giant demon has a huge use case.
A scarf? That's a model extension. Either you're asking me to create a whole new character with a scarf baked into the mesh that will deform weirdly as the character moves, or you're asking me to implement an accessory-anchor system all for the sake of a scarf (albeit other accessories might use this new framework) which will then need a physics/cloth sim to even look half good.
my thoughts. system has to be made for costuming from the get go and you bring in a wierd new character race and everything breaks for them.
-
As a gameplay programmer, I got anxiety from reading this (and I think the animators are already in a fetal position on the floor)
Can't you just swap x for -x. Run some unit tests just in case. We'll push to prod next Wednesday. Sound good? Got to dash, strategy meeting started 5 minutes ago. Seeyoubye.
-
Can't wait for the Disney live action movie remake of XKDC comics!
Plot twist: it will be written and created by AI:-(.
-
Can't you just swap x for -x. Run some unit tests just in case. We'll push to prod next Wednesday. Sound good? Got to dash, strategy meeting started 5 minutes ago. Seeyoubye.
The location that the player is visually interacting with would be different, but the world wouldn't know that. Eg. in a cutscene, the player reaches out and touches a button on a control panel. If the player's X is flipped, their left hand will be further left than their right hand, and will miss the button visually as they go to press it. Asymmetrical animations might also be fucked, ie. sidestep/jump right normally extends the left leg for leverage, but now their right leg would push off visually and they would still move right.
-
She did get her research team after all
Now try to identify if it's a fish
-
Well, sure, with an image classifier, the bird identification is doable. I'm sure I could implement that if I went looking for some open source thingamabob that does that. But it's still not something I could actually understand. That part definitely hasn't changed over the years.
wrote on last edited by [email protected]Having taken an ML class, with some of my college notes I could do this and "understand" it... but the weights would still be a black box. AI training is black (box) magic.
-
As another mod maker/game tinkerer...
Genuinely, how did you fix this?
If I understand this right, the problem would be... ignoring certain collision meshes/hulls while in grapple movement mode... but then if you stop your grapple while basically inside or intersecting with those meshes/hulls, now insane nonsense happens, right?
...
Assuming this is an OoT hookshot style, just throw the player directly at the grapple end point thing, and not a more complex and realistic 'throwing and climbing a rope like a mountain climber' style grapple... the way I would try to address this would be:
Give the grapple movement mode some kind of shut down mechanism/recovery.
Like... oh the player is still trying to grapple toward point A... but they aren't moving at anywhere near the speed they would be if they were unobstructed, cancel the grapple mechanic.
Or: oh, the player is in grapple movement mode, but they collided with something, and they're nowhere near the grapple end point, stop the grapple mechanic and stop moving them.
For either (or both) of these, at the end now transition the player into some kind of specifically designed 'grapple mode has failed due to an obstruction' state, where the player now gets some amount of damage, a 'collided into object' animation, during which the player gets repositioned into a 'collison safe/no collision violation' nearest position, like a 'get unstuck' check in an mmo or something.
Or another way would be: before the player actually begins being moved by the grapple... do the vector trace from the player, to the end point, and around that vector, quickly draw a large box, rectangular cuboid, perhaps with endcaps of some kind... that just projects what the straight line movement of the player's collision hull would be... maybe make it a bit bigger than the player's collision hull just to be safe...
...just 'draw' that real quick, if it intersects with anything, no can do chief, grapple attempt fails, doesn't engage.
That would at least work for static world objects that don't move, you'd still also need one or both of the above methods to handle colliding with things that can move, npcs, other dynamic objects.
You could plausibly implement some physics to deal with it. If the player is moving into a surface, move them along the part of their grapple movement component that's perpendicular to that surface. This will allow them to slide along walls/floors/ceilings realistically. For the case where they need to move "through" a small object, you could treat their collision as a sphere and have it collide with the object; for small objects, this could let them pass by. Eg. for grappling sideways over a small rock on the ground, their point of collision would be mostly below them and a bit to the right, but they're being pulled mostly straight to the right, so they would move perpendicular to the point of contact and move up-right over the rock, then continue their grapple path. Depending on your game's physics system there are other solutions, but for a typical game engine, that should work well.
-
I just want a game that lets my avatar be left handed.
Counterstrike did that over 25 years ago. Yikes I'm old
-
I just want a game that lets my avatar be left handed.
Hahah
No.
-
Can't you just swap x for -x. Run some unit tests just in case. We'll push to prod next Wednesday. Sound good? Got to dash, strategy meeting started 5 minutes ago. Seeyoubye.
Ok, but all your dialogue will be spoken backwards.
-
Always have to remind myself of this when managers ask me if something could be done. If it's easy, I naturally get a little annoyed that they're even asking. But knowing that is my job, not theirs, and it's good that they ask. There's lots of places where they assume and things go badly.
It’s always nice of them to ask
-
This post did not contain any content.
Shadows in the real world a lack of energy
Shadows in games imma need it all boss -
I just want a game that lets my avatar be left handed.
changes all weapons to be two-handed
This way, no one will complain and there’s only one thing to maintain!
-
Game director : we’re gonna add interact-able doors with proper door opening animations for the characters
The game designers:
The programmers and artists:
The producers:
Now we need to decide in the case of collisions if:
- Doors violently push anyone out of the way, possibly "crushing" them into walls or
- Force themselves back closed, turning any random NPC / obstacle on the other side into an unbeatable lock or
- Just trap an unfortunate NPC in a corner on the other side, or
- If they use the physics system to swing open, in which case they'll look smooth but possibly bonk the player/actor going through them a few times and could potentially (and comically) insta-kill them if physics is feeling grumpy.
The frustratingly comedic unintended results of any choice makes for great organic marketing though.
Gamedev is magical.
Aside: Know what did this really well though? Resident Evil games after RE:4.
The ability to "slowly quietly open", and then at any time decide to violently action-hero kick it open to send a zombie on the other side flying, was genius.
-
As another mod maker/game tinkerer...
Genuinely, how did you fix this?
If I understand this right, the problem would be... ignoring certain collision meshes/hulls while in grapple movement mode... but then if you stop your grapple while basically inside or intersecting with those meshes/hulls, now insane nonsense happens, right?
...
Assuming this is an OoT hookshot style, just throw the player directly at the grapple end point thing, and not a more complex and realistic 'throwing and climbing a rope like a mountain climber' style grapple... the way I would try to address this would be:
Give the grapple movement mode some kind of shut down mechanism/recovery.
Like... oh the player is still trying to grapple toward point A... but they aren't moving at anywhere near the speed they would be if they were unobstructed, cancel the grapple mechanic.
Or: oh, the player is in grapple movement mode, but they collided with something, and they're nowhere near the grapple end point, stop the grapple mechanic and stop moving them.
For either (or both) of these, at the end now transition the player into some kind of specifically designed 'grapple mode has failed due to an obstruction' state, where the player now gets some amount of damage, a 'collided into object' animation, during which the player gets repositioned into a 'collison safe/no collision violation' nearest position, like a 'get unstuck' check in an mmo or something.
Or another way would be: before the player actually begins being moved by the grapple... do the vector trace from the player, to the end point, and around that vector, quickly draw a large box, rectangular cuboid, perhaps with endcaps of some kind... that just projects what the straight line movement of the player's collision hull would be... maybe make it a bit bigger than the player's collision hull just to be safe...
...just 'draw' that real quick, if it intersects with anything, no can do chief, grapple attempt fails, doesn't engage.
That would at least work for static world objects that don't move, you'd still also need one or both of the above methods to handle colliding with things that can move, npcs, other dynamic objects.
I don't know the "right" answer, but I set it so if you hit something, it plays out some checks similar to as you described:
-
If we collide with something but its only waist high, then we will have the player stop the grapple and attempt to vault over whatever it is.
-
If we collide with something and its more than waist high, then we wait for a very small delay and see if we made any progress towards our destination. If not, end the grapple because something is in the way.
-
Ignore all collision damage otherwise when grappling. Either we get stopped on the way and give up, or make it and then end the grapple.
... And last but most horrible of all:
- Do a completely different set of checks if the player is underwater when the collision happens.
All my games are janky though so I don't think this is some ideal setup.
Edit: Cleaned up the collision damage part as I thought I handled it differently.
-
-
changes all weapons to be two-handed
This way, no one will complain and there’s only one thing to maintain!
You can hold a two handed weapon favoring the left, or the right.
