This is just a fun post, let's not get too crazy. The feature requests forum is overflowed when a billion gajillion feature requests and I'm sure it probably is a place Tom and Lummox like to often avoid (rightfully so, they have much more important things to worry about).
Just for the sake of having a fun and light conversation on the topic at hand: What features would you most like to see in Byond version 500?
Here's my current list!
atom/angle and atom/alpha - these added variables control an atom's current state of rotation and rendered transparency... Both of these would cause appearance updates so they are some-what expensive to add... But currently, if you want to achieve these, you have to do server-to-client icon operations which is SLOW AS HELL... If the BYOND team upgraded DreamSeeker to understand a atom rotation and atom alpha packet command, this could be added fairly easily and extremely useful to developers.
debug trace - the ability to trace a list of proc calls in order from oldest to newest... This is the closest thing I think we'd ever get to having a steppable IDE (BYOND will never have that, I don't think). With this, you'd be able to debug some complex code very easily. Its possible to create your own trace with a TON of work but it would result in a TON of overhead. This would only be available in DEBUG compilations and probably a profiler function... not intended to slow down performance on production builds or anything like that.
particles - Just watch this entire video: http://www.youtube.com/watch?v=Fy0aCDmgnxg and you'll see why this is important (listen to the crowd at 13:27 and 13:55). This has been avoided in fear of "feature creep" as Tom put it, but honestly its 2013 and there's not much of an excuse to not have a simplistic particle engine built in...
And some less important ones:
ability to get full file path from input() - currently its impossible to write really useful utilities that do batch processing without the ability to grab a full file path from an inputted file.. I'd also like an "as directory" type for input() so that you can select a "folder" to look for files in or to do stuff with files.
server request api - basically the ability to integrate your website with your game world. show people logged in, grab simple stats, etc... maybe just a simple way to get an HTTP response from the world server with some pre-defined world ?topics.
prevent the suppression of error messages - a compile time flag that lets you see every error message in all its glory, for people with some pesky problems that are unsolvable otherwise.
forced line break for maptext overflow - if you type the letter a with no spaces enough times in a maptext value to extend past its maptext_width, the engine makes no attempt to force line-break or cut off the text at the width.
ID:1294776
 Jun 16 2013, 8:07 pm (Edited on Jun 17 2013, 5:06 am)
|
|
Hmm. Oddly enough, you probably caught most of my interests with Particles, Authentication, and Forced line break. I do have two or three less important ones I'd love to see though.
input(), and alert() color change - Currently these procs are still used pretty often, and flash may increase how often they're used; so it would be really nice to see them be a little easier to make suit the game via an optional parameter. Especially considering how much quicker and easier they are to use. Flip all frames - Basically just the ability to flip the direction of multiple frames in an animation through the built-in icon editor. It's probably a pain in the butt to add, so I expect them to dread implementing this (I know I would), but as a Pixel Artist I will appreciate it quite a bit. More Zooming options for Map Editor - Just another Zoom or two in the map editor to help those who want to use 16x16 icons feel less of a strain on their eyes. I fiddled with the map maker for Feed once, and it drove me crazy, haha. Edit: I completely forgot about cash shop type stuff, and subscription splitting. WANO just reminded me with his post. I am really interested in Subscription improvements. Client-side projectiles intrigues me, but I haven't read anything about that so I can't measure how interested in it I am right now. | |
I agree with all of those, I've added a few I think are also worthy.
Auto-completion Authentication API - this ones really simple with DMCGI/PHP (though you .. need DMCGI to do it) in-line syntax hilighting Line highlighting BYOND linux 64bit package. Make Network profiling available to anyone with debug access. Flick to Client Website Specific Tagging people in a post Mobile friendly site.... | |
This post should cover most of what I have to say about particle effects. If developers had access to purely visual client-side effects it would be the killer feature which would give BYOND games the sort of polish modern games have.
As for what's not listed, I'd like to see a more robust version of flick(). Instead of using pre-generated icons and icon_states, you would have a sprite sheet without duplicate frames. You would then use flick() to script out what frames you want displayed in what order with what delays. BYOND would then take those commands and play a unique animation without having to do a bunch of icon processing. The whole point of it is to move away from bloated icons and costly icon processing. It would be much more reliable to have BYOND do it rather than trying to cycle through icon_states yourself as any network delays would mess up your animation in a multiplayer game. | |
One thing I've been thinking a lot recently is generalized client-side processing, where you could simply define an alternate "world" that would be your client, and use that world for your hud and localized things like icon-selection screens and so forth. The idea would be that the client and the server worlds would be superimposed onto each other and both functions would work, so if, say, you only defined MouseMove() in the client world (which is really the only way to do things efficiently), none of that stuff would generate network traffic. There would of course have to be an elegant way to then sync the client and server (eg, after the icon selection screen is finished).
Aside from various complexities coming up with a standard way of doing this, one issue is that it wouldn't be something that would work in our alt protocol like Flash, which is client-only (since porting the server is just too big of a project to consider at this time). But it does seem like if we could pull it off, it'd greatly enhance what you could do graphically since you could initiate an effect from the server and then do some fancy stuff on the client that wouldn't have to generate a lot of overhead for other users, since each user would only be getting the initial client proc call. Barring that (and this is largely a theoretical exercise at this point), I do feel that it wouldn't be hard to at least support partial client-side routines like a transformation matrix (to allow client-side rotation, scaling etc). One problem with this is that anything doing translation or scaling would only be a visual effect since as far as the server is concerned, the atom is at its initial (pre-processed) location. Improvements in flick() are also long overdue, I admit. So long as we can consistently bring in a decent volume of contributions, we can justifiably work on these kinds of things (at least the equivalent of one person full time). So the first month is very encouraging! | |
Tom wrote:
client-side processing, where you could simply define an alternate "world" that would be your client, and use that world for your hud and localized things like icon-selection screens and so forth. ++ | |
The only thing I can think of to add to this is a color wheel.
| |
In addition: map instancing (saving, loading, cloning, etc.), mobius strips (wrapping around without appearing to), and client.angle (rotating the entire view, rather than individual atoms).
| |
I would like to be able to bind windows together. I think I posed about this before a long time ago but lets say I have a game that is similar to an MMORPG, I make a chat box or some other form of user interface that belongs in the main window. I want users to be able to move it but I would prefer it stay inside the window that it is supposed to. (i.e. somehow attaching one window to my main window), the particle effects sound like an amazing idea as well and would open up a world of possibilities for games in BYOND. the way tom was talking about a separate client side "world", I would also like to see /image objects act just like any other form of atom (i.e. they have movement states, they can be flicked, etc) There are many multiplayer games you can play where there are NPC in areas that only people of certain level can see or maybe a cut scene going on for one player that nobody else can see (though the cut scene would possibly be better applied with tom's idea of a client side "world") these effects that could add depth to the games that we create could potentially help us developers in making something more profitable. Oh another thing that would be awesome is more control over the script for outputs I would like to change that hideous scrollbar.
| |
Auto-Update
| |
If Tom and Lummox are going to be working on improving byond a bit while they can, I think fixing bugs should be a priority. I'm happy with what I currently have, not that these ideas don't excite me at all.
Since it's too early to count on consistent donations to reach the goal every month, it would be nice to get as stable of a BYOND as possible while Tom can still justify working on it. | |
Auto-Update will update when they do a major revision. They don't do auto-updates for small changes.
| |
FIREking wrote:
Auto-Update will update when they do a major revision. They don't do auto-updates for small changes. Why would I re download for a small change? | |
King_LiOnZ wrote:
Why would I re download for a small change? For a specific bug fix which corrects a problem you've been having. If BYOND could auto-update in the background you wouldn't even have to bother checking for updates yourself. | |
SuperAntx wrote:
King_LiOnZ wrote: A update log. No one does anyway. | |
I thought of another big feature request:
Remove or increase obj compile-time limit: This problem has been unsolvable in the past, and this feature has been requested many times. I think a simple solution would be to create a chunk system that can fill its contents as needed. This could probably go hand-in-hand with a the "dynamic maps at runtime" feature. | |
Id like to see some optimization for games made with isometric perspective.
| |
somekind of system/engine revamp so a game can actually do stuff like a normal 3d game could like physics,particles, ability to handle multiple 2d objs at a time without lagging to death basically anything to make this smoother and better like a normal 3d engine would do but in 2d format
| |
client-side projectiles
timestamps for debug messages
debug trace
cash shop tokens
automatic subscription splitting
---
.. flash support! maybe not as soon as 5.0. ;)