Play nice, kids, or the pool gets closed.

To stir a bit of conversation: what features and/or behavior do you suppose should be dropped, if we were to draw a line between old and new games going forward?

Honestly, if we were in the hypothetical situation where BYOND were to be gifted 100,000 dollars to do whatever it wanted, and I were the lord of the universe, here's where I'd push the software:

1) Implement actual variable types, 1byte, 2byte, 4byte, 8byte signed/unsigned integer alone should suffice for my wants.

2) Implement chararrays/bytearrays, as well as mutable strings.

3) Permit operator overloading on datums.


4) Drop DirectX/GDI completely, in favor of a Chromium-based UI with HTML5 rewrites of all the interface elements, including map elements being <CANVAS>

5) Allow offscreen HTML rendering to be treated as an image that can be used on the map through Chromium's render to texture features. This would allow HTML pages and interface elements to be part of the map interface, and for them to be treated like atoms.

6) Rewrite the view() sending algorithm to only resend what has changed, or turfs entering the viewport after a move.

7) Rewrite the map code to make maps an entity level object. Map objects are objects that can be positioned in the world arbitrarily, and contain turfs, allowing dynamic loading/unloading, as well as making maps mobile.

8) Per-pixel collision using bitmask images.

9) Expose OpenGL shaders to the workflow, so that we can write shader behavior. Atoms would be able to be given specific fragment and pixel shaders. We could effectively write things like per-pixel lighting engines quickly and easily using this technique. We can also have direct control for how objects are rendered, such as how anti-aliasing is applied, and how nearest-neighbor calculations are done.

10) proper binary file io.

11) proper server-side DLL implementation, which permits objects in the DLL to have DM wrappers, and proxies that permit the passing of DM's datatypes directly into the functions as arguments, rather than using text strings.



All of that would make me happy as a clam, but I know it will probably never happen unless BYOND goes open source and some insane person decides to contribute a lot of it to github.

I wholeheartedly agree. The pace at which the engine is moving is slow, to say the least, but it is moving. The developers who have invested their hope in the engine don't want to leave because they covet improvement.

It's like a girl who's still in love with her immature ex-boyfriend. She doesn't want to move on, she just wants him to be a better man so there may be a possibility of rekindling their relationship.

I vote for drawing a line in the sand at some point and just breaking compatibility after a certain build number, so we can move on to bigger and better things.

it would basically be a big f u to not only the older games but even the 1s being made right now if all of that was added

How exactly would breaking backwards compatibility allow BYOND to "move forward"? What would you even need to break?

The problems that prevent BYOND from actually advancing run very deep. In fact, the root of the problem probably extends to the core of the engine itself. This means that breaking backwards compatibility likely wouldn't achieve much of anything that couldn't be done if it were not broken. It just isn't something that flexible.

What I'm saying is that what you are talking about here would require something far more drastic than what you seem to realize. I think a good way to summarize it would be to "replace the code that Dan wrote". In other words, it would be more or less a complete rewrite of all the "primitives" that even Tom and Lummox JR seem to be afraid of.

If they switched to modern tools, it still might take 5 years before they have something stable. I don't think it's worth it to break anything, unless the plan is a complete rewrite and renewal of BYOND, with full access to the latest high-end 3D technologies and a wide range of portability.

Unfortunately, it just isn't very realistic for BYOND to try to compete with other platforms, especially with the current state of things.

Well, I dare-say I'd push back on 1. and 3. out of hand, myself, due to the intended nature of the language. :P

----

In terms of dropped features ... well, depends. I don't actually know of any features who's nature prevents other features particularly being added.

I know plenty of implementation choices which make adding new features more difficult, unless a significant internal refactor is had. Which is a very different thing entirely, as you can usually do that and maintain source code level compatibility, or even binary compatibility through a translation process on load if that's a concern. Breaking netcode compatibility isn't such a big deal, BYOND's done this more than a few times and it's generally worked alright.

I'm sure there are some features you might need to kill to get other stuff working, but I'm not aware of any big ones at the moment?

Maybe I've glossed over certain bug/feature reports, I wouldn't doubt it. So I wouldn't rule it out, I just can't think of anything at the moment.

This is the thing, I'm not sure collectively we have specific things we know about, can point to, and go "yes, this well defined improvement here, it was blocked by maintaining compatibility for this older, less used feature or behaviour here".

I actually have my suspicions that this whole "can't do new features because we're maintaining compatibility for older ones" thing is largely a misunderstanding of what Lummox or Tom have said once upon a time, perceived to be a much bigger 'issue' by a year or two of chinese whispers.

The only thing I can think of, which actually fits the category, would be alpha transparency on some interface controls, or in combination with overlaying on a map. Which isn't a feature issue, it's a platform support issue / technology choice issue, in the sense that GDI+ in Windows XP isn't so hot, and in Windows Vista is craptastically implemented. I remember one issue where Windows 98 was the reason for a change being awkward, and Tom just dropped Windows 98 support.

It was probably these platform support issues, which have been misconstrued as "older game features preventing new game features / improvements being implemented". Platform support issues are a bit different to "supporting older games", because it concerns the width of your potential audience, not the size of your back-catalogue of games.