Future Musings
I've apparently lived in a cave for the last few months (or in actuality, at the work place) and was almost completely oblivious to the existence of pyglet, before it was pointed out to me in IRC today. Sure, I had heard about pyglet before and had a vague idea about what it was, but I had no idea it was already this advanced and sophisticated. Alex Holkner and the other pyglet contributors have really done a terrific job.
Opioid2D development has been really slow lately. It's mostly because of my work projects, but also partly because it has started to become difficult to add new functionality to the Opioid2D core. As I've developed the framework, it has unintentionally been emphasizing very specific kind of sprite based games (which were what I was mainly using pygext for when I started porting it to C++) to the point where the code base has become rather monolithic against certain kind of fundamental changes. I ran into this when implementing the box2d integration and while I would've gotten around the problems for that particular feature, there are same kind of problems when implementing support for isometric games or even plain 2D tile maps.
The main issue is that there is too much stuff that's coded in C++, that could just as well be pure Python and the C++ components have too much hard-coded dependencies to each other. It pains me to admit this, but pygext (my previous framework) was actually a lot more flexible and malleable, all while providing a nearly identical main API. On the other hand, the performance is way better, still over 10x for a large number of sprites, even with the latest improvements to psyco and the CPython interpreter.
At this point, I see it as a very attractive option to abandon most of the C++ core of Opioid2D, and migrate the API to use pyglet. Pyglet does lot of the low level stuff like windowing, timers, events etc. a lot better and cleaner than the Opioid2D code. I would also break up the Opioid2D framework into smaller, reusable components that could be cherry-picked into pyglet projects, instead of conforming your whole program to the "Opioid2D way" of doing things. The sprite engine would be cleaned up and written as a C extension (with box2d doing collision detection and physics) that would be an independent component that could be used by any pyglet project. Lastly, there would be a backwards compatibility layer called "Opioid2D" that would use these new, small components and transparently provide the same API as the current incarnation.
I haven't decided anything yet, but the above idea is one thoughtworthy possibility for the future of Opioid2D.
Opioid2D development has been really slow lately. It's mostly because of my work projects, but also partly because it has started to become difficult to add new functionality to the Opioid2D core. As I've developed the framework, it has unintentionally been emphasizing very specific kind of sprite based games (which were what I was mainly using pygext for when I started porting it to C++) to the point where the code base has become rather monolithic against certain kind of fundamental changes. I ran into this when implementing the box2d integration and while I would've gotten around the problems for that particular feature, there are same kind of problems when implementing support for isometric games or even plain 2D tile maps.
The main issue is that there is too much stuff that's coded in C++, that could just as well be pure Python and the C++ components have too much hard-coded dependencies to each other. It pains me to admit this, but pygext (my previous framework) was actually a lot more flexible and malleable, all while providing a nearly identical main API. On the other hand, the performance is way better, still over 10x for a large number of sprites, even with the latest improvements to psyco and the CPython interpreter.
At this point, I see it as a very attractive option to abandon most of the C++ core of Opioid2D, and migrate the API to use pyglet. Pyglet does lot of the low level stuff like windowing, timers, events etc. a lot better and cleaner than the Opioid2D code. I would also break up the Opioid2D framework into smaller, reusable components that could be cherry-picked into pyglet projects, instead of conforming your whole program to the "Opioid2D way" of doing things. The sprite engine would be cleaned up and written as a C extension (with box2d doing collision detection and physics) that would be an independent component that could be used by any pyglet project. Lastly, there would be a backwards compatibility layer called "Opioid2D" that would use these new, small components and transparently provide the same API as the current incarnation.
I haven't decided anything yet, but the above idea is one thoughtworthy possibility for the future of Opioid2D.
posted by shang at 19:44
11 Comments:
I've been using Opioid as a base for my game editor framework. It has a lot of great game-making features. I can certainly understand wanting to move to a more developed low-level platform like Pyglet. If it's not too much trouble, I'd say it's certainly worth it, because Pyglet does look pretty sweet.
Personally I won't change my editor away from Opioid until you did that because of the great arcade game specific features you've created. I really appreciate your work. I have been holding out on pointing you to my editor, because it's still pretty larval... but it IS starting to get pretty awesome... I'll try to get an alpha version out in the next couple months.
hi,
I've used pygext for a while. Nice framework. Thank you!.
A few months ago, we started to develop a library on top of pyglet: cocos ( http://code.google.com/p/los-cocos/ ). We took some features from pygext and other features of our own to build this game library.
I'm happy to hear that you will develop things on top of pyglet, welcome!
Hopefully your framework as well as ours and be used together to build games.
Hi Shang,
Please consider also working with the Cocos framework developers, since their framework is awesome and uses actions based on your actions.py from Pygext. Richard Jones has joined the team recently. The framework is currently under heavy refactoring, but there's lots you can do with the released versions already.
Cheers!
Thomas Woelz
Oops seems like riq was faster than me, I was typing before I saw his post :-)
Sounds good Shang... whatever keeps you interested and inspired. The backwards-compatible layer is a good idea, too, so that way I don't have to re-code everything :). Looking forward to the box2d integration for sidescrolling purposes...
I've been looking at that Coco thing. It does seem worth checking out whether your efforts could be combined with that... especially if you don't have that much time and you're thinking of porting to Pyglet anyway.
It already has what looks to be your action code built into it. And possibly more. In the docs, I haven't found as many nifty sprite or particle effect features...
I've looked at Cocos, but I think that at this point it is easer for me to start my pyglet code mostly from scratch, especially since Cocos is still pretty young and undergoing refactoring.
However, I hope we can cross-pollinate ideas and code between cocos and my framework in the future.
This comment has been removed by the author.
Hi shang,
Sure... let's share ideas and code.
We are about to release v0.3 which has (among other features) actions in all kind of objects. eg: an sprite can execute an action (this is old news), but also layers, scenes any other object can execute the same actions.
here is a video showing actions in scenes:
http://www.youtube.com/watch?v=mrhfaoMvpps
I guess the real question is whether pyglet is as efficient as o2d? Your engine is pretty fast and is excellent for shmups and most everything other than what I'm trying to do with it (layered isometric maps). Are you positive you want to abandon what you've been working on for so long which has incidentally had great results?
Sure, there are limitations to o2d, but having to manage your own game loop can be troublesome when trying to prototype a concept on the fly. The fact that the actions and other unique functionalities are handled automatically by o2d facilitates this. Having to 'tick' or otherwise update values manually in python over large populations can lead to inefficient loops, which is why you wrote the engine in C anyway, right?
But I guess I get the point with a more modular approach, where we can use different components individually. It's a hard sell, cause your project is most versatile and pragmatic python engine I've tried. Hate to see it go.
Hey Shang
Got a couple opioid questions for ya, if you have a minute some time...
1) I'm working on a wx based editor for Opioid scenes/sprites. Unfortunately, when I get an exception in my wx thread, Opioid crashes and does a full dump and I never get the actual exception message that caused the crash. Have you run into anything like that, and/or do you have a workaround?
2) I've been trying to figure out the best way to serialize Opioid scenes and sprites. It's an interesting problem because of the fact that they're generally stored as classes, not data. Currently, I am leaning towards exporting generated python code. Alternatively, maybe a function that is called from the Scene's enter method... that function could unpickle an object that has all the info necessary for creating the scene. Do you have any thoughts? How would you envision levels being saved?
Post a Comment
<< Home