Open DigitalLibrarian opened 8 years ago
We can put this off for a while by hard-coding the database behind provider and factory interfaces.
Looks like it might be a good idea to make a separate language like representation similar to #16
The language parser could drive parser factories that fill up an atlas.
For a data source, create another project that takes df raws and iteratively can import more and more as we build out our simulation model.
Most things in the simulation should be completely data driven. The list includes:
The entails a huge serialization and persistence requirement. Perhaps a database is in order. Or preferably a json flat file importer. Why not both? We need to abstract the persistence layer, so that it can be swapped out to different formats.
There is also an immense interdependence among the entities we want to serialize. The relationship requirements are very similar to a normalized database.
There would be a benefit to determining which pieces of data can be shared statically among the live entities running in the simulation, so save on memory usage. I've been thinking of an ItemClass system that stored definitions of objects that can be used to create instances. We already have this with WeaponClass and ArmorClass, but we need something more inclusive. Really, this Class system might be useful in even a more generic way. It is likely that we would want the same serialization and memory instance management patterns for all of the items on the list above.
20 entails a refactor of the item, weapon, and armor relationships.