Re: Software Architecture/Design

Such functional composition systems _are_ about as massively data driven and orientated as you can get!  You carefully arrange your data by access patterns, your data is sorted and filtered through the system with decisions being made by the contents of the data itself.  Your designers enter data that controls the very logic of the system given where this and that gets binned etc and you piece it together as a data flow diagram that is itself described by configurable data.
For game logic you effectively have 'decision tables' whose conditions are fed by batches of queries and the functions that process and issue the corresponding actions are driven by the query results and data tables of designer created rules.

From: [email protected]
Date: Fri, 4 Jun 2010 16:25:04 +0100
To: [email protected]
Subject: Re: [Sweng-Gamedev] Software Architecture/Design

Although these techniques don't immediately lend themselves to massively data-driven development, you can still use them to handle all the behind the scenes processing. There's also no concensus on what level of data driven anyone is thinking about when they talk about it.


For my development purposes, being able to add new gameplay features without adding more code is how I might define my game to be data driven. The POs and SOs style does not affect how that can be accomplished (in my opinion). You're merely using the POs to process the SOs data, whether that SO is a lump of dumb data, or a scripted entity, or allowing the PO calls to be generated by a PO process itself (which is pretty much what the existence based FSM technique does).



On 4 June 2010 15:57, Morten Brodersen <[email protected]> wrote:


Ups yes Richard is right. I am talking about Data Oriented Design here

not Data Driven Design :)



Morten



-----Original Message-----

From: [email protected]

[mailto:[email protected]] On Behalf Of

Morten Brodersen

Sent: Saturday, 5 June 2010 12:53 AM

To: [email protected]

Subject: Re: [Sweng-Gamedev] Software Architecture/Design





> Forgive me if I'm wrong, but this doesn't this approach limit the

flexibility of the system ?

> I mean, if behaviors are called explicitely, then adding a behavior

need changes in other place of the code

> (meaning in turn that beyond some limit, the code will be awfully

difficult to maintain).



It is actually quite the opposite. The more you break your application

into simple transform steps (SO->[PO]->SO) the easier it is to reuse and

maintain. Because you can "inject" new PO's without changing the old

SO's and PO's.



For example, if you have the following:



SO_1 -> [PO_1] -> SO_2



You can (for example) change the behaviour by doing:



SO_1 -> [PO_NEW_A] -> SO_1 -> [PO_1] -> SO_2 -> [PO_NEW_B] -> SO_2



Without changing a single line of code in SO_1, SO_2 or PO_1. In other

words you are adding new "lego blocks" that gives you more to build

with.



> It also seems difficult to me to build a data-driven approach on the

top of this appraoch (but again, I might be wrong).

> Or am I missing something obvious ?



Data driven design is about focusing on how the data is structured

instead of focing on algorithms/objects in the OO sense. Organizing the

data structures in a memory friendly way can give you a dramatic

performance improvement because of the CPU avoiding cache misses.



If you think about it, data objects/structures is what SO/PO is all

about:



SO -> [PO] -> SO



The State Objects (the data structures) are explicitly defined and the

PO's are simply transforming the input data to the output data. So it is

actually very easy to do data driven design with SO/PO. What you have to

do is to make sure the SO's take full advantage of the way the CPU

caches are organized.



Morten



-----Original Message-----

From: [email protected]

[mailto:[email protected]] On Behalf Of

[email protected]

Sent: Saturday, 5 June 2010 12:27 AM

To: [email protected]

Subject: Re: [Sweng-Gamedev] Software Architecture/Design







----- "Morten Brodersen" <[email protected]> a écrit :



> A message based architecture is actually very different from the SO/PO



> approach.

>

> The SO/PO focuses on state less PO's transforming one or more SO's to

> one or more SO's.

>

> The PO's are called directly in the code. There are no

> intermediate/mediator forwarding messages from one PO to another.

>

> Messaging can be added to a SO/PO architecture but it is not at all

> required.

>

> Given that a message is a SO and a network is an SO you could for

> example describe messaging this way:

>

> SomeState -> [SomeStateToNetworkMsg] -> NetworkMsg

> Socket+NetworkMsg -> [NetworkMsgSender] -> Socket

> Socket -> [NetworkMsgReceiver] -> Socket+NetworkMsg NetworkMsg ->

> [NetworkMsg2SomeState] -> SomeState

>

> Again breaking the architecture into simple State and Process Objects

> that can be mixed and matched with other SO's. For example with the

> following:

>

> Console+NetworkMsg -> [NetworkMsgPrinter] -> Console

> NetworkLog+NetworkMsg -> [NetworkMsgLogger] -> NetworkLog

> NetworkLog -> [NetworkLogSaver] -> NetworkLogFile

> etc.

>

> Morten



Forgive me if I'm wrong, but this doesn't this approach limit the

flexibility of the system ? I mean, if behaviors are called explicitely,

then adding a behavior need changes in other place of the code (meaning

in turn that beyond some limit, the code will be awfully difficult to

maintain).



It also seems difficult to me to build a data-driven approach on the top

of this appraoch (but again, I might be wrong).



Or am I missing something obvious ?



-- Emmanuel Deloget _______________________________________________

Sweng-Gamedev mailing list [email protected]

http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.

com



_______________________________________________

Sweng-Gamedev mailing list [email protected]

http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.

com



_______________________________________________

Sweng-Gamedev mailing list

[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.

 		 	   		  
_________________________________________________________________
http://clk.atdmt.com/UKM/go/197222280/direct/01/
Do you have a story that started on Hotmail? Tell us now

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