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.