We have a problem, not that particular “playerstat” thing that is just a trigger for this talk, but we have a problem in general with the dæmon engine. Like all idtech3 mods and games, we have suffered enough from the fact the id tech engines were meant to be forked.
Id tech engine is great and efficient, but it's like every part of it assumes you will fork the whole and never contribute back neither mutualize the development efforts.
Already 20 years of suffering have passed, 20 years of developers suffering from that.
Id tech was meant to be sold and forgotten from the seller. It looks to be designed for only one social relation: the sale. That's the absolute opposite mindset we had when we created this repository. That's the absolute opposite mindset we have when we develop a game.
Either map formats, either materials, either net code, either many things, there is no place to extend, versionnize, and in many case, no bits to even detect the format.
Everything looks to be done in a way the only future exists in forking. At the social scale, this is pure entropy.
Let's make an analogy: not fighting entropy is exactly the same as to run something without backup because the only purpose of a backup is to fight entropy. The issue we have is that not only id tech engine does not fight entropy, but it is designed in a way it induces entropy. To pursue the analogy with a backup, on the social scale an id tech engine behaves like an object with a design preventing lossless copies to be made.
I don't know if you have read Robert Sheckley, but on the social scale id tech engines are like Tangreese, forks of them are produced from thin air as time passes, drawing power from the environment, and we don't have a Laxian key to stop that.
I'm looking for a Laxian key. And before we find it, I'm OK to change the engine to make it more reusable.
We have to fight entropy or our project is already dead: we're not selling discs of plastic that are deads as soon as they are produced and sold. We are building free software and we are building a community. That means we are producing two living things: imagination and social interaction.
There is no "it had been like that since 20 years” to say, in 2020 no one game developer is looking for an engine that requires to be forked and maintained alone.
At some point, that's the reason why we did the NaCL thing and are looking at Wasm: make a game, build it once, run it everywhere the engine is installed. But that's not enough: at first id tech3 did the same with QVM, but it appears that was basically a way for them to ship updates easily.
The fact QVM also makes possible to mod the game is just there for free without guarantee, a game will even face trouble to extend itself without having to fork the engine at some point. We are there.
We already seen that problem with PK3 VFS. PK3 is good enough to ship updates. But PK3 is not mod friendly. Because PK3 is good enough to ship updates, the ability to mod the game is also there for free but without guarantee neither any failsafe. That's a fact players discovered with pain and suffered from for 20 years: PK3 VFS is not designed for modding, it's only designed for updates coming from one source only: the seller. As soon as you have more than one source, the PK3 VFS does not prevent the player's game to be broken. That's why we created the DPK VFS, and… we had to make the hard choice to break compatibility.
The game is so tied to the engine it's even hard for us to extend it without forking our own engine, I mean by breaking compatibility.
Like when we implemented DPK, I'm OK to break compatibility once for some design that makes the engine less prone to compatibilty breaking and less prone to forks on the project and social scale. If we don't find a Laxian key, that would be our Laxian key.
We have a problem, not that particular “playerstat” thing that is just a trigger for this talk, but we have a problem in general with the dæmon engine. Like all idtech3 mods and games, we have suffered enough from the fact the id tech engines were meant to be forked.
Id tech engine is great and efficient, but it's like every part of it assumes you will fork the whole and never contribute back neither mutualize the development efforts.
Already 20 years of suffering have passed, 20 years of developers suffering from that.
Id tech was meant to be sold and forgotten from the seller. It looks to be designed for only one social relation: the sale. That's the absolute opposite mindset we had when we created this repository. That's the absolute opposite mindset we have when we develop a game.
Either map formats, either materials, either net code, either many things, there is no place to extend, versionnize, and in many case, no bits to even detect the format.
Everything looks to be done in a way the only future exists in forking. At the social scale, this is pure entropy.
Let's make an analogy: not fighting entropy is exactly the same as to run something without backup because the only purpose of a backup is to fight entropy. The issue we have is that not only id tech engine does not fight entropy, but it is designed in a way it induces entropy. To pursue the analogy with a backup, on the social scale an id tech engine behaves like an object with a design preventing lossless copies to be made.
I don't know if you have read Robert Sheckley, but on the social scale id tech engines are like Tangreese, forks of them are produced from thin air as time passes, drawing power from the environment, and we don't have a Laxian key to stop that.
I'm looking for a Laxian key. And before we find it, I'm OK to change the engine to make it more reusable.
We have to fight entropy or our project is already dead: we're not selling discs of plastic that are deads as soon as they are produced and sold. We are building free software and we are building a community. That means we are producing two living things: imagination and social interaction.
There is no "it had been like that since 20 years” to say, in 2020 no one game developer is looking for an engine that requires to be forked and maintained alone.
At some point, that's the reason why we did the NaCL thing and are looking at Wasm: make a game, build it once, run it everywhere the engine is installed. But that's not enough: at first id tech3 did the same with QVM, but it appears that was basically a way for them to ship updates easily.
The fact QVM also makes possible to mod the game is just there for free without guarantee, a game will even face trouble to extend itself without having to fork the engine at some point. We are there.
We already seen that problem with PK3 VFS. PK3 is good enough to ship updates. But PK3 is not mod friendly. Because PK3 is good enough to ship updates, the ability to mod the game is also there for free but without guarantee neither any failsafe. That's a fact players discovered with pain and suffered from for 20 years: PK3 VFS is not designed for modding, it's only designed for updates coming from one source only: the seller. As soon as you have more than one source, the PK3 VFS does not prevent the player's game to be broken. That's why we created the DPK VFS, and… we had to make the hard choice to break compatibility.
The game is so tied to the engine it's even hard for us to extend it without forking our own engine, I mean by breaking compatibility.
Like when we implemented DPK, I'm OK to break compatibility once for some design that makes the engine less prone to compatibilty breaking and less prone to forks on the project and social scale. If we don't find a Laxian key, that would be our Laxian key.