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.

Sign in to participate in the conversation

cybrespace: 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