Running several games based on the same code

Game Play & Game Design
#1

This is more of a code design than a game design question, but I didn’t know where else to post it. Please feel free to move it somewhere if you see the need.

I posted a question in the State of Fortune thread, but a wise man pointed out that people don’t look at the thread for generic questions, and therefore this thread is created.

What is the best way forward (from a time/code point of view as well as maintainability) when one has two versions of the same game running, where a lot of the code is shared, but many functions are different?

Should one:
Make a copy of the current projects (client and server) and build on top of that?

  • Positive: Easy to separate the projects, the jar for the sandbox will download quicker as it doesn’t contain the game content
  • Negative: If one fixes something generic one will need to change both versions. Big refactorings needs to be done to both versions separately. Will need a launcher client where you can choose which version to start up

Extend the current classes where necessary and make a game version of them, only overwriting where necessary?

  • Positive: Cleaner code
  • Negative: I don’t know if my programming skills are good enough to keep it organized :slight_smile:

Split the game code completely away from the engine code and let the game know where it can inject code?

  • Positive: Cleanest code
  • Negative: I really don’t know if my programming skills are good enough to keep it organized :slight_smile: A lot of work to keep the game code separate

Add cases to the code based upon which game version one is playing?

  • Positive: Quick win
  • Negative: Messy code

Something obvious that I didn’t think of? :slight_smile:

Mike

#2

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 :slight_smile:

#3

Create 3 projects: Project A, Project B, and Commons.

Put all the common stuff in commons, and add it to the classpath of both the projects.

You just need to make sure that commons doesn’t depend on any code in the other projects, and that commons doesn’t actually run any part of the game, which may require some refactoring.

You don’t neccessarily have to extend, but in some cases it may be a good idea.

#4

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 :slight_smile:
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§==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 :wink:

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

#5

I personally would only use shared/same code on methods that I know will be constant, like math. Anything with different methods like that I would code specifically for that project.

#6

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.

#7

Okay, that makes sense. Unless someone else has an idea there doesn’t seem to be a correct answer so I think I’ll play around a bit with the different options and try to come up with what fits me the best :slight_smile:

Mike