I do remember stumbling across this issue[1] by one of the lead developers of SS14 calling out one of the devs of another project. I think it illustrates that the stories of people trying to remake SS13 alone are numerous and fraught with tension at times. But it speaks volumes about how passionate many individuals are about this specific game.
There is also this very interesting writeup[2] by another SS14 dev about four years ago about how the project got started.
Also interesting about SS14 in particular is that they use a completely custom engine called RobustToolbox, written in C#. This was after trying to use SFML, scrapping everything, and eventually spending a year "waiting for Godot", in someone else's words. One of the devs apparently spent two years mostly learning OpenGL just to finish the engine.
[1] https://github.com/Bluespess/tgstation-remake/issues/76
[2] https://www.reddit.com/r/ss14/comments/5k3tkl/comment/dbo633...
They are always hailed as a failing, but its not. ss13 wouldn't exist if byond was a competent programming language.
Half the features wouldn't get coded if class members had visibility/security levels (public/private), or had to be well written interface defined frameworks, or if types were enforced or required to be specified.
Lacking all of the fluff of modern programming languages allowed it to appeal to a wider base of contributors, a fair amount who got their start in programming by contributing to ss13.
Non-visualized programming languages also have issues that make game dev hard, that byond can sidestep. byond uses a single-thread:multiple-stacks framework that treats soft blocks (sleep, network/file io, client involved commands) specially and allows you to detach your call stack at an arbitrary point when a softblock happens allowing for easier programming of performant code.
So if i have code for airlocks to start the close animation, sleep for the duration of the close animation, then mark the airlock as dense and the tile its on as an airblocker, I can easily make code to handle closing all doors in a list of doors without making each wait thru the animation of the close block the caller, while still allowing for the blocking of the caller when thats what i want.
The curse is real, but its not insurmountable.
I haven't written any Dream code so I can't / wasn't speaking to the language design itself, and I got started in php and actually mostly like it for its design and accessibility so I wouldn't be the guy to shit on the language. I'm just aware that the platform is kinda crashy and non performant.
yes, in mechanic, the biggest benefit is you can get it via a control statement so its as easy as typing a keyword and an additional indentation block, ie, you can do it mid function and the function level vars just get copied over, or you can mark the entire function as non-blocking and the stack detaches at the first sleep, but at the non-blocking function, even if the sleep is 10 calls deep from that function. All without the caller of the non-blocking function needing to do anything (the biggest difference from c#'s async/await).
You can even define this on a base function and all 50 million overrides can be trusted to not block the caller.
Funny enough RobustToolbox also is being used to port existing codebases to C# [0].
This way old codebases can keep using DMI, and use CEF instead of Internet Explorer.