I recently posted about my new project, Simplicity. On the project home page
I spout off my views regarding how I feel about generic game engines, and how I want to keep Simplicity tailored to a limited subset of games. I think I'm in the middle of a paradigm shift.
Having expanded the original project goal of supporting only LWJGL to now include support for JOGL (and thereby JOAL and JInput), I sat down to knock up some interfaces. My initial plan was to keep scene management and the rest as a core part of the engine, without support for pluggability. The biggest reason for this is that I have a non-traditional method of scene management on paper, tailored for the specific types of games I had in mind. I couldn't imagine how I could develop interfaces generic enough to support a different implementation.
Eventually, the JOGL and LWJGL support became pluggable, rather than core components of the engine. This was to keep AWT/Swing dependencies out of the core for those who don't want or need it. After some long thought and a couple of waste baskets full of wadded up designs, I'm now thinking that making the entire engine pluggable may not be such a bad idea.
My initial reasonings against generic engines still hold - I still don't want bloated code or performance hits just because the engine supports multiple game types. However, a completely pluggable system seems to give the best of both worlds. I believe it's possible to keep the core interfaces simple enough (read small) such that no excessive bloat occurs when implementing them. Meanwhile, it will still be possible to tailor each plugin to the specific type of game required. So in this sense, the engine becomes an engine framework (dare I say container?) rather than an engine.
Certain issues arise, such as what to do about functionality required by an implementation that is not supported by the interfaces? An example of this would be the need to fetch a GLCanvas/GLJPanel Component representation when building an editor. The answer is, deal with it specifically in the app. My initial idea for the JOGL render system plugin includes a method to do just that, even though it is not present in the interface. I figure if you need it, then you won't be using LWJGL anyway (at least until SWT support gets into LWJGL core).
On the one hand, implementing special methods beyond those provided by the interfaces would be considered breaking pluggability (or breaking the contract). But on the other, the goal is not so much to allow drop in replacement for all components as it is to allow the developer an easy means of customizing the engine to fit the needs of a particular game. As long as the specified interfaces are implemented, then the default plugins will be able to interact with any replacement.
Anyway, the more I think about it the better it sounds. Restricting the engine to certain types of games limits the usefulness to the community. Being able to expand on this while still alowing a mechanism for game-specific optimizatrions can't be a bad thing. The hard part is coming up with some of the interfaces. The audio/renderer/input/resource stuff is easy. Scenes and entities are giving me fits. And regardless, there will be some things that will be forced on the user. For example, if I make all entities Controllable, so that they can be controlled by input, ai, or network messages without difference, then the interfaces will need to account for that .
Anyway, I've been at this for hours and I'm most likely rambling. But I'm looking for opinions of the usefulness of such a design.