My personal interest in GZDoom's client-server multiplayer code being finished is that I would like to host a server for ongoing experiments in community, authorship, shared digital spaces, etc. No concrete plans yet, I really just want to try stuff out and see where it leads.
c/S would make participating in that a matter of dropping in whenever one feels like it, and that seems crucial.
GZDoom is actually not a particularly great platform for a lot of what I'd like to try out, as it lacks full runtime editing of level geo, collaborative editing, hot-reload of scripts and resources... but it's still better than most more modern engines for that, and I'm not going to be able to build my own engine that *does* do that stuff any time soon.
@jplebreton uh wait
While Cube 2: Sauerbraten is an abandoned project, the fork Cube 2: Tesseract is still getting commits to its svn
They don't seem so good at releases tho
@jplebreton if you're not familiar, cube 2 can in fact do realtime collaborative level editing, and is zlib licensed.
@LogicalDash Yeah! I've long admired their tech. My sticking point with it is that all gameplay code still seems to be precompiled C++, so while it's a dream for level design and rendering tech you can't really deviate too far from the general FPS gameplay template without tons of work.
@jplebreton is this not the case for gzdoom? I'd thought that the less shooty games, sonic robo blast &c, had to fork the engine
@LogicalDash GZDoom has ZScript now, which while idiosyncratic and limited in a few ways is a pretty powerful scripting language - I wrote a quest generation system and custom UI dialogs for Mr Friendly with it. Not sure how SRB was implemented but it could definitely all be done in pure ZScript today.
ｃｙｂｒｅｓｐａｃｅ: the social hub of the information superhighway
jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal