Pixel Movement in Feature Requests

Page: 1 2 3 ... 8 9 10
ID:112359
 
Apr 23 2011, 4:33 am (Edited on Apr 23 2011, 5:13 am)
Resolved
Native pixel movement has been implemented. The following major changes have been made:
  • All movables have a bounding box (bound_x/y/width/height) and can be positioned with the new step_x/y vars. By default, all atoms still use the old tile system.
  • Movables have a step_size var that says how fast they move. The step and walk procs have been updated to take a speed argument as well, but default to the mover's step_size.
  • A new var, locs, says which turfs a movable is actually covering with its bounding box. If a turf is in a movable's locs, that movable is also in the turf's contents.
  • The Move() proc now takes two new arguments, the target step_x and step_y. A move can now "slide" or "jump", and if it slides then it can succeed even after a Bump(). A slide returns the number of pixels moved if successful; jumps return 1 if successful.
  • Within Move(), the Enter() and Exit() procs (and family) can all be called for multiple turfs now.
  • A new family of procs has been added to cover cases of movables trying to overlap each other. They are Cross(), Uncross(), Crossed(), and Uncrossed(). They are similar to Enter(), Exit(), Entered(), and Exited().
  • turf.Enter() no longer pays any attention to items in its contents that do not cover the entire tile. Items that cover the whole tile still count, so old games will work the same.
  • Bump() will only swap two mobs in the same group if neither one of them uses pixel movement. If either one uses pixel movement, Cross() will allow them to overlap instead.
  • New procs have been added to ease the use of working with bounding boxes: bounds(), obounds(), and bounds_dist().
  • Gliding has been deprecated. It only occurs now when atoms do not use pixel movement and move by full tile increments.
Applies to:DM Language
Status: Resolved (490)
This issue has been resolved.
How is there not a request for Pixel Movement on the tracker?
Everyone vote this up so that they can no longer deny what a necessity it is!

My Demands!
- Well... pixel based movement for starters. Instead of moving an entire 32-pixel-tile from a single button press. The current methods make games feel unresponsive, and look graphically inferior.
- The map editor could work generally how it does now, but you should be able to hold a key (Shift?) to place things free of the 32x32 grid. Regardless of pixel movement, this could be a useful implementation.
- If you want to take the map editor a step further, grid sizes could be supplied, to make tiles 8x8, or whatever other size(s) we provide.
- Procs, like walk(), should be able to take a degree as the direction, and move the object off at that angle.
- get_angle() would work somewhat like get_dir(), but provide a more specific angular measurement between the targets.
- The size of pixel steps should be easily adjustable by a variable on movable atoms
- Graphically pixel based hit detection (is this colored pixel touching that one!?), as well as hit-boxes (this mob is 16x32, regardless of him only being a small pair of floating eyes!).
- Things like get_step() should function based on hit-boxes.
- Backwards compatibility/implement-ability, as functionally as possible. If all existing games could easily be brought into using pixel movement, this would be an even greater advancement for BYOND
- I'm sure various technical issues and new ideas, that I haven't considered, will arise as the systems are worked on, and once they are implemented and put to use. Roll with the punches!
- Other stuff! Post your own in the comments below =o
#1 Apr 23 2011, 6:14 pm
Sounds good :O
#2 Apr 26 2011, 6:42 am
A lot of those things are possible now. I'd rather see the staff spend their time adding things that users can't implement themselves.

There aren't a lot of people trying to make games that use pixel movement. I agree that tile-based movement often looks bad, but you're asking the staff to do a lot of work for a feature that might never be used. I think you'll do better if you try making a game with pixel movement and request simple features as you realize they're necessary (ex: the map editor feature you mentioned).
#3 Apr 26 2011, 2:08 pm (Edited on Apr 26 2011, 2:15 pm)
Forum_account wrote:
A lot of those things are possible now. I'd rather see the staff spend their time adding things that users can't implement themselves.
Almost everything is already possible on our end, the question is just how much effort we would have to put in, and the fact that such amounts of effort hardly yield worthwhile results. If they want to have a successful engine, that people are actually interested in, then pixel movement is a bare minimum standard that they need to adopt.

There aren't a lot of people trying to make games that use pixel movement.
Practically every game on BYOND is designed around a pixel movement concept, they simply use unappealing tile movement because that's all BYOND offers.

I agree that tile-based movement often looks bad, but you're asking the staff to do a lot of work for a feature that might never be used.
I'd be willing to bet that every game created after pixel movement's implementation would opt to use it, unlike isometrics. I'd also say that the engine should default to pixel movement once its implemented, like it does with big-icons, which I don't think should be a default. And if it was easily backwards implementable into games, I would surely bring all of my games into it.

I think you'll do better if you try making a game with pixel movement and request simple features as you realize they're necessary (ex: the map editor feature you mentioned).
I've tried that route as well, they seem unwilling to implement even those simple features to help us along. And you actually seemed against it yourself... http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=1222
#4 Apr 27 2011, 9:05 am
Another thing Forum_account has pointed out before, that I think is relevant to this discussion, is that pixel movement can be handled all kinds of ways depending on what you want to do with it, so it's hard to have a catch-all implementation.

For my part I'd rather throw resources into making pixel movement smoother, like freeing it somewhat from our Appearance system and making sure pixel offset changes always stay in sync with loc changes.
#5 Apr 27 2011, 9:34 am (Edited on Apr 27 2011, 9:47 am)
Falacy wrote:
I'd be willing to bet that every game created after pixel movement's implementation would opt to use it

With world.tick_lag set to the default value (which most games use) pixel movement would look terrible. Ten frames per second isn't enough, you'd have to change world.tick_lag and that can affect gameplay (it affects animated icons, if nothing else). I agree completely that most games would look nicer with pixel movement but games wouldn't be able to convert as easily as you'd like.

Edit:
If they want to have a successful engine, that people are actually interested in, then pixel movement is a bare minimum standard that they need to adopt.

I agree, but I'm not sure what the staff can do. Through using my Sidescroller library I've come across some BYOND bugs and they've all been fixed. I don't think I've ever needed a new BYOND feature. Short of making the Sidescroller or pixel movement library themselves, there's not a lot the staff can do to help.

The one thing that would help, which I've asked for several times, is a welcome page that's shown when you start Dream Maker. My pixel movement library has gotten 400 downloads but thousands of people have run DM (maybe even tens of thousands) - most of the people who have run Dream Maker aren't aware of the pixel movement library. I doubt this feature will ever be implemented as part of BYOND, so all we can hope for is a library and the ability to make people aware of it.
#6 Apr 28 2011, 2:16 pm
Almost everything is already possible on our end, the question is just how much effort we would have to put in, and the fact that such amounts of effort hardly yield worthwhile results. If they want to have a successful engine, that people are actually interested in, then pixel movement is a bare minimum standard that they need to adopt.
#7 Apr 30 2011, 4:51 am (Edited on Apr 30 2011, 6:23 am)
Forum_account wrote:
With world.tick_lag set to the default value (which most games use) pixel movement would look terrible. Ten frames per second isn't enough, you'd have to change world.tick_lag and that can affect gameplay (it affects animated icons, if nothing else).
The engine already uses pixel movement internally. You aren't just hopping 32 pixels at a time. If it only runs at 10 FPS, then it must be possible. Even if the engine is hopping you 4 pixels at a time, that would still make games look & feel 8x more responsive, and it would require minimal conversion efforts.

Lets say 4 pixels per frame is how far they move you. The engine is currently forcing you to overstep by 28 pixels. If this overstep restriction was removed, most gameplay aspects could be easily converted over. The biggest changes required would be visual (correctly shooting a blast from your pixel offset hand, though even that could be handled internally by things like locate()), and step-to-speed conversions (you would need to step things 8x as often to accomplish the same movement speed, or step them further pixel distances at once)

If you're stepping something 4 pixels every 1/10th of a second, you can easily move it more than one 32-pixel-tile per second, which is about how long it takes to move a single tile if you just tap a single button. BYOND seems to automatically upscale the pixel step size if you're in constant movement - which it could still do if it had actual pixel-movement. However, if implemented properly, we could easily handle such velocity issues ourselves.

They could also just provide some pixel-movement-only setting, like tick_lag, that wouldn't completely destroy every other aspect of a game, like tick_lag does.

Using the base 32x32 tiles is still required if we make our own pixel-movement, because of limitations on how far you can pixel-offset something (among other reasons), so I don't see why they would need to change much there.

Short of making the Sidescroller or pixel movement library themselves, there's not a lot the staff can do to help. [..] The one thing that would help, which I've asked for several times, is a welcome page that's shown when you start Dream Maker.
That is what they should do. BYOND should come with some sort of default project, which exemplifies how to do many common features, using quality methods. Dream Maker should open to this example project the first time you use it (and after that, automatically open whatever project you last had open), and it should also have some sort of welcome screen (optionally) every time you use it. Unity does.
#8 Apr 30 2011, 6:15 am (Edited on Apr 30 2011, 7:51 am)
Lummox JR wrote:
For my part I'd rather throw resources into making pixel movement smoother, like freeing it somewhat from our Appearance system and making sure pixel offset changes always stay in sync with loc changes.
People making their own pixel movement systems can already do that, using animate_movement and client.pixel_x/y.
If you are actually interested in providing more support for DM based pixel movement, then the addition of a simple feature to make standard BYOND icons compatible with it shouldn't even need consideration, and things like tick_lag (as FA brought up), probably need to be addressed.
#9 Apr 30 2011, 2:42 pm
Falacy wrote:
If you're stepping something 4 pixels every 1/10th of a second, you can easily move it more than one 32-pixel-tile per second, which is about how long it takes to move a single tile if you just tap a single button.

If you only tap the key once the client will take the full second to show the movement, but most games limit your movement rate to one tile every 0.1 - 0.4 seconds. Movements this fast at 10 frames per second look bad. You can run my pixel movement demos with tick_lag set to 1 to see how bad they look.

Once BYOND v482 is posted and this feature is available I'll be posting a significant update to my pixel movement library. All you'll have to do is check the box to include the library and pixel movement will work*. Depending on how long it is before the v482 update, I might have some more "complete game" demos included, which show how to use the new features provided by the library to create projectiles, doors, and other things you might see in a game.

* There's no way the library can be included and work in all projects. You can't handle movement with a finer resolution (at the pixel level) when the game's code only handles movement at a lower resolution (at the tile level). Pixel movement can create situations that the game's code wasn't designed to handle. The code might handle situations a certain way (that isn't pixel-movement compatible) because of assumptions that tile-based movement allowed you to make. Including pixel movement can be easy, but will never be as easy as you want it to be.

My goal is to make a pixel movement library that can be used much like BYOND's default movement system. If you don't need to customize BYOND's tile-based movement for your game, you don't even need to know the names of the procs (Move, Entered, Exit, etc.). Same for my library - if you want to use the default behavior, you don't have to do any work (aside from downloading and including the library). The more you want to customize, the more you need to know.
#10 Apr 30 2011, 5:48 pm (Edited on Apr 30 2011, 5:56 pm)
Forum_account wrote:
Movements this fast at 10 frames per second look bad. You can run my pixel movement demos with tick_lag set to 1 to see how bad they look.
It already is movement that fast at 10 FPS, just smoothed by the engine.
I've made a pixel movement system worked just fine at standard tick_lag. Granted, it wasn't 1 pixel per step, but it was still vastly superior to BYOND's 32.
BYOND devs have access to internal workings, which they are already making use of for tile movement, that should make it quite possible (if not easy) for them to implement smaller step sizes.

Once BYOND v482 is posted and this feature is available I'll be posting a significant update to my pixel movement library.
I'm not sure how you could put special layering to use in order to accomplish pixel movement? Using "big-icons" is bad game design to begin with - I have absolutely no idea why Tom thinks its a superior default. Big-icons can be useful; However, those scenarios are few and far between, and the technical faults big-icons exhibit far outweigh the very few benefits they provide.
Big-atoms, on the other hand, may be a worthwhile implementation. Or maybe big-icons on a per-atom basis, so we could make use of those few beneficial scenarios (like HUDs).
#11 Apr 30 2011, 8:36 pm
Falacy wrote:
Lummox JR wrote:
For my part I'd rather throw resources into making pixel movement smoother, like freeing it somewhat from our Appearance system and making sure pixel offset changes always stay in sync with loc changes.
People making their own pixel movement systems can already do that, using animate_movement and client.pixel_x/y.
If you are actually interested in providing more support for DM based pixel movement, then the addition of a simple feature to make standard BYOND icons compatible with it shouldn't even need consideration, and things like tick_lag (as FA brought up), probably need to be addressed.

The sync issue I mentioned is actually something different. That is, loc and pixel offsets aren't updated at the same time and it is possible (though uncommon) for them to get out of sync.

Actually I've always liked your forced movement suggestion; I've just never had a good idea of a way to handle that without adding another var. Tom usually isn't keen on adding built-in vars/procs unless they'll see a lot of use. One nice thing about it though is like atom.override, it would only take up one bit in the relatively uncrowded appearance bits set.
#12 May 1 2011, 5:21 am
Falacy wrote:
I'm not sure how you could put special layering to use in order to accomplish pixel movement?

Pixel-based movement lets you more easily handle situations where you can walk on top of or behind obstacles, but BYOND's default laying screws up these situations (this feature request has additional picture examples). Obviously pixel-movement is possible without this feature, but having it'll simplify the library itself and simplify how you use the library.

BYOND devs have access to internal workings, which they are already making use of for tile movement, that should make it quite possible (if not easy) for them to implement smaller step sizes.

Of the eleven points listed under "My Demands!" in the feature request: two aren't specific features (the last two), one would require a built-in implementation (the first map editor request), the other eight are possible with user-made implementations:

- (already possible) Well... pixel based movement for starters. Instead of moving an entire 32-pixel-tile from a single button press. The current methods make games feel unresponsive, and look graphically inferior.
- (not possible) The map editor could work generally how it does now, but you should be able to hold a key (Shift?) to place things free of the 32x32 grid. Regardless of pixel movement, this could be a useful implementation.
- (already possible w/ world.icon_size) If you want to take the map editor a step further, grid sizes could be supplied, to make tiles 8x8, or whatever other size(s) we provide.
- (already possible) Procs, like walk(), should be able to take a degree as the direction, and move the object off at that angle.
- (already possible) get_angle() would work somewhat like get_dir(), but provide a more specific angular measurement between the targets.
- (already possible) The size of pixel steps should be easily adjustable by a variable on movable atoms
- (already possible) Graphically pixel based hit detection (is this colored pixel touching that one!?), as well as hit-boxes (this mob is 16x32, regardless of him only being a small pair of floating eyes!).
- (already possible) Things like get_step() should function based on hit-boxes.
- (already possible*) Backwards compatibility/implement-ability, as functionally as possible. If all existing games could easily be brought into using pixel movement, this would be an even greater advancement for BYOND
- (not specific) I'm sure various technical issues and new ideas, that I haven't considered, will arise as the systems are worked on, and once they are implemented and put to use. Roll with the punches!
- (not specific) Other stuff! Post your own in the comments below =o

* It's just as possible for a library to pull this off as it'd be for a built-in solution to pull this off.

Yes, the staff could implement pixel movement, but why is it necessary that the staff implement it? According to your list of features, there's only one that users can't make themselves (and it's not at all an essential feature). I don't think the staff is going to spend their time implementing lots of features that we could already implement ourselves just to add this one feature we couldn't. I've said right along that you'd be better off requesting individual features that would help to improve user-made pixel movement systems instead of asking for a complete built-in solution, and this feature request is a perfect example of why.
#13 May 1 2011, 5:35 am (Edited on May 1 2011, 5:52 am)
Of course its already possible, practically anything is. I could make a full blown 3D game with BYOND if I really really wanted to. However, it would be a ridiculous amount of wasted unrewarding work, and would effect a very small amount of (if any) other projects.

If BYOND wants to be taken seriously, then pixel movement needs to be built in, so that every new user/developer can play/make respectable games. This shouldn't even be a debatable point from any angle, and the fact that any members of the community, or that the BYOND developers themselves are so adamantly against it is just idiotic. "No, we don't want improvements to make the engine vastly superior!"

There are a lot of steps that need to be taken towards that goal, and admittedly, pixel movement is probably the biggest, but since they don't seem to be willing to works towards any of them, might as well shoot for the pixel movement.


Forum_account wrote:
I've said right along that you'd be better off requesting individual features that would help to improve user-made pixel movement systems instead of asking for a complete built-in solution, and this feature request is a perfect example of why.

Except, even when I do do that, you still go against it, making the same ridiculous claims that you've made here.
How many games have been made using your pixel movement library(s)? 1.5? How many games have been made with BYOND in general since your pixel movement library was released? 10 times that? More? I can (and do) build systems above and beyond anything BYOND itself offers, that doesn't help 99.9% of the other developers though...

The only reason DM based pixel movement for multiplayer games (which all BYOND games should be) is even a viable option at this point is because of my situational testing and rallying to get networking improvements made.
Generally, the feature requests I make are for wide-scale improvements that would positively effect most, if not all games on BYOND. Rarely do I request some minor new feature for something that can easily be worked around, because I'm used to having majority of my time with BYOND spent finding workarounds for its failures.
#14 May 1 2011, 7:32 am
I agree with most of what you're saying. Essentially, your argument is:

1. Many BYOND games would benefit from using pixel movement.
2. Pixel movement can be implemented in a user-made library.
3. Being built-in makes the feature more available to developers than a user-made library could ever be.
Conclusion: Make pixel movement built-in.

And it makes sense, but there are some more fundamental problems here.

The staff is right to say that some features are better handled by user-made resources (whether pixel movement is such a feature is a separate issue), but they're wrong to assume that this means they can get away with doing zero work to address these issues. For example, the majority of DM tutorials are not made by the BYOND staff. The staff doesn't have time to create and maintain these tutorials and I don't expect that they would make them, but here are some things they could do to help:

1. Maintain a list of topics that we need tutorials to cover / maintain a page that maps topics to existing tutorials.
2. Read user-created tutorials and offer feedback or help to improve them, promote that others do the same.
3. Feature some tutorials inside the Dream Maker program.
4. Link to relevant tutorials from DM reference pages (on the site and in the DM program).

But they don't do anything.

I'm not sure why, but the staff doesn't seem to realize that BYOND as a whole (themselves included) would benefit if the quality of BYOND games improved. I really don't know why this is. Maybe the staff doesn't realize how big certain issues are because they don't really make games. Maybe, because of the wealth of sub-par games, it's easier to ignore the issue than to admit that BYOND would be more successful if it had better games. Maybe they do realize how they'd benefit from this and they just assume that by making a quality tool, people will use it to make good things and it's not their responsibility to help people use the tool.

That's a long way of saying that a built-in solution would only cover up other problems.
#15 May 1 2011, 8:51 am
The main problem with #1 on the list is the word "maintain". There's just no time or manpower to do that properly. Overall though the items on that list boil down to improving communication between tutorial authors and staff, which would allow us to more easily add the appropriate comments to the reference pages. (#4 also entails a DM change I've had in mind for a while but haven't worked out yet, bringing online reference comments into program itself.)

Those issues don't get tackled not because of unwillingness to do so, but for lack of a clear road map. We do however realize that better games improve BYOND, which is part of the reason behind the recent feature push.
#16 May 1 2011, 10:09 am
went from four votes to 15 in the last hour. i'm trying hard, along with others, to get this voted up because we need it so badly
#17 May 1 2011, 10:46 am
Falacy wrote:
The only reason DM based pixel movement for multiplayer games (which all BYOND games should be) is even a viable option at this point is because of my situational testing and rallying to get networking improvements made.

Pffffhhhaaaahahaha
#18 May 1 2011, 1:17 pm
Yut Put, if you'd like to see movement on something in here then I recommend adding more specific requests because the laundry list in the request itself is both a little too vague and lot too broad. As written right now, the request is too open-ended and would represent a major overhaul of the engine without clarifying how to handle a number of important issues--like how bumps would work if your atom was offset by a partial tile, for instance.

I agree in principle that some kind of built-in pixel movement would be nice, but as I mentioned it would also vary in purpose and use so much in different games that it'd be hard to do in a truly universal way.
#19 May 1 2011, 4:38 pm (Edited on May 1 2011, 6:21 pm)
Lummox JR wrote:
The main problem with #1 on the list is the word "maintain". There's just no time or manpower to do that properly.

Maybe I wasn't clear - you'd be maintaining the list of tutorials/topics, not the tutorials themselves. You'd need a webpage that lists all tutorials grouped by topic and could occasionally make posts saying "BYOND doesn't have a good tutorial about ______, so we're offering a free membership to the person who can write the best _____ tutorial by next month."

Those issues don't get tackled not because of unwillingness to do so, but for lack of a clear road map.

There are no signs of trying to develop a road map. I've said before that the staff could make better use of their development blog and this is exactly why. BYOND game developers can use their blogs to get feedback on ideas for their projects, so can you. Write a post about the problems with BYOND you'd like to address and see what suggestions people come up with, then take the better ones and try them out. The worst case is that you don't get any good suggestions and are left in the same situation you're in now. If nothing else, these posts would let the community know that you're unhappy with certain aspects of BYOND.

Yut Put, if you'd like to see movement on something in here then I recommend adding more specific requests because the laundry list in the request itself is both a little too vague and lot too broad. As written right now, the request is too open-ended and would represent a major overhaul of the engine without clarifying how to handle a number of important issues--like how bumps would work if your atom was offset by a partial tile, for instance.

I would love if you implemented pixel movement because it'd save me a lot of time but I don't see any reason why it has to be a built-in feature*. With the staff being more receptive to feature requests and bug reports lately I've been sure to report any BYOND issue that impedes my progress - there just aren't any issues. The only thing I can think of is that it'd be nice to be able to override global procs (like step, walk, walk_to, etc.) so that they behave differently if you're using my pixel movement library, but I just used different names instead (it's kind of annoying though, by reserving "step" and "walk" there aren't many names left).

* The biggest issue with pixel movement is CPU usage, but this is mostly because it almost requires a lower value of world.tick_lag and this will increase CPU usage no matter what. To be able to customize the built-in pixel movement system you'd need to be able to override parts of it. This means that things would have to be handled in soft code and you wouldn't really be able to take advantage of your ability to handle things internally.
Page: 1 2 3 ... 8 9 10