Cohesion and coupling

Started by
2 comments, last by SeanMiddleditch 9 years, 8 months ago
In my project, I code that in a way that high coupling and low cohesion is not an option. For example, the Create Object method has to know about the Object map and geometry in which they are later used for navigation mesh building process. It seems unavoidable. All the stuff in Create are unrelated. Is it a bad practice? Or it is just unavoidable like I said.
bool Create(std::string name, LPDIRECT3DDEVICE9 pDevice, SkinnedMesh *pMesh, SkinnedMesh* geom, ObjectMap obj, float fAnimSpeed = 1.0f);
Thanks Jack
Advertisement
It looks pretty bad. Perhaps you can post the definition of that function, so we can see what you are doing with each argument.

Can navigation mesh building / updating be de-coupled from object creation?

This is a typical problem that is solved fairly well with component-based design. There's no reason for graphics to know about meshes used for collision or AI, or vice versa for AI to need to know about graphics or animation data. Create each of these separately and then make your game object contain both components.

With the right content loading system and data-driven design approaches you can (almost always) completely decouple your systems' code and interfaces.

The only systems that really need to know about all the different systems would be procedural generation modules. If you think of your game as a series of layers, however, this coupling isn't a problem. Your graphics, AI, and collision systems are lower-level services than game-specific procedural generation systems, so letting procedural generation depend on those other systems is fine. Just do your best to minimize the public surface area of each system so that higher-level systems need to know as few implementation details of the lower-level systems as possible.

Sean Middleditch – Game Systems Engineer – Join my team!

This topic is closed to new replies.

Advertisement