Post 1.0 and tes3mp
Posted: 09 May 2018, 00:04
Hello all. It’s been a while. This past semester was hell for me, but fortunately it has ended. Anyway, I’ve been catching up with this project, and there is something I believe needs to be addressed. I see that Zini has made significant progress on a design document for the next major version of the project (post 1.0). This is great and I’m looking forward to reading it once he releases it. I see he is planning to have Scrawl give feedback on it for his graphical expertise, which will no doubt make it that much better. However, there is a party that should be involved with the design phase, but isn’t: the main developers of the tes3mp fork.
There are three important reasons why the tes3mp team should be involved with the design phase. First, it would allow both teams to work on a single project. Currently, development efforts are being split across two separate projects which is unhealthy considering that the only important difference between the two is networking. New developers have to choose between working on the openmw project or the tes3mp project and being involved with both communities. They should not have to choose between the two.
The second reason is that joining the two projects would be much is easier if planned during the design phase. The main requirement is to use a client-server model (and maybe a plugin system) where logic is split from rendering graphics. This major change was discouraged previously because the project had not hit 1.0 yet. Now that major changes are being considered, this is no longer a deterrent. This should be done at the start, and not several months after development has started.
The third main reason is related to the second. If multiplayer is not considered at this stage, we are probably looking at another fork of the project in the future. David, one of the main developers of the tes3mp team, has done a great job of merging in changes from openmw. However, once the core engine begins to have major changes, it’s unlikely he will be able to continue doing so. If the changes are as big as I think they will be, then either progress will slow dramatically until the design of the core engine stabilizes or the two projects will diverge. At that point, someone may decide to add multiplayer to openmw again starting from scratch. This should be avoided if at all possible. It is unhealthy for both the community and future development.
I hope that the two projects can become one in the next major version of openmw. I wrote this on behalf of the tes3mp team after asking if they were already involved and discovering it was not the case.
There are three important reasons why the tes3mp team should be involved with the design phase. First, it would allow both teams to work on a single project. Currently, development efforts are being split across two separate projects which is unhealthy considering that the only important difference between the two is networking. New developers have to choose between working on the openmw project or the tes3mp project and being involved with both communities. They should not have to choose between the two.
The second reason is that joining the two projects would be much is easier if planned during the design phase. The main requirement is to use a client-server model (and maybe a plugin system) where logic is split from rendering graphics. This major change was discouraged previously because the project had not hit 1.0 yet. Now that major changes are being considered, this is no longer a deterrent. This should be done at the start, and not several months after development has started.
The third main reason is related to the second. If multiplayer is not considered at this stage, we are probably looking at another fork of the project in the future. David, one of the main developers of the tes3mp team, has done a great job of merging in changes from openmw. However, once the core engine begins to have major changes, it’s unlikely he will be able to continue doing so. If the changes are as big as I think they will be, then either progress will slow dramatically until the design of the core engine stabilizes or the two projects will diverge. At that point, someone may decide to add multiplayer to openmw again starting from scratch. This should be avoided if at all possible. It is unhealthy for both the community and future development.
I hope that the two projects can become one in the next major version of openmw. I wrote this on behalf of the tes3mp team after asking if they were already involved and discovering it was not the case.