   Seperate arrays for object properties, modular or just plain silly?
  I've been trying to wrap my head around this all day. Basically I'm trying to create a project whose sole purpose is to be completely modular--i.e Parts of it can be easily changed, from GUI to certain parts of the core logic, without changing any other part.I started this by splitting the core game-logic library (Which is not, in itself, dependent of the project) into three modules: Model, View, Control. A system which I do not fully understand.Since the first phase is a simple game in the Rogue-like tradition, here is how each module will be implemented:Model will contain the Map.Control will contain the behavior, and the glue class (GameObject) for the other modules.View will contain a function which will transform the Map (And the instances of GameObject therein) into an ASCII string.The function in Module View does this by accepting an instance of Map (With instances of GameObject), and a list of characters mapped to the GameObjects. These characters are mapped through a ViewID field in the GameObject instances.This does not strike me as a good idea. Usually, in an OOP project, I'd place the character right in the GameObject instance. But for this kind of project, I'm hoping to implement a system whereby a user can create a whole different set of characters and simply replace the file which contains the characters in order to plug them into the game.This could be taken a step further as follows:Since GameObject simply contains an id pointing to a View object, that View object can be anything from a character to a bitmap to a 3D model, and all that I would be required to change would be the function which generates a view from this information, and the GUI.Of course the same effect could be achieved -- more efficiently probably -- using interfaces. Yet I can't help but see the merit of using separate arrays, because like I said, a user can easily create a different tile set for the game, and switch between different tile sets without ruining the save game. And yet I can't help but see this approach as a bit iffy.I plan to use this philosophy for the rest of my application, but I would like some advise about weather or not it's recommendable.   
  I use MVC pattern quite a bit now and think its wonderful. Originally when I started using this I would stick all "model" type stuff in their models, my view would read all this stuff (info on meshes etc) and then draw it.I gotta say its be a right pain doing it that way. Now what I do (only simple demos, nothign huge). Niow I do it liek this:Model: Contains my scene, camera, render code AND logic. You'd think some of this would belong in control/view but I'm thinking differently now.View: This isn't even a window, for me its an "opengl view". Usually I put in some fucntions, "Set projection" some initialisation and a method "Render" which takes a model object.Control: Controls everyhitng, if I need my view too update in a seperate thread then control will launch that thread, kill it etc. Any key events (such as from the win api) get sent to the control object which in turn sends them where they need to go, when rendering it calls view.Render(model) etc etc.Its not entirly correct I'm sure, the idea is you should be able to swap out one model for another and one view for another.An example of some views might be like in a 3d modeling app, "Top" "Side" "Front" "Perspective" etc etc. Some controls might be "Right click menu". In a 3D modeling app the model usually is just that, a model.Anyway, I think its a nice pattern, not sure if I've done it entirly right myself :P but be careful when you try to to make things modular for the sake of it alone, it'll prolly end up being more work than it needs to be.Model should be everyhitng in your game (and perhaps also how to render everyhting). View should be just how its presented, control should hanbdle all key clicks, resize, start up ent). Its tempting to put all rendering into view but once you do that, view gets very bulky.I'm no expert though so bare that in mind :P.   ;  I am using a strict MVC pattern in my C++/Ogre3D client http://www.next-gen.cc.What I do is seprarate each object into three.A ControllerObject, a ModelObject and a ViewObject.I also have 5 classes:ModelModelListenerViewViewListenerControllerThe Controller creates the Model and the View. It also inhertis ViewListener andregisters itself as ViewListener on the View so it can act upon key and mouse events. The Controller also checks for network input.When an object is created the controller createds and ID and tells the model to create a new ModelObject with that ID.The Model is kind of stupid, it waits for something to create objects in it. The model also supports registration of ModelListeners, when properties in objects change it iterates over all of its ModelListeners and call an update on what has changed, added or removed.Properties are {key, value} values.The View has support for registering ViewListeners, as soon as something regarding keyboard, mouse input, clicks in windows etc happens it iterates over all of its ViewListeners and let them know what happens.The View is also a ModelListener and registers itself in the Model, so when ModelObjects are created, deleted or changed the View can react on it.Example action:The Controller gets a network message telling it to create an object with the property "mesh" set to "ogre.mesh". The controller generats an id and creates an object in the Model, the View gets notified and thus creates an ViewObject.Then the Controller sets the property "mesh" to "ogre.mesh" on in the Model (the Model sets the value in the ModelObject).The View gets the update and reacts on the property type "mesh" and thus load try to load the file "ogre.mesh" and apply it to the ViewObject.Note that in my case I dont't have a ControllerObject with the logic since all my logic is in the server. If you not developing a server/client game you probably want a ControllerObject that runs all the logic.The view should ofcourse should only react on graphical stuff, like positions, animations, speed vectors, meshes. It will totally ingore properties like "life", 31, "mana",40 , "max_mana", 100 and any other logical values.With this setup you can for example shutdown the view completly and the game is still running. This feature is used for example changes the resolution of the window ingame. If you ever seen a game which only can change this outside in the game menu you know it not a proper MVC.The model, view and controller are also loosely coupled, making it easy for example, to replace a view created in OpenGL with a new written in DirectX.A strict MVC will in general result in cleaner code.[Edited by - flodihn on September 3, 2009 5:01:02 AM]