Re: Software Architecture/Design

That sounds remarkably similar in structure to the internals of a game I 
designed (code wise) back at the turn of the century.

Essentially each system in the game was a distinct module and each 
module could only communicate with others through a (reasonably generic) 
messaging system.  So you had user input, GUI, gamecode, network, audio 
modules, etc.  Anything sent to the network module was broadcast to 
other clients, and similarly any incoming messages from the network were 
forwarded to their respective destinations.  Although I didn't do it at 
the time, I later realised it would have been incredibly simple to route 
input messages over the network and either play multiple clients from a 
single mouse/keyboard, or duplicate the same game play on multiple 
machines concurrently.

And of course the multi-threaded benefits are more obvious now than they 
were 12 years ago.  And looking forward you're also only several very 
small steps away from to moving from running on a single machine to 
running fully distributed across a cluster of machines.


Morten Brodersen wrote:
> One approach is to start at a high level:
>  
> GameState+Time+DirectX -> [Simulator] -> GameState+DirectX
>  
> and then step by step reducing it. The next step could be (for example):
>  
> GameFile -> [GameConfigLoader] -> GameConfig
> GameConfig -> [GameMaker] -> GameState
>  
> DirectXConfigFile -> [DirectXConfigLoader] -> DirectXConfig
> DirectXConfig -> [DirectXMaker] -> DirectX
> DirectXConfig+DirectX -> [DirectXConfigEditor] -> DirectXConfig+DirectX
> DirectXConfig -> [DirectXConfigSaver] -> DirectXConfigFile
>  
> GameState+Time -> [GameTicker] ->GameState
> GameState+DirectX -> [GameRender] -> DirectX
>  
> and you continue reducing it until you end up with a set of SO's and 
> PO's that are simple enough to understand and program.
>  
> Another approach is to start with something at a lower level and 
> expand from there:
>  
> PlayerState+PlayerInput+CollisionMap+Time -> [PlayerMovement] -> 
> PlayerState+SoundEvents
> SoundEvents+AudioState -> [AudioEngine] -> AudioState
>  
> in the last example I show how the PlayerMovement PO outputs a list of 
> sound events that can then be handed over to the audio engine for 
> playing. It does not call the audio library directly and there is a 
> good reason for this. It enables you to do the following:
>  
> SoundEvents+ConsoleState -> [SoundEventDebugger] -> ConsoleState
> SoundEvents+Camera -> [SoundEventFilter] -> SoundEvents
>  
> Giving you the ability to print out debugging information and to 
> filtering the sound events based on how close the camera is to the 
> sounds before the audio engine plays the sounds.
>  
> And hey if you add the following:
>  
> SoundEvents -> [SoundEvents2NetworkMsg] -> NetworkMsg
> NetworkMsg+NetworkState -> [NetworkSender] -> NetworkState
>  
> you can send the sound events over a network to be played on another 
> console/PC. Without changing a single line of the [PlayerMovement] 
> Process Object.
>  
> It might not be obvious from this small example but hopefully you can 
> see how outputting the sound events as data instead of calling the 
> audio engine directly enables you to feed the sound events to a number 
> of different PO's before the audio engine plays it. Even with the few 
> examples shown here you can already plug together quite a few 
> different architectures: Playing the player sounds with or without 
> debugging, with or without networking and hey even with or without 
> actually playing the sounds (for example when running a server side 
> simulation).
>  
> Continuing the example, if you add yet another PO:
>  
> SoundEvents -> [SoundEventPrioritizer] -> SoundEvents
>  
> you now have the ability to reorganize and remove sound events of 
> lower priority before the sound events are fed to the audio player. 
> Again without changing a single line of code in the previous PO's and 
> SO's. So you now have 2x2x2x2 = 16 different ways to combine the PO's 
> for handling the player sound events.
>  
> Morten
>
>     -----Original Message-----
>     *From:* [email protected]
>     [mailto:[email protected]] *On Behalf
>     Of *Richard Fabian
>     *Sent:* Friday, 4 June 2010 1:36 AM
>     *To:* [email protected]
>     *Subject:* Re: [Sweng-Gamedev] Software Architecture/Design
>
>     love it.
>
>     Something I've been worrying about with my stuff is how unwieldy
>     does it get the higher you go, but you're saying that higher level
>     stuff turns out fine too?
>
>     Can you go a bit deeper into how higher level and lower level
>     stuff gets figured out?
>
>     I can't make sense of a GameState SO, it sounds like too
>     much heterogeneous data for processing. I would guess you
>     decompose your SOs hierarchically and your POs hierarchically too,
>     but thinking about this makes me worried about syncing up
>     hierarchies of code and data. How do you do it?
>
>     I wasn't going to allow hierarchical anything, other than stepwise
>     refinement of what processes need to be done on my data per frame.
>     What have you found out / developed that we should all know ? ;)
>
>     On 3 June 2010 16:01, Morten Brodersen <[email protected]
>     <mailto:[email protected]>> wrote:
>
>         During the 15+ years I have been working in the games industry
>         (and the
>         30 years I have been writing software), I had a lot of
>         opportunities to
>         experiment with software architectures for games (from the
>         engine all
>         the way up). Some architectures worked well, others less so :)
>         But after
>         many interesting experiments I ended up with a non-complex way
>         to design
>         software that works well for small and large scale
>         applications. And it
>         (surprisingly) works well not only for OO style languages but
>         also for
>         functional style languages (and multi-threaded applications!).
>
>         I have no idea whether the approach will work for anybody
>         else. I am
>         definitely not making that claim. But hey it might be
>         interesting for
>         you so here it is:
>
>
>         Morten
>
>
>
>     -- 
>     fabs();
>     Just because the world is full of people that think just like you,
>     doesn't mean the other ones can't be right.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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