Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    422474

Resource Manager Design Pre-Part 3

Sign in to follow this  
_the_phantom_

71 views

This'll be a short entry because for starters I'm going out in a bit and because I haven't done a huge amount on this subject in the last couple of days.

So, what direction are we going to go with with this system? Well, right now it is very tied to OGL and GTL at a fundimental level, which is fine for testing but doesn't make it all that flexible.

So, this got me thinking, how can you design a system which is both flexible and safe without introducing an inhertiance chain as long as your arm?

Policies.

Policy based design and type-traits are a fantasic way to produce flexible systems which don't require inhertiance chains and allow you to customise various aspects of the system.

I'm currently considering an STL like system in some respects, were aspects can defined at both compile time AND runtime. However, the specifics are still somewhat stuck in my head and being worked around a bit.

The direction I want to head is so that the loader used, the storage system, how the handles are free'd and the handles themselves can be customised at compile time, so the functionality of the class is, effectively, pushed out to other user defined classes (of course, examples will be given).

As a future consideration there is an article in one of the GPG books which talks about introducing new resource types without needing to compile the resource handling code again, this aspect will also be brought into the system.

I'll probably come up with a few managers over the coming weeks, because there are a few ways to handle all of this, from monolthic managers to indivdual ones per resource and combining them in other wise.

It should be an intersting exercise in templates for me if nowt else, of course that means that part 3 proper might be a few days coming as I need to refresh my template knowledge as well as readup on policies and typetraits again, which gives me 3 books to look at (C++ Templates - The Complete Guide, Modern C++ Design and C++ Meta Programming).

Also, I've been working on getting the More OpenGL Game Programming GLSL examples working... they work on my framework but seem to fail on the book supplied one... slightly odd.

So, if there isn't an update in a little while, in the words of the HHGTTG; Don't Panic.
I'll be back with more as soon as I can [smile]
Sign in to follow this  


1 Comment


Recommended Comments

I'm considering writing a templated resource manager to replace my specialized resource managers; however I have a lot of utility code inside my specialized resource managers (GetClosestActorTo, FindOldestInventoryItem, FindExplosiveItemsNearby, TriggerEntityForActor) that I use to encapsulate a lot of data-specific mass-management code.

I'm suspecting I'll have to write two or three kinds of templated resource managers -- one for resources within the world (Actors, items on the ground), one for resources that take triggers (door panels) and one for just generic collections of resources (inventory, skills).

I can probably get away with rolling the worldobjects and triggers together into one resource type and then using one templated resource manager class for them, but that seems like it has the potential to snowball back into the system I have now (with ActorManager, GroundItemManager, EntityManager all having their own implementations and sharing no code whatsoever).

So what I've also considered doing is just writing a ResourceManager interface with integrated serialization and collection-management routines and then inheriting from it to produce ActorManager, etc, to deal with the specialized functions for their resource. But this is more or less what I have now with only slightly less code duplication and what will probably turn out to be template-fu or a base Resource class to get the generic ResourceManager class serializing properly for any type of resource manager that I inherit from it.

So I'm stuck. The templated resource manager is too generic, and the inherited one requires too much boilerplate (and produces like seventy billion special-case classes for every major datatype's specialized functions like GetClosestActorTo).

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now