Here's a nice pretty diagram of the various components of modelling a (any) world.
In my case here, the world is a virtual world. You would noticed quickly:
- The strong MVC reference. If you really don't see it, try look at the colours
- World is made of models - which are actually no different from a business application. The same model pretty much applies
- SilverLight 2 Beta 2 has strong work done on the visual manager, which I think is best used to utilize for rendering the world
- In fact, in most games, the graphics component is the main component, in my little model here, it isn't.
- The command logic is largely work from WPF's command syntax - in a business application, this means we can wire up multiple events to the same command (aka, control-C, menu)
- In the context of a game, it means we can offer key-bindings and the user can choose what keys he'd rather use instead of the defaults
- The blue part is the least ironed out section of my little model here - in a pure MVC situation, perhaps the Commands should be responsible for directly making the calls to the server / modifying the game objects.
- Should I wait for server response before making the object move? or should I trust the client and let it start moving, and allow the server to 'validate' the client's behaviour
One final work remains in this modelling exercise:
- Some sort of dependency-injection for making it all work in SilverLight, this way, I can work on each component one at a time and have them plug in/out
- And unit-test separately
- There's some good work in the AssemblyPart class
- Not sure about security implications though