The 3 boxes above represent the 3 layers, much like layers in the layer pattern. So that going from the game logic to the view, whereas the commands go from the views to the game logic. Events that occur in the game logic trickle up to the consumers of these events, which are the views. Particularly when coming from views and going to the game logic. Simply put, The command system is an interface to the game logic. Many different views that speak commands can interact with the game logic in a uniform way without themselves manipulating game logic code. Firstly, you have de-coupled the game logic with the views: Views speak Commands and Game logic understands commands. Commands are instructions from views to the game logic.
Events occur in the game logic when world state change occurs.It is separated into one set of view components which are both event consumers and command producers.No seriously, it does!Īnyway, here is a drawing I put together to demonstrate the simplicity of an MVC-like architecture:
I’m very much interested in system architecture and when I have the opportunity to design and see these architectures in play, it fills me with child-like glee. It's very much like MVC if you're familiar with this pattern. Here is an architecture that really shines in an object orientated world mostly because it uses some well-known patterns from OOP. So I've started piecing what my C++ code will need to represent.
I've been resigned to design a game engine in pure C and I started to try and do it here: SDL and stuff and while I didn't go into much detail, it became clear then and more so now that describing and managing architectures are more suited to an object orientated language like C++. I’ve been recently reading about an architecture design strategy for games described in Game Coding Complete 4th Ed. Details Stuart Mathews Code Game Development
0 kommentar(er)
