Pixel Movement in Feature Requests

Page: 1 2 3 4 ... 8 9 10
#20 May 1 2011, 7:28 pm
I really don't think a built-in implementation of pixel movement will even come close to how you wanted it to work, you'd have to re-do most of the game & probably even want to change the built in pixel-movement code or work-around things you didn't like because of its implementation.

---Your not going to get the flexibility you want from a built-in implementation & should almost certainly be handled yourself by your own code.

--However I do feel that libraries & such for things like this of quality work & for basically anything that's of quality work should be given more visibility somehow.

-Anyways I understand your frustration but as Lummox said it's a huge overhaul & not much information supplied on how everything might work, then theres loads of changes to be made anyways if you already have a game using tile movement, maybe even new icons, etc... because the movement animations & how you look entering certain things, what happens when you turn, etc...

* This seems like it could only be used on a game that started with pixel movement because it'd probably take more work to bring your current game into pixel movement that it'd be ridiculous & maybe even re-mapping & stuff for places you don't like with the new system maybe even rounder edges since you can actually move off a tile & not limited to 4 directions.
#21 May 1 2011, 8:05 pm
I hardly use any procs that are built into BYOND as it is since I can make it much better by doing it myself. I don't trust that built-in pixel movement would be an exception.

That said, BYOND has always been about being easy to use for beginners with these built-in procs. An easier way to convert to pixel movement wouldn't be a bad idea, kind of how isometric works.
#22 May 1 2011, 10:24 pm (Edited on May 1 2011, 10:43 pm)
Superbike32 wrote:
Your not going to get the flexibility you want from a built-in implementation & should almost certainly be handled yourself by your own code.
I don't see why you and/or Lummox thinks this. There is no possible way that pixel movement could be LESS flexible than tile movement. In fact, you should logically have to build pixel movement into tile movement (not vice versa) - it would be rather easy, by simply looping a few steps. If BYOND properly handled some type of pixel_step_size setting on movable atoms, then it could probably be as easy as changing that variable to 32. I'm not sure what type of flexibility issues you're referring to...

& not much information supplied on how everything might work
I provided a decent amount of suggestions. If they need more information, they can feel free to ask. As I said in the request, its very common for new issues to arise while developing, regardless of how well you have things planned out. And when/if pixel movement is actually implemented, I'm sure it will lead to a hoard of new issues & requests.

then theres loads of changes to be made anyways if you already have a game using tile movement
I've been over that multiple times in this topic alone, there really isn't.

maybe even new icons, etc... because the movement animations & how you look entering certain things, what happens when you turn, etc...
New icons surely wouldn't be required, though you may be able to improve upon them nonetheless. Turning shouldn't be effected at all by pixel movement vs tile movement...
#23 May 2 2011, 5:23 am (Edited on May 2 2011, 5:39 am)
Fugsnarf wrote:
An easier way to convert to pixel movement wouldn't be a bad idea, kind of how isometric works.

When I post the update to my pixel movement library I'll also be posting a video to show how you can convert to pixel movement just by checking the box to include the library. If I have time I might add examples of how tile-based features can still work even after you include the library.

Falacy wrote:
There is no possible way that pixel movement could be LESS flexible than tile movement.

What we're saying is that pixel movement can work many different ways, so it's unlikely that the default behavior would be sufficient. I expect that very few games use the default tile-based movement, most people need to override some movement procs to make the game work how they want.

then theres loads of changes to be made anyways if you already have a game using tile movement
I've been over that multiple times in this topic alone, there really isn't.

There really is. A lot of assumptions can be made when you use tile-based movement. For example, you can do this to limit movement speed:

mob
    var
        locked = 0
    Move()
        if(locked) return 0
        locked = 1
        .= ..()
        spawn(3) locked = 0


But things like this don't transfer over to pixel movement. There is also the assumption that the mob is standing in the center of a single tile. What should view() return if you're standing partially between two tiles? If the behavior of these procs changes when you enable pixel movement, what do you do if you want to access their tile-based behavior? Also, when you assume that a move takes you from the center of one tile to the center of another, it's obvious when Exit, Enter, Exited, and Entered should be called. When you can move pixels at a time, when precisely do you enter or exit a turf?

Edit: another issue: when you set an object's loc you are only being precise to the tile. When you're using tile-based movement that's fine, but when you have pixel based movement it's not. Suppose you want to move an item from the player's inventory to the ground at their feet, just setting the item's loc to be the mob's loc wouldn't cut it. What if you wanted to swap the positions of two mobs - you can't just swap their locs. There's no way for old code to work exactly how you'd want it to.
#24 May 2 2011, 8:10 am
This is my point exactly. The tile-based environment allows for assumptions that are strewn throughout the code and going with a pixel-based approach would raise many questions and require many changes. Heck, the reason we still don't have built-in big-atom bumping, view(), etc. is because of these very same questions.

The considerations involved in making pixel movement native are nontrivial, and I think many games would use pixel movement differently. There's the obvious approach where an icon and its hit box take up a whole tile, which still raises a lot of difficult view() and Bump() questions, and then there are less-obvious cases like atoms that don't take up a whole tile. Many of these cases can be reconciled, but not all. (I also honestly don't think pixel-based collision checking is all that feasible.)

But all that being said, if there were clear answers to the view() and Bump() questions (and others like them), I do think some kind of basic native pixel movement system would be pretty beneficial, and probably we could come up with one that would fit the majority of users' needs. It's just that such a project is rather huge even if the implementation path is clear, which it presently isn't.
#25 May 2 2011, 1:37 pm (Edited on May 2 2011, 2:28 pm)
Forum_account wrote:
For example, you can do this to limit movement speed:
First off, that's a horribly unresponsive way to limit movement speed, and shouldn't be used outside of Zeta rips. Second, the change to pixel movement would somehow have to handle the "sliding" caused by movement, just like it does now with the tile based movement, since moving something on the pixel level 10 times per second will rarely suffice. Finally, I can only speculate on how such things are/would be implemented, but any necessary modifications to such a movement limitation should take a few minutes at worst.

What should view() return if you're standing partially between two tiles?
The same thing it returns now. As I stated earlier, there would most likely be no change to the base tile handling. We can't get away from such tile limitations in our own pixel-movement, which you seem to be blindly in support of. If game devs want to make sure everything possibly in view is captured, they can make such simple additional calculations themselves, but it shouldn't be necessary, especially for existing games. There is also the possibility of having pixel based versions of all these procs, pixel_view().

Also, when you assume that a move takes you from the center of one tile to the center of another, it's obvious when Exit, Enter, Exited, and Entered should be called. When you can move pixels at a time, when precisely do you enter or exit a turf?
Again, tile existence wouldn't be changed; we can't get rid of it in our own pixel-based systems. You would graphically transition between a 32 pixel tile after moving at least 32 pixels, this is when entered/exit would be called. A new proc could be added, which would be called if you take a step that doesn't change your tile; in case you decide to run around in circles in a single tile of lava or the like.

when you set an object's loc you are only being precise to the tile.
I mentioned this before as well; the engine could handle procs like locate() easily enough - if the argument is an atom. Again, such changes will depend on how exactly pixel locations are stored/handled (The DM level equivalent of pixel_x/y).

There's no way for old code to work exactly how you'd want it to.
Maybe not exactly, but it shouldn't degrade to the point of being game breaking. Dropping a potion at your location, even if its several pixels off, isn't going to have much of a negative effect.


Lummox JR wrote:
But all that being said, if there were clear answers to the view() and Bump() questions (and others like them), I do think some kind of basic native pixel movement system would be pretty beneficial, and probably we could come up with one that would fit the majority of users' needs. It's just that such a project is rather huge even if the implementation path is clear, which it presently isn't.
That was more or less the point of: 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!. Start working with it, see what feels right and what doesn't, and make the necessary changes as you go along. Even if you spend the next 8 years planning out every point of a pixel movement update, I'd be willing to bet majority of it would fall apart halfway into actually implementing everything.

For starters, we need a new DM variable that will determine how far an atom moves (32 pixels by default), which can be set to any numerical value through the code (1-32?). Once you move a full 32 pixels, it transitions you to a new tile, just like it would now. Once this is implemented and functional (that's pixel movement!) all of the higher (or lower?) level concepts can be addressed.
For this alpha version, hit detection could work off what it does now, taking full tiles into account. If you're 8 pixels into a tile, but about to take a 28 pixel step into a wall, then it should be denied. Though, in a final version, you would most likely want the atom to move as close to the wall as possible, based on defined hit-boxes.

An important part of this transition is to make sure that movement speeds can be maintained, possibly even exceeded, even though the step sizes may be technically smaller.
#26 May 2 2011, 2:25 pm
Falacy wrote:
You would graphically transition between a 32 pixel tile after moving at least 32 pixels, this is when entered/exit would be called.

If you use Enter to prevent a mob from entering a tile, using tile-based movement the mob cannot step inside the tile at all (because they're either inside the tile or not). With pixel-based movement there's some gray area. Consider this picture: http://files.byondhome.com/Forumaccount/ pixel-move-problem-1.png

According to you, Enter and Exit aren't called until the last picture ("after moving at least 32 pixels"), but clearly the mob had begun to enter that tile long before that moment.
#27 May 2 2011, 2:41 pm (Edited on May 2 2011, 4:42 pm)
It would probably work best based on the atom's hit-box. In which case, it would be somewhere between that 1st and 2nd frame.

This could lead to a few issues. Issues that could be handled by the game-dev. IE: If you were to enter some sort of swimming mode when stepping into water (Think SNES Zelda), you would still be graphically on land. The game-dev would need to do a simple check to make sure you're far enough into the water before making such a graphical transition. Most likely, this would just require some basic math to check if pixel_x>=16 for example.

If you were at any point between tiles, like in that middle frame, then tile transitions would happen every time you moved either left or right. However, if you were to continue moving further into a single tile, then that wouldn't occur. This is where a new proc, for moving inside the same tile would be called. You need to determine if the player is far enough out of the water to not be swimming anymore.

Also, I'm not sure if you're trying to make a point about Enter vs Entered, but they would still be triggered in the same general circumstances. Enter would occur when attempting to enter the new tile, Entered wouldn't occur until afterward.
If you somehow ended up halfway inside a wall, moving further inside it should then be disabled, while walking out of it would still work. Similar to how it would work now, if you had a 2 tile thick wall, and somehow ended up on one.

Double also, and on a somewhat unrelated note to your comment, hit-boxes should probably be defined in some sort of text string, like screen_loc "8,1 to 24,32" Unlike screen_loc, there should be some built-in proc to recover these numerical values (which should be added for screen_loc too). This system could possibly even replace/augment density, instead of being something completely separate.

The atoms graphical position could also be based on hit-boxes. Their 0,0 position would basically be 8,1 of the actual icon, or wherever you have the bottom-left hit-box coordinate set. This could be especially useful for something like a 96x96 icon, with a player base in the middle, and sword animations that extend into the blank space (useful big-icons). Though, this offset method could cause problems for existing projects. Some system to optionally apply these default hit-box pixel offsets, on a per atom basis, would probably be preferable here.
#28 May 2 2011, 6:34 pm
Fugsnarf wrote:
That said, BYOND has always been about being easy to use for beginners with these built-in procs. An easier way to convert to pixel movement wouldn't be a bad idea, kind of how isometric works.

Here's a video showing a sample world using tile-based movement, then showing how it works when you merely include my pixel movement library. The library used in the demo hasn't been posted yet, so you won't get the same results if you try it yourself, but the update will be posted sometime this week.

Video demonstrating pixel movement using my library
(edit: a note to the BYOND staff: around 0:47 in the video you can see the camera getting out of sync with the mob and how jerky it looks)

Falacy wrote:
It would probably work best based on the atom's hit-box. In which case, it would be somewhere between that 1st and 2nd frame.
If you were at any point between tiles, like in that middle frame, then tile transitions would happen every time you moved either left or right. However, if you were to continue moving further into a single tile, then that wouldn't occur.

The problem is that Enter/Exit are called when the mob moves from one turf's contents list to the other. The default behavior can't work how you'd hope it would work.

For starters, we need a new DM variable that will determine how far an atom moves (32 pixels by default), which can be set to any numerical value through the code (1-32?). Once you move a full 32 pixels, it transitions you to a new tile, just like it would now. Once this is implemented and functional (that's pixel movement!) all of the higher (or lower?) level concepts can be addressed.

PixelMovement by Ebonshadow does exactly what you're asking for, but if you play around with it for a little while you'll realize that it's not capable of transforming boring games into awesome games.
#29 May 3 2011, 10:25 am
Making pixel movement the default behavior and backwards compatible into old games; you know that's asking the staff to completely remake the entire engine basicly? DM is based entirely around the grid and tiled movement, they've made in lenient enough so you can change the grid so it's not all 32x32, and added client features to make pixel movement very doable as a soft-code engine. Which Forum-account thankfully already did a very good job of. This feature would require more work and time than it took to come out with BYOND 4.0 most likely. They've given you enough, and more, to work with, so use it.
#30 May 3 2011, 10:51 am
The fact of the matter is pixel movement isn't really the issue here. We've had multiple forms of pixel movement over the years and Forum_account's lib is the latest edition to a long list of demos.

The root problem is BYOND's antiquated netcode. It renders most forms of pixel movement inadequate for use over a network. Rather than focusing on native pixel movement I think it would be a better allocation of resources to work on BYOND's network optimization.
#31 May 3 2011, 11:35 am
Games with pixel movement function poorly over a network for the same reason any other game functions poorly: almost all processing is done on the server. This is what makes BYOND game development so simple but also what holds it back.

In World of Warcraft, movement is handled on the client. When you press up, your game client figures out if you can move forwards, performs the move, and notifies the server of your position change (the server then relays these updates to other players). In BYOND games, movement is handled on the server - when you hit a key the client tells the server what command should be run, the server executes the command, and if your position changes as a result your client will be notified.

As a result, movement in WoW remains smooth even if my connection to the server is shaky. The consequence for the developers is that they have to build the game client and manage the communication protocol. Movement in BYOND games is prone to lag because the server manages movement, but the bonus is that all games use a generic client and the game developers don't have to build the client or deal with the network communication.

No matter how much BYOND is optimized things will lag because everything is managed by the server.
#32 May 3 2011, 7:17 pm (Edited on May 3 2011, 7:34 pm)
Forum_account wrote:
Here's a video showing a sample world using tile-based movement, then showing how it works when you merely include my pixel movement library.
lol Are you finally hopping off that delusional rant about how implementing simple pixel movement would break literally every aspect of a game, and be impossible? That video seems to be an example of exactly what I've been telling you all along.

* Stuff about the server handling everything, instead of the client *
IMO, this is somewhat preferable. Having the client handle things may give players a slightly smoother experience on their end, but it can cause an overall disconnect feeling with the game (everyone other than you looking laggy). I'd prefer the small lag that BYOND's fully server sided processing causes, compared to the bullshit lag issues that games like S4 display, where a player with a slow connection becomes an invincible rubber-band. Having everything server-sided is also a major cheat deterrent. However, on that same note, things that are purely client sided could be an acceptable improvement - like my other feature request for client sided dynamic graphics. You can also cut down on communication/lag with BYOND by turning things like movement into simple loops.

The problem is that Enter/Exit are called when the mob moves from one turf's contents list to the other. The default behavior can't work how you'd hope it would work.
Why not? What I'm suggesting is pretty much how it already works, and would be how you could/would handle it in DM based pixel movement. I guess it could cause some problems with get_step()...?

PixelMovement by Ebonshadow does exactly what you're asking for, but if you play around with it for a little while you'll realize that it's not capable of transforming boring games into awesome games.
I haven't used it, so I'm not sure what its capable of, but that probably is the case. I'm not saying its going to make horrible games great. It will most likely make them better, but it may not even take them from bad to good. It could, however, make already great games awesome. And it should give a pretty blatant advantage to any games created after its implementation.


Bakasensei wrote:
Making pixel movement the default behavior and backwards compatible into old games; you know that's asking the staff to completely remake the entire engine basicly?
Not at all. I'm pretty much only asking them to remake the movement itself. Though, if they want to recreate every proc with a pixel alternate, then that would be fine with me. And I'm not asking them to force pixel movement into all existing games, simply make it an option developers could easily toggle - like a functional version of isometrics

This feature would require more work and time than it took to come out with BYOND 4.0 most likely.
Hardly. 4.0 was a mass of completely new features, and changes to default existing behavior that all required backwards compatibility. Pixel movement would more or less only be changes to existing systems, and wouldn't necessarily effect backwards compatibility of existing games at all. Not to mention, 4.0 was so horrendously buggy for months (if not years) after its release, that it was flat out unusable. Pixel movement should be much more comparable to the isometric update they released a while back, it could quite possibly require even less work than that.
#33 May 4 2011, 5:38 am
Falacy wrote:
Are you finally hopping off that delusional rant about how implementing simple pixel movement would break literally every aspect of a game, and be impossible? That video seems to be an example of exactly what I've been telling you all along.

You've been asking for two things: ease of use and backwards compatibility. The problems with existing movement procs are why backwards compatibility is not feasible. The video shows ease of use. The library works in the video because its being added to such a simple project. I can add some effects that rely on get_step, Enter, and other movement procs to show how backwards compatibility is often not possible.
#34 May 4 2011, 5:37 pm
Backwards compatibility and ease of use should be one and the same for this implementation. The addition of pixel movement shouldn't make it any more difficult to develop games, nor should it have much effect on existing ones - even if they do convert to it. It should, however, open up several new development avenues, and provide a quality increase for all projects in general.

Basic movement procs, like Enter, shouldn't need much, if any changes made to them, aside from a new proc that gets called when movement doesn't actually change your tile. As I said in my demands, get_step() should take hit boxes and whatever new variable is used to determine step size into account - though overriding built in procs like get_step() isn't possible for DM based pixel movement.

Its basically just saying: Instead of moving 32 pixels at once, move 4. Lowering all calculations to automatically take this into account shouldn't be all that complicated.
#35 May 5 2011, 5:50 am
Falacy wrote:
Backwards compatibility and ease of use should be one and the same for this implementation. The addition of pixel movement shouldn't make it any more difficult to develop games, nor should it have much effect on existing ones - even if they do convert to it. It should, however, open up several new development avenues, and provide a quality increase for all projects in general.

Backwards compatibility would be a way to make it easier to use, but its not feasible. There are other ways to make it easy to use.

Your idea of just making the mob move a few pixels at a time (determined by their step size) wouldn't work as well as you imagine. If the step size isn't a divisor of the tile size, it's easy to create passages that mobs can't navigate. For example:

####
#  #
#
#o #
####


If the mob (the "o") wants to move out of the room they'll have to move up 32 pixels and right 64 pixels. If their step size is 5, they can't get out of the room because they can't move up 32 pixels, they can go either 30 or 35.

get_step() should take hit boxes and whatever new variable is used to determine step size into account

get_step returns a turf. So no matter what arguments it takes, it'll return a turf and you'll lose whatever pixel precision you were trying to achieve. For example, if you wanted to find targets for a melee attack you might do this:

for(var/mob/m in get_step( ... ))


Even if get_step takes your step size into account, it'll return a tile so you're not looping through mobs within one step of the player, you're looping through all mobs that are anywhere inside of the tile that's one step in front of the player.

My library includes a proc to do what you probably want in this case, but it's meant to facilitate ease of use, not backwards compatibility:

for(var/mob/m in src.front(8))


The front(8) proc returns a list of all atoms that are within 8 pixels of the front of the mob.

Using my library for pixel movement is just like using BYOND's tile-based movement, if you don't need to change how it works you don't need to know anything about it. My library will be the same, if you don't news to write any code that involves movement or positions, you won't need to learn any new vars or procs.
#36 May 5 2011, 5:58 am (Edited on May 5 2011, 6:22 am)
Forum_account wrote:
If the mob (the "o") wants to move out of the room they'll have to move up 32 pixels and right 64 pixels. If their step size is 5, they can't get out of the room because they can't move up 32 pixels, they can go either 30 or 35.
First off, that would more or less be a fail on the game-developers end, and its under the assumption that you're a 32x32 box - trying to fix through a 32x32 box.
There could be a system that "slides" you around tiles if you're partially walking against their edge, most games have something similar. http://www.youtube.com/watch?v=PmAtMbU_cEo

get_step returns a turf. So no matter what arguments it takes, it'll return a turf and you'll lose whatever pixel precision you were trying to achieve. [...] Even if get_step takes your step size into account, it'll return a tile so you're not looping through mobs within one step of the player, you're looping through all mobs that are anywhere inside of the tile that's one step in front of the player.
I suppose. Even if get_step() had to be completely replaced with some pixel-based equivalent, it wouldn't be that big of a deal. I'm not saying this should be some 100% automated changeover for existing games, where you can just change a single variable, and everything magically works. I'm just expecting it to be as close to that as possible. Several hours of work to convert a project would be acceptable, especially if it could maintain every aspect of gameplay, while become multiple times more responsive and graphically appealing.
#37 May 5 2011, 6:41 am
Falacy wrote:
There could be a system that "slides" you around tiles if you're partially walking against their edge, most pixel movement games have something similar.

There *could* be such a system, but that's not what you asked for :-)

I'm not saying this should be some 100% automated changeover for existing games, where you can just change a single variable and everything magically works. I'm just expecting it to be as close to that as possible. Several hours of work to convert a project would be acceptable, especially if it could maintain every aspect of gameplay, while become multiple times more responsive and graphically appealing.

The amount of work depends on the game and how its coded. Some things might be easy to change (like the example of changing get_step to front in my precious comment), but some things might be more difficult.

There's only so much that can be done to make the conversion easier. The worst case conversion is that you have to rewrite the feature entirely. My goal is to provide pixel equivalents or alternatives to useful built-in procs to make development (from scratch) easy. Making development easy makes the worst case conversion easy.

With all that's been said, I still don't think there's an answer to why this has to be a built-in feature that the staff implements and maintains.
#38 May 5 2011, 6:44 am
Forum_account wrote:
There *could* be such a system, but that's not what you asked for :-)
Sure it was: "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!"

With all that's been said, I still don't think there's an answer to why this has to be a built-in feature that the staff implements and maintains.
Because tile based movement != good games, unless those games are tactical in design - where only tiles matter. DM based pixel-movement cannot be effectively accomplished without destroying everything via tick_lag, and I don't support the use of libraries to begin with. Built in pixel movement should be a pro for most existing games, all games created after its implementation, provide a bigger draw for general gamers/developers, bring BYOND up to some half decent standards, and not have any cons if implemented competently...
#39 May 5 2011, 7:24 am
Falacy wrote:
DM based pixel-movement cannot be effectively accomplished without destroying everything via tick_lag

If you want games to be "more responsive and graphically appealing" you'll have to lower tick_lag. This isn't an opinion - for as long as motion pictures have existed people have known that 10 frames per second is insufficient.

I agree that tile-based movement often makes BYOND games look awkward, but its not the only problem. Almost all games (byond or not) look bad at 10 fps. Adding pixel movement to BYOND won't change that, 10 fps will still be insufficient. It would have to use a higher framerate, so I'm not sure what problems you think a built-in solution could avoid.
Page: 1 2 3 4 ... 8 9 10