Re: Software Architecture/Design

This is a really flexible and powerful way of structuring your code and
data.

I have used this approach outside of the games industry in the design and
implementation of a network protocol stack some years ago, and for that
purpose it worked and scaled wonderfully.

To map things to the terminology of this thread the protocols
(Ethernet/PPP/IP/TCP/UDP/...) were the process objects and the data
packets/network frames were the state objects (along with whatever meta info
they accumulated during processing steps).

This approach made it a breeze to configure new interfaces, set up protocol
tunneling, add support new protocols etc. It was also a great help during
testing and debugging since we could just inject POs at will or replay
previously captured or handcrafted SOs for unit testing.

Want to test your TCP retransmit code? Just add a simple PO that randomly
drops packets to simulate a noisy connection. Want to test your IPv4
fragmentation and reassembly code? Inject a PO that buffers and reorders the
packets it receives.

The more polymorph you can keep the PO connection points the more flexible
the system becomes and you can rewire everything to your liking. Or use them
to plug isolated components into a unit testing framework.

Others have already commented on how much this kind of thinking can help
parallelization efforts. I completely agree. As long as you break down your
POs enough and make sure to encapsulate everything relevant in your SOs you
get multithreading at a reasonable granularity for free.

Another trick (which we used to implement bandwidth management and quality
of service), that I think transfers rather well to game development, is that
you can think of your state objects as your scheduling units. Your scheduler
basically holds all the SOs, sorts them according to some priority and
schedules them to their next PO accordingly.

This way you can easily set up your AI to run reasoning and perception code
at a lower "framerate" when they are far away from the player (by making its
scheduling priority a function of this distance) and a bunch of other neat
things. You can even use the abstraction to abandon some non-essential SOs
to recover from a framerate drop without having to write a lot of cleanup
code.

Good stuff. Thanks for sharing!

- Morten

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