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 _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
