choas
-
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.
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.
That just is running into the problem the original comment was trying to avoid in the first place:
You are constantly jamming into the surface and doing a whole bunch of collision checks to basically scrape the player across the surface...
...because you have to keep doing those checks in a loop untill you determine the obstacle is finally cleared, and then switch back to unrestricted or 'normal' grapple-movement.
You have to keep doing 3d vector collision mesh check calculations for the whole time the player is being 'scraped'... because you don't know when to switch 'perpendicular movement only' mode off, otherwise... so this is inefficient.
Assuming this is a 3D environment... there's no way you can just totally null out one dimension of the movement vector unless the player is perfectly perpendicular hitting a perfectly perpendicular surface.
If your level design is any degree of complex, with objects beyond basically perfect boxes that are all perfectly orientes to the world grid... and if the player is allowed to rotate... this doesn't work, your calcs still always involve 3 dimensions.
What you're saying might work in a 2D game... or I guess 2.5D, maybe?... but it wouldn't work in a 3D game.
...
Something possibly, sort of like what you've described, I think? but not really?... another idea that might work would be:
Upon detecting a collision, before the player has gotten to the grapple end point... the grapple movement basically complexifies with more nodes.
So you use a pathfinding algorithm to draw, instead of just a line between two points... now you have a point of origin where the player is, the end point, and a third point that is off to the side of the obstruction.
Now for that first segment, now the grapple pulls the player perpendicular to the obstruction surface, so it isn't constantly colliding and doing friction... and then when the player clears the obstruction, hits that midpoint, the movent vector changes.
This is basically what I described with doing the 'draw a giant skinny box' to check if a player can do an unobstructed grapple... but now more complicated as it involves 3D pathfinding...
This could possibly work, but it would take a good deal more work to optimize this, to make your entire world work with 3d path finding... normally, nav meshes are just done on more or less flat ground, up to some degree of incline... but now you also have to do this on literally all surfaces.
Again... this might work ... but it would take a lot of game dev work to implement, as you'd have to fully 3d navmesh every level... and this potentially would not handle complex surfaces well.
3D, aerial pathfinding in a very complex environment ... to my knowledge, still isn't really a thing many games have done very well, efficiently, with a general system. It usually just a bunch of manually placed aerial nav nodes, particular to the level itself... very intensive, manual work.
...
This will allow them to slide along walls/floors/ceilings realistically.
You have an odd definition of 'realistically'.
...
For the case where they need to move "through" a small object, you could treat their collision as a sphere...
Whoah whoah whoah wow ok gotta stop you there.
Spheres tend to be the absolute worst objects to use in a collision mesh or hull, because they are comprised of far, far more tris or rects than a box.
This is a terrible idea.
There is a reason hitboxes... are called 'boxes'.
...and have it collide with the object; for small objects, this could let them pass by.
I think what you are trying to describe is a common concept in games where many objects that are basically... clutter, vegetation, extra fluff... they just do not interact with the player collision mesh/hull at all, for many parts of the engine/game.
Like a uh, a small pile of trash or rock that doesn't interact with the core player movement controller, but it might interact with an inverse kinematics system that slightly modifies the player's animation so that their foot rests on top of the rubble or rock.
But uh... doing a 'estimate everything's size by bounding it with a sphere and then negating movement collision if its small?'
This is not something you'd want to call when the grapple attempt is started, it'd be a massive stutter or slowdown, you'd have to index every object in the level... and you'd end up with like, if you have a pile or array of many small things, all together... well individually they are all small, so you can phase through a pile of many small things that is in totality actually large.
This is the kind of thing you just design your whole game and level and objects around from the ground up.
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.
Again this 'solution' of yours (which just entirely abandons the concept of just not colliding with small objects, which you literally just described) just causes the problem the original comment was trying to avoid: having to do a whole bunch of collision calcs every time any obstacle is encountered.
... You speak as if you know what you are talking about, but you clearly do not.
Have you ever actually mocked up a 3 physics scenario in a game engine, or modded an existing game in a manner that is very reliant on or interactive with its physics engine?
-
This comic is so old, that both should be rather easy now
It took almost exactly 5 years from publication for that to be commonplace.
-
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.
wrote on last edited by [email protected]Yep, those first 3 are either exactly or almost exactly what I ended up with when I toyed around with making something similar, haha.
Honestly, I think what you are describing as 'janky workarounds'... are actually how you do this right, they are 'efficiently implemented game mechanics'.
Maybe the code could be cleaned up and de-spaghettified a bit, but I've seen many other systems like this in many games and mods.
If it seems stupid, but it works... it isn't stupid.
The word for that is actually 'clever'.
... you'd be amazed how much enterprise level business software, for instance, relies on some weird ancient library or function that literally has a comment in the code that says "I do not know why this works, but it does, DO NOT CHANGE".
.....
But also: oh god WATER.
Fuck video game water rofl.
I feel your pain.
-
-
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.
As a programmer, I've learned to cringe at any suggestion from someone that starts with "can't you just". Cause I guarantee you, I can't "just" do that. It's way more complicated than just.
-
This post did not contain any content.wrote on last edited by [email protected]
Way back in the 90s I did a contract job at MS Research on a project called "V-Worlds" - a world simulator similar to the Doom or Quake engine, but it was browser-based and everything was a script, so changing how the world worked didn't mean you had to restart a server, just change the scripts and new stuff would appear right in front of you.
Anyway the concept of adding accessories to the player's avatar and even having a pet follow you around came up, and I remember there was an involved discussion of how difficult/impossible that would be. The player's avatar was a special object class that represented a user, and didn't have the same capabilities as ordinary objects in the world. I remember asking, "Why isn't the avatar just a world object the player happens to control? Then you could do all kinds of cool stuff like let the player transform into something else just by switching objects, or let another player run your character." Dead silence. I was just a contractor, what did I know?
-
As a gameplay programmer, I got anxiety from reading this (and I think the animators are already in a fetal position on the floor)
Would it be possible to just mirror what the player is seeing so literally everything is backwards? Like a visual effect 'in-post'? Obviously that would mess with any printed text but other than I cant think of big issue?
-
This post did not contain any content.
I want dresses, and I don't care if they clip through literally everything!
-
I didn’t say they were very good web devs.
It doesn't really matter how good of a web dev you are, you really shouldn't be changing any part of someone else's website... They tend to do things like call the police on you for "hacking" and other such frivolities /s
-
Ok, but all your dialogue will be spoken backwards.
That makes sense. All left handed people are witches anyways, they'll feel right at home
-
Ok, but all your dialogue will be spoken backwards.
-
Would it be possible to just mirror what the player is seeing so literally everything is backwards? Like a visual effect 'in-post'? Obviously that would mess with any printed text but other than I cant think of big issue?
The Zelda tactic
-
Would it be possible to just mirror what the player is seeing so literally everything is backwards? Like a visual effect 'in-post'? Obviously that would mess with any printed text but other than I cant think of big issue?
You could even do that on the player's model specifically. But it's still a maybe, you're almost guaranteed to get some cursed bugs due to every preexisting code having been made with right handedness in mind.
I'm sure animators are internally screaming at the reasons why this will make some originally right handed animations look off but that's not my area of expertise.
In reality it's probably not the hardest thing to do gameplay-wise, especially if you're doing it from the very beginning of the project, but I don't think you can simply mirror animations (and some animations-related logic) and have it look natural, so you'd have to make dedicated animations and possibly logic for left hand strikes, right hand blocks etc. which would obviously be much more expensive. But yeah that's probably what Minecraft does now for example, and since they have a very low level of detail on player characters and their animations it looks alright.
-
This post did not contain any content.
"I noticed the elves in level 3 look too similar to the dwarves in level 5."
"It's too late to change it now!"
-
Ok, but all your dialogue will be spoken backwards.
Noted. I'll talk to Jeff in FX and get all the .wav files reversed. Shouldn't add too much to storage. I wonder if lip sync will be affected? I'll mention it to Sue when she gets back next week.
-
As a programmer, I've learned to cringe at any suggestion from someone that starts with "can't you just". Cause I guarantee you, I can't "just" do that. It's way more complicated than just.
I am familiar with the PTSD trigger words. -
Would it be possible to just mirror what the player is seeing so literally everything is backwards? Like a visual effect 'in-post'? Obviously that would mess with any printed text but other than I cant think of big issue?
That’s basically what they did for Legend of Zelda:Twilight princess. GameCube version Link was left handed, Wii version he was right handed. Looking at game guide sites was kind of comical. They basically said we’re not rewriting our guide for Wii…just flip the directions. If the guide says go left…go right for Wii.
-
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.
I don't want you to come to me with problems. I want you to come with solutions. I'm going to schedule some action orientated soft skills training for you next month. There is a push to increase our education KPIs so budget is available.
-
You can hold a two handed weapon favoring the left, or the right.
You’ll just hold it right at the center of your screen. You’ll not see anything, but it’ll work!
-
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.
PM: You know real world?
Make it like that
-
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.
Have you ever played ATV Offroad Fury on the PS2? When you reached the edge of the map, it would just fling you back towards the center.
I propose that is how we deal with NPCs blocking doors. With negated fall damage, of course
