Project Refactoring

[ennioVisco]

Hi everyone,

as someone may know, together with @DDuarte, we started a process of general refactoring of WPP. That's because this project has started to grow wildly in the latest years and since the increase in complexity of the protocols (and of the game in general) using this fundamental tool is becoming challenging.

Therefore we identified a couple of key steps in order to move to a more solid, efficient and manageable structure, so that we're able to satisfy the original feature request[1]:

1. Refactoring handlers

At the moment of this issue, the project is built upon a "parser-oriented" approach. This means that the interpretation logic is embedded in few and fat classes containing all the related methods, with multiple versions of the classes managing the different versions of the communication protocol. We're planning to move to a "message-oriented" approach, in the sense that the interpretation logic is moved to many thin classes, of which everyone handles just a single opcode. This step is really crucial: at the moment the handlers are heavily coupled and the whole logic of the program is built on side effects to objects, making the whole program almost impossible to test. We have therefore structured a hierarchy of messages so that they are not put all together in one place but in small logical namespaces where updating one has no effects to the others. Messages are divided into:

• [x] CliChat
• [ ] Client
• [x] ClientConnection
• [x] Global
• [x] Other
• [ ] Player
• [ ] PlayerCli
• [ ] Submessages
• [x] UserClient
• [x] UserRouterClient

As you can see, some of them have been already ported successfully, I've planned to complete all of them in the near future, except for "Client".. Since it is composed of nearly 1000 classes, help is really needed!! Keep update on the handlers_refactor branch[2].

2. Abstracting serialization

Once obtained this change, we'll start exploiting it by building a more efficient parsing process that structures the data on a tree-based approach, in order to produce different, more mangeable outputs which will make it possible to filter and fast-search the packets needed, together with store the information in a more compact way (no more 1GB outputs). A reference can be found of the XML feature proposal [3].

3. Expanding Interfaces [to be extended]

Once the first two steps have been completed, more clear interfaces for input and outputs must be defined, in order to make this project exploitable by other programs, like web servers, databases, and classical cli programs.

4. Enhancing/Building UI [to be extended]

At the end of this very long journey, we expect to have a robust and efficient parser, which will be usable by developers to learn much more about how the game communication works and update the game much more frequently, maybe interacting by a GUI or a Web UI.

Comments and support are really appreciated. Updates will follow!

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.