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?


[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.

Attachment: pgpFJQ7PKU5b9.pgp
Description: OpenPGP digital signature

OSGi Developer Mail List

Reply via email to