ID:100953
 
Not Feasible
Applies to:BYOND software suite and language
Status: Not Feasible

Implementing this feature is not possible now or in the foreseeable future
Now, this is not really as much as a request for a specific feature, but please bear with me for taking it to the tracker as it still seems the best place.

BYOND, as it is now, is meant to fill a niche. It tries to target those looking to create semi-powerful games semi-easyTom.
It is only natural that people start to venture on, once the software no longer suits their needs, which is an inevitable result of progressing and learning.
As it is now, a lot of features and functionality can not be worked on in a reasonable time-frame because of BYOND's legacy and focusing BYOND's full resources to redesign the project from scratch is too much of an economical and commercial risk for an uncertain outcome.

I wonder if Dantom would be willing to query it's community for the will and desire to fund a complete redesign as side-project, followed by a public discussion on a design document for BYOND.
The BYOND administration would have to comment on feasibility of suggested functionality in regards to the available funds.

If Dantom would only have to take a share on the resource and could hire some freelance programmer(s) specifically for reimplementing BYOND with some new functionality, the risk to benefit ratio should decrease to a level worth considering (given enough funds can be raised in advance and the community requests can be focused enough to avoid featurism).

This way, BYOND could gain a broader audience through targeting not only people wanting to create game semi-easy, but those wishing for a bit more advanced functionality as well. Which would hopefully result in both, more polished games and a growing community.

Thank you for taking your time to read this.
It's not very clear what you're proposing. Do you want a complete re-design of the DM language? Do you want new, advanced features added?

Why do you want these things? Do you want to make BYOND more powerful so the existing users can make better things? Do you want it to be more powerful to attract more advanced users?

A complete re-design can fix anything. Any software project that ever existed would benefit from one. The problem is time.
Unless this is for a 3D version of BYOND, I don't see much merit.
Falacy wrote:
Unless this is for a 3D version of BYOND, I don't see much merit.

Of course you wouldn't. Who cares about 3D?
If what you're mainly advocating here is for the ability to do things client-side easier, like you say in your blog post, then this would actually make more '3D' games possible at least as far as ray-casting goes. That's how Vengeance 56 works so well, if I'm not mistaken. Most people would not want to go through the trouble that Gakumerasara did to make that, though. It would also take immense strain off of servers in a lot more cases such as custom pixelized movement, which is definitely one of the problems with BYOND.
It would also take immense strain off of servers in a lot more cases such as custom pixelized movement, which is definitely one of the problems with BYOND.

Pixel movement is hardly a strain on the server. There are many things that are simpler conceptually but cause much more network traffic. Handling movement on the client also brings up a lot of issues:

The smooth transition from one tile to another is the only form of movement handled by the client and there are many reasons why it should stay this way.

The server might have complex rules for who can enter a tile. If movement is handled by the client, the client needs to be aware of these rules and it needs to have all of the information necessary to enforce the rules.

Also, by handling movement on the client you can have two clients perform conflicting moves (ex: you and I both move onto the same tile). Because the clients are performing the moves instead of the current model (the clients send the move command, the server processes it) we both move and the server has to fix this problem (by undoing one of our moves).
Forum_account wrote:
It's not very clear what you're proposing.

I'm sorry (in all seriousness), I have the bad tendency to struggle when trying to explain a complex concept in a foreign language. Please bear with me, I'll try my best to elaborate.


Forum_account wrote:
Do you want a complete re-design of the DM language?

Of the language and software alike actually. BYOND was designed with a very specific idea in mind and the source-code does not only reflect this (together with the language), but lacks a modular approach and comments according to these working on it.
This was mentioned as main reason to defer various feature requests in the past.

Given the ease of use and rather fast visual success for a beginning developer, BYOND seems to be suitable for teaching (see BenG's BYOND class). Now it seems logic (in my humble opinion and I might be very wrong) to try and foster this advantage by optionally providing more advanced concepts with the language to keep the clientèle with the software during progress (e.g. valuable members like Alathon). By catering for both, a semi-easy game creation and an advanced one, I think BYOND could gain a lot more attention, which is what Dantom seems to aim for.
The adjustment to offer additional advanced functionality seems to fail due to BYOND's legacy though, which is why I wonder if a complete fresh design would be feasible as side project.


Forum_account wrote:
The problem is time.

And money, because money can buy time (or, rather additional manpower). I'm well aware that BYOND couldn't invest into such a venture by itself, but it seemed to me that some people were willing to donate towards certain functionality added to the software (e.g. Falacy wanting 'pixel movement' built-in, whatever that my mean). And if enough people donate, I'm sure Tom could hire free lance programmers to take this venture.


Falacy wrote:
Unless this is for a 3D version of BYOND, I don't see much merit.

Didn't you state that you'd be more than happy to donate to BYOND if they'd implement 'built-in pixel movement' (whatever that may mean) only just recently?


Fugsnarf wrote:
If what you're mainly advocating here is for the ability to do things client-side easier

Despite the fact that a client-server model is a lot more powerful than BYOND's current strict server model, I didn't specifically mean to add just this, but have the community add feedback to whatever seems like it could be designed better with BYOND. Be it language, nomenclature, built-in functionality, anything that is possible with the created fund. This chance could be used to solve some problems like a less operation system based implementation (e.g. port to Linux/Mac), more interface features (by drawing elements instead of using the Windows API), making great use of hardware acceleration (e.g. particle effects and the like) and whatever you think an advanced developer misses with BYOND.


Forum_account wrote:
Pixel movement is hardly a strain on the server.

I think that a lot of professional software engineers would disagree with you on this point, given that most any modern game handles physics next to completely client-sided for exactly this very reason, but that shouldn't really be discussed on this feature request.
I'm not necessarily opposed to the idea, I just don't think it's going to happen any time soon even if there was ample community desire for it.

I'd love to know what Tom or Lummox are thinking considering the fact that BYOND would have come all this way just to be completely redesigned. Money speaks louder than that, though. I just don't think the money is going to come.
Fugsnarf wrote:
I'd love to know what Tom or Lummox are thinking considering the fact that BYOND would have come all this way just to be completely redesigned.

I hope that I haven't left the impression of dislike on BYOND, because that is simply not the case. I do not mean to rethink the idea behind BYOND, but simply the implementation, which I figure would be different nowadays than it was a dozen years ago (a rather long time in terms of computer related development). I would dare to think that Tom has gained a lot of insight on some design decisions (due to feedback) that he certainly couldn't have back then and that there has been some progress in developing software.
Schnitzelnagler wrote:
Didn't you state that you'd be more than happy to donate to BYOND if they'd implement 'built-in pixel movement' (whatever that may mean) only just recently?

Indeed. However, for the most part, pixel movement is currently possible for us to build ourselves. 3D is near impossible, and for the amount of work it would take you'd be better off moving to another engine entirely. Also, I see little difference between redoing the engine to render/process on isometric/diagonal tiles as compared to making it render/process on 16x16 or whatever pixel size we input; except that it would be a far more worthwhile and rewarding venture, IMO at least.
Schnitzelnagler wrote:
Forum_account wrote:
Pixel movement is hardly a strain on the server.
I think that a lot of professional software engineers would disagree with you on this point

Statpanels can easily generate more network traffic than pixel movement.

Handling movement completely on the client is a good idea when you have lots of players. World of Warcraft handles all aspects of movement on the client (collisions too) but some MMORPGs don't. Everquest handled collisions on the server. This creates some awkward situations that a BYOND game with 6 players can trivially avoid by keeping this bit of the work on the server.

Things like view calculations are excellent for dumping on the client because it's completely independent for each client and requires no client-to-server communication. The server tells you what objects exist and which ones are opaque and the client takes care of the rest. Lighting effects (assuming they're purely visual) would work nicely as a client-side effect for the same reason.

I think client-side processing is better if it takes the form of "here's a feature that makes more sense to exist on the client, so the BYOND staff implemented it that way" rather than having the BYOND staff provide a client-side scripting language that can let you implement all of the client-side effects you might want to see. These client-side features could delve into any aspect of the client. It would be easier for the staff to modify things as needed rather than provide an API for client-side scripts to access anything they might need.

if enough people donate, I'm sure Tom could hire free lance programmers to take this venture.

Based on this forum post, let's assume BYOND has made $10,000 from memberships and would expect to make this much from a "re-design fund". This will pay for 50-60 hours of time from a single programmer. I wouldn't expect that the new implementation could be written in a week and a half. This solution seems too costly to become feasible any time soon.

the source-code ... lacks a modular approach and comments according to these working on it. This was mentioned as main reason to defer various feature requests in the past.
to try and foster this advantage by optionally providing more advanced concepts with the language

You don't actually say it but it sounds like you're suggesting a separate version of BYOND that provides more advanced features. I've seen a lot of features deferred because they would be hard to implement in a backwards-compatible way. Even minor things, like adding or re-ordering an argument to a built-in function can often not be done without breaking old code. If Tom didn't need to worry about backwards compatibility BYOND would be way ahead of where it is now. Unfortunately backwards compatability is a valid concern.

I think we'd be better off trying to get community support (contribute ideas) for an in-house re-designed version of BYOND that is not backwards compatible.
Forum_account wrote:
Statpanels can easily generate more network traffic than pixel movement.

There are more resources on a server than network traffic though and physic calculation can get rather CPU intense (as well as network intense actually, if your environment support basic 'pixel movement' as well)


Forum_account wrote:
Pixel movement is hardly a strain on the server.
Handling movement completely on the client is a good idea when you have lots of players.

That is actually contradicting your initial statement. If handling several of a simple process is resource intense, then the simple process is resource intense by itself.


Forum_account wrote:
BYOND game with 6 players

Indeed. then again, one might argue if a game with six players on a server is really successful and warrants paying said server, or if it wouldn't be better to handle a thousand players on that same server. Take transformice as a simple example. There are 1500 players on a single server without any resource related issue. Can you recreate the same on a completely server based model and run on the same server with 1500 players?


If client-sided processing would be better implemented with some hard-wired procedures or a more flexible API could be discussed on the design document, but as of right now, neither is possible with the current state of BYOND, which is the 'big picture' argument I'm trying to point out.
If legacy stands in the way of a lot of improvement to keep a product on level with it's competition, isn't it sound to consider getting rid of that burden of the past?


Forum_account wrote:
Based on this forum post

I wouldn't exactly use Teka to estimate the average contribution to BYOND.


Forum_account wrote:
$10,000 (...) will pay for 50-60 hours of time from a single programmer.

Uhm, I'm sorry. I don't have the slightest clue on average monthly expanses for a company in the USA to get a semi decent software engineer, but ~25000$ a seems a bit... odd.


Forum_account wrote:
This solution seems too costly to become feasible any time soon.

Which is exactly why I was asking if BYOND could create a poll/fund. that way nobody would have to speculate, but we'd have solid facts ;)


Forum_account wrote:
(...)suggesting a separate version of BYOND

Yes, I am, sort of. Call it BYOND 6.0, or however you like. You can easily keep full backwards compatibility by including the software we have now to run and interpret whatever byte-code we currently have.


Forum_account wrote:
I've seen a lot of features deferred because they would be hard to implement in a backwards-compatible way.

This is exactly what I'm trying to point out.


Forum_account wrote:
If Tom didn't need to worry about backwards compatibility BYOND would be way ahead of where it is now.

Again, exactly my point, or at least the one I'm trying to make. And if the product BYOND is intended to keep competitive, one has to consider if losing that possible advantage is a viable long term strategy.


Forum_account wrote:
in-house re-designed version of BYOND that is not backwards compatible.

That wouldn't be feasible with BYOND's current sparse resources, which is exactly why I was asking if BYOND could get enough support to allow outsourcing to become a viable option, given that the in-house resources are rather constant and already in heavy demand.
There are more resources on a server than network traffic though and physic calculation can get rather CPU intense (as well as network intense actually, if your environment support basic 'pixel movement' as well)

As I mentioned, Everquest handled collisions on the server. If they could handle it for hundreds of players I'm sure we'll be okay with tens of players. Very few people have ever done anything on BYOND with pixel movement but everyone is an expert on its CPU usage and network requirements.

I wouldn't exactly use Teka to estimate the average contribution to BYOND.

If I was taking Teka to be the average contributor, the amount of money BYOND has received would be:

(amount Teka has contributed) * (number of users)

Which would be on the order of millions of dollars at least. I don't think BYOND has even made that much in Tom's wildest dreams. If Teka, at that time, had contributed ~$5000 and Tiberath was 9th on the contributions list with ~$700, I estimated the total amount of all contributions at $10,000. Looking at it again that might be a bit low, but I wouldn't put the total much over $20,000.

Uhm, I'm sorry. I don't have the slightest clue on average monthly expanses for a company in the USA to get a semi decent software engineer, but ~25000$ a seems a bit... odd.

There's a big difference between what it will cost Tom and what the freelancer is actually making. A freelance programmer has to cover their own expenses, a full-time employee's overhead expenses are paid by their company. Because of this, a freelancer will charge, I figured, between $150 and $200 an hour. An employee of a consulting firm might make $50/hour but their firm charges $150/hour for their time.

Based on these numbers it doesn't look like a complete re-design would ever be feasible.


Yes, I am, sort of. Call it BYOND 6.0, or however you like. You can easily keep full backwards compatibility by including the software we have now to run and interpret whatever byte-code we currently have.

Backwards compatibility also means being able to compile old code under the new system. If you want to leverage BYOND 6.0 features in a project you currently have, you might need to re-write a lot of the code. Even tiny changes to the DM language can break old code.


Forum_account wrote:
I've seen a lot of features deferred because they would be hard to implement in a backwards-compatible way.
This is exactly what I'm trying to point out.

I'm not sure how this necessitates a complete re-design. BYOND isn't broken to the point where starting over from scratch is practical. It does a lot of things right. It's not that problems go unfixed because they're too hard to fix but because they can't be fixed in backwards-compatible ways. Breaking backwards-compatibility is hard to justify.

The work could be done in-house, we just need to show that it would be worthwhile. Personally, I'd rather see the current language fixed up before more features are piled on top. If a magical new feature brings a lot of people to BYOND, those people will run into the same problems we've all run into with the DM language and the BYOND platform. I think that having a better product is more important at this point than having a larger audience, but I'm not the one you need to convince.


I don't see how this relates to client-side processing. If these can be separate issues it's probably best to keep them separate.
so basically you want there to be BYOND, but you also want there to be something somewhat like a BYOND pro?
Forum_account wrote:
Backwards compatibility also means being able to compile old code under the new system. If you want to leverage BYOND 6.0 features in a project you currently have, you might need to re-write a lot of the code. Even tiny changes to the DM language can break old code.

Not necessarily. That's not even 100% the case with the current systems.
Falacy wrote:
Not necessarily. That's not even 100% the case with the current systems.

Care to explain more? I have no idea what you mean.
Forum_account wrote:
Care to explain more? I have no idea what you mean.

The newest example is map_format. There were a lot more changes that required reworking when 4.0 was starting out.
How did map_format break backwards compatibility? I still don't understand.
Forum_account wrote:
How did map_format break backwards compatibility? I still don't understand.

map_format is there for just that, backwards compatibility. It defaults to TOPDOWN, and unless you change it to TILED before compiling an old source, the in-game map can get screwed up to the point of being unplayable.
When 4.0 was first coming out, they were adding a lot of new things. world.host, for example, forced me to rewrite/remove several of my own host detection systems.
New features are bound to make some of your code obsolete and may obviously require changes to your code to utilize new features.

Breaking backwards compatibility means that old code will not compile and work anymore. For example, if the order of the last two arguments to copytext was changed this would cause old code to no longer work.
Page: 1 2