We've got 4 games based off of the same framework. It's a pain maintaining it as a tweak for one game means having to be extra careful not to break the other 3, or more usually, having to do something to all 4 games. It sounds like a drag but it's not nearly as much of a drag as fixing a bug in one version of the framework and forgetting to do it in the other 3, and it subsequently surfacing again months later...

Cas

Right, creating separate projects and adding the common one in the classpath sounds good (and is probably what Cas meant too, but with a twice of experience, which is very nice )

So, to put it in a simple example that I can comprehend with my limited OO knowledge
Say that I have a project "Common" with a method called "build" and now I want game A (in project "A") to have a couple of extra checks (not only can you not build where there is already a block, but you can only build on your own land). I would then extend the Block class in project Common and overwrite the method "build" and add another check (if (getOwner(p)==you) before calling the build method in the superclass which does the original tests. I'd then overwrite all of the block classes (each block type is one class) and make them extend the new version instead of the copied version, and overwrite the method that add blocks, so it adds the new block types instead of the original ones... starting to sound messy

Does that sound about right? It sounds like a lot of maintenance, but I think that it will make it flexible enough and make fixing bugs in the common project automatically fix them in both versions.

Mike

The cleanest approach would be based on 3 layers:
1. foundation - independent of concrete games as well as of game types (like the fashionable block-builder here)
2. game type or domain layer - anything related to the world of blocks
3. the games

Be sure to set up seperate projects to avoid unwanted dependencies lingering in your code base.
Class extension and overriding methods is the obvious way, though not the most flexible. Instead, get familiar with object composition and interfaces.