Sign in to follow this  
  • entries
  • comments
  • views

Implicit Dependencies...

Sign in to follow this  


As I'm wrapping up the 1.2 Ancient Galaxy patch, I think back on some of the challenges I've had with the AG Engine and why it can be somewhat of a cumbersome codebase to work with - similar to other complex software systems.

A largish piece of it is the fact that so many data and logic dependencies in the engine and game become implicit, and not articulated in any sort of manner that can be automatically checked ( like by the compiler, for instance ).

I been thinking one way to improve things would be to add explicit dependencies into the core of an engine, as a fundamental concept. A limited version of this would be ref-counting, where you at least prevent pulling an object away from another that's using it, although there are no guarantees w.r.t what state the object might be in.

Rather than ref-counting, which only tells you how many folks care about you, you might do reference linking, where you have a pointer back to the interested parties. With this you can create a rudimentary subscription ( or signal/slot ) model.

The next step would be to have an all-seeing, all-knowing subscription manager class that could manage subscriptions, something like this :

struct Subscription
enum NotifyType
ntNone = 0x0,
ntRead = 0x1,
ntWrite = 0x2,
ntConnect = 0x4,
ntDisconnect = 0x8,
ntFrame = 0x10,
ntPause = 0x20,
ntUnPause = 0x40,

ntCreate = 0x80,
ntDestroy = 0x100,

ntUpdate = 0x200,
ntSceneAdd = 0x400,
ntSceneTraverse = 0x800,
ntSceneRemove = 0x1000,
ntContact = 0x2000,
ntTrace = 0x4000,

enum NotifyWhen
nwPre = 0x0,
nwOn = 0x1,
nwPost = 0x2

uint32 _datum_id;
uint32 _scope;
uint32 _flags;

uint32 _subscribee;

std::vector< uint32 > _subscribers;

// can hold history here, rather than in subscriber or subscribee
Datum::Value _history[ 16 ];

class Mgr
std::map< uint32, Subscription > _subscriptions;
public :

typedef void (__cdecl* Notify )( ( const Datum* const pDatum, const Subscription* pSubscription, const uint32& notify_type, const uint32& notify_when, const int32& datum_age );

One potentially interesting idea possibly beyond a standard signal/slots mechanism is the history, which can include the previous values of the data, for weapon trails, interpolation, etc. It could also be useful for futures and reading 1-frame behind data. You would subscribe to history -1 for the last frame, choose 0 for this frame, etc.

I also like the separation of the Pre/On/Post flags from the subscription type. That way any subscription type can be combined with the Pre/On/Post flags to allow you to hook in where you need to.

The scope value is there as a differentiator, for instance, an object may get added to multiple scenes, so you could have different scopes that would have separate subscriptions.

It seems this would allow things to be more data-driven, which can be good, but also places a larger burden on having tools to display & manipulate these dependencies...
Sign in to follow this  


Recommended Comments

There are no comments to display.

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