Comments on: MVC, my friend http://www.brainfold.org/blog/2007/12/15/mvc-my-friend/ On Python, game development and everything Fri, 21 May 2010 13:34:29 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Jussi Lepistö http://www.brainfold.org/blog/2007/12/15/mvc-my-friend/comment-page-1/#comment-142 Jussi Lepistö Tue, 18 Dec 2007 11:51:16 +0000 http://www.brainfold.org/blog/2007/12/15/mvc-my-friend/#comment-142 Thanks for the long comment! At least this somewhat reinforces my faith in this design actually working in practice. The major difference between our designs seems to be that in yours, communication is handled by the entity, and in mine, by components. I'll post more details and experiences on my design once I've implemented and actually used it. :) Thanks for the long comment! At least this somewhat reinforces my faith in this design actually working in practice. The major difference between our designs seems to be that in yours, communication is handled by the entity, and in mine, by components. I’ll post more details and experiences on my design once I’ve implemented and actually used it. :)

]]> By: Oliver Charles http://www.brainfold.org/blog/2007/12/15/mvc-my-friend/comment-page-1/#comment-103 Oliver Charles Sat, 15 Dec 2007 23:59:21 +0000 http://www.brainfold.org/blog/2007/12/15/mvc-my-friend/#comment-103 An interesting approach, I've took a somewhat similar route when I started my little Asteroids engine. Models were purely abstract data, left to be interpreted by systems - which would do this interpretation through use of the visitor pattern. Worked reasonably well, but I just don't like the Visitor pattern - it always feels like you have one class doing a TON of work, and I don't like that... However, after refactoring my component system heavily, I seem to have ended up with a somewhat MVC approach again :) Here's what it looks like (hopefully it's followable): My current system, if it helps to hear what I'm doing is this (class names are /LikeThis/). The game runs with an /Engine/ and a /World/. Objects in the game are classified as /Entity/ derivatives which are built up of various /BaseComponent/ derivatives (like your features). The /BaseComponent/s are created and managed through a class that implements /ISubsystem/. These subsystems loop over all of there components, updating them accordingly (for example, the moveable component updates the Position attribute, based on Velocity). Here, the subsystem acts like a controller, with the components as the model. Now the next step is getting stuff on the screen. For this I use superpig's Kernel model, which is the engine. I bind the RenderingTask to the RenderingSubsystem, and insert the Task into the engine. By binding the rendering task to the RenderingSubsystem, when GeometryComponents are created, the subsystem is able to refer to the rendering subsystems resource manager, and request vertex buffers (I've abstracted the graphics api into RenderingTask derivatives). Communication is also handled by events (which I believe are synonymous to signals, just event is the C# term), but maybe in a slightly different way to yours. When I create my spaceship entity, the entity hooks into any component events, and routes these as it sees necessary. So the ShipEntity might hook into it's Destructible component's Destroyed event and, and then cause the creation of a particle emitter component. I know this is a bit of a long post (hey, I don't have my own blog :P) but I just wanted to get my system out now, because now that I've actually been using it, it really is working nicely - and I think we are definitely on the right lines about pushing this whole component system idea - it is the way forward! Hope this is in someway helpful :) An interesting approach, I’ve took a somewhat similar route when I started my little Asteroids engine. Models were purely abstract data, left to be interpreted by systems – which would do this interpretation through use of the visitor pattern. Worked reasonably well, but I just don’t like the Visitor pattern – it always feels like you have one class doing a TON of work, and I don’t like that…

However, after refactoring my component system heavily, I seem to have ended up with a somewhat MVC approach again :) Here’s what it looks like (hopefully it’s followable):

My current system, if it helps to hear what I’m doing is this (class names are /LikeThis/). The game runs with an /Engine/ and a /World/. Objects in the game are classified as /Entity/ derivatives which are built up of various /BaseComponent/ derivatives (like your features). The /BaseComponent/s are created and managed through a class that implements /ISubsystem/. These subsystems loop over all of there components, updating them accordingly (for example, the moveable component updates the Position attribute, based on Velocity).

Here, the subsystem acts like a controller, with the components as the model. Now the next step is getting stuff on the screen. For this I use superpig’s Kernel model, which is the engine. I bind the RenderingTask to the RenderingSubsystem, and insert the Task into the engine. By binding the rendering task to the RenderingSubsystem, when GeometryComponents are created, the subsystem is able to refer to the rendering subsystems resource manager, and request vertex buffers (I’ve abstracted the graphics api into RenderingTask derivatives).

Communication is also handled by events (which I believe are synonymous to signals, just event is the C# term), but maybe in a slightly different way to yours. When I create my spaceship entity, the entity hooks into any component events, and routes these as it sees necessary. So the ShipEntity might hook into it’s Destructible component’s Destroyed event and, and then cause the creation of a particle emitter component.

I know this is a bit of a long post (hey, I don’t have my own blog :P ) but I just wanted to get my system out now, because now that I’ve actually been using it, it really is working nicely – and I think we are definitely on the right lines about pushing this whole component system idea – it is the way forward!

Hope this is in someway helpful :)

]]>