Re: Software Architecture/Design

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]> 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