HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Composite vs. Component based systems.

08-12-2004, 01:00 AM#1
weaaddar
A frequent question I recieve is "Hey, I like so and so feature of Drag and Drop, can I just use so and so feature without the rest of the stuff?"

D+D RC3 is a nice composite system. Features can be turned on and off on a per hero basis without the crashing or having wierd glitches. However, despite how nice it is, it can not really function without all the code present. Trying to remove an object is asking for a crash.

However, I could move to a component based system. Where you could remove certain features from code completely from the core without any danger. I do not like it, because A) Very few people understand the working of Drag and Drop and removing components may convince them into thinking other NECCESSARY CORE features would be just as easy to remove. The code would also increase probably in size to get the same effect as currently. One advantage I see is that if you don't use all features you get a small size saving. The major disadvantage is ANOTHER core rewrite. (I hate doing these things).

The other advantage is more important. I could create an API Standard for components to allow you to add entities to Drag and drop without it giving a whir, instead of having to directly mess with the crazy order trigger you could create you own component which interact with my objects by using your own order trigger. (Note you may have to use more triggers then order, but order is used by almost everything).
Composite vs. Component based systems. - Wc3C.net