Re: Software Architecture/Design

Morten Heiberg <[email protected]>
Newsgroups gmane.games.devel.sweng
Message-ID <[email protected]>
Emmanuel:

I can't speak for anyone else, but in the system that I was involved with
each PO exposed a named collection of input points. In C dialect terms you
could ask a PO for a pointer to the function/method of a given input point.
The prototype of that function was well known and was the same for all input
connection points.

You can then tell another PO to store that function pointer for a given
named output connection specific to that second PO.

In the simplest case, whenever the second PO needs to send a SO from one of
it's output ports it would just hand the SO to the stored callback function.
And if you choose to go all fancy and have a scheduler managing your SOs
like I described in my last post then the second PO would just say to the
scheduler "hey, please feed this SO to this function pointer whenever you
think it is time".

Then a small piece of config code can parse a config file and wire
everything up correctly, or even rewire during run-time.

You never need to go into the code of one PO and hack it to call into
another PO.

Simple pseudo-code example of linking an output port of one PO to the input
port of another:

InputPoint *input_callback =
PO2_instance->GetInputPoint(config->input_port);
PO1_instance->Connect(config->output_port, input_callback);

None of the POs should know who they are sending data to or receiving data
from or you would be violating your abstraction and reducing flexibility and
maintainability.

Any information needed from previous processing steps should be encapsulated
in the SOs being passed around.

- Morten


On Fri, Jun 4, 2010 at 4:26 PM, <[email protected]> wrote:
>
>
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.