It sounds like what you're really asking for is more thorough documentation... I think it would be a bit loose to call it a standard if it changes every time the ENet 'team' feels like changing it. Aside from more thorough documentation, it would be no different to what we have now: we just download the latest version of the enet code and call it 'the standard'.
> > You could treat the spec the same as the source code: Make an initial > version which matches the code as it is now and use a revision control > system to track changes. Programmers could then create their own code > compliant with a specific revision of the spec. Interoperability > shouldn't be a big issue with "virtual worlds" or FPS games, because > you typically only have one or two programs (game client and game > server) which will actually interact, so multiple incompatible specs > isn't a big deal, but those who want to create some additional program > to interact with a particular system will have the information they > need to do so. > > That said, Lee doesn't need to be the one to write the spec. If you > want a spec, read the source code and write one yourself. If you see > areas which could be improved upon, feel free to incorporate those > changes into your spec and make a patch to feed them back into ENet. > If your changes make sense, I'm sure Lee won't mind committing them to > svn. > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
