ID:650504
 
Redundant
Applies to:DM Language
Status: Redundant

This feature has already been implemented, or is already achievable with existing methods.
angular_step/walk() procs should work just like the normal ones, but the direction should be treated as an angle.
There's the obvious problem that both directions and angles are numbers. Does walk(src, 1) make them move north or 1 degree above east?

Also, BYOND's pixel movement doesn't support fractional moves. If you try to move 4.5 pixels to the right, I'm pretty sure it gets truncated to just 4 pixels. For movement based on arbitrary directions this can be a big problem:

If you move 5 pixels and your angle is 0, your move is (5, 0). If you move 5 pixels and your angle is 10 degrees, your move is (4.924, 0.868). If you truncate that it becomes (4, 0). If you round it, it becomes (5, 1). Neither would make the mob move at a 10 degree angle.

This is easy enough to add yourself (you could even do it by overriding mob.Move(), so it's totally transparent), but at that point it's obviously trivial to implement your own angle-based version of walk().
In response to Forum_account (#1)
Forum_account wrote:
There's the obvious problem that both directions and angles are numbers. Does walk(src, 1) make them move north or 1 degree above east?
As I said in the request, there should be an angular_walk() proc.

Also, BYOND's pixel movement doesn't support fractional moves. If you try to move 4.5 pixels to the right, I'm pretty sure it gets truncated to just 4 pixels. For movement based on arbitrary directions this can be a big problem:
There are a ton of problems with the way BYOND rounds things, but that is a separate issue.

This is easy enough to add yourself (you could even do it by overriding mob.Move(), so it's totally transparent), but at that point it's obviously trivial to implement your own angle-based version of walk().
I have already built my own systems for use in Box Zombies, but there is no reason that this shouldn't be built in.
Also, using Move() like that example seems to, by providing it with step_x/y arguments, ignores hit detection, which doesn't provide very effective "movement".
Falacy wrote:
There are a ton of problems with the way BYOND rounds things, but that is a separate issue.

It's not a problem with how things are rounded. The problem here is that things have to be rounded. It'd be better to ask for support for fractional moves in BYOND's default movement system. It'd make this trivial to add and it'd have other benefits.

there is no reason that this shouldn't be built in.

There are lots of features that make sense for BYOND to provide but the staff will never have enough time to add them all. This means that we can determine which features are worth adding and which aren't. This is something a small fraction of games would use and you can easily implement it using the Pixel Movement library:

mob
proc
angular_walk(dist, angle)
vel_x = dist * cos(angle)
vel_y = dist * sin(angle)

angular_step(dist, angle)
pixel_move(dist * cos(angle), dist * sin(angle))
In response to Forum_account (#3)
Forum_account wrote:
It's not a problem with how things are rounded. The problem here is that things have to be rounded.
Pixel locations do not have to be rounded, only when it comes to actually displaying the location, since you can't get any more visually specific than a pixel.

It'd be better to ask for support for fractional moves in BYOND's default movement system. It'd make this trivial to add and it'd have other benefits.
Depending on what you mean here, this is impossible. Unless you are saying they shouldn't bother rounding step_x/y, which you just said was necessary...

There are lots of features that make sense for BYOND to provide but the staff will never have enough time to add them all.
Lummox is supposedly a full time employee, it shouldn't take long to get this done.

This is something a small fraction of games would use and you can easily implement it using the Pixel Movement library:
Libraries shouldn't be used. The ridiculous claim that not many games would use this, or any other feature, is just that; ridiculous. Practically any feature they build in will be used by almost every game. Almost no games used keyboard macros, pixel movement, icons larger than 32x32, custom windows, in-game text, or plenty of other features before they were built in, even though all of those things were possible with awkward effort beforehand. The only feature that I've seen unused is isometrics, which is understandable and expected.

* snippet *
If they have to build in all of that on top of your library, and presumably even calculate the angle on their own, then what does your library even provide?
Falacy wrote:
Pixel locations do not have to be rounded, only when it comes to actually displaying the location, since you can't get any more visually specific than a pixel.

They don't have to round the coordinates but they do. If you do "mob.step_x += 1.5" four times you'll have only moved four pixels, not six. Movement based on an angle is likely to have a fractional component, which they'd have to keep track of (which is non-trivial and is a weird thing to add for just two procs) or support fractional moves natively (which is also non-trivial).

Lummox is supposedly a full time employee, it shouldn't take long to get this or anything else done.

The problem isn't just this feature. The problem is that there are millions of other features that are equally insignificant. For each single feature you request you can say "this would be easy to add" but when you add all of those features together, at some point, it becomes non-trivial.

Almost no games used keyboard macros, pixel movement, icons larger than 32x32, custom windows, in-game text, or plenty of other features before they were built in, even though all of those things were possible with awkward effort beforehand.

Being something that many games would use doesn't necessarily justify a feature request. Many games define the "health" var for mobs, but that doesn't mean it'd be a good addition as a built-in feature.

Also, making features more accessible isn't always an improvement (we've been over this before). The hard part isn't making a mob walk at a given angle. The hard part is using that feature to create a fun game. Giving people that feature doesn't make them any more able to create a fun game - it doesn't help them with what matters. The people who are capable of making decent games were capable of implementing simple functions like this right along - these people didn't need the help. It doesn't benefit BYOND to cater to the people who *need* the angular_walk proc and the people who BYOND should cater to, they don't need these kinds of procs.

Your statement also shows that some feature requests are far more important than others. The angular_walk() proc is useful, it's just not a very important feature. What'll benefit BYOND most is if we look for features the absolutely need built-in support (like better client-side graphics support).

what does your library even provide?

It's available for download and it comes with many demos, so you can easily see what it provides. The short list of features is that it provides smooth, improved movement for 2D and 3D environments, customizable camera control, better keyboard support that's more easily customizable (and doesn't rely on key repeat events), extensible pathfinding, and a set of useful helper procs.
In response to Forum_account (#5)
Forum_account wrote:
Movement based on an angle is likely to have a fractional component, which they'd have to keep track of (which is non-trivial and is a weird thing to add for just two procs) or support fractional moves natively (which is also non-trivial).
How do these concepts differ? and how are they non-trivial? (I don't think you're using that word right) All they would have to do is NOT round step_x/y and they could accomplish such tracking.

The problem isn't just this feature. The problem is that there are millions of other features that are equally insignificant. For each single feature you request you can say "this would be easy to add" but when you add all of those features together, at some point, it becomes non-trivial.
Millions is probably a bit of an overestimation, but implementing several simple features is equally beneficial to implementing one massive one that takes just as much overall time.

Being something that many games would use doesn't necessarily justify a feature request.
That combined with complexity is exactly what should justify a feature's implementation.

Many games define the "health" var for mobs, but that doesn't mean it'd be a good addition as a built-in feature.
It takes 0.2 seconds to implement a health variable, and even a complete novice should be able to figure it out. It is also part of a larger system that provides a generally beneficial feature. On the other hand, if they were to implement some sort of native support for the display of a health-bar (HUD bars in general), I would support something like that.

The hard part isn't making a mob walk at a given angle. The hard part is using that feature to create a fun game.
That's not entirely true. Considering BYOND's current lack of features, it is actually somewhat complicated to setup anything dynamically angular. Making such a feature "fun" varies by personal opinion, but angular movement would almost always provide better results than the 8 directions BYOND currently provides.

Giving people that feature doesn't make them any more able to create a fun game - it doesn't help them with what matters.
It should help, games are developed around their platform, if the platform is better, the games will be better, because they can be designed to be better. The core concepts of a game may or may not be fun, but if you can only make that game in 32x32 squares with unresponsive controls, even the best idea is going to suffer.

Also, making features more accessible isn't always an improvement (we've been over this before). [...] It doesn't benefit BYOND to cater to the people who *need* the angular_walk proc and the people who BYOND should cater to, they don't need these kinds of procs.
Yes, you have been over that ridiculous philosophy of yours before, but it is completely and utterly wrong, and you should stop attempting to promote it.

Your statement also shows that some feature requests are far more important than others. The angular_walk() proc is useful, it's just not a very important feature. What'll benefit BYOND most is if we look for features the absolutely need built-in support (like better client-side graphics support).
The issue of importance is functionality, but also consider time input vs results output. This feature request would only take like 10 minutes to implement, and would open up entirely new and vastly superior game design mechanics. Client-sided graphic support would probably take 10 hours, and wouldn't really change the way gameplay could be designed.
Falacy wrote:
How do these concepts differ? and how are they non-trivial? (I don't think you're using that word right) All they would have to do is NOT round step_x/y and they could accomplish such tracking.

It would be silly (but not *that* surprising) for them to go out of their way to round the coordinates if they don't need to. I'm guessing there's a reason why they're rounding step_x and step_y. If all of the implementations of movement (including other stuff, like the bounds() proc) are based around integer coordinates, it could be a lot of work to change that. I wouldn't be surprised if this wasn't a trivial change.

It should help, games are developed around their platform, if the platform is better, the games will be better, because they can be designed to be better.

If something is already possible then it's not necessarily making the platform better. Adding support for custom macros (on key press, release, and repeat) is better than the old alternative, but in this case there's no difference between the angular_walk() proc that BYOND would create and the one you can already create.

Being something that many games would use doesn't necessarily justify a feature request.
That combined with complexity is exactly what should justify a feature's implementation.

That'd mean that BYOND should provide enemies with default AI since that's something complex that many games have. There's more than just that to evaluating how worthwhile a feature is.
In response to Forum_account (#7)
Forum_account wrote:
If all of the implementations of movement (including other stuff, like the bounds() proc) are based around integer coordinates, it could be a lot of work to change that.
Which seems to be the problem with a lot of their rounding. It is done on an overall level, instead of in the specific times where it is actually needed. Maybe they could add a couple of variables to catch the fraction pixel locations.

If something is already possible then it's not making the platform better. Adding support for custom macros (on key press, release, and repeat) is better than the old alternative
That seems a bit contradictory?

but in this case there's no difference between the angular_walk() proc that BYOND would create and the one you can already create.
There probably wouldn't be much of a difference. The issue is more that, if it isn't built-in, there isn't even going to be a difference to compare to, because 99.9% of developers aren't going to bother building their own systems for something so basic yet so complex. If it was built-in, 99.9% of those developers would probably use it, because it is generally superior to the current 8 directions, and wouldn't be any more complex.

That'd mean that BYOND should provide enemies with default AI since that's something complex that many games have. There's more than just that to evaluating how worthwhile a feature is.
They do provide a lot of the basic building blocks for AI, like path-finding and ways to look for targets. Having them build game-specific AI is somewhat impossible. Some games may be shooters, or fighters, they may have cover systems, jumping/flying/height systems, some may be more tactical like chess; all of these concepts require completely different game-specific AI that can't really be predicted or generalized.

Then again, if they were to develop a common fighter engine, that was capable of implementing custom skills, it could probably be adapted to a shooter. A generalized turn-based RPG type AI would probably also be possible. Having these things built-in would further steer game development, but would probably be generally beneficial.
That seems a bit contradictory?

I meant to say "...not necessarily making the platform better".

The issue is more that, if it isn't built-in, there isn't even going to be a difference to compare to, because 99.9% of developers aren't going to bother building their own systems for something so basic yet so complex

If someone needs the angular_walk() proc but can't or won't write it, they're a terrible programmer and there's nothing we can do to fix that. Their best shot at making a game is by downloading an existing game's source code and making some changes.

it is generally superior to the current 8 directions, and wouldn't be any more complex.

There are many different kinds of games out there. It seems like you're working on a particular project and, for that project of yours, this might be better than 8-directional movement. You think it's a very useful feature because you have a need for it but that doesn't mean it's particularly useful. Remember, there are still lots of games (board games, card games, etc.) that don't need pixel movement and certainly don't need angular movement.
In response to Forum_account (#9)
Forum_account wrote:
If someone needs the angular_walk() proc but can't or won't write it, they're a terrible programmer and there's nothing we can do to fix that.
It has little to do with them being a terrible programmer. For starters, as a game engine, BYOND should already have basic features like this. Most people who aren't terrible programmers wouldn't even be using BYOND to begin with, because it is a terrible engine. There is also far more to making effective angular movement than just basic programming. You need knowledge of trigonometry and specific formulas for both calculating angles and calculating the movement speed/distance for these angles. As for making it effectively, take that example you linked to a few posts ago; Move() is being used, seemingly by your own suggestion, that would disable all hit detection, and therefor wouldn't function very well for most cases of movement.

There are many different kinds of games out there. It seems like you're working on a particular project and, for that project of yours, this might be better than 8-directional movement. You think it's a very useful feature because you have a need for it but that doesn't mean it's particularly useful.
Any game where you shoot things would generally benefit from angular movement, and most BYOND games have some sort of projectiles. Vehicle systems can be more "realistically" designed by rotating the vehicle to determine its direction. Now that pixel movement is in, basic get_dir() calculations are generally lacking, so being able to pull and compare a proper angular direction would be an improvement. It can be useful for special "particle" effects. etc

Remember, there are still lots of games (board games, card games, etc.) that don't need pixel movement and certainly don't need angular movement.
Most board games have cards, card games obviously do, even for simple effects like moving cards from a deck to a player's hand would look much better with a direct angular path, instead of the current partially angular path until things line up and then a straight line.
Ter13 resolved issue (Redundant)

Move() already takes step_x and step_y arguments.