To develop your PT server executable, you should understand Win32 x86 RCE principals. This means, you should understand x86 Assembler mnemonics, and be able to work in a low level debugger.
Most of us work primarily with OllyDbg. But SoftIce, IDA Pro, Immunity, WinDbg, PE Explorer, CFF Explorer and Syser are all good tools too. Many of us will use one or more of these in conjunction with Olly, because while they can provide more insight, or allow us to see relationships between code and data or interactions between functions more easily, only Olly makes writing back modifications to an executable a simple matter of in-line assemble / binary edit, copy to file dump, save the dump to a new file.
Beyond that... understanding how Microsoft Visual C++ creates x86 executable code from C++ source code is an invaluable skill, both for developing, and for communicating with other developers. Clearly, understanding C++ is advantageous.
You should also be aware, however, that much of the code in both the client and the server (as already stated, actually part of the same source project on the official developers system) is written as C, not C++. So many of the conventions and principals of well structured C++ are not followed in the source (which we don't have) and that affects the final x86 code in the executable. The point where C++ has to be used, for DirectX, ODBC and other such "new" APIs introduces a "cross-over" where much of the code you will see in your disassembler looks very messy indeed. Also, because the original project was written by students, (or equally untrained persons) and seems to have been to hard to understand and modify by the company that bought it, so it is actually written "badly" in many areas.
In other words, because there is a standard, well defined and commonly reproduced method of solving a problem, don't assume that that is the method PT uses... and if it isn't, don't assume there is a "good reason" for an alternative method to have been used.