[DGD] subdividing into subsystems

[James Smith]

It depends on how the modularity affects execution, among other things. I'm a bit new to developing with DGD, but here's what I've noticed.

I'm developing a mudlib on top of the kernel lib that divides up responsibilities roughly as outlined in some of the Skotos posts. I already tend to do data-oriented, event-driven development elsewhere, so this is a natural fit for me. 

Modularity can mean several things: separation of concerns (e.g., code that handles parsing goes in /usr/ToolLib while code that handles interpreting the parse results goes in /usr/DevLib), separation of execution threads (e.g., requesting a service from /usr/ToolLib requires queueing an event), and aggregation of functionality (e.g., a library managing bulk properties).

What I've found so far is that separation of concerns and aggregation of functionality isn't a performance issue compared to separation of execution threads. As long as the code path is pretty clear and straightforward, it doesn't matter as much how many different users or inherited libraries are touched.

The other thing I'm keeping an eye on is how may different objects have to be involved to get some operation done. If I can distribute information across many objects instead of concentrating it in a few (such as object relationships for containment and proximity), then (hopefully) the driver has more flexibility in which objects it keeps in memory at any one time. This seems like a good rule anyway when working with atomic functions.

On Apr 2, 2013, at 8:05 AM, Raymond Jennings <shentino at gmail.com> wrote:

> I've been on a modularization kick lately and I just split the main game
> logic.  My latest move was to extract all object handling functionality
> such as bulk, description, and so on to its own subsystem.
> 
> Is there such a thing as excessive modularity when it comes ot a mudlib?
> I'm starting to feel like I'm going crazy, but otoh having the kernel
> library enforce privilege barriers as a perk is quite reassuring.
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd