They are all fine ideas but they require a lot of work. In order to do a 'proper' design it is a full time job. I know that some of us have full time jobs programming and then doing another serveral hours a night on PlaneShift is not always possible. I'll try to give some points on each of them.
- Problem: Documentation (or the lack thereof)
Solution suggestion: D.E. Knuth's Literate Programming ideology. It simply makes sense to me.
If we updated our Doxygen stuff that would be a good step at least.
- Problem: Entity System Mass Confusion (and code duplication)
Solution suggestion: Make a choice between rolling our own entity system (what GEM sort of is) and using CEL.
When we started to use CEL it was very young but we thought it would grow quickly. It's only in the last little while that CEL has received some attention from Jorrit. In our case we have removed a fair bit of CEL from the PlaneShift code base. Maybe at some point we will remove all links into CEL ( which is what GEM started to do ).
- Problem: Utility classes in CS that aren't as useful as you'd first think
Solution suggestion: Talk Jorrit into dumping them in 1.4. They are just adding to his maintenance headaches right now, as the STL (as of TR1) contains most of that stuff anyhow.
At the time CS was supported on platforms that did not support STL. I think support for those platforms has been dropped so we can probably use a bit more STL stuff.
- Problem: Uncontrolled Class Proliferation
Solution suggestion: Re-engineer the upper (game logic) layer of the PS code. We do not need manager classes for everything but the kitchen sink! - Problem: Objects Run Amok
Solution suggestion: Replace the messy CS refcounting mechanism with something that is much cleaner to use. (pointer-like objects should not intrude on the pointee's interface, and csRef<> does)
These two are the big ones and require a lot of thought and design decisions to be made. Many classes are not a bad thing but I think a lot of our classes are not 'self sufficient' enough and a lot of classes depend on a lot of other ones. This is something that we try to fix periodically but it can be difficult to do.
Either way I think we know that there are several issues with the code base and a lot of times we implement something and realize later that it was a pretty poor system. But replacing it can be a large task but one that we have done and will do again in the future.
