QUB - the Q Universal Boardgame

June 2008: QUB has been reborn...

QUB is being re-implemented under a different name, QBoard. It is now hosted at:
11 July 2007:

The QUB project is officially defunct (and it has been for 2 or 3 years). It became too large to maintain (it was requiring 1/2 hours to recompile any significant changes) and the code became more and more spaghetti-like as the project grew. As much of the code no longer compiles under newer Qt versions (or even newer gcc versions, due to stricter C++ standards compliance), it would be a major undertaking to get it re-started. Maybe someday i'll find the energy to do it, but after my bout with cancer, my energies are currently elsewhere. Boardgame fans may be interested in gaming material available on my gaming site, or in a newer prototype application written in JavaScript which is basically QUB-lite-lite-lite.

21 March 2004:

Despite appearances, QUB is not dead!!!!

The current QUB architecture has about reached it's limits in terms of extendability-vs-maintainability, and it's time for a rewrite - QUB's 4th (5th?) since it started out as a Java Applet in 1997. Obviously, this definately WILL NOT happen overnight. It is, in all likelyhood, 12+ months away. Real Life will play an important, yet completely unpredictable, role in this schedule.

The current source tree is still usable, but there are no plans to actively maintain it - only to fix really horrible bugs. If anyone is indeed interested in actively maintaining it, email us and we'll get you all set up ASAP.

The following list should give you some idea of what's going on behind-the-scenes, and what the future plans are for QUB:

- My main goal for the next generation of QUB is that it's core be UI-toolkit-neutral. That is, the internals are to be implemented such that the are independent of any specific UI toolkit - Qt, GTK, etc.

- Half of the past year has been spent rewriting the object serialization and classloading layers in STL. Those two pieces play critical roles in QUB's architecture, and need to be in place before the rest of development continues.

Some notes regarding future versions:

- It will aim for UBP [Universal Boardgame Protocol] compliance. The UBP standard is under development via the CounterMoves group (countermoves.sourceforge.net), and the intention is for QUB to provide one of the reference implementations.

- The signals/slots lib from boost.org is under serious consideration as a replacement for Qt signals/slots, so these can be handled outside of a UI-specific layer. Alternately, if a good event-handling mechanism is proposed, that may be used in place of boost's signals/slots.

- The forseeable future will be mainly re-thinking some of the architectural fundamentals rather than coding. Once some fundamental questions are answered about modelling gcoms the coding can begin in earnest.

Powered by:
SourceForge Logo