Despite my years of experience, I still occasionally get slapped in the face by things that somehow slip by under the radar until they're close enough to strike. One such thing that dominated a portion of my weekend is an unforeseen relationship between the design of the platform independence layer and the configuration of the projects in the development environment. As with many of my posts in this blog, this one is intended to document the issue so that lessons are learned rather than lost.
MHFramework 1 and 2 were designed to be used as code libraries that existed as a separate project or an external JAR file. Most of the games built with it simply absorbed the engine binaries into their distributable files. Most often, they were just packaged into the game's executable JAR file.
MHFramework 3 introduces a new challenge, however. One of the main objectives of this version is to add Android as a target platform while still maintaining compatibility with Jave SE platforms. After a few days of puzzling over this challenge, I came up with a solid design that conforms to a number of object-oriented design principles. That design is documented here.
The problem, as usual, is in the implementation details. I could create a Java SE demo program that hooked into the engine with no trouble whatsoever, but the Android programs weren't so forgiving. An Android app simply won't deploy if there is any reference whatsoever to SE-only classes.
My planned solution to this problem was to isolate all the SE stuff into a single package hierarchy that the running app would never encounter. The problem with this solution is that the platform factory interface couldn't be completely generic. (For example, mobile apps launch as an Activity while PC apps launch as a JFrame.) There is no way to have a single branching point that accommodates both platforms because it creates problematic (and unnecessary) dependencies.
The solution I am attempting now, which seems to work so far, is to break the engine up into multiple projects. The main engine core is now an Android-compatible library. This main project contains the cross-platform heart of the engine along with the Android platform layer. Java SE support has now been moved into a separate project, so now the main engine core is completely free of Java SE elements. With just a few more alterations, I can completely remove all Android references from the execution path for PC games, and vice versa.
So, while the class diagrams are only slightly affected, the configuration management has changed dramatically. Updated documentation to come.
Important lesson learned!
MHFramework Developer's Blog: Peeking behind the scenes and under the hood of the MHFramework game engine.
