Is there a use to coding a game that can run under 2 different libraries?

eugman on 2008/08/21 12:22 of Awesome Block Game 5: Quadrangles of fury.

Apparently the pypy-flex project was sorta abandoned. So, no game in flash for me.

However as a result of looking into it, I came up with a crazy idea. I could code my game in both pygame and pyglet and at the same time abstract the common code to a game class. In practice the idioms for each library is probably so different, that trying to abstract things out will be difficult.

However I can think of two possible benefit of such a strange idea. Firstly, I'd be able to try learning pyglet while having pygame to fall back on if that fails.Of course I'd probably be better off just diving in headfirst instead of bneing slowed down by trying to support two libraries. Also, in theory the game could detect which of the libraries you have and run accordingly. Of course since pyglet is includable this really shouldn't be an issue.

So, can anyone think of a reason for doing this?

(log in to comment)

Comments

pymike on 2008/08/21 13:09:

I think that having your game logic separate from the "rendering" (drawing?) code is a real good idea. I've been doing that with my PyWeek warmup :-) I say go for it! :-D

Chard on 2008/08/21 13:57:

The way we write things is so very dependent on the underlying APIs that stopping them from showing through is nigh on impossible. I also think that an attempt to abstract the common API will actually reduce to an attempt to extend pygame to an implementation of pyglet. pygame is definitely a lower level API than pyglet; its little more than a wrapper around SDL with some convenience functions. And as you so rightly point out because pyglet is pure python anyway it becomes no effort to distribute it bundled in to your game.

The only advantage (that I see) is one of agnosticism which is something to be wary of. There are cases where it is good and cases where it is bad and the former are generally the cases where it is easy and the latter the cases where it is hard. Database agnosticism for example: thanks to SQL most implementations have a very functional common core, so an abstraction of that common core can be a useful thing. In this case though I have doubts.

Still, don't let my pessimism dissuade you!