Architectural Patterns for a Game

So I've got a solution that contains a few big projects, which I'm trying to break down into smaller projects with more isolated responsibilities. This is a game, but I'm mainly a LOB developer and I think the principles are probably universal, and I think I could learn something here.

The dependencies in some of the objects are a bit too tightly intertwined, and I'm hoping for some help on how to untangle them. Or maybe some sort of pattern or abstraction that might make them more manageable.

Ares.Core.World has classes in it like Creatures, Items, etc. All of them inherit from Entity, which is aware of what cell on the map it开发者_运维百科 exist at. It accomplishes this by holding a reference to a Ares.Core.UI.MapControls.MapCell... And you can see that the wires are already getting crossed.

Ares.Core.UI.MapControls contains Map and MapCell, each of which contain Lists of creatures and items that they contain. MapCell also inherits from Ares.Core.World.Entity since that solved a few early problems very elegantly -- for instance, all Entities have inventory.

I would like to find a way to split UI and World out into seperate projects (Ares.World and Ares.UI) since UI and the overarching world should probably be seperate concerns. But as you can see, the way it is now the two projects would need to reference each other, and circular references are not allowed.

I'm wondering if there are any architectural patterns out there that might help in this situation. Thanks!

So, your World classes - Creatures, Items, etc. - they all need something from MapCell.

Can you reasonably create an interface (or several) that represent what the World Entities need? So that the Entities only need an implementation of that interface?

This would be the first step to decoupling the two. Perhaps obviously, none of the method signatures or properties of this interface can include classes from the UI project. It should be defined with standard types or custom types in a library both World and UI reference (e.g., Ares.Core).

Then, in the UI project define implementations of the interface(s) that encapsulate a MapCell and provide what is needed to the World Entities.

Use your IoC of choice to provide the implementation where it is needed, depending on how you get the MapCell, you may need to also layer on a Factory.

Without more details of your particular needs it's hard to be specific, but I think this approach in general should be workable.

There's nothing wrong with having classes in different namespaces interacting at a fine grained level. Separation of concerns can be done at the accessor protection level (public, protected, private, etc). You can break down your project into subprojects either logically or structurally, applying whatever extra organizational constraints you think are relevant.

Some strategies might be:

• Structurally separating logic, where each silo happens to reside in their own established namespaces, and interacting only through high level interfaces.
• Logical separation, where an assembly (or set of asms) become a logical project that may span multiple namespaces. Interaction could be done through interfaces, but also through thorough consideration of member access.

To untangle them, try to see the project from different perspectives. What can look like an utter mess from one POV can actually look elegant from another POV. If you find there actually is a reasonable logic behind their class structure, perhaps all that is needed is to start separating bits and pieces into different assemblies, with only minor tweaks to namespaces. If you find it truly is chaos, well, your work is cut out for you :-D

1. Divide and Conquer design suggest that you should separate UI and core component.
2. Your Game logic should be part of core module instead of UI.
3. UI should have graphical interface and action interface or object behavior interface and implemented by core module.