[crossfire] Improved/redone client.

[Kevin R. Bulgrien]

On Monday 09 October 2006 03:10 am, Mark Wedel wrote:
 
> ==
> Standardize on 19x19 map size.
> 
> This size was chosen as that the map could still fully fit on lower resolution 
> systems.  Standard size so that map makers know what to design to, and so 
> players don't have an unfair advantage (if I have a 25x25 map and you only have 
> 19x19, I have more info).
> 
> To me, the idea seems reasonable.  Having a single map size to supports 
> certainly makes programming easier.  As a user of high resolution displays, that 
> would seem to leave the map a bit small to me (it has been suggested to make a 
> 'large sized' image set with 64x64 tiles, but that is probably a separate 
> discussion).  It maybe that resizing the images on hi-res systems to be larger 
> is the way to go, or the client displays fog info in the extra space it has.

Does this mean each layer of every map is 19x19?  That every client has a max
display grid of 19x19 that cannot be set higher?  I guess I'd see the priority of
this as being quite low.  The main advantage of a larger display is that you have
a "better memory" of where you have been before.  I don't see that as critical,
but I may not understand the issue.
 
> ==
> Make client fullscreen.
> 
> Reasoning here is that most games run in fullscreen mode, so it becomes more 
> like most games.  It can also ensure that other applications are not grabbing 
> keystrokes/button presses (eg, window manager, etc), so if we tell the player to 
> press a key, we can know for sure that if the player presses that key, the 
> client gets it.  For lots of reasons, would still need to support a windowed 
> mode of operation.
> 
> My thoughts: I personally find fullscreen applications annoying, so would also 
> use the window mode (I think most people using unix don't expect full screen 
> apps).  While we can run fullscreen, I don't think we can or should attempt to 
> switch resolution.  This does then mean that client could be asked to run at odd 
> dimensions.  I think this issue needs to be investigated further - it may be 
> possible to make the pointer captive in a non full screen window.  I also think 
> that if we do full screen window, it needs to be pretty clear how to get out of 
> it (nothing more annoying than an app taking over your system)

Ugh.  Full-screen is awful IMO, and not worth any development time vs. getting
other things improved/fixed.

> ==
> Standardize on one client
> 
> Doesn't make sense to be supporting 3 clients in the current client distribution 
> alone, plus a few others hanging around out there.  This is just more work when 
> a bug/issue shows up (may need to be fixed in all 3, or maybe only shows up in 
> one client, requiring digging in there, etc).  So in the trunk, should just use 
> the gtk2 client, and get rid of the x11 and gtk1 client (note, they would still 
> exist in the 1.x branch).  Related to this, SDL mode in gtk2 client should 
> probably just go away (opengl will give us the features we need long term)
> 
> My thoughts: As the writer and user of the gtk2 client, I'm biased, but keeping 
> the gtk2 clients seems fine to me.  I know there are complaints about it, as 
> well as bugs, but having 3 supported clients I don't think really helps things 
> much (it becomes too easy to just not make improvements or fix bugs and keep 
> using the gtk1 client).
>
>   It may also be that a completely new client should be written (see point 
> below) so that the gtk2 client goes away.  But whatever is done, I think going 
> forward,  it certainly makes the most sense to only officially support one 
> client (people could unofficially continue to support the x11 client, but in 
> that case, the developers making changes to the protocol or official client 
> wouldn't have to update it, just like the unofficial clients out there now)
> Better UI interface
> 
> ==
> Improve client UI
> 
>   This is often discussed, but I hear few concrete suggestions.
> 
>   I'll be the first to admit I'm not wholly satisfied with the gtk2 client.  Yet 
> at the same time, I'm not exactly sure what I'd change to make it better.

First off,  there are very attractive features in the GTK2 client.  I was glad to see
it when I first tried it.  The presentation / UI design had polish that was obvious
at first glance.

But, the GTK2 Client is highly biased towards users with large high-resolution
displays and high experience with Crossfire gaming.  I am blind when I play
with it.  I feel _very_ strongly about this and that this is way more of a problem
than map size.  Specifically, I run with a large inventory  pane and a large pane
for output like store signs.

The client is also quite buggy. It crashed my server this morning when I tried it
again to answer this message... (http://rafb.net/paste/results/X0AAlv84.html)
before I even got logged in. Resizing different from default for my lower-res
systems seems problematic, keyboard lockups during game play make death
inevitable.  I get incredible spews of errors that bog the client to the point of
being unusable.  Configure options/screen layout settings do not seem to save
properly. I would hope these would be fixed,  but one cannot really count on
that when one is not that familiar with GUI programming.

The layout constraints would be hard to get around until I found a treasure hoard
in the real world so that I could get one of those displays that is very, very tall.
Messages/critical messages on different panes seemed cool in the beginning, but
the longer I used it the more I disliked it.  On the GTK1 client, I depend a lot on
having split panes because the critical messages persist without having to
specifically flip back and forth even though the critical pane is relatively small.

Long and short, I would hate to see v2 go to one client if it is the GTK2 client
without any changes. As for any other clients, as I only use GTK1, I personally
don't care if they go.
 
>   Here are various thoughts and some suggestions I think people presented:
> - Pop up window for inventory handling (one gets so many items in crossfire, 
> that the normal scrolled area really isn't sufficient)

Vote no unless somehow this can be done only for containers.  I have never
gotten to the point where everything ever done is bound to keys, and even
then, some of the bindings break sometimes so in an emergency you have to
"reset" a multi-step binding by hand.  This happens, for instance when using
emergency bindings that apply a rod of heal,  and unapply it.  I would die more
if I had to pop a window up to fix the state of such a binding with a mouse.  In
dangerous situations, I can have my inventory pane already positioned in case
I need to use the mouse to fix something.  Can see that this could be an option,
but GTK1 client is _ideal_ for me in this regard, and is one of the main reasons
why I use it and not GTK2 client.

On second thought, maybe exploring the a "body slot" motif might be a way to
overcome this.  Selecting a body slot might automatically give you only items
that could be configured for that slot and might actually speed up the ability to
manually juggle what is equipped, not equipped, etc.  The point being perhaps
that simply dropping the existing panel on a separate window won't cut it, but
totally rethinking it might be a more worthwhile pursuit.  Can't remember what
I thought about the way Daimonin did it, but I seem to think maybe they had a
good idea.

> - Maybe use themes to make the appearance more that of a game and less that of 
> an application (font size, background colors, etc)

Unimportant to me, but have no objection as long as display density is not
reduced.

> - Figure out what information is important to display, and what isn't.  In 
> particular, I'm thinking of the stats pane here - most often I use the exp pane 
> to see where I am at relative to leveling, less so the resistances, and seldom 
> use the overall stats one, since stats don't change very often.  Could we maybe 
> use icons instead of string names, and scrollbars instead of numbers to 
> represent progress?  Add popup hints so if you hover over the value, you get the 
> full info?

The one improvement in the GTK2 client that I do like concerns the stats displays.
Having a tabbed pane works well for me.  Popup hints are not something I'd want
to see, but maybe I am missing something.  I feel the GTK2 current implementation
is excellent as-is, except perhaps for the rubber-banding on the vertical layout
(that is just wierd, and garbles the pane if too small).
 
> - Improved help - I don't think the help in the client has much useful content - 
> I think a lot of the information currently in various places could make it to 
> the client so it has a real help system.

Would be great, especially in the area of keybinding.  Gameplay help could be
improved by in client improvement for spells pane content.  Pickup could use
some coverage too.
 
> ===
> 
> Thoughts/comments?

Strong suggestion to add "background music" like the Windows DX client had.  In
my opinion, this adds far more to the ambiance of game play than anything else
one might do.  The Daimonin client seems to have done a good job with sound
improvement, and it has background music.

Sound setup is a royal pain...  I have done without sound for ages.  Somehow on
my x86_64 system it all of a sudden started working... I still don't know why.  I'd
rank sound improvements high if I were setting priorities.

Kevin