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