Issue:	Modularisation of HX Coop
Date:	2006-10-03
By:	Sebastian 'Hanfling' Kaufel


I.	Preamble

With increasing ammount of classes (about 200 atm) in HXCoop.u compile time is pretty slow, which slows down extremly the development. There are about thousend classes in the DeuEx.u package - a value to which HXCoop.u will is supposed to grow. Compile time is becomming a major issue, and consumes already to much time.


II.	Modularisation as a state of art

I must admit, that modularisation is one of the major keywords in open source development and in the software industry. Programming became more and more complexity with rapidly growing code bases, and has become a major organisation issue -- tho decades or even one decade in the past, this has been no issue. As I stated in the preamble compile time comsumes to much development time and aggeressivly kills the workflow of the programmer. Also distribution of big static packages has shown to slow down development and especially bug fixing cycles. One good example is the switch between from X11R6 to X11R7 to which features a fully modularized xserver.


III.	Problems with Modularisation

UnrealScript (UC) doesn't handle circular dependencies of different packages. Widgets form a good example for this problematic: In orginal DX Code, settings are instantly applied to playerpawns' variables and are saved automatic this way. This way the UI packge would have to depend on the `base package` where the player pawn is defined. But the player pawn will have lot's of widget specific code, so it will depend on the widget package. To work around this issue, settings might be stored directly to INI files, but how to notify the player of these changes? This might work by using ConsoleCommand(). There should be plenty of these issues and some might geht really nasty.


IV.	Outsourcing by keeping gernerics in the `base package`

When keeping generic classes for Weapons, Pawns and Decorations in the base package, placeable actors derived from those can be put in extra packages (HXScriptedPawns, HXPlayerPawns, HXDecorations, HXWeapons). There might be tiny circular dependency issues, when one class violates those generic behaviors, but by adding a generic interfaces this  might be avoided.


V.	Summary

Modularisation of HX code can be done, but needs proper planing and probably much work. But as compile time becomes more an more a development bottleneck, the switch needs to be done soon. I think this might also be one mayor issue for buggy dx code. (Who want's to wait 1-2 minutes to test just one little line of code?)