Re: Software Architecture/Design

Did you consume that description to setup the code at runtime? Or some other non-C# configuration language?

MSN
From: [email protected] [mailto:[email protected]] On Behalf Of Morten Brodersen
Sent: Friday, June 04, 2010 7:23 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] Software Architecture/Design

You are welcome Morten (hey! somebody else who is also called Morten...doesn't happen every day :-) and thanks for your comments. Very interesting!

I some time ago used the approach to write a fast multi-threaded web server in C#. A bit similar to what you are describing here. The architecture was roughly as follows (according to memory):

[MakeServerSocket] -> ServerSocket
ServerSocket -> [ReadServerSocket] -> ServerSocket+ClientSocketList
ClientSocketList -> [ClientSocketFilter] -> ClientSocketList
ClientSocketList -> [ReadClients] -> ClientSocketList+HTMLRequestList
HTMLRequestList -> [HTMLRouter] -> ImageRequestList+ApplicationRequestList
ImageFiles -> [ImageCacheLoader] -> ImageCache
ImageRequestList+ImageCache -> [ImageRequestHandler] -> HTMLReplyList
ApplicationRequestList+ApplicationState -> [ApplicationRequestHandler] -> ApplicationState+HTMLReplyList
HTMLReplyList -> [WriteClients] -> HTMLReplyList+ClientSocketList

where the sockets were non-blocking and using a game style tick loop to execute it. Using the SO/PO approach it was easy to write. And the end result was an extremely fast mini web server. That was fun to write :-)

Morten
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Morten Heiberg
Sent: Saturday, 5 June 2010 12:02 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] 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