Pixel Collision in Feature Requests
How is it not?
What happens if they come to an area with a low roof or otherwise blocked area that they would normally be able to fit through? If they are just moved up by a constant amount every time regardless of the actual step size needed, then moved over, then moved back down, they would often whack their face on things that they shouldn't.
Pretty much. This is how it works in most top-down 2D games, The Legend of Zelda on the SNES, for example, and also in most 3D games. It is unlikely that the player was intentionally running a small portion of their body into an object in an attempt to stop on it, and much more likely that they were attempting to walk past (ie: into a doorway).
How is it different from the demo that you provided? It is a method integrated into pixel movement that makes the movement much more intuitive and generally better feeling. Running a single pixel of your character into a wall, and coming to a complete stop, just feels clunky.
Right, which is why it's not something the BYOND developers should be bothering with.
The BYOND developers should be bothering with just about everything. If the engine doesn't support pixel movement, intuitive HUDs, on-screen text, mappable keyboard controls, etc forever; then nobody is going to offer these things in their games. If such systems are naturally supported by default,then everybody is going to use them, and the overall quality and playability of BYOND gameswill be improved across the board from the start.
It would improve the average quality of games by raising the lower limit, but that's not really helping.
It's like suggesting that BYOND have default background music in games. It improves the games that don't have music but it doesn't help the games that already do.
BYOND needs features that make good games even better, not features that make bad games slightly less bad.
Guys, what I was saying that sliding stuff is more of a consequence of the precise pixel collision, it doesn't have anything to do with the pixel collision itself.
The BYOND devs add pixel collision, then you use that new feature to make the sliding on your own.
Collision and movement systems may be separate concepts, but the sliding movement would still happen as a result of collision.
I certainly could have built such straightforward systems in the span of 2 days within DM.
Well, why haven't you added the sliding feature to FA's pixel movement library?
Game Maker, Unity, FlatRedBall, none of those have the sliding feature built-in because it's not something which should be.
I'm not sure how you don't consider that helping. By raising the starting point, you would effectively raise the end point as well
Unity definitely does.
That's what the music analogy shows - having default music wouldn't improve the upper bound of game quality because good games will use their own music.
If features are easier to use or are present by default, it does make BYOND better but doesn't raise the upper bound on what is possible.
No, it doesn't have the wall sliding you are referring to.
What you are thinking of its physics engine which is unrelated to precise pixel collision.
Even then, you can still ram a box into a door frame and it's not going to slide in unless you add that behavior yourself.
There are some minor logistical problems with this, and with round bounding areas, that would need to be solved. One that comes to mind is that right now, an object's locs var lists any turfs it covers, but here you'd have the possibility of locs not including the actual loc at all. The right way to handle bounds_dist() is also in question. On the whole the problems aren't very big ones though, and the chief reason we didn't add this at the time was simplicity.
Falacy, I know you always talk about using other development tools besides BYOND but have you ever actually used one for more than a few minutes before closing it then never touching it again?
You just said yourself the wall sliding is, "mostly due to movement angles."
Wall sliding is a game-specific feature.
one which is entirely separate from pixel collision
It's something which should not be built into BYOND.
You'd need to create icons to act as density masks for each turf just to use this feature.
This is a feature that people ask for because they think games work this way.
It looks like they do, but most don't, which shows you how nicely bounding boxes can work.
Because most games do work this way.
On top of that, they both have much better handling of what happens if you do walk into a solid wall, so that it doesn't just look like the entire game came crashing to an end; CT simply continues your walk animation (which again, is common among most games), ALTTP continues your animation for a short while, and then switches you into pushing.
Both of those are game-specific details that you can easily implement. Maybe you want to continue showing the movement animation. Maybe you want them to stand still.
Maybe you want to show an animation when the player bumps into a wall.
Different games handle things different ways.
However BYOND's default movement works, there's a very good chance it won't be sufficient and developers will have to extend or change it.
When you get into game-specific details, it's not BYOND's job to implement features for you, it's BYOND's job to make it easy to implement the features you need. In this case, these features are already very easy to add.
It isn't easy, actually, it isn't possible at all to continue showing an animation. Unless you do something like manually change the icon_state when movement is involved, which is just a completely broken concept to begin with.
Then they need to make it better
You seem to have said that you want the box to wrap itself around each pixel, but then later in your post you said that the box should be defined by 2 numbers, which is what is already incorporated.
Even in more popular games such as Call Of Duty, each person has a "bounding box". A simple rectangle around their character that registers collisions.
A collision system based solely around the pixels is likely to be something made by another BYOND member. The BYOND staff probably won't include something like this in DM.
Games change the player's icon_state to reflect the action the player is performing all the time (attacking, running, flying, etc.). Having to change the player's icon state to show that they're trying to move is very simple and not out of the ordinary.
It's not that BYOND's default movement system isn't good enough. There are just game specific details that you'll have to add. Maybe one game wants the player to slide around obstacles and another doesn't. Whichever the default behavior is, one of those games will have to change it.
It's best to provide developers with a generic feature and give them the ability to write code to modify the movement system.
If you just have global constants they can change to control how movement works, you're out of luck when you want to implement something slightly different than what BYOND provides.
You'll have to write code to make a BYOND game, so there's nothing wrong with having to write some movement related code. BYOND makes it easy to add the features you've been asking for, and that's all you can expect.
breaking the concept of how iconning was designed.
There is something wrong with it when I have to work on an incredibly low level system like basic movement, and as I mentioned, these concepts aren't particularly easy (or efficient) to implement via DM.