I don't think the datum approach is remotely practical. For one thing each movable would have to have its own copy, which racks up way more memory.

Then make it a set of vars on the atom.

It sounds like you're afraid to add new vars because it makes things more complex (yes? no? I still have no idea where your apprehension is). Adding support for new formats of the bounds var, to the user, is adding complexity. It wouldn't be any worse than adding a new var or two. The difference is in how easy it is to use.

Write the code to compute a mob's absolute position taking x, y, pixel_x, pixel_y, and bounds into account. It won't be pretty. Look at a game and see how often it references a mob's x or y coordinate. This isn't some rare, obscure case. This is something that games will do a lot (especially games with pixel movement because that'll open the door to a lot of movement and position-centric features that are completely avoided in tile-based games). If the hassle of dealing with these string vars doesn't add up, there's a more significant chance than you might think for the overhead to add up (40 fps leaves you very little time for processing per mob).
I have no fear of adding vars; actually I find a lot of sense in what you say about having two vars that are equivalent to your px and py. Any resistance to adding mroe vars comes from the fact that we try to adhere to the KISS principle as much as possible. The fewer new vars are introduced, the better, as long as the hassles of dealing with the few don't outweigh the benefits of having more vars. I think you make a pretty persuasive case for those benefits.
Forum_account: I don't disagree with your OO vision and notational concepts. I didn't for things like winset() and the mouse procs either. Unfortunately, you are speaking purely theoretically without considering the practical implications for us to implement this stuff. Given infinite time, I'd love to completely rework DM to make it UML-based, but that's not going to happen.

When coming up with new language features, I'd rather we not sacrifice flexibility for cleanliness. In this case, while the string approach may be slightly clunkier, it gives us: 1) flexibility for future expansion (not possible with only width/height), 2) assignment at compile-time (not possible with datums), 3) compactness, and 4) ease of implementation (on our end). Meanwhile, it is not difficult to override with a more OO notation if the user prefers (I already gave the necessary procs and it really just amounts to zero parsing and having to call one extra proc when performing a write update). It will annoy language purists, of which you undoubtedly are.

DM is probably more like C than Java in the sense that the base notation isn't that elegant, but the nice thing is that you can override the majority of this stuff with your own constructs. Why don't we do these constructs internally for you? Because we'd like to release this software (also the reason we don't post about everything we're working on).

At any rate, we will consider what you and others have suggested here. To me, the notation is not nearly as important as ensuring that users can do what they want (eg, the visual/physical pixel issue).

We will not be releasing this half-update this week as planned, but instead will incorporate it as part of the full-update including the pixel movement. That will give us more time to play around with the notation and ensure that it isn't limiting.
I'm pretty much convinced that the string approach, though not pretty, is the way to go - Unless the only collision model people will ever care about is bounding rectangles, which is a pretty big possibility.

Thank you for taking the time to explain your reasoning.
IainPeregrine wrote:
I'm pretty much convinced that the string approach, though not pretty, is the way to go - Unless the only collision model people will ever care about is bounding rectangles, which is a pretty big possibility.

Yes, for that reason we may go ahead and provide width/height as well as bounds (internally we convert to width/height anyway).

I do think that if we had, for instance, icon masks for bounds, a lot of people would use that. After mulling on that a bit, it actually turns out to not be such a difficult problem (at least in 2D!) either.
I just don't see it. Thanks for blogging about this and considering the input provided here. But I still don't see it.

Tom wrote:
When coming up with new language features, I'd rather we not sacrifice flexibility for cleanliness. In this case, while the string approach may be slightly clunkier, it gives us:
1) flexibility for future expansion (not possible with only width/height)

Suppose you initially support only rectangles, then want to add circles.

With the bounds var you initially support strings of the form "x,y". To add circles, internally, you have to support parsing strings of the form "circle(r)".

Using vars you initially have width and height vars. To add circles, you add the radius var.

In both cases the internals have to change. Whether you're using new variables when checking for collisions or checking for new formats of the bounds string, something is changing. Neither one seems like a more significant change than the other.

2) assignment at compile-time (not possible with datums)

I agree that numbers would work better than datums. Numbers would allow for assignment at compile time. In some cases, strings don't allow for assignment at compile time. If you want to set the bounds based on constant values, you can't, because string concatenation is done at runtime. For example:

var
const
WIDTH = 3
HEIGHT = 5

mob
bounds = "[WIDTH],[HEIGHT]"


3) compactness

Using a single bounds string makes it more compact to initialize the bounds but not to modify them. To increase an atom's width by 1, using the bounds string, is less compact than if you had a width var.

4) ease of implementation (on our end)

I'm not sure how this works for you. Are you internally storing it as a string? Or are you parsing the string every time the value is set?
Tom wrote:
Yes, for that reason we may go ahead and provide width/height as well as bounds (internally we convert to width/height anyway).

If it's easier for you to parse the bounds string and deal with width and height vars (internally), why don't you think it would be easier to provide the DM developers with the width and height vars? If you already have the internal width and height vars, it shouldn't be that difficult to expose them to the DM developer.
Forum_account wrote:
In some cases, strings don't allow for assignment at compile time. If you want to set the bounds based on constant values, you can't, because string concatenation is done at runtime.

This is an important point. Now I understand why I had such a strong negative reaction when I saw the old "NxN" format. Because embedded expressions are considered non-constant, they cannot be used in many places at compile time - You can't even use the preprocessor to construct a valid string at compile time:

http://www.byond.com/developer/forum/?id=782905#782905

This means that you have to use "magic numbers" whenever setting the bounds variable at compile time.
Considering bounds are more likely to be based on the atom's icon than anything else, I don't consider the #define issue important. I can't think of any reasonable circumstance where that would come up, and no unreasonable ones where the bounds strings (in their entirety) couldn't be setup in a block of #define statements.
What if a sub-type of mob should inherit its width from its parent but have a different height? What if you want to set the bounds based on the world's icon_size? What if the bounds are based on the current "base" mob icon and you make changes to it?

You and Tom keep suggesting that certain cases are uncommon. I'm not sure how you can make these statements with any level of certainty:

1. You need BYOND game development experience to know what developers will want to do. Tom doesn't have BYOND game development experience. Lummox JR doesn't have a ton, but...

2. There's no amount of experience that'll give you the foresight to say that a case will be rare. I'm sure there have been many DM-based creations that made Tom think "hmm, I didn't expect someone to do that" (I'm sure most bugs come from someone doing something you didn't anticipate. If BYOND was bug-free I'd support your assumptions about user behavior 100%). Pixel movement opens up a lot of possibilities and I'm not claiming that I can predict what people will do, but I'm certain that you can't predict it either.

I think it's good for the staff to dictate, to some extent, how people will use their product. This would work best on a higher level (ex: don't make rips of garbage anime games) instead of the lower level (ex: store numerical values as strings).
Considering world.icon_size is itself read as a string, basing bounds on it would have to be done via a #define anyway. Presumably if an author wanted icon_size to be changeable (this is what I would refer to was one of the unreasonable circumstances) they'd be setting a #define for that, and bounds based on it could easily be #defined in the same place, so that scenario is covered. I'm keeping an open mind on this but I just can't imagine a counterexample where this becomes important.

None of the above is to say, however, that I think separate width and height vars wouldn't be desirable. I just mean that the #define thing doesn't strike me as a very strong argument on its own. In pretty much any game, the icon size you're using is a known quantity early in the development process.
Neblim, I've written games from scratch before, in C++ back in the bad old days of DOS. I do have development experience outside of MUDs and BYOND. And I do understand people wanting to get the most out of pixel movement; one of my early projects, which has been on hiatus a long time (mostly due to control issues that I think are now plenty resolvable), used a fairly advanced physics-based collision system and soft-coded pixel movement. For this reason I get where FA is coming from when he mentions preferring two numeric vars to represent x*size+pixel_x and y*size+pixel_y, for instance.

We're taking all feedback into account, and FA's in particular is taken very seriously because he's worked extensively with pixel movement already in soft code. Nothing is truly final at this time.
Neblim wrote:
Tom has only played MUD based games.

This is not true! I am an avid Halo player but I can't reveal my gamer tag because of my penchant to teabag and trash talk.
Tom wrote:
Neblim wrote:
Tom has only played MUD based games.

This is not true! I am an avid Halo player but I can't reveal my gamer tag because of my penchant to teabag and trash talk.

This explains the slow development of BYOND in late 2004, 2007, and 2010.
Are icon masks the ability to make non-rectangular bounds? For example, an L-shaped collision box?

I know for a fact I would use that first thing.
Lummox JR wrote:
For this reason I get where FA is coming from when he mentions preferring two numeric vars to represent x*size+pixel_x and y*size+pixel_y, for instance.

You're simplifying it there. I think it'd be something like: absolute pixel x = x * icon_width + pixel_x + bounds.left

x is the atom's x var
icon_width is parsed out of world.icon_size
pixel_x is the atom's pixel_x
bounds.left is parsed out of the bounds string (if you set bounds to something like "8,8 to 24,24", it'd be the first 8)

I'm still confused about how you can store it as separate numbers internally but think that it'll be easier for DM developers to have a single string. If you have any questions about how to make it work by exposing a set of new variables to the developer, pose some questions to the community. I'm sure we can come up with something.
Forum_account wrote:
I'm still confused about how you can store it as separate numbers internally but think that it'll be easier for DM developers to have a single string.

Since bounds can theoretically represent many things besides a simple width x height, it is more flexible to use a text string. Yes, assigning to a datum would be nicer but that is a lot more work and has some limitations, which Lummox JR and I have both gone over multiple times.

If there is really this huge need to constantly read or write the bounds, and for whatever reason people don't want to use the extremely simple method I proposed, I suppose we could provide width/height in addition to bounds (which could store more complex information).
Mista-mage123 wrote:
Are icon masks the ability to make non-rectangular bounds? For example, an L-shaped collision box?

Yes, with an icon mask you could assign any shape bounding region you wanted. Using the atom's icon for its mask would give you true pixel-level collision detection.
Tom wrote:
Yes, with an icon mask you could assign any shape bounding region you wanted. Using the atom's icon for its mask would give you true pixel-level collision detection.

If that's the case, then would non-square icons work as well, like triangles and circles? Would they bump based on pixel collision? I'd love to see this.


Tom wrote:
Neblim wrote:
Tom has only played MUD based games.

This is not true! I am an avid Halo player but I can't reveal my gamer tag because of my penchant to teabag and trash talk.

^Lol'd.
Page: 1 2 3 4 5