Hello! As I've elaborated on in the past, I'm currently at work on a commercial game as (currently) the sole developer. Without going into unnecessary detail, a fundamental design requirement of the game has always been to fully support third additions to the game via exposing APIs and having sane, versioned package management built-in to support this. Ideally, the base game itself would be distributed via the same package system.
You can look at just about any current commercial game with an active mod community and see the same classes of problems and bugs caused by not having versioned APIs and package management. It's DLL hell on an enormous scale. I've been experimenting with and considering OSGi as a fundamental part of the game engine over the past 4-5 months or so and now have the following general picture of how things will work: 1. The user buys the game (via Steam, or some other digital distribution mechanism). I think we can probably agree that this is the most challenging step :D 2. The user downloads a simple launcher that downloads the base packages for the game. This same launcher will be able to update packages at a later date, and will display optional third party packages. The launcher essentially plays the part of a (non-technical-user-friendly analogue of a) package management tool such as apt, pacman, FreeBSD's "pkg", and so on. The launcher is not necessarily an OSGi application. 3. When the user wants to play the game, they select the game and any additional third party packages desired. The launcher automatically selects any required dependencies of those third party packages too. 4. The launcher forks a new JVM which starts up a minimal Felix instance with the set of required bundles/packages obtained in step 3. This new JVM runs the game proper and lives until the user quits the game. The bundle cache for the created Felix instance is deleted. As is probably clear, I'm not depending on the dynamic aspects of OSGi bundle loading and unloading as I'm simply selecting a set of bundles once per launch and then discarding the install cache afterwards. I do, however, see the dynamic bundle loading/unloading to be highly desirable *during development*: Game engines often have long startup times due to the various heavyweight resources that have to be loaded. Eliminating a compile/run cycle that's typically measured in minutes would be hugely beneficial. My main problem: How exactly do I determine what bundles are required if none of myself, the user, or the launcher have in-depth knowledge of what each bundle is? Leaving aside minefields such as DynamicImport-Package, I assume that I could statically analyze the metadata of each bundle and build up a graph that the launcher could consult to determine required bundles. This seems like a lot of work, however, and I understand that there may not always be a definite answer to the question "what bundles are required?": Many bundles are purely "optional" service providers and yet I could imagine cases where a bundle is technically optional and yet you'd not actually be able to play the game without at least one instance of whatever service it provides - "I need at least one implementation of this API". That kind of soft-but-actually-hard requirement is, as I understand it, not something expressible via the current OSGi metadata. I would also, presumably, need to be able to at least report conflicts and other problems in a language that users can understand[0] if not (necessarily) resolve. Is there a library out there that can do this kind of work for me? Am I destined for utter failure using this approach? M [0] I'm working from the assumption that any user that's capable of understanding that they can install third party modifications via a friendly tool is also capable of understanding error messages similar to "We need version x.y of this package, but only version z.w is available", and so on.
pgpFJQ7PKU5b9.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
