[crossfire] Improved/redone client.

[Alex Schultz]

Mark Wedel wrote:
>   One of those perennial items on the TODO is an improved client interface. 
> Unfortunately, seldom are good details provided.  I had a discussion with a few 
> people on irc a little while back on this, and some ideas where exchanged.  Note 
> that this is likely far from a complete list:
>
> ==
> 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).
>   
I wouldn't consider this a high priority, but seems like a reasonable
reasonable thing to do.

> 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.
>   
Well relating to what is said below in the fullscreen section, this
issue could be considered a strong reason to make a fullscreen client
change resolution. I'm not personally sure if it would be worth
switching resolution, but this issue makes switching resolution make
some sense.

> ==
> 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.
>   
Agreed here. Some other reasons for making it 'fullscreen-style', is
that it allows 'popups' or 'heads up display' like interface elements
somewhat nicer than a traditional widget system like gtk. It also frees
up interface design, possibly allowing better inventory controls than is
possible with traditional widgets.

> 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)
>   
Personally, I would also be one using it in windowed mode usually,
however I still would most likely prefer a 'fullscreen' UI design. In
terms of switching resolution, why shouldn't it switch resolution
defaultly? It would help with the first note. Of course there is the
option of simulating a resolution switch by scaling the graphics up in
size (IMHO though, that would look ugly if the UI didn't scale in the
same way with no smoothing). Also, I don't think it would be a good idea
to make the pointer captive in a windowed mode, I find applications
which do that to be really annoying. Also, yes, we need a clear UI for
display settings such as being full screen or not, actually I'm tempted
that we should make windowed mode default to be safe.

> ==
> 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)
>   
IMHO this would be a good idea, however, only once whatever client we
decide to keep seems to have the approval of the masses and has no major
UI problems.

> ==
> Improve client UI
>
> <snip>
> - Pop up window for inventory handling (one gets so many items in crossfire, 
> that the normal scrolled area really isn't sufficient)
>   
This seems like it would be a good idea to me, in certain conditions, if
handled very carefully. For one, I don't believe popups would work in an
environment where the popups are controlled by the window manager. Also,
it would need to be carefully set up as to not obstruct anything, and it
would be best if it could be keyboard controlled, while still allowing
keyboard control of the game.
> - Maybe use themes to make the appearance more that of a game and less that of 
> an application (font size, background colors, etc)
>   
This in my opinion is something that should be done, but again needs to
be done very carefully to do right. Badly chosen fonts and colors and
such could be much worse than things are now, however if chosen very
carefully and tastefully it could be a nice improvement and give the
game more depth.
> - 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?
>   
Scrollbars with 'popup hints' seems like a good idea to me. On the other
issues though, I'm not sure how it should be handled, and personally the
way the gtk2 client handles it annoys me alot. I also use the exp one
most, resistances next, and overall stats next, however I use even the
overall stats one frequently enough that them being hidden annoys me. On
the other hand, what I use least, is some of the exp display, as most of
the skills are not ones I use. Because of that I'd be inclined to think
about ways of making useful exp/level info visible to the user while not
showing the full list. I think that perhaps some sort of thing that
displayed the skill one was most recently gaining experience in might be
a good thing to persistently show.
> - 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.
>   
Strongly agreed. Also, we need to decide how much to store client side
and how much to store server side.

Alex Schultz