Opioid Game Dev

Opioid2D Pages Down

2008-07-14T12:24:00.002+03:00

The Opioid2D web page is currently unreachable for some reason. I'm waiting to hear back from my server provider, but meanwhile, the pages are temporarily mirrored here.

June Status Update

2008-06-08T15:33:00.002+03:00

Apologies for the long hiatus. I've just recently finished a really hectic project at work, and I'm now slowly getting back to Opioid2D. The first order of business is to finish the Box2D integration which I already got decently far. While I was "away", Box2D released the official 2.0.0 and 2.0.1 versions, so it was actually pretty convenient to delay the integration this far. There's also lots of very promising stuff coming, based on Box2D's HEAD revision (like automatic polygon decomposition), which will be very useful in O2D.

My summer vacation begins in the middle of July, and that's when I'll try to complete some bigger new features. On August, I'm moving about 150km closer to my job, so that'll cut down my commuting times significantly (translating into more free time to use on personal projects).

Future Musings

2008-04-17T19:44:00.003+03:00

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.

Bitograph 0.8 Release

2008-04-05T13:24:00.002+03:00

I finished all the essential functionality, so I'm releasing the Bitograph library for others to try out. You can download the library from here and read the user guide online here.

Bitograph

2008-03-31T02:20:00.002+03:00

I had to put the box2d integration on hold for a while, because of more urgent projects. However, this weekend I had a sudden inspiration to improve and expand the bitmap font support a bit. The current bitmap-font feature in Opioid2D (and pygext) is pretty primitive and doesn't let you fine tune things like kerning or have smart support for accented characters. The new one is the Ultimate Bitmap Font Engine(tm), with every possible fine tuning parameter you can think of, in order to have professional looking typography.

Creating a new bitmap font begins with a template file. This is automatically generated by Bitograph (the new library) according to the template parameters defined in the font project file. The generated template with the linked project file looks like this:

You can then load up the template file to your favorite graphics software and decorate the font as you see fit. The library also contains some stock effects (like Outline and DropShadow in the above example) that can be used by us non-artist programmers.

The linked project file might seem a bit daunting with the sheer amount of metadata, but choosing proper values is done very iteratively. You begin with nothing but the basic values (like line_height etc.) and then just add small adjustments according to how the font looks. This is made easier by the included Font Viewer:

You can tweak the kerning etc. values in the property file, and instantly see the changes in the Font Viewer (no restart needed).

The rendering code supports automatic text wrapping and will eventually support various text alignment and justification options. You can also compile long strings into bytecode-objects for the rendering engine, which makes line-wrapping and rendering a lot faster.

Expect to see the first release version of Bitograph soon.

This is Why I Like Bazaar

2008-02-20T22:16:00.002+02:00

Bazaar has been a great productivity booster for me lately. It enables me to work on several concurrent major refactoring tasks, and painlessly merge between them. You can imagine what it would be like to do several merges daily with SVN or (*shudder*) CVS.

The biggest new thing I'm currently working on is the Box2D integration. I'd estimate I'm about 40% done now, and the biggest obstacle has been (once again) having enough time to code, but I hope to have the main functionality + a simple demo working next weekend or next week.

The Bazaar Is Open

2008-02-16T13:37:00.002+02:00

I tested Bazaar for real development for a while, and it is really great. So, from now on all Opioid2D development will use Bazaar and the old Subversion repository is no longer maintained. The are two main branches in the public Bazaar repository

http://opioid-interactive.com/opioid2d/bzr/trunk

and

http://opioid-interactive.com/opioid2d/bzr/experimental

The trunk will mainly get bug fixes for now, and all new features are developed and published in the experimental branch. Once the features mature and undergo enough testing, they are merged into the trunk and a new alpha is released. I'm not going to rush the new releases until the new features are properly finished and the API stabilized, so I encourage you to get the experimental branch every once in a while if you need the latest and greatest features. Now that Opioid2D fully supports mingw, it should be pretty easy for anyone to compile their own extension. However, I can provide binary snapshots of the experimental branch if needed, so let me know if that is the case.

In order to download the trunk, for example, all you need to do is

bzr get http://opioid-interactive.com/opioid2d/bzr/trunk opioid2d

However, if you are going to use several different branches, I recommend you do the following:

bzr init-repo opioid2d
cd opioid2d
bzr get http://opioid-interactive.com/opioid2d/bzr/trunk
bzr get http://opioid-interactive.com/opioid2d/bzr/experimental

Creating your own local repository lets Bazaar share metadata between the different branches, so it's a bit more efficient.

Now if you want to make your own changes or fixes to the Opioid2D source, you should create your own branch. E.g.

cd opioid2d
bzr branch trunk my-bug-fix

The my-bug-fix is the name of the branch, which should be as informative as possible. I usually name bug fix branches beginning with fix-, so e.g. fix-sprite-edge-bug. At this point, you have your own complete copy of the source tree in the my-bug-fix folder, and you can freely make any changes you need. After you are done (and periodically while you are working), you run bzr commit to record your change history into your local branch. Finally, you run

bzr send -o my-bug-fix.patch

Which creates a patch file you can send to me to be included in the main trunk. Alternatively, you can publish your branch e.g. via HTTP and just send me the URL.

Opioid2D Version Control

2008-02-06T12:36:00.000+02:00

I've been reading a lot about distributed version control systems lately, and have come to the conclusion that the development of Opioid2D would benefit from lot of the features available in them. I code on several PCs and e.g. my laptop is often cut off from the net when I travel. Distributed version control like Bazaar would make it easy to retain version history while offline and then merge the revisions to the online repository when regaining net connectivity. I'm also going to be doing some major refactoring of the C++ internals, and I think the distributed model of "branch per feature/bugfix" would make things a lot easier.

The one thing that worries me is that Subversion is something that is familiar to almost all developers, so it is easy for anyone interested in O2D to grab the SVN trunk. Distributed version control systems, however, don't seem to be as widely used or even known. I looked at several different solutions, and Bazaar is currently my top choice because it seemed to have the lowest barrier to entry with decent documentation and support for Linux, Windows and MacOSX. Mercurial was a close contender, especially since TortoiseHg seems more mature than TortoiseBzr at this point, but after giving them both a try, I slightly prefer using Bazaar (and its quick-start guide was a lot more comprehensive).

Another good thing about Bazaar compared to SVN is that I could publish the repository via a standard web hosting service and thus put it on the same server that contains the Opioid2D web pages. I'm currently renting a virtual server to run svnd in, and it hasn't been very reliable (nor cheap enough to justify the mediocre up-times).

January Update

2008-01-23T20:15:00.000+02:00

Unfortunately I don't have much to tell regarding Opioid2D, even though it's been several months again. There have been small patches and adjustments since the last release, but most of my coding time has been spent on the game project I'm doing at work. The game is nearing its release deadline and the crunch is on, so I really haven't had that much energy for personal projects.

There are a couple of Opioi2D related things I've been thinking about, but haven't yet started implementing. The biggest is the rethinking of the node hierarchy system and sprite drawing order. The current design just isn't flexible enough in all use cases, and also isn't as efficient as it could be. Another important thing is the drawing system (lines, triangles, rects etc.) and how to tie that neatly into the action system and rest of Opioid2D. I also happened to come upon a really promising looking 2D physics library called Box2D, which would be a perfect fit for Opioi2D. I've browsed through the API, and I don't think it would be all that difficult to integrate it, giving Opioid2D true physics support.

When thinking about how to integrate drawing primitive shapes with the action system, I've built a prototype for a more generalized action API. This is something that will be released both as a part of Opioid2D and as a standalone action library that can be used with any Python program (pygame games etc.). The API currently looks like this:

@action
def example():
   size = interval(10, 15, time=0.5, mode=pingpong)
   for x,y in interval(start=(50,0), end=(70,100), time=2):
       draw.color = (255,0,0)
       draw.circle(x, y, size.value)
       yield
   for alpha in interval(255, 0, time=0.5):
       draw.color = (255,0,0,alpha)
       draw.circle(70, 100, size.value)
       yield

How does that look? My goal was to design the API so that it would be somewhat clear what the code does, even for someone not familiar with the API beforehand. interval objects give a value based on the current time and their initial parameters, so for example interval(0, 10, time=10) will increase its value by 1 per second until it reaches 10. yield is used to suspend the action until the next frame update.

October Update

2007-10-14T13:51:00.000+03:00

My laptop (which was my primary development PC) had a hardware failure last month, so it has taken some time to order parts for a new machine and setting up the development environment for Opioid2D. Since setting up the free MS tools for Python extension compiling is somewhat of a hassle, I decided to try open source tools this time around.

The Opioid2D alpha 6 patch 3 released today has been modified so that it compiles correctly for Python 2.5 using MinGW32. Also, since the official release of Python 2.5 is now over a year old, I've decided to use that as my main platform from now on. If you need Python 2.4 support in Opioid2D, please let me know, as all future testing and releases will otherwise be for 2.5 only.

Other than that, I haven't had much time to develop new features and such, as I'm currently commuting about three hours a day to my new job. However, this is only a temporary phase and later on I will telecommute most days from home and that should free up some more time to work on my personal projects.

A short status report

2007-08-26T13:38:00.000+03:00

Just in case you are wondering where all the Opi2D updates are, I'm currently in the middle of changing jobs, which has occupied my attention a bit. Expect more updates after I've settled down in the new place.

Opioid2D alpha 6 patch 2

2007-08-11T22:10:00.000+03:00

Since alpha 7 still needs a lot of work, I'm releasing another crash-bug-fix for alpha 6. Get it from the usual place.

About the Name

2007-07-25T14:42:00.000+03:00

I've had a couple of inquiries about the "opioid" in the framework name, so I just wanted to make it clear that it is not meant to be a pro-drugs statement or anything like that. It's a bit of an unfortunate choice from a marketing perspective, but the link to gaming in this case is that endorphin is a natural opioid (and Endorphin2D would've been a clumsy name for a framework).

(EDIT: actually, the wikipedia link doesn't currently explain the connection all that well, since it doesn't mention the supposed connection between endorphins and feelings of pleasure and euphoria.)

Opioid2D alpha 6 patch 1

2007-07-23T03:00:00.000+03:00

There were a couple of bugs in the alpha 6 release (thanks to everyone who reported them!), so I've released a new patched version. You can get it from the usual download page.

Opioid2D alpha 6 release

2007-07-16T14:41:00.000+03:00

I've released the 6th alpha of Opioid2D. It's available from the Opioid2D download page and the list of changes can be viewed here.

Unfortunately I didn't have enough time for the snippets library yet, so that has to wait for alpha 7.

I'm rather happy with Opioid2D feature-wise so far, so the next couple of weeks will be spent on cleaning up and optimizing the internals before another feature push.

SVN and TRAC back online

2007-07-04T22:20:00.001+03:00

The server move is finally finished and everything seems to work fine so far, so the TRAC can once again be found at http://trac.opioid-interactive.com/opi2d and SVN checkouts are available from svn://svn.opioid-interative.com/shang/opi2d/trunk

I've finished committing all code changes made during the downtime to SVN, and I'll go through the wiki and update it accordingly in the following few days. After I get everything cleaned up, O2D alpha 6 will be right around the corner.

Opioid2D Code Snippets Library

2007-07-01T19:58:00.001+03:00

Another thing I'm starting from alpha 6 onwards, is to compile a collection of useful example snippets, that show the idiomatic way to do certain things in Opioid2D. They will be smaller than actual example games, but a bit larger and better written than the short test scripts in the distribution so far: things like HealthMeter, ParallaxScrolling, ObjectPicking etc. The idea is that you can study those snippets and paste them into your own code when learning O2D. They should give a better starting point until I can finalize all documentation.

So, if you have any suggestions for useful snippets you'd like to see, please list them in comments for this entry.

Upcoming API Changes

2007-07-01T19:46:00.000+03:00

I've started cleaning up the APIs a bit, revising stuff that doesn't feel quite right in actual use. The biggest change is in method naming conventions. For some reason, it originally felt like a good idea to capitalize class methods and methods on singleton objects differently (using CapWords), but this hasn't really felt Pythonic when using the framework, so I'm going to change everything to lowercase_words now that I still can. The old naming convention will still work in alpha 6, but it prints out a deprecation warning as a reminder.

Other changes that I'm currently evaluating include moving sprite rect attributes to the sprite object itself, so that you use e.g. sprite.left instead of sprite.rect.left and so on. The particle emitter API is another part that feels somehow off, so expect at least small changes there.

I'm trying to get all backward incompatible changes out of the way by alpha 7, so that APIs in alpha 8 and onwards should stay stable and compatible.

Subversion Maintenance

2007-06-20T23:27:00.001+03:00

The server that hosts all my subversion repositories and TRAC pages is currently down for maintenance. The physical server that hosts my virtual server broke down (which is probably the cause for my TRAC troubles earlier), and my server is currently being moved to another physical machine.

Hopefully everything will be back up in a couple of days.

Opioid2D Runtime Environment

2007-06-20T23:03:00.000+03:00

Games made in Python are somewhat cumbersome to distribute. In order to facilitate distributing new versions of games to testers and friends, I've designed an utility similar to JRE, that allows one to run O2D games on Windows platforms without having Python installed. It's still a work in progress, but I've compiled a prototype you can download to see how the whole thing might work.

O2D RE prototype (4,345 KB)

Example game(62.5KB)

After you install the Runtime Environment, you can launch the example game by simply double clicking the invaders.o2d file. As you can see, the game itself is a relatively small file, which is much more convenient than always having to distribute several megabytes worth of dependencies.

New Opioid2D Pages

2007-05-17T13:05:00.000+03:00

I've recovered what I could from the TRAC database, and put temporary pages for the project at http://opioid-interactive.com/opioid2d/. There isn't much besides the basic documentation so far, but I'll work on it more as soon as I have some free time again.

All Project TRACs Down

2007-04-14T15:31:00.000+03:00

I started having trouble with my TRAC installation a couple of days ago, as the TRAC server seemed to hang and eventually get killed by the operating system. I tried to remedy this by upgrading my TRAC and Subversion packages, as they were rather old, but that ended up breaking everything and now the whole TRAC just segfaults for all page requests. After several hours of frustrating trial and error, I've narrowed the problem down to libsqlite3. I've tried different versions. I've tried compiling from source and using stable .debs from apt-get. Nothing helps.

I've pretty much exhausted all my Linux knowledge at this point, so the TRAC probably won't return any time soon. I'll need to figure out a good alternative way to provide the library documentation in the future.

Opioid2D alpha 5 released

2007-03-13T23:42:00.000+02:00

I've made a couple of bigger API changes and added some very useful new features lately, so I'm making a new release now even though alpha 4 just came out. The list of changes in this version can be found in the ChangeLog. Downloads below:

Windows installer for Python 2.4 (232KB)
Windows installer for Python 2.5 (232KB)
Source Tarball (852KB)

The documentation is still a bit spotty and partly out of date, but I'm working on it next. I've also added a new example game to the source distribution which should demonstrate pretty well how to do all the basic stuff.

Opioid2D alpha 4

2007-03-07T17:50:00.000+02:00

The alpha 3 release was plagued by a couple of nasty bugs, so I'm releasing alpha 4 even though it doesn't have any major new features. There are a few backwards incompatible API changes, some performance boosts (especially for particles) and a lot of bug fixes. You can read the full list of changes in the ChangeLog and download the source and binary packages from below.

Windows installer for Python 2.4 (203KB)
Windows installer for Python 2.5 (203KB)
Source Tarball (553KB)

Opioid2D alpha 3

2007-02-18T14:06:00.000+02:00

I've just uploaded the alpha 3 release of the Opioid2D framework. You can see the list of changes here. And download the release from the below links:

Windows installer for Python 2.4 (187KB)
Windows installer for Python 2.5 (187KB)
Source Tarball (545KB)

The usual disclaimer about the framework's alpha status still applies. There are some big internal changes underway. I would especially appreciate feedback from Linux and MacOSX users, as I haven't been able to test the latest release under those platforms yet.

Opioid2D New URL

2007-02-14T12:16:00.000+02:00

I'm currently in the process of creating all new pages for my projects and migrating to a new server and domain. The new home of the Opioid2D project TRAC will be at http://trac.opioid-interactive.com/opi2d/, and the Subversion repository can be found at svn://svn.opioid-interactive.com/shang/opi2d/trunk.

A new release is also much overdue, so I'm trying to get the official alpha3 out within a week.

Alternatives to the Demo/Full Game Model

2007-02-02T14:49:00.000+02:00

A common way to sell shareware games is to offer a demo version that is feature-limited and often time-limited as well. The most extreme cases let you play the game for 30 minutes before locking the demo and preventing further evaluation. As a consumer, these time limitations really bug me, and it often feels like I don't have enough time to make an informed decision about the longevity of the game. Now that I'm going to be selling games myself, I'll have to decide a strategy that is lenient enough that my consumer self would find it appealing, but at the same time aggressive enough to create sales. This leaves time-limitations right out. My personal distaste for them is too great to include those in my own games even if it'd guarantee more sales (and I'm not so certain that it would).

What I'd really like to do is to offer a compelling and functional game for free. Something that doesn't have any obvious or crippling limitations and that can be enjoyed as a complete (albeit simple) game. So instead of a trial version and full version, I'd like to think of my games having a basic version and a premium version. I.e. the basic version would be a complete game in its own right, but by paying for the premium version, you would get an extended game experience (for example, more maps, more game modes, maybe a basic game that is single player only and a premium version that has multi-player support).

I guess the risk from the business side of things would be that if the basic version is "too good", most people won't be willing to pay money for the premium, but I would like to believe that the opposite could be true. That if a gamer gets a really fun game for free, he would be more likely to spend a little cash to expand that experience.

This is certainly not a new and radical idea (for example, if I remember correctly, the original Doom used a model like this). It just seems to me that lately many small independent developers opt for the heavily restricted demo versions that, at least for me, lessen the interest for that particular game instead of making me more likely to pay.

Oops

2007-01-16T11:19:00.000+02:00

I didn't get any notification about the codereactor.net domain expiration, so all links pointing to pygext and Opioid2D stuff are currently broken. Until the situation gets resolved, you can use these temporary URLs:

pygext: http://212.94.75.178/projects/pygext/
Opioid2D: http://212.94.75.178:8000/opi2d

I'm Still Alive

2006-12-11T16:37:00.000+02:00

A lot has been happening lately, although unfortunately not so much with the O2D framework. I've been adding small features and bug fixes as time allows, but there's still a bit of tweaking I want to do before releasing the latest alpha (and the latest source is always available directly from the SVN of course).

The new big thing that has been taking my time is that I finally did something that I've been considering for a couple of years at least, and founded my own company. I'm still keeping my day job, but evenings will be dedicated to producing small shareware games. The company officially employs only me at the moment, but I'm getting help from a couple of freelancers to produce the first batch of games. I'll talk about the games a bit more after the projects are further along.

So, what does this all mean for the framework? Naturally, I'm going to use O2D for my own games, so I'll keep developing it. However, the game projects take priority, so new features will be added to the framework as dictated by the games, and I won't make any guarantees about the release schedule (again, all the changes will be available on a public SVN repository even if there isn't an official release).

A little side project: O2DMini

2006-09-20T20:43:00.000+03:00

I have been working with the Nokia 770 Linux tablet at my pay job, and it got me thinking about game development on the handhelds. Direct port of Opioid2D is out of the question, as mobile devices rarely have support for OpenGL, so I started (half jokingly at first) designing a light weight version of O2D that would drop features such as rotating and scaling and use software rendering.

The plan is to write a pure C API and implementation (no C++ and STL bloating things up) that can be wrapped to Python using ctypes. However, since the Python interpreter is a bit too resource hungry for embedded devices, the main way to utilize O2DMini would be via a custom Python-like language that is translated to C.

I.e. take this hypothetical piece of code:


action = Delay(10) + MoveDelta((100,50)) + Delete
sprite.do(action)

It would be translated to something equivivalent of:


Action* action = malloc(sizeof(Action));
Delay_Init(action, 10);
Action* action2 = malloc(sizeof(Action));
MoveDelta_Init(action2, 100, 50);
action->next = action2;
Action* action3 = malloc(sizeof(Action));
Delete_Init(action3);
action2->next = action3;
DoAction(sprite, action);

The whole thing is still mostly at the brainstorming phase (with a few hundred lines of proof-of-concept C-code), but let me know if you think such a tool would be useful. In addition to embedded use, it could target low-end PCs that lack hardware accelerated OpenGL.

The standard Opioid2D has the first priority at the moment, but once it matures, I can see myself dedicating a good amount of time to the mini-variant.

Opioid2D alpha 2 released

2006-09-16T05:01:00.000+03:00

The second alpha of Opioid2D has just been released. Downloads and detailed change log can be found from the O2D TRAC at http://trac.codereactor.net/opi2d/.

Tweaking the particle engine

2006-09-12T19:44:00.000+03:00

I've been wondering how to make good looking particle explosions for some time now. Seems that no matter what kind of image or parameters I used, the explosions always ended up looking like separate particles. Like this example image:

Today I finally figured that doing a double rendering pass on the particle layer using different glBlendFuncs, I can blend the particles together and achieve a much better result:

I'm also looking into recursive particle emitters (emit particles that emit particles that emit particles...).

Opioid2D first alpha release

2006-09-10T19:49:00.000+03:00

The development of Opioid2D has progressed to the point that I'm releasing the first public version. It's still very much an alpha, but I'm aiming for a bit more frequent release cycle from now on.

More info and downloads from

http://trac.codereactor.net/opi2d

I was thinking about the license for a long time, but I finally settled on LGPL. I was going have a small licensing fee at first for commercial games once O2D reached the necessary maturity (mainly to cover development costs like domain and server rent), but I figured voluntary donations are the better way to go.

Pre-Alpha Status Report

2006-07-03T12:13:00.000+03:00

The pre-alpha of O2D has progressed nicely. I just started my vacation, and will try to get the public alpha out as soon as possible. It's now mostly a matter of getting basic documentation and basic examples together.

Hilights from the pre-alpha:

Builds and runs on Windows, Linux and MacOSX

The collision detection system is still under development. This is the most significant thing that's currently holding the public release back.

Action system is pretty much finished. There are still a bunch of actions waiting to be converted from pygext to O2D, but these will probably be added after the first alpha.

Camera system is implemented and there's built-in support for parallax scrolling etc. The only major feature missing is object picking.

Basic particle systems are implemented, but only "point emitter" is currently available. More emitters will be added in later alpha releases. Also, the particles emitters are currently implemented in Python, but they will be ultimately be translated to C++ (moving and rendering the particles is already C++).

Lighting system is pretty much done. There are a couple of additional features that I have in mind, but they can wait until the beta releases.

Opioid2D Pre-Alpha Program

2006-06-09T16:46:00.000+03:00

First, I must apologize that the release of the new Opioid2D framework has been postponed for so long. I haven't had much time or energy to work on my projects for the last two months, but things are getting better and my summer vacation is getting closer, so I'm trying to kick O2D development up a gear.

In its current state, Opioid2D is not yet usable for real game development, and I've decided a long time ago, that I won't make a public release until you can run a fully functional example game using it. However, I've received many inquiries over the last couple of months, so I'm going to launch a semi-closed, pre-alpha program to get some feedback and let those who don't mind the unfinished state to get a first peek.

So, if you are interested and understand that the framework still requires a lot of work, send me an email (shang@iki.fi) with the following info:

What platform are you developing on

What platform are you developing for

What are you planning on using O2D for (commercial/non-commerical, games/utilities?)

How familiar are you with pygext

You need to have a working environment for building C++ extension for Python (see this page for info on how to setup a Windows environment using freely available tools).

All participants will get access to the Opioid2D development wiki and the Subversion source repository.

The first public release is currently planned for July 2006.

Another Slow Month

2006-05-04T14:08:00.000+03:00

...well, slow for O2D development. I have been very busy at work (the paying kind), so progress has been rather slow after the last update. I'm currently working on the first example game, the particle system and the camera system.

Pygext has an undocumented early prototype of the camera system, but for Opioid2D, it will be properly integrated from the get go. Instead of having screen coordinates, every Sprite will have "world coordinates" instead. The Camera object can be moved around, rotated and zoomed, as well as mounted into objects to e.g. create a game where the display automatically follows the player sprite. You can choose on a per layer basis, how the camera affects the layer to make static UI layers or layers that apply a lesser transformation (for parallax scrolling).

SHMUP-DEV just launched a new competition, and I'd really like to participate, but I'm not sure how I'm going to find time for it. May will be even busier than April work-wise.

I'm so easily distracted (new benchmarks)

2006-04-13T02:08:00.000+03:00

I was supposed to finish the collision and action systems tonight... And what do I do? I just had to implement a feature that wasn't even in my original list of features for the framework: dynamic lighting. So, now you'll be able to create light sources, and they can move and smoothly alter their color/brightness (via Actions of course).

Here are some benchmarks with moving Sprites (using simple newtonian physics) and dynamic light sources.


sprites:      1000     3000     10000
------------------------------------
10 lights    85fps    85fps    ~35fps 
30 lights    85fps    ~59fps   ~18fps
100 lights   ~64fps   ~21fps   ~6fps

As you can see, there's still some room for optimization, but implementing different levels of lighting detail should help a bit in situations typical to games. Currently, each light source affects every corner of every sprite, so that's four calculations for every sprite for every light source. Small sprites don't really need this, so they can be optimized by calculating a single light value for the center of the sprite and using it for the whole image.

On the other hand, having 100+ dynamic light sources might not be the most typical scenario...

PyWeek Finished

2006-04-02T11:45:00.000+03:00

I finally got a good night's sleep last night, but I'm still exhausted. The whole Saturday was nothing but coding and play testing. There is still a lot of room for improvement and we didn't have time to add sounds and music this time, but I'm overally quite happy with what we came up with in a week, considering we only had time to work on the entry during evenings.

If you want to try our game (titled "Steam Run"), you can download the Windows installer here, or the Python source code here (requires Python 2.4, Pygame and PyOpenGL).

It runs on steam!

2006-03-30T00:07:00.000+03:00

We've been quite busy with PyWeek. This time, the voted theme is "It runs on steam!", so we are doing a side scroller with a steam powered flying machine. The goal is to navigate the rickety air craft from one side of the level to the other, while avoiding a multitude of obstacles and enemies. It's past the halfway point of the competition already, and there' still much to be done. Hopefully I'll have enough free time to code everything in.

Week of Unproductiveness

2006-03-26T14:46:00.000+03:00

I've had a nasty flu for the last week or so, and unfortunately I haven't gotten much done. PyWeek started last night with the theme "It run on steam!", so that'll occupy all of my time next week. Hopefully my fever goes down enough that I'll be able to concentrate on the competition.

I'm sorry for the lack of updates, I'll make a proper post after I have some more energy.

Opioid2D Status Update

2006-03-15T12:01:00.000+02:00

I've been quiet for a few days, so here's a brief feature checklist on how Opioid2D is coming together.

Rendering engine: 100% done.
Scene engine: 85% done. Still missing state transitions and a couple of callbacks, but otherwise all the important functionality from pygext has been translated.
Sprite engine: 90% done. Nothing fancy here, so it has been straightforward to re-implement. Added very basic physics on top of the pygext API (velocity, acceleration, friction).
Action system: 60% done. The base classes need some more tuning, and then I'll get to work on implementing all the different actions from pygext.
Event handling: 90% done. Needs support for multiple states.
Keyboard handling: 95% done. Needs testing and might require some small tweaks.
Mouse handling: 10% done. Barely started with this, but should be a quick job.
Collision detection: Not started yet, but I'm going to start implementing this tonight. The plan is to start with simple radius-based collision detection (as in pygext) and then expand it to (convex-) polygonal collision nodes and add optional multi-sampling for fast moving entities.
Particle engine: Not started yet, but should be very straightforward to translate from pygext's implementation.
Large sprite support: Not started yet. Sprites are currently constrained to a maximum size of 512x512 by the rendering engine.
Camera system and scrolling: Not started yet.
GUI framework: Not started yet.

I'd like to get the first release out within two weeks, but I'm afraid PyWeek will interfere with the schedule somewhat. So, a more realistic release date for the first public beta of Opioid2D might be in the middle of April.

First Benchmarks!

2006-03-11T00:37:00.000+02:00

While these are very rough and preliminary benchmarks, I'm very happy with the results so far. I'll the pain I've suffered with C++ seems to have paid off. ;) This is a simple sprite benchmark that has static sprites with no logic or movement. It's purpose is to test the raw output of the rendering pipeline. 85fps is the limit, as the renderer is synced to vertical refresh.


sprites          1000     5000    10000   15000
-----------------------------------------------
pygext           ~35fps   ~7fps   ~3fps   ~2fps
pygext + psyco   ~60fps   ~13fps  ~6fps   ~4fps
Opioid2D         85fps    85fps   ~70fps  ~45fps

EDIT: To be fair, the difference isn't all C++ vs. Python related. Opioid2D uses smarter algorithms in the rendering engine, which help a lot too.

Object Identity Crisis

2006-03-09T00:12:00.000+02:00

Opioid2D has progressed pretty nicely, and I now have working C++ code for displaying an O2D-sprite on screen via a Python API. While writing the sprite test, I came upon a very unfortunate "feature" of SWIG that I wasn't aware of before. As this was the first time I've really used SWIG, I wasn't really sure how the class wrapping mechanism works. It turns out that SWIG creates a "shadow" object in Python, which has a pointer to the live C++ object and the problem is that, as far as I know, SWIG doesn't do any tracking between the two, so once the C++ object is passed to the framework machinery, it pretty much becomes detached from its Python twin.

I have a cunning theory on how to solve this pretty transparently, but this will slow down development somewhat until I can design and implement a working solution. I guess I could go read on the Python extension API and write my own wrappers in C, but that seems a bit daunting at this point, compared to the relative ease that SWIG has provided. We'll see...

Goals of the Pygext Rewrite

2006-03-07T14:05:00.000+02:00

The rewrite of pygext will change enough things, that I thought renaming might be appropriate to lessen confusion (especially since the original Python-pygext will stay around and updated for a good while still). The new working title for the framework is Opioid2D (or the Opioid2D Game Engine), abbreviated O2D.

Speed. As I wrote in my last post, performance is one of the most essential things in a game framework. The general guideline in O2D is that all the code that gets called at every screen update should be on the C++ side. Using C++ also allows the rendering pipeline to contain more logic without adding overhead, so O2D will have better texture packing, and sprites will be rendered in batches using OpenGL arrays.
Maintainability. On the other hand, everything that is NOT speed critical should be written in Python instead of C++, for easier debugging, fixing and extending. The O2D implementation will have three tiers: The core written in C++, a SWIG wrapper exposing the core API to Python and a very-high-level Python API that calls the wrapper.
Minimalistic High Level API. The pygext API was huge and cluttered with things you rarely need. The O2D high level API will concentrate on the bare essentials, which leads to the next point.
Better Documentation. When I started developing pygext, it was supposed to be for my own use only. While it's slowly starting to have an adequate level of documents, the messy and large API makes writing documentation a pain. The O2D API is being documented constantly as I write it, and being much leaner, having good documentation coverage takes a lot less work.
Smaller Footprint. O2D aims to have all calls to SDL and OpenGL inside the C++ core, so I can drop all dependencies to Pygame, PyOpenGL and Numeric. This is done mainly to reduce the size of standalone executable distributions of games made with O2D.

On Performance

2006-03-07T11:53:00.000+02:00

Having spent a lot of time with Python in the last couple of years, I've often come across the claim that while Python is not nearly as fast as C, it is, more often than not, fast enough. I agree that this is generally true, and I was gladly surprised on how far I could go with pygext using pure (psyco-accelerated) Python for everything (of course, pygame and pyopengl called SDL and OpenGL in the background).

Games are a pretty different kind of beast when it comes to optimization, and a somewhat generic game framework even more so. They can never really be "fast enough". There are two main goals that improving the framework performance attains: 1) You can put more stuff on the screen. More enemies, more particles, more background layers OR 2) Your game will have lesser system requirements, allowing you to reach a wider audience.

That is the line of thought that convinced me to try and rewrite the core of pygext using C++ instead of Python. I'm only a few days in, but things are progressing pretty nicely so far. I'll post some benchmarks as soon as all basic funtionality has been re-implemented.

Of Python and C++

2006-03-05T22:05:00.000+02:00

I did some experimenting today with both Boost.Python and SWIG, and SWIG will be the wrapper of choice, at least for now. Boost might be better for some things, but the whole installation and configuration step was a huge hassle and ultimately I didn't get it to work properly on my setup. SWIG on the other was usable right away, and after a brief read through the basic documentation, I had a working version of my C++ extension.

Python has proved to be an excellent prototyping tool for the C++ extension. I'm currently developing the extension in tandem with a pure Python version so that, whenever I'm about to implement a new class, I add it to the pure Python version first and test it. This way I can verify all architectural and algorithmical ideas before writing them in C++. I'm also writing the prototype in "C++ style" so that each dynamically created object has .new() and .delete() methods (and my tests track memory allocation issues), and I use 'this' instead of 'self' etc. This makes writing the C++ code based on the Python prototype very straightforward and fast. So, even though I'm pretty much writing all the code twice, I think I'm still making faster progress compared to trying to write the whole thing directly in C++.

Boost.Python vs. SWIG

2006-03-04T22:08:00.000+02:00

I found this comparison between Boost and SWIG an interesting read. Although, it is a couple of years old, so I don't how relevant it is with new versions of but Boost and SWIG. Pretty much all the links I found from Google were pretty old, so I guess I'll just have to try both of them myself. The general consensus seems to be that Boost has more features and is often more convenient, but when problems come up, they are much more difficult to debug compared to SWIG.

A Short Introduction

2006-03-04T13:06:00.000+02:00

Opioid was the moniker chosen for our team in the first PyWeek competition and since then we've continued using the name and gathered a couple of additional friends to the bunch. We currently have a couple of open source game projects under way, which we hope will provide us with enough team working experience and proper tools so that we can start looking at some more "serious" game development (probably portal games at first).

On the tools side, our current focus in on Python, using pygame, pyopengl and pygext. Prototyping is on the way to add C++ to the mix too.

As for the current events, three Opioid members (including me) are currently taking part in the shmup dev horizontal scroller competition, and later this month, the full team will take part in PyWeek #2.

I'll add some info about our current open source game projects in future posts. Stay tuned!