Well, fear not Lummox Jr, I can run about 50 mobs, all with AI code with a dual core at about 30% CPU usage, and that's with a pretty sturdy AI code. I wouldn't be surprised if we see more and more p_m games.
I just got done playing 8bittrip with Resonance, and may I say, one of the most fun games I've played, and that includes games outside of byond. I wish it were longer/had more content
There is one problem I can see from this.
This part concerns me: "By giving an obj or mob explicit bounds, that tells the server that its pixel offsets (x and y, not z) matter" What if you have a big object you want to give specific bounds, but you still want pixel offsets to be visual only? The way I see it, some people might not want a system where an object can bump more tiles than it should simply because of pixel offsets. | |
Mista-mage123 wrote:
There is one problem I can see from this. I don't think that this would be too big of a deal, I've never really come across a situation like that; the only case where I could really see this being an issue is for when someone creates an icon with open space, which is pretty silly, anyway, especially when you can create icons with any dimensions you could think of. | |
Well, think about its implications. What it's basically saying is you can't have a bigicon use multiple tiles without pixel offsets impacting movement. As crazy as it sounds, pixel offsets are used for purposes other than movement.
For example, I have a 2D Sidescroller big icon facing one direction, I want to flip it ingame. After flipping it, I want to reposition the character so its in relatively the same position as it was standing the other direction, which requires adjustment via pixel offsets. This would mean the icon would be bumping another tile it isnt bumping when facing the other direction, which causes problems. Also, some games use visual effects on icons, such as a character shaking as the result of an earthquake ability. Even the addition of 1 pixel_x or pixel_y would break movement if this update came to be as it is. These aren't the only examples, i'm sure you can think of many other practical uses for pixel offsets that have been used outside of a pixel-movement engine. Basically, pixel offsets can only be used for movement in such a system, which is pretty lame as they do have other purposes. | |
All I can say is yes =), and kinda bumping out the need for better programmers ;p.
| |
Also, some games use visual effects on icons, such as a character shaking as the result of an earthquake ability. Even the addition of 1 pixel_x or pixel_y would break movement if this update came to be as it is. It's a big mistake to make this work based on pixel_x and pixel_y. It complicates a lot of issues *and* removes the ability to have purely visual offsets. Suppose you want to make an attack that hits enemies within 48 pixels of your mob, you need to: 1. Parse your bounds and use the parsed values, mob's coordinates (x and y) and pixel offset (pixel_x and pixel_y) to find the corner points of your bounding box. Then extend the box 48 pixels on each side. 2. For every nearby mob, do the same computations (taking x, y, pixel_x, pixel_y, and the parsed bounds values into account) to compute the corner points of every nearby mob. Then check if the mob's rectangle overlaps the area of the attack's effect. Not to sound like I'm against a native implementation, but it shouldn't be clumsier to use than the existing libraries. The way my library handles this is that the atom's px and py vars are the lower-left corner of its bounding box. The pwidth and pheight vars tell you the size of the box. To compute the corner points (and to compute the distances between two objects) you can just use these numbers to do the math. The object's coordinates are single numbers, not the products of combining many numbers. | |
Forum_account wrote:
Also, some games use visual effects on icons, such as a character shaking as the result of an earthquake ability. Even the addition of 1 pixel_x or pixel_y would break movement if this update came to be as it is. Tom explained over and over again why they chose the current implementation and I kind of like it. You could always create a bounds datum yourself and create procs to handle the changing of the bounds variable for you. | |
ExPixel wrote:
Tom explained over and over again why they chose the current implementation and I kind of like it. You could always create a bounds datum yourself and create procs to handle the changing of the bounds variable for you. I still don't fully understand the explanation. I understand what it lets you do, but I don't understand why its preferred over having multiple numeric variables. All this simplifies is the easiest case (setting the bounds and never changing them), but that case is easy no matter how you do it. Using this string complicates any usage that's more advanced than that. Saying "oh, but you can work around it" misses the point that you shouldn't have to work around it. If you can make a feature easy to use, why not do it? I haven't heard (or I missed it, there are a lot of comments) a reason why it's not feasible to use numbers for this. It can be tough, but BYOND should find ways to make difficult things easy. That's the selling point: multiplayer game development is tough, BYOND makes it simple. It's not as good of a selling point to say "we make easy things even easier (and the hard things even harder)". | |
Forum_account wrote:
ExPixel wrote: What if they decide to implement bounding circle collision. Why have 3 variables instead of one. IF there are two types of collisions you would end up with: var/pixel_width var/pixel_height var/pixel_radius Instead you could always just have one variable to handle it all: bounds = "[width]x[height]" or bounds = "radius-10" or something similar. | |
Extensibility is the main reason a bounds var would be preferred, but I understand the intrinsic value of having raw numbers to work with too. Tom and I had a talk about this last night following the comments that popped up, and we agree this needs more thought.
As far as using a single coordinate pair to represent the location, I'm not sure that's so easy to handle--at least not unless we break it down internally into simpler, more familiar terms. Using pixel_x/y for this seems much easier in a lot of ways. Perhaps though it'd be handy to have such vars around so that modifying one of them would simultaneously impact loc and pixel_x, for instance. I see your point about the possibility of wanting to mix visual and tactile pixel offsets, though I think in practice this won't come up at all; also, altering the bounds could be enough to achieve that effect. | |
Lummox JR wrote:
Extensibility is the main reason a bounds var would be preferred, but I understand the intrinsic value of having raw numbers to work with too. Tom and I had a talk about this last night following the comments that popped up, and we agree this needs more thought. Can you give an example of this extensibility? Do you mean supporting other, non-rectangular shapes? As far as using a single coordinate pair to represent the location, I'm not sure that's so easy to handle--at least not unless we break it down internally into simpler, more familiar terms. Using pixel_x/y for this seems much easier in a lot of ways. Perhaps though it'd be handy to have such vars around so that modifying one of them would simultaneously impact loc and pixel_x, for instance. I see your point about the possibility of wanting to mix visual and tactile pixel offsets, though I think in practice this won't come up at all; also, altering the bounds could be enough to achieve that effect. Think about what would factor into computing an object's absolute location. Having a single var to give you this simplifies a lot of things. About the underlined part, I'm not sure why you think that. Also, having a way to set a visual offset eliminates the need for the full support of the bounds string as I understand it. Setting bounds = "8,8 to 24,24" would be the same as setting the size to 16x16 and giving it a -8,-8 offset. | |
Forum_account wrote:
Can you give an example of this extensibility? Do you mean supporting other, non-rectangular shapes? That's the gist of it. It might for instance be feasible to handle collisions on the individual pixel level of icons. Not that it'd be fun to implement. Think about what would factor into computing an object's absolute location. Having a single var to give you this simplifies a lot of things. 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. That'd be really ugly, internally. And that wouldn't be friendly to work with, either, since you couldn't set mob.pixel_loc.x=... in that scenario. This could be done if every movable had its own unique pixel_loc with a special ref type (in much the same way contents works), in which case we would just need two new ref types (or maybe three, if you wanted to account for turfs at least for collision-checking purposes). | |
Forum_account wrote:
Can you give an example of this extensibility? Do you mean supporting other, non-rectangular shapes? Yes. For example, you could assign bounds to an icon to be used as the mask to support arbitrary bounding regions. We may compromise and have a generic bounds assignment as well as a width/height for the common case of the rectangle. 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. | |
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) 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: 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. | |
To answer your concerns about servers though, Fugsnarf, I suspect performance gains will be pretty much down to the difference between handling things internally vs. with a great deal of soft code. Certainly the collision checking that has to be done with soft-coded pixel implementations currently will be much simplified. Hard or soft code though, any game in which a very large number of atoms is moving every tick is going to have performance issues, more so if tick_lag is lower. However many of the client-side performance issues currently seen are due to the old pixel offset approach which was in use before version 489, and to the network delay issue being fixed in 490.