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