Re: [Alephmodular-devel] High Level Modules
Status: Pre-Alpha
Brought to you by:
brefin
From: Br'fin <br...@ma...> - 2003-01-02 06:02:45
|
On Monday, December 30, 2002, at 10:24 PM, Chris Pickel wrote: >> A very good list. I'm trying to think of what we should call this >> group of ... extended physics. Scenario? Personality? (Do you play a >> Map Scenario ala E:MR within AM with the Personality of M2?) I agree >> that they should have their own module. Something that might >> interface a bit more strongly with the other modules than any other >> module is allowed to. >> >> An extended example would include not just monster definitions, but >> also provide the monster control functions. (Hah! *MY* Scenario >> implements a segmented worm as a monster!) >> >> I'd really like a decent name for this! > > Let me think... > "Bio" modules? It's a little more interesting than calling them > "Definitions" modules. A "Map Scenario ala E:MR with M2's Bio." > Bio certainly has a nicer ring to it than Personality :) Not convinced 100% but it does ring better. > Another issue that has just come to my mind is inter-module > dependency. It's bound to happen - someone will add an extra item on > to item_definitions, and then someone will write another module that > depends on that item. If we're not careful, AM will screw up and leave > the user wondering how to fix it. > > So, we create a "module_compatibility.h/.cpp" for modules to work > with. Fairly simple: > > -------module_compatibility.cpp------- Mmm, good idea. Don't know if I'd quite phrase it like that... Or more to the point... most modules are compiled together. So something that was macro-based to complain during compilation would probably be better. As for plug in or other external components that require various systems, it would certainly be a good idea. Like if we allowed AM to load an external bio, then we could have an api to check to make sure all the features the bio asks for are up to snuff. -Jeremy Parsons |