The only limitation I see in this kind of implementation is that we cannot create and destroy objects dynamically, since ChoiceScript does not allow variables to be created during runtime. That is, if I’m not mistaken, we have to know up front how many dragons we’re going to have in the game, or at least the maximum we’re going to allow to exist.
For example, in the case of my current project, I needed several instances of a given “object” with eleven fields. Since I don’t really know how many will be needed (it depends on how the game goes each time) I estimated as many as possible and decided to create ten instances, which immediately forced me to have 110 *create commands in startup.txt (and more because there are other auxiliary variables). The part that is very similar to this approach is that I also created an additional generic “instance”, with the same eleven fields, to fetch the information needed at a given time.
On the other hand, for inventory management, I preferred a different, simpler approach that I have already shared in this topic, which is list-based. In that approach, the “object” is an item with two fields, description and amount, but that could be extended, although limited of course by the maximum size a string can have in ChoiceScript, of which I am not aware. The advantage is that it is very easy to use even for those without much programming knowledge.
I think an abstraction layer could exist over such an implementation of lists to make an object-based approach possible and allow different types of “objects” with specific fields. I don’t know if that would bring too much value for the authors, but it would be a lot of fun to implement. 