Re: DCI vs Data Oriented

    Interesting discussion, this. It verbalizes lots of thoughts I've had around the OOP/NOOP arguments that seem to be the flavour of the decade. I for one welcome a more nuanced discussion than simply "OOP sucks".

    I would just like to add one small comment though: I would be careful to try and shoehorn every problem into the same type of solution. For example, using normalized tables is awesome for some types of data (or rather, some types of operations on the data), but terrible for others. There's a reason why you often denormalize tables when moving the data out of OLTP systems into data warehouses, and also why people move away from RDBMS in favour of "NOSQL" solutions.

   Also, code has to be written not only for machines - it has to be comprehensible by humans as well. Programming is a balancing act :)

-Stefan

From: [email protected] [mailto:[email protected]] On Behalf Of Richard Fabian
Sent: 04 June 2010 10:08
To: [email protected]
Subject: [Sweng-Gamedev] DCI vs Data Oriented

After having read up all I found yesterday on DCI, I can say that I think it's a good decoupling of data from capability and responsiblity, but it seems like it's more important than that.

"So really, the core concept isn't in the names of things but what DCI allows you to see: that an object and the interfaces it can support are separable things"
Which is what database programmers have been aware of for years, except they never locked down on objects. I've been trying to look through their eyes at what we do in games, and the biggest concern seems to be that no-one is normalising their tables.

Even in DCI there's still this tendency to think of things as having some object level control over its data. The example mentioned numerous times is the Account object, but in DB speak there is rarely an account object, normally there's an AC# to opening date table somewhere, but that's about it as far as a one to one mapping with an account you'll get in a normalised DB. There's merely a set of transactions with an AC# in the source and destination. An account to customer many to many table and maybe an account closings table. There could be cache tables for reasonably current values of each account to help DB speed, but it's not absolutely necessary, and is definitely not part of the normalisation of the system.

The point I'm making is: in DCI, I am allowed to think of the account object as a mental model of the sum of the transactions plus the fact the account was opened. That feels like a role. That's not some type conversion from one object to another, that's a proper convolution of one set of objects into a whole new thought space. I like that. We don't need to move from one object to another, we can move from a question about a collection of state data, into a role object.

I think this means that DCI sits better with data oriented development than OO.


On the other hand, a page written by someone else who understands this stuff would be useful ;)

Yes, the naming is painful, I think methodless roles is well defined by the concept of a role in general, however methodful roles just seems to be another name for algorithm or transaction or action. The underlying theory, in my opinion, is really sound, but the way the authors describe their work makes it sound harder to get than it is (or I'm just not getting it).

I also like how the idea is not tied to any language, or for that matter, technique in any language. I found some source for an example written in C++ with templates and virtuals, but I don't see why it can't be written in almost any language, or style.

I tried to work DCI through using my data oriented principles and it comes out just fine, it's just less recognisable as a leap forward there as it's not coming from the coupled implementation/intention land of C++ classes. Still good, but not something you can't reach accidentally by observing old school DB techniques.


On 3 June 2010 17:28, Mat Noguchi <[email protected]<mailto:[email protected]>> wrote:
I was wondering if anyone would start talking about DCI...

To me, DCI is about separating intent and implementation. The naming convention is a little opaque, but methodless roles capture identities as a type (so you can typecheck proper use of parameters!) and methodful roles capture intended behavior. In the bank account example, you have two methodless roles (identifiers as types, basically) of SourceAccount and DestinationAccount, and a methodful role of TransferMoney.

DCI comes in by binding the identifiers and methodful roles to objects through the context object (the C).

So really, the core concept isn't in the names of things but what DCI allows you to see: that an object and the interfaces it can support are separable things, and separating them makes it easier to work with both the interface and the object itself.

MSN

-----Original Message-----
From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Bill Kelly
Sent: Wednesday, June 02, 2010 6:33 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [Sweng-Gamedev] Existence Based Polymorphism

[DCI stuff snipped]
_______________________________________________
Sweng-Gamedev mailing list
[email protected]<mailto:[email protected]>
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com


--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com