Re: Software Architecture/Design

Not in this case. But that is an interesting idea. Similar to how code
injection frameworks work (Spring etc.)

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