Alternative View, Luminosity, And Distance Calculations

Bravo1 >So, basically speaking, depending on the math you use you're going t get a different result, and in most cases the distance calculation that byond uses by default isn't what people what to use.

Hiro TDK >It's not really about creating a circle, it's about alternative calculations. I will post some pictures later of each of these within a lighting system so that you can see the differences.

Toadfish> Thank you, yours are the only relevant answers here.

I said pretty much the same thing but you refuse to acknowledge it because you can't wrap your head around the fact that sometimes you want a different way to calculate distance.

It doesn't matter what shape you have in the end, what matter is what you're using it for, and each different calculation will give you a slightly to greatly different result.

The point of having this feature is not to make circles or rhomboid shapes specifically. It's to get a distance calculation that fits the situation that you're calculating distance for. If I want a circular attack I can do it with this, if I want it to be diamond shaped, yep, same here. if I want it to be a cone that only affects the direction I'm facing but spreads outward, this can help with it.

I really don't know any other way to explain it.

I mean, what you're arguing is along the lines of: "Why would you get a dog as a pet, cats are pets too, just get a cat." Well, what if I don't like cats? What if I don't like the ugly ass chebyshev squares? What if I want a circle, or a cone, or an oblong?

Also, don't try to insult Falacy, you made an error and he corrected you so you call him stupid? Remind me to call my college professor a moron when I get an F on my test, because I definitely know more than him, right?

Oct 26 2011, 5:03 pm
Falacy	Toadfish wrote: get_dist() doesn't use Euclidean distance (as I thought it did) Try being less stupid. O RLY?

Oct 26 2011, 5:05 pm

Toadfish

Bravo: I didn't read your post other than the last paragraph but I'm calling Falacy stupid because of this:

Maybe this is why every game on BYOND is complete garbage, does everyone just pretend that their code actually works?

sentence.

Despite the large amount of effort I had to spend to get a straight answer out of one of you, I actually understand the point of this feature request now, and have up-voted it.

Oct 26 2011, 5:06 pm
Bravo1	That's Falacy, he's a dick but he's also right. In my mind, Falacy is the real life version of Gregory House.

Oct 28 2011, 9:39 am

I don't understand this.

Opacity calculations are done on the client, I think. I see why it'd be useful to change this but I don't think it'd be easy.

For anything else, I don't understand why implementing it yourself isn't sufficient. A Manhattan distance proc is a simple calculation. If implementing something that simple in DM is too slow, there's something horribly wrong with BYOND that needs to be fixed instead.

Oct 28 2011, 2:12 pm (Edited on Oct 28 2011, 2:24 pm)

Forum_account wrote:

A Manhattan distance proc is a simple calculation.

That's assuming BYOND developers know of or even consider alternate distance formulas. Most of them probably couldn't even figure out the proper method to duplicate BYOND's current box distance.

This shouldn't be too difficult for BYOND staffs to implement, and would provide a much larger and higher quality variety of simple game changing calculations for majority of the developers on BYOND. Especially now that pixel movement is not only feasible, but the superior design standard. I think its pretty obvious that a distance calculated like this is going to be generally better looking and more game-like, especially for something like special effects, than a the current squares.

Oct 28 2011, 3:33 pm

A proc to get a circular range of turfs is easy to implement and many examples are available. I'd hope that people aren't settling for using square ranges just because that's what range() and view() provide.

Improvements to opacity would be nice but ideally it'd be more customizable. Even with a different way to determine visibility (or a custom proc to determine it), the solid black squares don't look nice. The current method also doesn't work well with pixel movement.

Oct 28 2011, 3:40 pm (Edited on Oct 28 2011, 3:50 pm)

Forum_account wrote:

I'd hope that people aren't settling for using square ranges just because that's what range() and view() provide.

I'd say that's the reason why 99.9% of the systems in 99.9% of BYOND games are the way they are. Awkward interface layouts instead of HUDs. Macros were almost never used until they were implemented directly into interfaces. Tile based movement, gameplay/movement limited by only 1 readable key input at a time, panels full of "verbs", right clicking EVERYTHING for a list of gray boxes. This is whats there, so its what 99.9% of the games on BYOND use, even though none of it is desirable. These things can all be worked around, if you have the will and knowledge to do so, but most developers around here either can't or won't. "Settling" for what's actually provided by the engine is understandable. Its why simple improvements like these should be made.

Oct 28 2011, 3:53 pm

These things can all be worked around, if you have the will and knowledge to do so, but most developers around either can't or won't.

This is a symptom of a problem that BYOND can't solve. BYOND doesn't come with built-in gameplay, so unless developers are willing to "work around" that, they're never going to make a decent game. BYOND should improve by appealing to better developers, not by catering to bad ones.

"Settling" for what's actually provided by the engine is understandable.

BYOND isn't exactly the engine. I'm not sure if it's trying to be one because it falls short in many regards. With a little work you can make a game engine using DM, but I wouldn't call what BYOND provides you with an "engine".

Oct 28 2011, 4:03 pm (Edited on Oct 28 2011, 4:33 pm)

Forum_account wrote:

This is a symptom of a problem that BYOND can't solve. BYOND should improve by appealing to better developers, not by catering to bad ones.

I don't fully agree with that in the first place, but even if I did, your suggestion of how they could appeal to better game developers, is for them to suck at being a game engine?

> BYOND doesn't come with built-in gameplay
Yes, it does. All of the bad mechanics that I listed in my previous post are examples of the gameplay that comes built-in with BYOND.
Gameplay is the specific way in which players interact with a game.

> [...] but I wouldn't call what BYOND provides you with an "engine".
Why not?
The core functionality typically provided by a game engine includes a rendering engine for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, localization support, and a scene graph.

Oct 28 2011, 4:23 pm (Edited on Oct 28 2011, 5:07 pm)

A better developer won't look at BYOND and say "wow, it provides a function that returns a set of tiles in a circular region, I'm impressed". To some BYOND developers that's a huge feature that'd be difficult to implement themselves, but that's not the kind of developer that BYOND benefits by appealing to - it's the kind of developer BYOND *does* currently appeal to, but look at how well that's turned out.

Let's also tack on part of the next sentence to the second wikipedia quote:

" ... adapting the same game engine to create different games."

BYOND provides some of those features (though it is light on collision detection and completely lacks physics), but it doesn't provide features in the way an engine would. An engine is middleware that helps you implement those things, BYOND just does some things for you in its own way and you can't customize it (networking, graphics, threading, memory management).

Oct 28 2011, 5:14 pm
Hiro the Dragon King	FA, setting up a get_dist() using alternative measurements is easy, as well as range(), though for range(), it's rather intensive. For view() though, it's almost impossible, and even more difficult to implement well.

Oct 28 2011, 5:30 pm (Edited on Oct 28 2011, 7:32 pm)

Forum_account wrote:

A better developer won't look at BYOND and say "wow, it provides a function that returns a set of tiles in a circular region, I'm impressed".

No, a better developer will look at BYOND and say "What, it CAN'T return a simple circular region? Next."

> To some BYOND developers that's a huge feature that'd be difficult to implement themselves
I don't know if I'd go as far as calling it a "huge feature" for anyone. Its a rather simple feature, just one that majority of developers would overlook.

>but that's not the kind of developer that BYOND benefits by appealing to - it's the kind of developer BYOND *does* currently appeal to, but look at how well that's turned out.
Most of the bad games on BYOND are bad due to BYOND being a bad engine. Though, it is a hell of a lot better now that pixel movement is built-in.
If BYOND had a simple proc that you could call to setup an interactive HUD menu, do you really think people would be using verbs/alerts/inputs/interfaces instead?
Macros are a great example, before their implementation into interfaces, almost no games used them. Now, practically every game does. You could set them up with a simple script file before, but it was something most developers didn't know about?

> Let's also tack on part of the next sentence to the second wikipedia quote:

" ... adapting the same game engine to create different games."

Yes, look at all the different games on BYOND, created using the same engine.

> BYOND provides some of those features but it doesn't provide features in the way an engine would. An engine is middleware that helps you implement those things
The engine is there to handle things for you, preferably in a customizable way, but all is better than nothing.

> (though it is light on collision detection and completely lacks physics)
The collision detection seems fine now that pixel movement has been implemented.
Physics in a 2D game? Especially before pixel movement? I can understand why it isn't included.
Also, the list said collision detections OR physics.

> BYOND just does some things for you in its own way and you can't customize it (networking, graphics, threading, memory management).
I'll give you threading for the most part, but since when does every game on BYOND look exactly the same, crash because you used 80 gigs of RAM in 3 seconds, and force you into single player only?

Oct 28 2011, 9:13 pm

I agree with Falacy, looking at BYOND it does fit the definition of an engine, the problem with it is that it's support for design features is extremely low.

That is, by far, the only thing holding BYOND back, it's lack of capability. Features like this increase BYONDs capability. Another big issue is the network support/ It's functional but unless you want an MMO that only supports 30-40 players on a server, and even then very poorly, BYOND just doesn't work for you as a viable engine.

BYOND has massive potential, anyone can see that, but when it comes to people requesting features and updates that will help BYOND reach that potential most of the devs seem to respond with "Not Feasible." Even when it's perfectly ideal for the betterment of BYOND.

Remember the huge debate over native pixel movement? Well, all the nay-sayers got shut up because the built-in system is great and it boosted BYONDs popularity practically overnight.

It seems that the devs will overlook features such as this because they're considered "too small" to be worthwhile, when these features are the building blocks of a good engine.

It's like looking at a brick and saying "No one could ever make a building out of this, I will only work with giant stone slabs!"

I can entirely understand if they're busy and they mark a feature as "Accepted for future implementation" for stuff that they don't have the time for but do want to put in. Instead it seems like they just allow things like these fall to the wayside and then when new developers join and start working they look at byond and go: "What the fuck, there's no way to get a simple circular area?"

I understand the devs do hard work, and it is great work that I'm very grateful for, but in all honesty, they often miss the stuff that counts.

Oct 29 2011, 10:07 am

Bravo1 wrote:

That is, by far, the only thing holding BYOND back, it's lack of capability. Features like this increase BYONDs capability.

I disagree. The problem isn't that there are things BYOND can't do. The problem is that the things you'd want to do are difficult to do and aren't intuitive to new users.

Think about what you'd need to do to have a certain key make the player run when it's held down. You'd have to make an interface file and edit the macros to define key press and release macros for the key that call a verb you've defined which then enables/disables running. This doesn't sound difficult to us because we know how to do this already, but no new user will find this intuitive.

Another example is BYOND's interface support. Yes, you can create custom windows and place controls on them. You have this capability, but it's not as functional and intuitive as a new user would expect. winset and winget are not what an experienced game developer would expect.

BYOND has made it easy to create buttons on a window, but it's still very difficult to create decent looking menus. If you purchased a brand new game made by a professional game studio, started it up, and saw the interface had default-skinned Windows controls for the textboxes and buttons, you'd be disappointed.

The capability is there, it's just unintuitive or missing the mark. The feature being requested here would improve BYOND's capabilities but wouldn't make a significant difference in what game developers can do with BYOND.

Oct 29 2011, 10:22 am

Forum_Account wrote:

I disagree. The problem isn't that there are things BYOND can't do. The problem is that the things you'd want to do are difficult to do and aren't intuitive to new users.

It's not about new users, it's about new developers, and ultimately, new developers will come in with the impression that a simple circular distance calculation will be possible on byond, but it isn't.

The problem isn't that byond can't do it, the problem is that byond can't do it efficiently enough to warrant using it in the first place.

and it would increase what the developers can do, because now they don't have to use a slow-inefficient soft coded procedure to run through something simple like lighting calculations.

Also, I don't know why you started talking about the interface really... but if you'd like another idea of an interfaced based issue much like this one:

There is no windel(). you can create show and hide windows but you can't delete them.

It just seems to me like the useful procs and features that developers would use to make better games are few and far apart. The most recent being pixel movement.

Think about what you'd need to do to have a certain key make the player run when it's held down. You'd have to make an interface file and edit the macros to define key press and release macros for the key that call a verb you've defined which then enables/disables running. This doesn't sound difficult to us because we know how to do this already, but no new user will find this intuitive.

Because the standard keys are usually exactly what you want. New users will almost never experience this because they would be perfectly fine with it. If they weren't then they would put in the effort to go about changing it, so they're going to have to learn in the first place right?

Regardless, there's a difference between being able to do something and being able to do it efficiently. I could make a full 3d system with byond, but can I actually use it? Probably not because it would lag to high hell, because it's not efficient. What's the point in being able to do something, unintuitive or not, if I can't even use it? You've seen yourself how built in calculations can trump any soft-code. As a result, having something like this in built in code would A: make it easier for people to use and B: make it more efficient in the long run.

I don't see how it's unintuitive to include a flag for changing the distance calculation rather than making people create their own calculation systems from scratch. The point is: this is stuff that any good engine has from the get go. These things should already be in BYOND. Why aren't they? I don't know, but that's why we're here saying "Hey guys, this really should be a given with a program like this, we should have this!"

Oct 29 2011, 11:34 am

new developers will come in with the impression that a simple circular distance calculation will be possible on byond, but it isn't.

BYOND comes with a programming language so it should be obvious to users that you can write your own code to do things that BYOND can't do for you. If BYOND was strictly for making MUDs and DM was just a light scripting language to customize enemy AI or abilities, I'd agree with you. But, because DM is obviously a complete programming language you can use to implement a wide range of game types, I doubt that any experienced game developer will start using DM, try to find a proc to return a circular area of turfs, not find it, and decide "that must be impossible".

Any efficiency concern is irrational. If implementing this proc in DM isn't sufficiently efficient, nothing written in DM is. The solution is to improve the performance of executing DM code, not to mask the problem in this one, single case.

Oct 29 2011, 4:40 pm