Tinkering with this is going to be fun.
Tom wrote:
Yes. For example, you could assign bounds to an icon to be used as the mask to support arbitrary bounding regions.

If you're talking about other shapes there will always be some way to have a set of numbers to define them too. Have a basic /Bounds datum and have children of it (Ex: /Bounds/Rectangle, /Bounds/Circle, etc.).

This is pretty basic OO stuff, I'm not sure why you're so afraid of adding this. Look at how complex the help pages get for certain topics (mouse procs, winget/winset, medals, scores, etc.) because it's a big feature crammed into a single help page. Creating an actual object that's fleshed out gives you a way to distribute documentation. Adding more stuff actually simplifies things. The /sound datum is very easy to use. The /icon object isn't (the same can be said for /image objects, they're also lacking a lot of features because they aren't fully fleshed-out objects).

If you want to keep it simple, have some built-in procs to create instances of these /Bounds objects. There's not much difference between these:

atom.bounds = rectangle(8, 16)
atom.bounds = circle(10)

atom.bounds = "8,16"
atom.bounds = "circle(10)"


The difference is that the first method gives you vars to read and write individual properties of the bounding shape. When you want to do something that's one step more advanced than defining static bounds (ex: add 5 to the height of the bounding box) it's really easy (with the first method, but not with the second).

We'll have to play around with the visual/physical pixel offset modes. It shouldn't be difficult to let the user control the interpretation, but we don't want to add too many settings as to make the system confusing.

The easiest way is to have one coordinate pair for position and another for the offset. If you're using pixel_x and pixel_y as part of determining the actual position, what do you use for the offset? You can't avoid making a new var unless you lose the ability to have a visual offset. If you have to add a new var, what makes the most sense - repurposing pixel_x/y or making the new var support the new feature?

Lummox JR wrote:
A single-var loc with pixels would basically be the x position in pixels, y in pixels, and z in tiles. A single 4-byte value can't handle that so it would have to be done in some kind of new specialized type that would have to be refcounted.

I meant having a single var for the x coordinate and a separate var for the y coordinate. Currently it sounds like you'll have to combine x, bounds, and pixel_x to get your absolute x coordinate.
Forum_account wrote:
Some Words...

You could always do it yourself, they don't need to make things anymore complicated for themselves if you can do it.
Neblim wrote:
ExPixel wrote:

You could always do it yourself, they don't need to make things anymore complicated for themselves if you can do it.

Quit promoting programming blasphemy.


It's not programming blasphemy, I just don't see the point of having something built in if can be done so easily.
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. Datums are infeasible to setup at compile-time. Also, setting a var to the datum (e.g. var/bounds/B=mob.bounds) would make that a "hot" copy, where if you modified it it would impact the attached object. Also we'd have to actually be on the lookout for changes to that datum. It'd make a little more sense as a custom internal type, but then it'd be a pain to set that up so it could have overridden procs and extra vars like a true /datum.

It may be basic OO, but think about the internals: There are only two ways to implement a setup like that. One way is to have a C-like struct, in which case it is not refcounted and the var you're assigning it to is strongly typed, and the other is to make it more of a proper object, which is more like what Java would do. The latter is really impractical and tying that to the atom on an intuitive level is even more impractical. The former has no obvious equivalent in our language.
ExPixel wrote:
You could always do it yourself, they don't need to make things anymore complicated for themselves if you can do it.


That can be said about any feature or about BYOND as a whole. It doesn't add anything to the discussion.

The fact that they're adding the feature at all suggests they want to add it in a way that'll be useful so there's room for debate on how to make it useful.
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.
Page: 1 2 3 4 5 6