Falacy wrote:

How is it not?

It's not automatic because I wrote the code myself. Game Maker might have a drag and drop interface, but you can still get in there and script everything yourself if you want to.

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.

They aren't moved up at a constant amount. If the player only needs to be raised one pixel, they will be raised only one pixel. They will not "whack their face" into things while walking along a flat surface, nor a slope.

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).

Right, which is why it's not something the BYOND developers should be bothering with. I'm pretty sure this functionality could be added to FA's pixel movement lib. I think all you would have to do is check the bounding box of what you're colliding with against your own width/height then nudge yourself over when appropriate.

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.

For the reason I just described above. It's a feature dependent on the way you personally use pixel movement in your game. I don't really see how it could be added as a native feature in a way which makes sense and you already have most of the tools you would need to make it yourself anyway.

Falacy wrote:

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.

Falacy wrote:

Collision and movement systems may be separate concepts, but the sliding movement would still happen as a result of collision.

Yes, separate concepts. Sliding happens as a result of collision. Precise pixel collision is the tool given to you by the BYOND developers, sliding is what you make using that tool.

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? I think you have a lot of unfounded assumptions about the amount of automation in other languages. Game Maker, Unity, FlatRedBall, none of those have the sliding feature built-in because it's not something which should be. Those game you're thinking of with the feature, it was put there by its programmers. It's an intentional features which was planned then implemented by the game developers.

The Pixel Movement library has a demo of Zelda-like movement where your position is shifted to the nearest half tile to make it easier to line up with doorways. It wouldn't be hard to add other features to achieve a similar purpose, but it's a game-specific feature.

Both the Sidescroller and Pixel Movement libraries have their own ways of handling collisions, which includes sliding along walls or being moved up/down along ramps. These aren't trivial things to implement but the code is flexible enough that if you had an implementation to handle collisions with new shapes, it'd be easy to add to the library.

Falacy wrote:

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

It doesn't raise the end point because people can already get there. 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.

Forum_account wrote:

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.

It doesn't show that because having music doesn't necessarily increase the low end. If BYOND is just going to play some common elevator music across all games, then it would most likely have a negative impact instead. Not to mention that background music is a feature that can already easily be included with a single line of code.

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.

Most features wouldn't raise the upper bound of what is possible, only what is probable. And a guaranteed raise in the lower bound wouldn't be a bad thing.


SuperAntx wrote:

No, it doesn't have the wall sliding you are referring to.

In most cases, a rounded object is used to represent the player. This leads to you easily sliding along and past objects. The same could be applied in reverse, if the player was square and attempting to slide past a round object, or even a square on square in most cases (mostly due to movement angles).

What you are thinking of its physics engine which is unrelated to precise pixel collision.

Are you confused about this? You keep bringing it up. "Precise pixel collision" is just "is pixel A touching pixel B".

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.

Assuming that the box is at least halfway into the doorway, and the force is being applied from the center of the box, then it would "roll" into/around the door frame.

As I mentioned before, this is not some application of unnecessarily complex physics, just the common sense that; when somebody is hanging 99% off the side of an object, they should automatically be helped around that object.

Lummox JR wrote:

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.

I'm not sure how it would handle turfs that have some dense pixels and some non-dense ones. You'd be able to enter parts of the turf, so the collision detection would have to be occurring even if you're already overlapping a turf. It seems like quite a switch from the way the movement procs currently work. Also, for turfs you wouldn't want to use their icon and icon_state since all pixels are typically filled in. 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.

Falacy wrote:

Because most games do work this way.

I was talking about the original feature being asked for here, pixel precise collision detection. Most people think games have fancier collision detection than they really do because bounding boxes work surprisingly well.

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.

Falacy wrote:

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.

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.

Then they need to make it better

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.

Forum_account wrote:

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 is out of the ordinary, because BYOND's iconning tool is specifically designed so that you don't have to do that. Even if you use an icon_state to represent flying vs walking, it still includes a feature for automated idle animations. To be able to account for both of those states while changing icon_states during movement, you would also have to rely on a non-standard naming convention. It also brings up a ton of issues with changing states during or out of movement, starting movement while in a non-standard state, and if icon_states are used to identify activity-states (which isn't a good idea to begin with, but probably happens a lot) then it can completely break things.

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.

Not sliding around obstacles isn't a feature, it is a lack of feature. If sliding was included, those who didn't want it could simply turn it off, the same as pixel movement in general. And just like general pixel movement, including it as an option is far better than not including it at all.

It's best to provide developers with a generic feature and give them the ability to write code to modify the movement system.

It depends on the system. Playing an animation when you run into a wall is heavily game specific. Most games won't have such a feature at all, and the ones that do will require extra effort from the developer, like creating the actual animation and telling it which one to play and when (only when sprinting? after a delay to show pushing? etc). Such a system would also be incredibly simple to do, and could be fully accomplished in less than 5 lines of code.
On the other hand, a walking animation is something that practically 100% of games are going to have. Continuing to play this animation when walking into a wall is a common and generally desirable feature. The way I requested this before, it would even be a "generic feature", since it would be a simple variable that could be changed when movement started or stopped, but could also be used for various other effects, and wouldn't necessarily have any impact on a game by default. Expecting people to change icon_states to accomplish a similar effect is often game breaking, on top of always breaking the concept of how iconning was designed.

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.

They should rarely be global constants, but even if they were, implementing your own systems around them shouldn't be any more complex than if the systems weren't there at all, if anything, it should only be easier.

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.

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.