Step 1: One at a timeOne thing that's very important with feature requests is to keep them simple: One idea per post. Don't make a laundry list of suggestions all at once, because we won't be able to deal with them on a case-by-case basis.
Step 2: Has it been requested already?Take a look through the feature requests already present, including those marked as Not Feasible, Redundant, and Resolved. They say great minds think alike, so we get a lot of requests that have already been made.
Some ideas are rejected as Not Feasible, which usually means they can't be done or are highly difficult to do. Others may be Redundant, which means they can be accomplished already by a workaround and there isn't a lot to be gained by making such a feature built-in.
To save you some time*, have a look at our top list of rejected features below.
Step 3: Describe it in detailGive us a clear, thorough description of your feature--not only what it will do and how, but why you would want it. The why is actually pretty important; it can help distinguish between a common issue that people will tend to need, and something that comes up infrequently.
Sometimes the major obstacle to implementing a new idea is syntax--it's hard to come up with a common-sense way to invoke a feature that will be clear and easy to use. If you have suggestions for this, it's a good idea to include them. If you can't think of any way you would handle it either, the idea probably needs more brainstorming.
In the report you'll be asked what the request applies to. Here's what each item on the list is for:
Website: Anything that solely impacts the website belongs here.
DM Language: New language features, skin controls and parameters, and other miscellany go here. Most feature requests are for language features.
Dream Daemon: Anything that would impact the server alone is a Dream Daemon issue.
Dream Seeker: This is the client, the piece that plays the games, so this would cover some skin features, display options, etc.
Dream Maker: Suggestions that are for the editor alone (e.g., the map editor or icon editor) apply to Dream Maker.
BYOND Pager: The pager controls login and logout, and other features like sending messages.
There are occasions where nothing fits, or the issue might be more of a BYOND Hub issue, but just fill in one of the above. It's rare that you'll need to use the Other option.
The all-time top list of rejected featuresSome ideas have been requested more than once, or twice, or even a hundred times. Here's the top list of Not Feasible features suggested, and why they're not planned any time soon.
iPhone/iPod/Android/other mobile app
Simply put, it's not feasible for us to port BYOND to a mobile device. The backend code is somewhat portable, which is why we have a version of Dream Daemon and a command-line compiler for Linux. The frontend code, i.e. that used by Dream Seeker to actually play games, is far less portable. Significant modifications to both would probably required however for a mobile app. Apple's app store is also known to have relatively arbitrary acceptance standards, and the fact that Dream Seeker can run code through an interpreter is at odds with what they'll currently allow.
Our webclient version makes this moot, because it supports all modern browsers. Users should be able to play any game that is hosted with webclient support, provided the game is hosted somewhere.
The same portability problems are here as for the mobile market, only worse because while we wouldn't be dealing with capricious app store policies, we'd be serving a tiny market. It's not cost-effective to port.
We do however support running servers on Linux, and compiling games via the command line. It's the Dream Seeker client and the Dream Maker IDE, and the pager, that won't port easily. Many servers are hosted on our Linux builds. Users can play via the webclient or Windows.
Multithreading / Multicore
Many users have noted that BYOND runs on only one processor, which does not take advantage of modern multicore processors. There are several reasons for this, one being that language itself is single-threaded and only one proc runs at a time. This simplifies concurrency issues that would otherwise baffle most users. Internally, there are also no protections that would prevent one thread from modifying an object in use by another thread, and if there were then there would also have to be a way of resolving deadlocks. So the structural changes required internally would be massive, and the language would need to make any multithreading features optional anyway as an advanced choice to prevent confusion.
Some internal operations that are not related to the interpretation of compiled code could potentially be spun off into multiple threads to speed their execution; icon operations are one good example. Overall however, multithreading would show the most impact in code execution, the place where it is least feasible.
(Of note: For several versions we did attempt to at least split the user interface and the backend code into separate threads, and also split the map-sending code into separate threads. The result was a nightmare, and as of version 507 the threading experiment has been disabled. It may be revisited in the future.)
Make the project open source
We support the idea of opening more of the BYOND API to users, but we have no plans to make the entire project open source. For one thing, the source code still isn't well-organized enough to make it feasible for strangers to jump in and work on it. We've also long had to fight against our own desires for feature creep, which can introduce new bugs pretty easily, so we'd have to rein in most participants. Adding features is way easier than fixing bugs. The upkeep of handling the repository, security concerns, and quite probable lack of meaningful contributions make open source prohibitive.
Voice chat integration
This is popular for some kinds of games, but there's already third-party software to do VOIP pretty easily. Why reinvent the wheel? If there are people you want to voice-chat with, you can all decide on the software you want to use to communicate and follow whatever instructions they have for syncing up.
Although we've made strides away from our longtime tile-based approach, 3D worlds really aren't something BYOND can do in the foreseeable future. Doing 3D well actually requires a pretty intimate connection between the game and the rendering engine, taking as many shortcuts as possible in order to boost performance. But we also don't foresee a lot of people doing 3D modeling for their games, as good modeling work is hard to do and often requires expensive tools to do well.
More transparent skin controls
Windows has some inherent limitations in its paint model that make proper transparency more or less impossible without extensive workarounds. There have been many flawed and limited solutions to the problem of transparent controls, but none that are suitable for BYOND's skin model. As a result of this, few controls in the skin support transparency and those that do have limitations. The webclient is much more capable of handling transparency, however.
User-driven game ratings
We've tried a million ways of letting users rate games before, and in the end it never ended up being worth the time. Site features are time-consuming, and ratings and recommendations are downright evil to work with. It's too thorny a problem for the kind of data BYOND works with.
* I lied. This list was actually just to save me time.