Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

How Generic is "Generic"?

Sign in to follow this  


I wanted to make my game code seperate from the generic engine code. The first Idea I had was to have a completely generic engine system which I could use to load any one of a set of games which I would write later. The engine could access a number of jar files, each of which had game code in it, and the user could select from any of the games which ran under this engine.

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.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!