In response to Falacy
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.
In response to SuperAntx
SuperAntx wrote:
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 games will be improved across the board from the start.

Developers could certainly build such systems themselves, and almost always get around to it before the BYOND devs ever manage to, but such improvements only effect a very small number of games, and almost never cross between them. One game may have the smoothest movement on BYOND, while another has the best looking HUDs, while yet another has the most intuitive interactions, but it is unlikely that any game would have all of that, and most games would have none of it, because such simple features that should be naturally supported by BYOND are for some reason ignored, if not intentionally put down by the devs and/or community.
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.
In response to Forum_account
Forum_account wrote:
It would improve the average quality of games by raising the lower limit, but that's not really helping.
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. Currently, a fresh BYOND project starts out a lot closer to a text RP (which, most "successful" BYOND games finish as), than an actual game. By bringing the default standards of the engine closer to an actual game, developers would have to waste a lot less time building their own support for just about everything that a proper game should have to begin with. Which means better overall results.

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.
It is not like suggesting that at all, and music doesn't necessarily improve a game, especially not if it is randomly inappropriate music.

BYOND needs features that make good games even better, not features that make bad games slightly less bad.
Which is what a feature like this would do. Not that there are any good games on BYOND
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.
In response to SuperAntx
SuperAntx wrote:
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.
Collision and movement systems may be somewhat separate concepts, but the sliding movement would still happen as a result of collision. Graphical collision is just another form of collision, and sliding around it shouldn't be treated any differently than it would be with the currently available bounding boxes.

The BYOND devs add pixel collision, then you use that new feature to make the sliding on your own.
Just like every other basic system in existence that BYOND is somehow lacking, this should NOT be something that we have to build into their engine for use in our games. It is a basic, superior, intuitive concept that practically every BYOND game could and should benefit by making use of. I am still befuddled by how seemingly competent developers who actually use the software on a regular basis are somehow consistently in support of keeping BYOND as craptasticaly nonfunctional as possible. In the time that has been wasted discussing this topic, Lummox could have already implemented and released these new feature(s). Well, I guess I can't speak for him, but I certainly could have built such straightforward systems in the span of 2 days within DM.
In response to Falacy
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.
In response to SuperAntx
SuperAntx wrote:
Well, why haven't you added the sliding feature to FA's pixel movement library?
Because I don't work on his libraries?

Game Maker, Unity, FlatRedBall, none of those have the sliding feature built-in because it's not something which should be.
Unity definitely does. If I'm not mistaken, Flash does as well. I've never used Game Maker, so I'm not sure about that, and I've never even heard of FlatRedBall.
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.
In response to Falacy
Falacy wrote:
Unity definitely does.
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.
In response to SuperAntx
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.
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."

The sliding you want is entirely dependent on your implementation of pixel movement. Moving in 360 degrees will produce the desired sliding effect when running into a wall (not flat on, though), but moving in strictly north/south/east/west will cause you to stick to the wall rather than sliding along it. In this case, as I explained before, you will have to add that functionality yourself.

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.
In response to Lummox JR
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.
In response to SuperAntx
SuperAntx wrote:
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?
I used Unity for several months, and got pretty well along with it. I used flash for more than a few minutes, but never got too into it, and that was a long long time ago.

You just said yourself the wall sliding is, "mostly due to movement angles."
Movement angles are rarely going to exist in a 2D game, since you don't steer with the camera. Which is why an intuitive system for helping players around objects should be implemented.

Wall sliding is a game-specific feature.
It is not really game specific. Most games should use it for better playability.

one which is entirely separate from pixel collision
Again, you bring up pixel collision. Collision is the simple concept of "is A touching B", it has no effect on movement in concept alone, even internally, the value of "is A touching B" should be separately applied with density to see if collision should stop movement or not, no less cause you to slide around objects.

It's something which should not be built into BYOND.
It is something that should be built into BYOND, and easily customizable with a few variables, to the point of being completely turned off for those who want to degrade the quality of their game by not using it, or for the few situations where it wouldn't be desirable. You would want to be able to set how much overhang is needed before a slide occurs, and how far they should slide per step.


Forum_account wrote:
You'd need to create icons to act as density masks for each turf just to use this feature.
First off, how would that be any better than just using their icon_state to begin with? 2nd, you wouldn't use such hit detection for turfs to begin with, they are considered all or nothing; They don't even have bound settings as is...

This is a feature that people ask for because they think games work this way.
Because most games do work this way. Chrono Trigger and A Link to the Past are just two quick examples of extremely popular/successful SNES games that both have such a feature. 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.

It looks like they do, but most don't, which shows you how nicely bounding boxes can work.
"It looks like they do" is all they need to do, and then they work that way. Games are a concept of visual trickery to begin with.
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.
In response to Forum_account
Forum_account wrote:
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.
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. It should, however, be incredibly simple for them to implement something like that internally, and I had a feature request for just such a thing back before pixel movement was released.

Maybe you want to show an animation when the player bumps into a wall.
Now THIS is something that actually sounds game specific, and would also be easy to handle with what BYOND already provides you.

Different games handle things different ways.
They do, but there is a better/best way, and coming to a complete stop any time you vaguely touch a wall is not it.

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.
Then they need to make it better

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.
I wouldn't consider either of the features being discussed here (per-pixel hit detection and sliding around corners) easy to implement within DM, and I would actually say the collision detection would be the easier of the two.
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.
In response to Albro1
Albro1 wrote:
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.

As you and Nadrew pointed out, there are already bounds variables, what I'm suggesting is a combination between both the pixel collision AND the bounds. Making it all one big variable, which can be changed per. atom, much like the bounds vars. a setting of 0 would wrap around each pixel, any higher will be the definition of the "bound box" so 0 is pixel collision and 1 is a box of 1 pixel by 1 pixel. (32 would be 32 by 32, you could also define both seperately, as in world.icon_size. i.e. 180x20).
In response to Forum_account
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.
In response to Falacy
Falacy wrote:
breaking the concept of how iconning was designed.

BYOND's creators may have planned how its features can be used, I'm sure they had something in mind when each feature was added, but ultimately the people using BYOND decide how things can be used. There's no way they could have anticipated every way you can use an icon, for loop, list, if statement, or variable - that doesn't make the unanticipated uses bad or incorrect. If we had to use BYOND's features in the way they figured they'd be used, we'd all be making MUDs!

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.

In some ways BYOND is an engine (it does handle graphics, sound, and networking), but it'll never be an RPG engine, racing game engine, or a top-down shooter engine. There will always be some work needed to build your game's engine on top of it. Since movement varies across those types of games, there's no default movement that BYOND can provide that'll be sufficient. Since movement varies within instances of those types of games, there's not even a global variable BYOND can provide (ex: world/movement_mode = RPG_MOVEMENT, RACING_MOVEMENT, SHOOTER_MOVEMENT, etc.) that'll be sufficient.

That's the exact problem with this feature request (one of them, anyway). There is a clear and obvious way that pixel-level collision detection works. The problem is that resolving those collisions can become game-specific. More precise collision increases the potential for BYOND's default behavior to be unsatisfactory. Currently there's no way to override part of BYOND's movement to provide custom collision resolution. BYOND can certainly provide a proc that takes two atoms and returns 0 or 1 based on whether their icons have overlapping pixels or not. That's about as much as BYOND can easily provide for this feature, but it's still a long ways from what people would hope for.

If you want default movement behavior that's more game-specific than BYOND can provide, you'll have to use a library.
Page: 1 2 3 4