3 ms·
isn't space station 13 infamously cursed when it comes to remakes? There have been numerous attempts over the years (mainly because SS13 is built in a terrible
by beaconstudios 5y ago
isn't space station 13 infamously cursed when it comes to remakes? There have been numerous attempts over the years (mainly because SS13 is built in a terrible unmaintained closed-source engine with a custom language) but all have failed because SS13 is so mechanically dense.
- gaogao 5y agoOn an engine that makes PHP look like a paragon of good design
- MrStonedOne 5y agoa compiled language with a function call overhead higher then php? it could only be byond.
- AngryData 5y agoYes, it has been so far, but this project has progressed much farther and steadily than most every other attempt. The sheer amount of features is astounding though, and highly varied among the different servers and codebases.
- ajvs 5y agoCurse seems to be over thanks to the progress in SS14 as well as Unitystation[1] which is slightly further along. Whilst not as featureful as /tg/ they have enough content to support several antagonists and most departments. [1] https://github.com/unitystation/unitystation https://github.com/unitystation/unitystation
- nonbirithm 5y agoEvidently so. I'm not quite up to speed, but ever since SS13 was first created there have been maybe a dozen attempts to move it off of BYOND: SS14, SS3D, RE:SS3D, UnityStation, Griefly, Bluespess... 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 https://github.com/Bluespess/tgstation-remake/issues/76 [2] https://www.reddit.com/r/ss14/comments/5k3tkl/comment/dbo633i/ https://www.reddit.com/r/ss14/comments/5k3tkl/comment/dbo633...
- Ygg2 5y agoAs much as any attempt to rewrite is cursed. 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. [0] https://github.com/wixoaGit/OpenDream https://github.com/wixoaGit/OpenDream
- rackjack 5y agoYep. I'll believe the curse is over when Goon/tg/etc. get some servers running on SS14/Unitystation for at least a year.
- MrStonedOne 5y agobyond does alot of things differently then most programming languages. 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.
- beaconstudios 5y agoThe execution flow you describe is similar to JS' event loop and (I think, I'm not very experienced at C#) C#'s async/await functionality. It's a godsend in JS for exactly the reasons you describe. 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.
- MrStonedOne 5y ago> The execution flow you describe is similar to JS' event loop 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.