   Game coding structure
  Heres a question Ive had for a loooong time now figure the following scenarioIm want to make a game that needs a level and a character, so after thinking about the requirements and the classes for the engine I always figure out that I need a base Game class (handles renders and updates) a Level class and a character class.the problem comes after I finished my level class which I create an instance of it in the game class I always find the need for my character class to access the data stored in the instance of the level classso my current way of solving this problem is: 1. try to make my level class static if possible2. all of the player functions need a level class as a parameter (where the level class now has public functions to help the character class get the data needed)option n2 is the solution I use most of the time but I find it to be not an elegant solution at all I was wondering what would be the proper way to do these kind of thingsthank you
  Sounds to me like you're trying to make the character do too much work. I can't think of much that a game entity would need access to the game-world for... Things like path-finding or collision are part of the simulation, not the character, so they probably should exist at the "game" level.   ;  so you suggesting that I should abstract the positioning data of charcters into another class and have that class request collision data from the level class?still the same situation repeats;  Well, yes, but the "game" class owns the instance of the 'level' class, no? As well as owning all entities, no? So the dependancy is appropriate.It seems that your problem is that someone convinced you, at some point -- possibly a misinformed teacher, that each object should fully contain all the smarts that it needs to "be" -- which is an incorrect and dangerous notion. Alternatively, perhaps you just have a difficult time with the Single Responsibility Principle (SRP), so you should go read an article or two on that.Looking at it from a different angle, which is always useful, what you were inclined to do originally was to bend the game to suit your conception of the game entities, when really you should be bending the conception of the entities to suit the game.Also, the fact that you're striving to make the level class static is a huge warning flag. A level has state (and I imagine a great deal), and generally speaking, you should avoid making things with state static (otherwise you have, essentially, another glorified global, like the much-maligned Singleton pattern). This is not *always* inappropriate, but *usually is*.Think for a second about path-finding or collision: What is the necessary data? Environmantal collision information (which probably comes from the level class) and entity positions (and possibly entity state) -- and for path-finding you need a start and end point. Thinking of the class hierarchy relationships between classes in your game, which class is the nearest common ancestor of all that information? That is nearly always where that functionality is *orchestrated* from, though the functionity itself may be housed in an external class (again, SRP).Something like the pathfinding algorithm itself might make a good candidate for being a static class because it doesn't really need its own state -- what little state you need to maintain to return the path is usually encapsulated in a "path context" in an algorithm like a*, and often largely implicit in the recursive nature of the algorithm.[Edited by - Ravyne on July 9, 2010 8:04:11 PM];  What about a Model View Controller architecture?You have a model with stores object containing state data.The view listens to changes in the model and creates its on object for each object in the model, it only reacts on graphics stuff like changes in position, meshes etc.Controller listens for user/network input and add/changes/remove stuff in the model.Then you can hook a logic layer between the controller and model that does logic stuff, also affecting the model.;  @flodihn: Which is all well and good, except that it doesn't address any of the problems the OP has. He hasn't asked about separating presentation from representation/behavior from input. He's asking how to structure the portion of his code that cooresponds to the Model in the MVC pattern (data and behavior).   ;  yeah looks like I would benefit from reading a couple o books before venturing any deeper into the making of my gameabout the static classes I was not actually referring to the level class was just an example , I usually use static classes when I know there is going to be only one instance of that object *although this is not true on all scenarios*thanks   