Re: [qub] attempt to build QUB on SuSE 7.1

[stephan b. <st...@ei...>]

On Wednesday 23 January 2002 03:10 am, Joshua Rodman wrote:
> Please try to take this as constructive, .. I'm feeling
> rant-ish at the moment.  If it makes you unhappy just
> delete it as unwanted. :-)

No problem - everyone's allowed his opinion.

> I dislike C++, I dislike that it isn't avail on windows (where
> most likely game players would be), and most
> importantly, I feel it's ornate and overly complex.

It is overly complex if what you want is something like V_MAP. i Highly 
recommend V_MAP, and if i ran Windows full-time, i probably would never have 
started QUB, because i had V_MAP. CyberBoard, on the other hand, i find too 
restrictive (have to set up a scenario before you can even begin to play, and 
that's not very game-design friendly).

QUB was actually started in Java, but i had so many problems with drag/drop 
in the JVMs of the time that i abandoned it (after 1.5 years of work). It had 
network play, etc. It was architecturally Horrible, but it worked pretty 
well, except for the dNd problems, which were fatal.

> I would rather put a textfile and a few images in a tar or
> a directory to make a board than click around in a tree widget
> guessing what things do.  

That's exactly what GUB (QUB's predecessor) did. See below for how this can 
be done in QUB.

> The windows-esque MDI + microsoft
> widgets are a serious UI issue, the games I play most often
> don't have dice but turning those off seems not possible,

Click the little "tab" looking thing on the left of the main menu.

> and I have yet to find a convenient way to duplicate
> pieces.

You use ctrl-drag to copy pieces. Or right-click on them and click Copy. 
Couldn't be simpler than that. :)

> How does one play go, pente, tic tac toe, and friends with QUB?

Currently it must be done over email, by mailing your files back and forth. 
We're working on a real-time network solution, but we don't have a model we 
like, so that hasn't happened yet. QUB's first design priority (from my side, 
anyway) was the ability to help in design of games. From this point of view, 
with the exception of a few obviously-missing features (like the ability to 
drag multiple pieces), it has far surpassed what i ever expected it to do. 
So, you're right, it is way more ornate than it was originally thought QUB 
would be.

> Is it normal to just use a lot of windows-esque control-dragging?
> Have you considered having 'pool' icons from which you can grab
> a piece?

That's very possible, and there are several ways of doing that:
a) A "counter sheet" can be created using the command-line program gmaker. i 
have a script which takes a V_MAP file and makes a QUB-friendly counter sheet 
for it. You simply drag pieces from the sheet into play.
b) someone could programmatically make one in C++.
c) One can be made by hand and saved, then loaded at any time later.


> Anyway, I'm impressed with the amount of effort put into
> it may be that the tool is nearly perfect (or getting there)
> for the kind of games you were looking to play, but it
> seems cumbersome to set up and to play simpler games.

Quite to the contrary - QUB is the fastest way to set up and play most games! 
Here's an example of setting up and playing a brand new game:

a) Create the directory MyGame under my "game root" (~/gamesets is the 
default).
b) Drop one graphic in that directory for the board.
c) drop any number of graphics in that directory for the pieces.
d) Optionally, drop HTML or TXT files there (rules).

Now simply browse to that dir and double-click files! Any "big" graphics will 
be turned into boards and "small" graphics will be turned into pieces. If the 
terms "big" and "small" turn out to not work for your games, please let us 
know and i'll change the default size thresholds, or make them configurable 
(in almost 2 years i've never once had a problem with the default values, 
though.)

i agree, how to go about this setup is not obvious, but i will always 
maintain that QUB offers the absolute _simplest_ approach, even simpler than 
V_MAP (which requires you to make a counter sheet from your pieces, and all 
counters must be the same size, etc.).


> Sorry again if that seems whiny, I'm trying to depict

No, not at all. it's nice to hear what QUB looks like from someplace other 
than under the hood ;).

> both the issues and perspective I have, as a newcomer
> to the program, so you can relaistically evaluate in
> both ways whether these things are worth adressing.

Anything a user of the software finds confusing is, IMO, worth a addressing. 
That's not to say it will 100% certainly be changed, but if it cannot or will 
not be changed, i will certainly always try to give a really good reason as 
to why.

Thanks very much for your directness :).

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
This email is encrypted with ROT26 encoding. Decoding it
is in violation of the Digital Millenium Copyright Act.