Re: 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.

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