DRAMF - Dependency Respecting Asynchronous Module Framework

Do you ever find yourself using an organization schema like this, where you have a frontend API module with a large amount of internal modules?

If you’re even more brave, you’ll have modules that other modules require for utility purposes that provide things elsewhere, etc, etc…

This type of system can get complicated and convoluted very quickly, and that’s where libdramf comes in in order to provide a way to flatten these dependencies, and provide an easy framework for making modular systems in your games.

A DRAMF instance can be grabbed or created via the frontend module based upon a specific name. By passing any number of modules, etc. to this, the instance will act as a framework to hold all the various functions that your system uses. If a module attempts to call a function that isn’t available, the DRAMF instance will yield the request until the function is available.

DRAMF includes a library function which allows you to seamlessly create DRAMF instances inside of DRAMF instances, allowing easy subdivision of your systems combining to the singular frontend, incase if you have some crazy organization scheme.

All DRAMF instances have a shared variable table inside of them that can be used to store runtime variables, and includes a function to wait for values to exist inside of this table for convenience.

All of these features for this specific organizational schema are done in a mere 150 lines of code, keeping the system clear of bloat and ensuring that DRAMF isn’t in your way, allowing you to get work done.

Documentation is on the Github and inside of a module in the model.


Sounds like a really cool tool. I’ll have to check it out

1 Like

This is a very well-made framework, well done! Thanks for sharing as a resource! :slight_smile:

1 Like

This is awesome, what qualities does this provide over Knit framework?
Really interested to look into it!

Looks super cool, I like how it separates modules… I’ll have to give it a try some time.

It can be used to fulfill a similar role to Knit through the usage of names with :GetDramf(). DRAMF’s organization and usage schema is however better for making internal modular systems where cross-dependencies exist, which is popular even in Besides that, I made it intentionally more barebones and simple to not trap myself (or anyone using it) into any specific paradigm. One of the main drawbacks of using DRAMF right now is that Knit has client <-> server communication out of the box, and a tighter bond between the client and server end of code than DRAMF’s architecture would allow the facilitation of.