freem {l Wrote}:Fast paced games do not have to run everything on clients
Nope, but they should. The reason is simple: sending the user input to the server and waiting for a response introduces latency which kills performance. If more computation happens on the clients, user input is processed in place, then the result is immediate, no network latency involved (but then you'll have to approximate or predict on each client what other players do, and correct it when they receive the latest actual data from the server).
freem {l Wrote}:should avoid it as it allows clients to easily cheat (wall hacks)
The part about cheating is true. If game logic happens on the clients, then there's a chance a client might be hacked to cheat. That's one of the reasons why I said pushing game logic to the clients is harder to implement.
freem {l Wrote}:This also prevents modifying stuff easily, like in red-eclipse where bots are ran by clients, which prevents AI improvements to land without a new release (and implies that old clients impact on that).
But this one isn't true. It doesn't matter where the bots are handled, it does not make implementing AI more difficult (but other factors make it more difficult to implement more on client side, just not the AI part). Also players must use an up-to-date client no matter what. Both the clients and the server must speak the latest protocol, otherwise there will be incompatibility problems, they won't understand each other.
freem {l Wrote}:When doing client-server, you might think before hand about how much stuff should be moddable.
Again, not true. Take for example Minetest, which pushes as much as possible to the clients, yet it is highly moddable.
freem {l Wrote}:Red-eclipse uses a script lang, which is largely insufficient for any serious modding.
The scripting language itself doesn't matter, it's the interface that determines how much can be modded in a game. For example, if there's no plugin interface to change the map, then no matter if you use QuakeC, NaCl, WASM whatever, your mods won't be able to destroy the scene (like in Xonotic). And vice versa, if you provide an API to change the map, then it doesn't matter how that's called (what ABI your mods use), you'll be able to change the scene (like in Scorched3D or any voxel game).
Note the difference:
-
API: Application
Programming Interface, determines what can be done, how much data is sent, what functions are accessible from the mods.
-
ABI: Application
Binary Interface, determines how an engine call is made and what kind of technology the mods use. This latter has nothing to do with what interfaces are provided for the mods.
freem {l Wrote}:Xonotic uses QuakeC, which limits people to an old C variant which never was standard: needs to cope with the limitations of C
Excuse me, what "limitations of C" are you talking about? There are no such thing, people use C for literally everything, from embedded bare-metal, driver and kernel programming to high level user applications like SDL games. It is the most portable language ever created.
It is a proven fact, that as long as a language supports sequence, conditionals and loops (and C does), then all kind of
algorithms can be implemented in that language (if I'm not mistaken, then it was Nicolaus Wirth who proved this). Some languages are easier to use than others, but it's never the language that might limit you.
freem {l Wrote}:Unvanquished, which does not sends all data to all clients and do the calculations server-side (while clients have enough info to predict some stuff) uses google-nacl, which replaces quakeC, and is hoped to be replaced by WASM.
Again, these are just ABI implementation details, they won't change the API. If you hope that using a different language or bytecode interpreter would solve your issue then you're on the wrong path. It might give you better performance on the clients, but that's all.
freem {l Wrote}:From the few researches done on it, WASM does not limits the technologies to write code
Neither does other languages, like QuakeC. Again, it does not matter what kind of ABI you use, it's the API that limits your modding capability.
freem {l Wrote}:it notably does not forces one to use JS or HTML5
On the contrary.
WASM forces you to use JS when run in a browser (using the emscripten ABI). It is true that WASM could be used outside of the browser (using a different ABI and API called
WASI), but that's fundamentally incompatible with everything you'd normally associate with WebAssembly.
Simply put: if you compile your WASM code for
WASI, then you won't be able to run it in a browser. And vice versa, if you compile it for
emscripten, then you'll never be able to run it without Javascript and outside of a browser.
There was some work done trying to
replace emscripten ABI with WASI ABI (or at least make them compatible), but the effort miserably failed after years of trying, and it's now labelled "wontfix". Those ABIs are just way too incompatible by design, they can never work together.
freem {l Wrote}:but you do need an engine able to understand it, and a toolchain able to generate WASM binaries.
Yep, but as I've said it's a little bit more complicated than that, because the WASM has multiple competing ABI standards.
Here's a good, easily embeddable WASM interpreter written in C. Here you can clearly see, that the
wax interpreter is for running bytecode compiled for the
WASI interface, and
wace is for the ones compiled for
emscripten (note this just implements the ABI, it does not provide the environment normally found in browsers!!!). The two are incompatible. The first needs lots of hooks in the engine (wax provides some of these implemented atop of POSIX libc), and the latter needs Javascript wrapper libraries running in a browser to provide the WASM interfaces (wace does not provide these at all).
Cheers,
bzt