Alt text: In the 60s, Marvin Minsky assigned a couple of undergrads to spend the summer programming a computer to use a camera to identify objects in a scene. He figured they’d have the problem solved by the end of the summer. Half a century later, we’re still working on it.
Edit: seems I’m the third person to comment this! :')
I love how this is actually an example of progress. These days, ML can be used for this kinda thing and it’s not too bad at it even.
https://code.flickr.net/2014/10/20/introducing-flickr-park-or-bird/
This page about it still exists, but I guess the identification site died with Flickr.
deleted by creator
Only in 3D. In 2D, you slap some pixels on top and there’s your scarf:
I tend to find it’s the other way around. Once you’ve got a scarf modelled and rigged, it’ll work* for all animations, but for animated 2D sprites you have a lot more things to do.
* May have visual artifacts like clipping
and add a couple of frames to the sprite sheet in order to animate the scarf if that’s required.
Sure. Player character? No.
There’s already a codebase for bursting from the ground in an explosion of lava. Everyone wants that.
You’re the first person asking for a scarf, and our system doesn’t even know what a neck is.
Time for the old NPC-with-a-train-for-a-hat trick.
Player? Easy. Scarf? Easy. Wearing a scarf? That depends on a lot of factors such as which part of the body, how the models were made and rigged, etc.
And if it like blows in the wind that’s a whole jigglebone system and wind simulation that’s a lot of stuff going on
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?
This feels like the kinda project that should have a 1hr YouTube indie doc about it
I wouldn’t mind seeing that! After V-Worlds was declared “completed” MSR tried to find a product group to fold it into, but nobody wanted to own it. I don’t remember if XBox existed then, but the code just sat there for a few years, then I heard they opensourced it. When my kids were playing ToonTown I found a bug that let you slide behind the background and move around, like you could see that a clerk behind a counter was just a legless floating torso. The method of getting there seemed to be exactly like a V-Worlds bug, so I wondered if Disney might have been using the code. But it could have just been a common graphics bug, I dunno.
I remember finding another bug while creating a demo with a snaky sea creature swimming around. To animate a multi-segmented object you had to animate each segment separately. After the animation ran for a minute or two, enough unrelated interrupts would happen in the computer that would throw the body parts out of sync, making body parts either merge into each other or move apart, and the whole thing would look like crap. Same thing if you had somebody ride in a car or on a train - the car and character were animated separately and you’d end up with the character floating along behind the car.
I asked the dev about making the animation itself an abstract object whose position would be moved around, and attaching in-world objects to it, with position offsets. Each animation step would be computed just once instead of for each body part (or for the person and the car), and all the parts would be rendered with offsets from that one position, guaranteeing them to stay in sync visually. He said yeah that’s a good idea, but we’re not working on that code anymore. Oh well.
Another bug involved moving from room to room. The engine only loaded graphics for the current room, so when you went through a doorway it would load the new room and dump the previous one, causing a very unnatural visual delay that looked like a glitch in the matrix. The way we coped with this was by putting an entire world in a single room, so all the world’s graphics were loaded all at once. But this not only limited the world size, it meant we had to create our own version of the room system in script. To keep track of where players and objects were, we put invisible barriers in doorways and used event handlers when things passed through them. Then we used this to enforce which players could talk to each other or hear sounds made in a given “room”.
I suggested loading a cluster of rooms at once - the current one and those that were one connection away. Then when an avatar passed into a doorway the new room’s graphics would already be there, no glitch, and the graphics for nearby rooms could be loaded and unloaded in the background. Again, nice idea but we’re done working on that code. Sigh. I really wish I had joined that project about 6 months sooner. Not like I’m a genius or anything but these seemed like really fundamental things that should have been addressed up front.
Okay, rant over. I haven’t thought about this stuff in quite a while - I’m kind of amazed so many details are still in my head. I must have agonized over it a lot at the time lol.
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:
Legend of Zelda did it well.
Honestly, I think a major issue with doors is that they just slow down gameplay.
It’s like coming across a ladder only every building has one.
Almost all game-slowing doors are just hidden loading screen baked into the gameplay.
Granted. All door animations are now forced cutscenes.
deleted by creator
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
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
Wow, memory unlocked! Motocross Madness did this too, if you managed to drive up the giant wall surrounding the world. I checked, and it turns out both these games were developed by the same company, Rainbow Studios, so probably they used the same engine.
FROM Software: Fuck that, we’re doing fog-walls.
Okay, okay. No doors but stairs instead
There’s an XKCD comic for that.
This comic is so old, that both should be rather easy now
She did get her research team after all :)
Now try to identify if it’s a fish
There’s no such thing called fish.
- Stephen Jay Gould (Biologist)
Oof
🐬
Oh, yeah, the specific example listed was solved within roughly a month of the comic being posted. But the idea still applies, as seen with the twitter post above.
It took almost exactly 5 years from publication for that to be commonplace.
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.
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.
only because people never stopped asking it to be able to id birds.
Can’t wait for the Disney live action movie remake of XKDC comics!
Plot twist: it will be written and created by AI:-(.
It will feature all sorts of jokes about using qwerty and windows
And Linux, if the Fediverse had any say about the matter! (Or xkcd either:-D)
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.
You could import fabric physics and just have it lie there, but that’s going to be a bigger hit on performance than you possibly can imagine and it will move weirdly (in large part becomes we’re not modeling wind, just fabric in a vacuum) and the model features it will lie on top of won’t deform accurately from the simulated weight, etc…
Feature requests never account for the performance hit.
or you’re asking me to implement an accessory-anchor system all for the sake of a scarf
It… shouldn’t be that difficult?
It’s literally adding another piece of gear, like gloves, breastplate, helmet, etc. Now just repeat the process for a scarf.
You’re assuming the game in question already had character customization in place.
I mean, if it doesn’t then it’s just adding to the model.
Django from Boktai had a scarf. I doubt it was difficult to add.
Even then, it becomes a problem of adding a gear system at all and a scarf is pretty irrelevant.
A character model is made up of “slots”. The head slot, the chest slot, the legs slot and so on. When you equip a piece of gear, it replaced the body mesh in that slot. So a helmet model replaces the head, a cuirass replaces the chest, I think you follow. If you want a piece of gear to only partially cover the character, you need to create a new slot. But gear is easy to implement, since it conforms to the character’s “body” and uses the same animations.
Now add a scarf. First, you need to create a new slot, so that equipping the scarf doesn’t replace the head or chest. And then comes the question of animations. Are you going to have the scarf just lay flat against the character? That’s the easiest approach, but it’ll be completely static, look like ass and probably clip through at least some of your armors. You could use a cloth sim. If your scarf mesh has enough polygons, it’ll look the best. But it’s also computationally expensive, especially if you go with mesh-based collisions for maximum eye candy. And what types of objects can the scarf collide with? Just the character, or world objects as well? Every object the scarf collides with will create a whole new slew of physics calculations, all the time, dropping your performance in the gutter like a mob snitch. Or you could create a bespoke rig for the scarf. It’ll look better than a static object and won’t have a notable performance hit, but won’t look as good as the cloth sim, especially since it won’t collide properly with whatever else your character is wearing. And you’d need to create matching animations for literally every animation the character can possibly do. Every. Single. One. Your animators would want to murder you. And they will, when you come back to them a little later and say “Okay, real impressed with the scarf, now let’s make 5 different ones. And I want capes.”
TL;DR: It’s not just another piece of gear.
TL;DR: It’s not just another piece of gear.
Yes it is. It’s identical to adding a cape.
TL;DR: skill issue
I didn’t think I’d have to point out that adding a cape is a similar pain in the ass. Dynamic objects like scarves and capes are not the same as a shirt. If your character framework isn’t set up for them from the start, implementing them is not as simple as “just plop it in there bruh”.
I didn’t think I’d have to point out that adding a cape is a similar pain in the ass.
Yeah, skill issue.
Right. Go add capes that aren’t just rigged to the existing skeleton to Jedi Outcast or Morrowind, then come back and tell me how easy it was.
Already done.
Soft-body physics aren’t hard.
In fact, I challenge you to do it yourself so you can see exactly how easy it is.
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.
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.
Remember the phrase “it’s not in-pattern”. Another one is “it’s possible, but expensive”
It’s always nice of them to ask
It’s not natural lol
I want dresses, and I don’t care if they clip through literally everything!
My bg3 character is female. She was in slacks until act 3 where she could finally have a dress
We looted everything. I feel like there are two dresses in the game: the robe Gale wears and a white dress you find in a Balders Gate house near the end of the game
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)
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.
😬 I am familiar with the PTSD trigger words.
You little shit xD
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
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.
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.
Not sure whether to upvote because this is so accurate it’s funny or to downvote because it’s infuriating 😂
Ow that one hits me right in the briefcase
dies
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 entire game is mirrored.
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.
The Zelda tactic
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.
😵
You’ll just hold it right at the center of your screen. You’ll not see anything, but it’ll work!
You’ll just hold it
rightleft at the centerFTFY
hahaha
Counterstrike did that over 25 years ago. Yikes I’m old
They just mirror the viewmodel
minecraft allows left-handedness ever since they added the off-hand mechanic
I think before that even
Hahah
No.
Could I at least get some left handed emoji?
We’ll see with the investors
Counter strike
- “Can you make the player be able to summon a monster from the fifth dimension?” “Yes ok ez lol”
- “Can you make the player able to exist in the world without having it fall though the ground?” “You are asking too much mate”
You’re the one who asked to open a gate to the fifth dimension, you can’t then get upset that you broke 3+1 dimensional physics
deleted by creator
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.
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.
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.
-
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?
… You speak as if you know what you are talking about, but you clearly do not.
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.
Unnecessary “…”, and no, you don’t loop the check until the obstacle is passed any more than you would “loop” the player’s ordinary movement. As normal, each tick you attempt to move the player forward some distance. If there is an obstacle in the way, they’ll move less distance, which is fine-- this prevents them from rocketing up walls if they’re slightly below a target grapple point beyond the wall, as in the below scenario.
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.
What would be more efficient? Depending on how the game physics work, the player’s collision mesh is probably a capsule, simple box, or sphere. It’s really not that expensive to add this check; the player is presumably already doing collision checks using their mesh every tick for like, standing on the ground and touching walls.
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.
When did I ever say that you would accomplish this effect by nulling out one component of their movement vector? That idea is a fabrication of your own delusions. It’s pretty easy to do a mesh collision check, get the normal of the tri the player collided with, and use that to remove all the player’s movement in that direction. This is probably already part of the engine’s physics calculations anyways!
[the 3d pathfinding idea]
This could work, especially if the grappling hook is one of those ones where gravity stops affecting you (could be good for gameplay, that’s valid). But to construct this path in a realistic manner, you would need to do similar calculations to what you’re saying are inefficient, except all at once instead of spread over multiple frames. If you simplify the pathfinding checks to make the movement simpler, you could in most cases do the same thing with the player collision checks. Depends on how you implement it though I suppose. Too specific to cover all cases in a general discussion.
You have an odd definition of ‘realistically’.
It is realistic that if I grapple into a surface I will move a shorter distance than if I was grappling freely, yes. This is true without friction etc. as well. Think of the extreme case: grappling directly downwards into the floor, in which case I would not move at all.
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.
LMAO are you kidding me??
First of all you could do a check using a proper sphere rather than a mesh with tris. This can actually be faster than using a box-- eg. checking if two spheres (or a sphere and a point) collide is literally just a distance check compared to their combined radii. I bet even sphere-tri collision is easier than tri-tri, although my game engine knowledge doesn’t extend far enough to say for sure in that case.
There is a reason hitboxes… are called ‘boxes’.
They’re called that because boxes are common, not because they’re the best.
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. […]
This entire line of critique is invalid because I wasn’t saying that at all. I’m saying that as a consequence of the collisions, they could pass around an obstacle; not that they could go through it. A rock under the player as they grapple sideways would push them upwards and slightly away due to the angle of the collision, and they could then continue moving sideways as before.
Again this ‘solution’ of yours (which just entirely abandons the concept of just not colliding with small objects, which you literally just described) […]
How on God’s green Earth could you possibly, after I literally just described the precise mechanism by which the player would interact with small objects, still believe that I meant they should simply pass through them??? Maybe if you read the whole post instead of replying to each sentence individually you would’ve made that connection. Yes, I see the irony; I did read your whole post first though.
[…] 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.
If you apply the grapple as a force it’s literally the same collision calcs the player makes every single tick. If you can’t due to engine/game/etc. limitations, it’s still not that much extra collision calculation.
… 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?
Try me. I am extensively aware of the way physics is typically handled in games. I will admit I don’t often use game engines, because I usually try to make 2d games from scratch and implement my own simple physics. But yes, I’m aware of how 3d engines handle physics as well.
Shadows in the real world a lack of energy Shadows in games imma need it all boss
“I noticed the elves in level 3 look too similar to the dwarves in level 5.”
“It’s too late to change it now!”
