'Extending' a type at runtime
BlitzMax Forums/BlitzMax Beginners Area/'Extending' a type at runtime
| ||
| For lack of a better way to describe it, I'll use an example. My quick proof of concept game had two classes - TUnit and TUnitKind. TUnitKind loads from an xml file at runtime certain stats of a unit kind (eg MaxHP, Name). It acts kind of like a super type for TUnit at runtime. TUnit would store the stats that are particular for each instance of that kind of unit (eg CurrentHp, Position) as well as a reference to a particular TUnitKind instance. Therefore TUnit is acting like a derived type created at runtime. While this work, it's a little awkward. If I was hard coding all my rules and stats into the engine (again, for lack of a better word) this would be trivial. When it comes to trying to do it at runtime, my experience runs a bit thin. I was wondering if any of the experienced people here could suggest a better (cleaner, more efficient, simpler, whatever) way of achieving this behaviour. Now I'm out of the proof on concept stage it's time to code the final reusable modules which will make up the final game (and hopefully form a part of different games I make). Clearly then I'd like to get it right. |
| ||
| I'd try a composition-based approach at compile time rather than trying to build an über generic runtime framework. The problem with the direction you're going in is that it's primarily data based and you lose the nice sematic benefits of OOP. Now, if your particular implementation won't win anything from polymorphism then the road you're on might be the right one. However, from your description, I'd say there's a lot to be gained from a reified domain model. Here's what I'd do: 1. Build a concrete, reified model for your first game. 2. After the game works, refactor any common classes and other functionality "up the tree". 3. Move the generic base classes into their own module. And, finally, if you really want super composition: 4. Break reusable subclasses off into their own modules so you can quickly recompose them into new projects. For example: You might break off an TDarkKnight subclass into its own module so you could reuse it in the future for another game. Hope this helps. |
   |