ID:117471
 
I'm not sure what will happen to my Pixel Movement and Sidescroller libraries once built-in pixel movement is added. It would be nice if the built-in feature eliminated the need for these libraries but it doesn't look like that'll be the case. For the Sidescroller library there are some things that the built-in feature isn't likely to have (gravity, ladders, etc.). The Pixel Movement library has fewer such features, though it does have gravity and 3D movement (I'm not sure if the built-in feature will support this).

Not much information has been provided so I'm not sure how extensible the feature will be. It sounds like things will be handled internally and not much will be exposed to the developer for customization. In some ways this could be a setback, I'm not sure if it'll allow for some things (ex: the can_bump proc, 3D movement, ramps). Hopefully there will be some way to make the libraries compatible with the new feature so that anything made that uses the libraries will automatically make use of built-in pixel movement once it's released. I'm not confident that it'll be fully compatible, but we'll just have to wait and find out.

In either case, it looks like the way you use the built-in feature will be awkward so a library will be needed to create an easier way for DM developers to use the feature. This is unfortunate because, at least to me, there's a huge difference in motivation. I'm motivated to add support for features that BYOND lacks, but I'm much less motivated to "fix" features that BYOND botched. For example, the Interface library started as a library to fix a botched feature (winset/winget) but quickly turned into adding support for new features (JavaScript-DM interaction).

No matter how their built-in pixel movement works, the bounds var (described here) will be useful to my libraries. One of the limitations of the libraries is big atoms. For example, if you have an icon size of 32 you can set a mob's pwidth to 128 but it won't really behave as being 4 tiles wide. This is because when it checks for atoms that you collide with, it only looks in view(1). You may be 3 tiles away from the 128 pixel wide mob and be inside of it, but because it's outside of view(1) the library doesn't check for collisions against it. With the bounds var, the 128 pixel wide mob will appear in the view(1) list.

Sidescroller v2.8

I wanted to add ceiling ramps, but ran into some problems and couldn't get them working perfectly. It's been close to a month since the last update and I have enough changes ready that I'll leave ceiling ramps for another update.

The changes are:

  • Changed the SCROLL_X and SCROLL_Y constants to be named REPEAT_X and REPEAT_Y. These names make more sense since they are used to determine in which directions the background repeats. You can make any background move horizontally and vertically, even if it doesn't repeat in those directions.
  • Created the /Controls object which contains the vars up, down, left, right, and jump. These vars contain the keys that correspond to those actions. Each mob has an instance of the /Controls object, so to change a mob's jump key to Z just do: mob.controls.jump = "z"
  • Fixed a bug with the way the stepped_on and stepping_on procs were called. Previously there were times when they wouldn't be called when you land on the ground while not moving horizontally at the same time. Now they should be called in all cases that they apply.
  • Fixed a bug with the behavior of ramps (it was most noticeable in the scaffold ramps in the movement-demo). I think it was caused by the support for fractional moves, but I'm not sure. Whatever caused it, ramps seem to work fine now.
  • Fixed another bug related to ramps. Some cases where you bumped a ramp from the side weren't being handled correctly.


Pixel Movement v3.3

Just a couple of changes to path finding and path following:

  • Changed the way path following (the mob.move_to proc) works. It should improve performance and make use of the move() proc's support for 8-directional moves.
  • Changed the way path finding works. It now makes use of diagonal moves.
Programming with your libraries is a blast. There is so much support for so many features that all you need to do to get a little game working is override a couple procedures. I can only imagine how fun it is to work on your games, like Tiny Heroes. Which I'm really looking forward to :3
Thanks!

I tried to think of what people will try to do with the pixel movement and sidescroller libraries (ex: flying, double jumps, wall climbing, etc.) and code them in such a way that those features would be easy to add. Most features can be added with 10-20 lines of code. Some features have built-in support (ladders, scaffolding, pathfinding) so it's just a matter of setting a var or calling a proc. I didn't always get things right on the first try, but after using the library quite a bit myself (the sidescroller library, at least) I started to get a better idea of how things should be laid out. The Tiny Heroes code is very much the same way. It's very easy to work on, I just haven't had much time lately.

I hope the BYOND staff takes the same considerations into account for their implementation, but I'm not optimistic it'll happen. They don't seem to have the game development experience to know what would make it useful, simple, and versatile. They also don't seem to have much interest in trying to get it right the first time and, based on how other features have turned out, I wouldn't expect to see iterations of drastic changes after its initial release.

On the bright side, as long as their built-in feature doesn't break my libraries they're still completely viable to use. I haven't been making a lot of progress on Tiny Heroes lately, but Bravo1's Tanx nicely shows off what the pixel movement library can do (and, unfortunately, what BYOND's poor mouse handling can't do).
Please continue on, Forum_account. Your library, along with HDK's Mouse and Keys, are two that have shaped Byond's future in great ways. One comical thing that I just realized a fix for was, what do I do with mobs that never move? Objects or Turfs of course!
Resonence wrote:
One comical thing that I just realized a fix for was, what do I do with mobs that never move? Objects or Turfs of course!

Using objs is probably best, but another way is to use mobs and override their movement() proc to make it do nothing:

mob
doesnt_move
movement()


For all child types of /mob/doesnt_move, their movement loop will do nothing. You can use a similar technique to make mobs whose icon_state doesn't change by overriding the set_state() proc to make it do nothing.
which is better byond's built in pixel movement or your library?
Akriloth wrote:
which is better byond's built in pixel movement or your library?

A comparison wouldn't even make sense - my library uses BYOND's built-in pixel movement but adds features on top of that so it is much easier to work with.
Akriloth wrote:
which is better byond's built in pixel movement or your library?

so the answer is byonds pixel movement
Forum_account wrote:
Akriloth wrote:
which is better byond's built in pixel movement or your library?

A comparison wouldn't even make sense - my library uses BYOND's built-in pixel movement but adds features on top of that so it is much easier to work with.

Oh, i didnt know your program used the built-in pixel movement, havent really looked into like that, other than trying out the demos.
The library also has its own pixel movement implementation that had been used in the past. This mode is still needed for some features that the library supports but BYOND doesn't (ex: 3D movement, ramps). The default mode of the library is to use BYOND's built-in pixel movement, so if you include the library in your project you're automatically using built-in pixel movement.