*I did not proofread this yet.
[spoiler]
For the levels, im using a component/entity system. I used to use mad inheritance when i started out learning xna (and was really new to c# and programming). It was a few years ago when i was trying to make a mario fangame. There was the classic GameObject -> Character -> NPC -> Enemy -> Goomba or GameObject -> Character -> NPC -> Enemy -> Koopa.... And those leaf classes really only changed a very few things like sprites. Something seemed veery wrong with what i was doing. I had that deep hierarchy problem that most will have as beginners and so i stopped making the game to research better ways to design a game.
My entity system work like this:
Entity:
-Data (all data derives from IData...simple interface with just a name)
-Components (all components derive from IComponent... another simple interface with just a name)
-ID (number, not string. Using strings as an identifier was a huuuge mistake. You don't even think its a big deal until you start manipulating it and performance dies)
Basic Entity components:
-IInputComponent -> handles anything that would affect the entity. Includes player input or AI.
-IPhysicsComponent -> handles the physics simulation
-ICollisionComponent -> simply handles creating and updating the collision masks of entites. doesn't do collision itself
-IRenderComponent -> draws the entity
Components have a reference to the containing entity. Datas do not. Components also don't have an data themselves, they just take it from the entity. I could have let the collisionComponent have all the collision data but that would mean components would need to rely on the actual type of class for data. So i separated them and it turned out great. I've made 2 entity systems so far and separating the data is easiest and best.
SubSystem:
-InputManager
-PhyiscsManager
-CollisionManager
-CollisionHandlingManager
-Rendering Manager
-Manager<T>
The subsystem managers simply call update or render. The generic manager simply handles all the entity component/data caches. It's how i would add/remove components/datas and ensure it happened the way it was supposed to. All the managers derived from the generic one. (Theres more to how i did mine but thats basically it). It might seem that the subsystem is redundant but it was meant so that i can easily change the update order. Right now its Input -> physics -> collision -> collisionHandler -> render. If i were to have it as Input -> collision -> ->collisionHandler -> physics -> render, then objects would be overlapping on collision.
System:
-Update
-Input.Update
-Physics.Update
-Collisions.Update
-CollisionHandlingManager.Update
-Render
-RenderManager.Render
ummm what else...I think thats all there is to what my entity system is. To some it might be confusing and unnecessary to make a system like this. But it allows much better organization and i can use this engine for the future...and am. Its easier to code and debug with too. I simply make an entity and build it with components and data. The molero enemy is simply:
*oh yeah, i use factories. Its just a place where i build objects. Hopefully, i can make it so that i can simply load the build process as content.
Entity (molero):
Components:
->input: MoleroAIBehaviorTree. -> you should seriously look into behavior trees. They're very useful. I still use a finite state machine for the player though.
->phyiscs : generic
->collision : generic
->renderer: generic (in the context of my engine)
Data:
->phyiscs : generic
->collision : generic
->renderer: generic (in the context of my engine)
->Input : Ai behavior tree's simply take in the entity as the context data.
Molero isn't much different other than his AI. The brad talkable npc:
Entity (Brad):
->input: TalkableComponent
->phyiscs : generic
->collision : generic
->renderer: generic (in the context of my engine)
Data:
->phyiscs : generic
->collision : generic
->renderer: generic (in the context of my engine)
->Input : Ai behavior tree's simply take in the entity as the context data.
->DialogData
-Dialog
Brad also isn't much different. If i were to add the talkablecomponent and dialogData to Molero, i could talk to him too . The dialogSystem actually uses the behavior tree system, its not just for AI. I use BTs mainly to handle how dialog develops. I should mention that components are best used together as long as they are compatible with eachother. You shouldn't add components that don't mix well together. That itself is a bit confusing at first, and that's where i use a FSM with the player as input. Soon i'm going to try to make my FSM sorta like how SSBB had it (from what i know about it). I used to mod on kc-mm and it seems like ssbb used FSMs. I really like the way the design was using project smash attacks (just a program) and it seems like it would work out real well.
I dunno what else to say. Thats all there is to it i think. If you have any more questions, just ask.
[/spoiler]
tl;dr.......don't worry about it.
[spoiler]
For the levels, im using a component/entity system. I used to use mad inheritance when i started out learning xna (and was really new to c# and programming). It was a few years ago when i was trying to make a mario fangame. There was the classic GameObject -> Character -> NPC -> Enemy -> Goomba or GameObject -> Character -> NPC -> Enemy -> Koopa.... And those leaf classes really only changed a very few things like sprites. Something seemed veery wrong with what i was doing. I had that deep hierarchy problem that most will have as beginners and so i stopped making the game to research better ways to design a game.
My entity system work like this:
Entity:
-Data (all data derives from IData...simple interface with just a name)
-Components (all components derive from IComponent... another simple interface with just a name)
-ID (number, not string. Using strings as an identifier was a huuuge mistake. You don't even think its a big deal until you start manipulating it and performance dies)
Basic Entity components:
-IInputComponent -> handles anything that would affect the entity. Includes player input or AI.
-IPhysicsComponent -> handles the physics simulation
-ICollisionComponent -> simply handles creating and updating the collision masks of entites. doesn't do collision itself
-IRenderComponent -> draws the entity
Components have a reference to the containing entity. Datas do not. Components also don't have an data themselves, they just take it from the entity. I could have let the collisionComponent have all the collision data but that would mean components would need to rely on the actual type of class for data. So i separated them and it turned out great. I've made 2 entity systems so far and separating the data is easiest and best.
SubSystem:
-InputManager
-PhyiscsManager
-CollisionManager
-CollisionHandlingManager
-Rendering Manager
-Manager<T>
The subsystem managers simply call update or render. The generic manager simply handles all the entity component/data caches. It's how i would add/remove components/datas and ensure it happened the way it was supposed to. All the managers derived from the generic one. (Theres more to how i did mine but thats basically it). It might seem that the subsystem is redundant but it was meant so that i can easily change the update order. Right now its Input -> physics -> collision -> collisionHandler -> render. If i were to have it as Input -> collision -> ->collisionHandler -> physics -> render, then objects would be overlapping on collision.
System:
-Update
-Input.Update
-Physics.Update
-Collisions.Update
-CollisionHandlingManager.Update
-Render
-RenderManager.Render
ummm what else...I think thats all there is to what my entity system is. To some it might be confusing and unnecessary to make a system like this. But it allows much better organization and i can use this engine for the future...and am. Its easier to code and debug with too. I simply make an entity and build it with components and data. The molero enemy is simply:
*oh yeah, i use factories. Its just a place where i build objects. Hopefully, i can make it so that i can simply load the build process as content.
Entity (molero):
Components:
->input: MoleroAIBehaviorTree. -> you should seriously look into behavior trees. They're very useful. I still use a finite state machine for the player though.
->phyiscs : generic
->collision : generic
->renderer: generic (in the context of my engine)
Data:
->phyiscs : generic
->collision : generic
->renderer: generic (in the context of my engine)
->Input : Ai behavior tree's simply take in the entity as the context data.
Molero isn't much different other than his AI. The brad talkable npc:
Entity (Brad):
->input: TalkableComponent
->phyiscs : generic
->collision : generic
->renderer: generic (in the context of my engine)
Data:
->phyiscs : generic
->collision : generic
->renderer: generic (in the context of my engine)
->Input : Ai behavior tree's simply take in the entity as the context data.
->DialogData
-Dialog
Brad also isn't much different. If i were to add the talkablecomponent and dialogData to Molero, i could talk to him too . The dialogSystem actually uses the behavior tree system, its not just for AI. I use BTs mainly to handle how dialog develops. I should mention that components are best used together as long as they are compatible with eachother. You shouldn't add components that don't mix well together. That itself is a bit confusing at first, and that's where i use a FSM with the player as input. Soon i'm going to try to make my FSM sorta like how SSBB had it (from what i know about it). I used to mod on kc-mm and it seems like ssbb used FSMs. I really like the way the design was using project smash attacks (just a program) and it seems like it would work out real well.
I dunno what else to say. Thats all there is to it i think. If you have any more questions, just ask.
[/spoiler]
tl;dr.......don't worry about it.