In response to Tiberath
Tiberath wrote:
Only good for one genre? BYOND has survived for over a decade with just tile movement which has generated games for all genres. Obviously something about it works. It might not work exactly how you want it too, but it clearly works. Please don't attempt to speak for all developers so casually.

BYOND as a whole has probably pulled in as many players as a single great flash game. And far less than any "real" game out there. You're saying if BYOND had pixel movement you'd still opt for tile based? Majority of game genres are just flat out better when you aren't moving around in giant boxes.

Same with map formats. General laziness of the majority of the developers on BYOND.

Not really. Map formats simply offer a different perspective, or some horribly designed overlays for "big icons". Pixel movement would effect pretty much every aspect of the games design, and would even be applied on top of those map formats. And I don't see how being lazy applies to not wanting to make an iso game over a top down one, or pixel movement vs non for that matter. Unless you're taking into account the developers who just go ZETA RIP, YAY.


Moonlight Memento wrote:
*something stupid*

Productive, as always. Thanks for the input.
In response to Falacy
Something stupid isn't what I said. It was the truth was it not, my good friend? :)

Anyway, get rid of tile-based movement and I'm basically out of the picture, because I love puzzle games and... they're a lot easier and funner in my opinion with tile-based.
In response to Moonlight Memento
Moonlight Memento wrote:
Anyway, get rid of tile-based movement and I'm basically out of the picture, because I love puzzle games and... they're a lot easier and funner in my opinion with tile-based.

I'm not saying get rid of it. I'm saying make it an option. Just like the map_formats.
In response to Falacy
Well, that would be the way to handle it. The problem with implementing built-in pixel movement is this: What if they have it by pixel and I want it every 8 pixels or something? Would it not be a pain in the ass to set it up to be customizable the amounts you go forward/backwards?
In response to Moonlight Memento
movement_format (or whatever) could just be a numerical value that represented pixel step size.
In response to Falacy
Does pixel_step_size actually have a purpose? Everytime I've modified it, I never notice anything.
In response to Moonlight Memento
Not that I've noticed, but I've never really messed with it. Based on what the help files say, it might actually prevent the map movement from looking so jumping. But that's not what I was referring to when I said pixel step size.
In response to Moonlight Memento
You can use it in combination with a delay in Move() to change the speed at which an object moves between tiles. In my experience, though, finding the right value/delay length combination is pretty hit or miss.
In response to Falacy
Falacy wrote:
I'd be willing to pay a pretty hefty amount to get them to implement pixel movement.

http://www.byond.com/developer/Forum_account/PixelMovement

http://www.byond.com/developer/Forum_account/ IsometricPixelMovement

I agree that pixel movement would be very useful. Because two games might use pixel movement in entirely different ways a native implementation won't give you the flexibility you might need.

It makes sense that some feature requests would be ignored because you can implement the feature with DM. This is often easier than having the staff modify DM to include the feature. Though it would be nice if instead of saying "that's possible with DM" the staff developed the libraries and said "here's how you'd do that in DM." Merely being possible isn't very helpful.
In response to Forum_account
I've built pixel movement before. Multiple times. The latest hitch I ran into was this.
And things on the tracker should never be ignored. Staying marked as "New" for more than 24 hours is somewhat ridiculous. As soon as Tom or Lummox read them they should change the status.
In response to Falacy
Falacy wrote:
I've built pixel movement before. Multiple times.

I haven't seen any demos by you. For a feature that you're willing to pay for, it seems strange that you wouldn't want to share.

The latest hitch I ran into was this.

That doesn't sound like enough of an issue to warrant a request complete built-in support for pixel movement.

Obviously you can't use icon states like you would for other games. In a 2D top-down game your icon is generally the product of a single state and direction. In a sidescroller it is much more: are you running, jumping, shooting? Facing left or right? Any combination of those could be its own state (ex: jumping + shooting + facing right).

My sidescroller demo manages the mob's icon state for you. You can independently change their direction or state (standing/running) and it updates their icon state accordingly.

The only issue is that changing the icon state does not start animations from the beginning but that's not an issue related to only to pixel movement. It's also a minor issue, is much simpler than asking for a complete pixel movement implementation, and is probably already possible.
In response to Forum_account
That feature request is somewhat unrelated to requesting full built in pixel movement. If they can waste all this time on map formats, they can do so on pixel movement, for far more rewarding results. IMO that request is a pretty major issue when it comes to creating our own pixel movement. Having to change the way you design/use icons is a somewhat annoying necessity as it is now. It would be minor change on their part, I would think, that should resolve more issues with pixel movement; plus it would provide new usages in various other situations.

I don't generally release demos, though I have countless systems that I could do so for. So I don't see why I would be releasing a demo for a system that wasn't even fully functional due to BYOND restraints. I might however release a completed pixel movement demo/library if everything comes together, one that fully implements into existing systems so that you barely even know its there. That would be the goal at least.

Obviously you can't use icon states like you would for other games. [...]

I don't see how that's related to pixel movement?

EDIT: In the Zelda game I had built pixel movement in, for example, if you were carrying a pot vs normally walking, you would need multiple icon_states to properly handle everything using pixel movement; a rather pointless inconvenience. And if you ever wanted to check an icon state, you would have to take these multiple states into account; even more inconvenient, and less efficient.
In response to Falacy
Falacy wrote:
Having to change the way you design/use icons is a somewhat annoying necessity as it is now

Check out the demo I linked you to. It has a variable to keep track of each aspect of the mob's icon state (direction and action). When you start moving you call set_action("moving") (or something like that) and it updates your icon_state to be the concatenation of your direction and action. If, while running, you change direction you'd call set_direction("left") which changes your icon state without changing your action. I don't know how much simpler you'd expect built-in support could possibly be.

The built-in icon support (having 1, 4, or 8 directional states, movement states) is really only sufficient for the most basic of built-in things. As you add features beyond what the built-in features provide you can't expect that all other built-in features will be sufficient for your needs. In a driving game you would need icons to represent every angle a car can face, but that doesn't meant that we should have built-in support for 180 or 360 directional icons.

In response to Forum_account
Forum_account wrote:
When you start moving you call set_action("moving") (or something like that) and it updates your icon_state to be the concatenation of your direction and action. If, while running, you change direction you'd call set_direction("left") which changes your icon state without changing your action.

That sounds pointlessly overcomplicated from both a design (icon&code) and functionality/usage standpoint.

I don't know how much simpler you'd expect built-in support could possibly be.

The developer shouldn't have to go out of their way to do anything extra, calling set_action() or whatever. These systems are already built in by default, and if you're making a library that just changes how far things move it should be almost identical in usage to said default.

The built-in icon support (having 1, 4, or 8 directional states, movement states) is really only sufficient for the most basic of built-in things.

Its actually quite sufficient. The problem is mostly with how the language lets you use the icons. Things like flick() could be majorly improved, and minor new features like the one I linked to could offer much more expansive usage of icon_states.

In a driving game you would need icons to represent every angle a car can face, but that doesn't meant that we should have built-in support for 180 or 360 directional icons.

The turn() proc is built in to handle things like that. I surely wouldn't expect people to make 360 icon_states, which is somewhat equivalent to what you're suggesting for pixel movement.
In response to Falacy
Falacy wrote:
That sounds pointlessly overcomplicated from both a design (icon&code) and functionality/usage standpoint.

If you think that this:

set_action("walking")


Is "pointlessly overcomplicated" compared to this:

icon_state = "walking"


Then it sounds like you're sitting around waiting for BYOND to add built-in features to do everything for you. They can't anticipate everything you'll need to do so there's no way the built-in functionality can ever satisfy you. Having 1/4/8 directional icons is just one of millions of ways to manage icon states, it was never meant to be adequate for all circumstances.
In response to Forum_account
Forum_account wrote:
If you think that this:
Is "pointlessly overcomplicated" compared to this:

I don't think that is, but that's not a proper example. You don't have to change icon_states every time somebody starts or stops walking in the default systems.
The latest pixel movement system I built was plug and play. You could add the code to any existing project, and it would turn them into pixel movement - with the one exception of needing multiple movement states - which that feature request would address.

Having 1/4/8 directional icons is just one of millions of ways to manage icon states, it was never meant to be adequate for all circumstances.

What kind of situation wouldn't they be adequate in? And how did the number of directions even come up?
Page: 1 2