I had a "Games" directory underneath the directory with my engine jar file. Into that Games directory I would place several jar files each one with a different game. The engine would then look for all files with the file name *.jar, load them as a ZipFile object. Once I have that object I could look at the Manifest file for each jar. In that manifest file I added lines for "Loader Name", "Loader Image Path", and "Game Config Class Name".
The Loader Name is what displays in the game selection panel. The loader image is the image which shows below the game's name. The game config class name is the file in the jar which extends my GameConfig class. That's my entry point into the game via a generic class which the engine understands. When the user selects the game I load that jar file into the classloader and then build (via reflection and introspection) an instance of that game's class which extended GameConfig.
Here's a test where I had one legitimate jarfile for PlanetBall and 3 fake jar files with nothing more than the display data in the manifest and the loader image. This was just a test of the technology to see if I could do it.
So that's a cool idea and it looks great. I'm building a generic game engine which can run any number of games all of which reuse the generic code. But how marketable is that? Although it's a cool technical idea, I know from personal experience at work how often architects will design overly complex systems which leave open the possibility of doing anything they may want to do in the future while sacrificing the ability to easily do the very thing you set out to do in the first place.
Am I really going to ask a potential customer to download the engine code separately from the game code? Wouldn't most customers simply want to play the specific game they asked for?
It was a cool idea and an interesting technical problem. But it's not a great idea from a customer experience point of view. I went ahead and simply added an entry point class with a main method which created the GameConfig class manually and started the game. Cleaner, easier, and all the code can stay in one jar file.
HOWEVER: This wasn't a complete waste of time. In order to make my basic game function I had to completely seperate the engine code from the game specific code. That refactoring cleaned up my code quite a bit so this little programming "side quest" actually did spawn some good ideas.
Once again. I've benefited from making a prototype. If it doesn't work then throw it away and learn from it.