QUB - the Q Universal Boardgame
June 2008: QUB has been reborn...
QUB is being re-implemented under a different name, QBoard. It is now
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
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
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.