Jul 13, 2011 Comments Off
Jul 12, 2011 Comments Off
Jul 9, 2011 Comments Off
Jul 1, 2011 Comments Off
Jun 19, 2011 Comments Off
Greetings PARPGians!
Its been a while since we last updated the blog, and boy have a lot of things have happened in that time! I’ll try and outline what we’ve accomplished in the past few weeks below.
The single biggest change we’ve made is that we now use Assembla (http://assembla.com) as our source repository host. Although Codesion, our previous host, has done a lot for us over the years we decided that it was time to update to a distributed version control system and Codesion’s offerings in that area simply did not meet our requirements. However, we will continue to use our Trac page for bug tracking and keep our old svn repository online, at least for the foreseeable future.
One of the really neat things about Assembla is that it is built with Agile Programming methods in mind. Our Assembla workspaces provide tools for asynchronous communication, posting progress reports, viewing repository changesets and managing milestones and backlog items. Although we’re still getting used to Agile methodology, I think that most of us would agree that it has significantly improved our communication and collaboration habits. Overall, we’ve been very impressed with Assembla’s free hosting. It is by far the most professional free host we’ve seen, and has tons of features that we haven’t even figured out how to use yet!
Feel free to explore our Assembla pages at http://parpg.assembla.com and get a feel for how it all works.
One of our primary reasons for changing source hosts was that we wanted to migrate to a distributed version control system (DVCS). Subversion simply wasn’t scaling well enough for us, since we often had two, three or even more developers working in parallel. Add in the fact that each of those developers was working on some experimental changes and… well you get the idea.
So we said good bye to subversion (well, sort of – see below) and migrated our codebase to Mercurial. We narrowed down the field to either GIT or Mercurial, and most of the developers agreed that the learning curve of GIT was too steep compared with Mercurial’s subversion-like behavior and commands.
There have been a few stumbling blocks to implementing and using the new Mercurial repositories, but we’re starting to get used to the new workflow. So far the extra flexibility of Mercurial has been very useful, at least to the programmers.
As if changing our source host and VCS wasn’t enough, we also split up our codebase into three separate (but related) repositories: parpg-core, parpg-assets and parpg-tools.
The parpg-core repository contains the core code framework which makes up the PARPG application, and as such contains the majority of our Python source code.
The parpg-assets repository contains all of our game data – object definitions, sprites, maps, dialogs, music and sound fx, etc. Unlike the other two repositories, which are Mercurial repositories, parpg-assets is a subversion repository (the reason for this is explained below).
Finally, the parpg-tools repository contains the source code and supporting assets of the various tools and utilities we’ve developed over the years to help us create game content.
Our justification for splitting up the code like this was that the binary asset files don’t change very often and yet comprise the bulk of the storage space (more than 200MB in all), which would have significantly slowed down clones of the repository (DVCSs copy all history in their “check-outs”). Compounding this problem was the fact that Mercurial (and most other DVCSs, actually) don’t handle changes to binary files well and tends to create a lot of bloat with each commit. To solve this issue, we moved most of the binary files into parpg-assets – a subversion repository which is able to handle changes to binary files much more gracefully.
To prevent parpg-core from drifting apart from parpg-assets and parpg-tools, we made parpg-assets and parpg-tools subrepositories of parpg-core. What this means in practice is that any time you clone parpg-core, you will also clone/checkout parpg-tools and parpg-assets, respectively. This is a feature of Mercurial that was really fleshed out in the 1.7 branch, so you’ll probably want the most recent version of Mercurial clone parpg-core.
Just to make things as confusing as possible we also changed our build system (twice). Originally we used Python’s distutils installer to build and install everything, but unfortunately as the project grew more complex we discovered that distutils was very difficult to extend and was really starting to slow down development. To be fair the distutils module was developed to build, maintain and install Python libraries, not games with thousands of assets and dozens of tools.
SCons seemed like the natural replacement for distutils, since FIFE (our rendering engine and game framework) uses SCons as its build system. But right from the start we ran into problems with SCons. First, SCons didn’t like our Python code and we had to write a custom extension to get it to correctly install and optionally compile our Python code. Then SCons didn’t like our 8,000+ asset files and we had to write ANOTHER extension to get it to correctly copy our assets (and very, very SLOWLY at that). Then SCons had issues verifying which files had changed between the build/installation directory and the source, which required YET ANOTHER extension (you can see where this is going…).
In the end, we abandoned SCons in favor of its bastard child, WAF. WAF is an old fork of SCons that was developed by a couple of KDE developers. Although much less mature than SCons, WAF has proven to be more than stable enough for our purposes. So far, WAF has been very easy to work with: our current build script is a fraction of the size of our previous SCons buildscript, and yet does everything that SCons could do and more. WAF is also many times faster than SCons, which makes development a lot quicker. Finally, WAF comes as a self-contained script, which means that we distribute WAF along with PARPG – eliminating any issues with users using an outdated or incompatible version of the build software.
Our WAF build system is still being tested, but it should be in the main parpg-core repository soon!
We have even bigger changes planned in the weeks and months ahead, so stay tuned!
Jun 17, 2011 Comments Off
Jun 11, 2011 Comments Off
May 30, 2011 Comments Off
May 19, 2011 0
May 9, 2011 0
codesion.com
Recent Comments