Re: [crossfire] Improved/redone client.
Standardize on 19x19 map size. Good idea, and scale tiles accordingly otherwise. Would probably want to make a 16x16, 64x64, and possibly a 128x128 tileset in that case. Or just try to use OpenGL to scale tiles appropriately. Make client fullscreen. I have mixed feelings about this one. I would run it windowed, but I know for a fact that many Windows-using people expect a full screen app from a game they would consider playing. I experimented on some Windows users and a private server a few months back, and they all wanted full screen and preferred gtk-v1 client, as it could display more information to the user at the same time. So, if the game UI is geeky, it is only in the sense that CF uses the OSes standard UI elements, and users expect shiny UI in a game. Improve client UI From observing the Windows users I found they liked as much info displayed as possible, with often needed info in easy to look at locations, and less often needed info in less easy to look at locations. Perhaps some often unused inventory tabs could be converted to a body tab, which graphically shows what equipment is worn and what slots are free? Or a resistances tab that shows slidebars of the resistances from 0 on a scale between -100 and 100? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Mark Wedel wrote: Standardize on 19x19 map size. If the interface is also changed to be more of an overlay, this could work, but with the current UI...at 1280x960, 19x19 leaves very little room for the rest of the interface. 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) A fullscreen/windowed option seems reasonable. Perhaps also a grab mouse/free mouse toggle? 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 [...] 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) On SDL/OpenGL: I have to disagree. SDL does the job well and has ports on almost everything. OpenGL may do it better (hardware scaling go!), but SDL should at least be available as a fallback on systems where OGL is unavailable or doesn't work properly. 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 [...] wouldn't have to update it, just like the unofficial clients out there now) The problem here is settling on a client that satisfies everyone. I'll be clinging to the X11 client until you pry it from my cold, dead finger-analogues - it's noticeably more responsive than the GTK2 one, and on windows (built with Cygwin, for those interested) it's much more stable, too. One of my friends feels the same way about the GTK2 client and can't live without his tabbed inventory pane. Etc. == 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. 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) Having a scrollable inventory always present like that can be very useful given CF's realtime nature. At least, so long as you keep it organized (or use the GTK client's tabs?) so that you can quickly find that potion of fire resistance before the dragon catches up to you. Perhaps have two flavours? A roll-out scrollable side pane a la classic CF, and a larger popup that shows you everything at once, more suitable for when you aren't in a hurry? - Maybe use themes to make the appearance more that of a game and less that of an application (font size, background colors, etc) As long as there's a classic X11 client skin :) - 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. Seconded. The in-game help is a lot better than nothing, but has some serious gaps. - Ben ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Kevin R. Bulgrien wrote: I have been giving this extra thought lately, and fired up the gtk2 client. I have to say I do not agree with the statement that the clients are too geeky, but then again, I score high on nerd tests too. At first I thought the gtk2 client tabbed information was cool, but, I still go back to the gtk1 client, again because I can see everything. The fact is, the more information you have at the ready, the better you can shoot the bogey's down. There really is no other way to do battle effectively. The resistances might qualify for hiding, but even they help remind you who not to go up against without checking equipment. Maybe if you are high-level, you never look at those things, but I would not find crossfire nearly as fun without the geek factor of the GTK1 client. Every time I try the GTK2 client I get frustrated at how much is not on screen. That may illustrate some of the problem however. I suspect that if we did a widescale pool, we'd get following results: Everyone would agree that some elements should always be displayed (hp, sp, some others). A mixture of people agreeing what other things should always be displayed. Some would say that ABC should always be displayed, but I don't need DEF. Other saying I really like DEF, but don't care about GHI, etc. And you'll get different input on how that data should be displayed. For example, in the gtk1 client, things like skills and protections are in scrolled windows - some people may find that annoying, etc. I think the best we can hope for is a try to get something that most people would agree on. I don't think we can ever get anything that everyone would agree on (and probably, even in the case of the current clients, everyone has something they'd like done slightly differently). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Here is a screenshot of my gcfclient2, with some comments about where some space optimizations could be implemented: http://wilber.gimp.org/~raphael/crossfire/gcfclient-ui.png I don't think I ever responded to this. But one of your points is that the look/inventory icons are too big. You can already control this - -iconscale command line option, or there is also a space for them in the config windows. Set it to 50, and they are now half the size. Now it may be reasonable to make the default value something other than 100 (maybe 50?) Simply because when the tiles were increased from 24 to 32 pixels a while back, that obviously decreases density. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Alex Schultz wrote: -Less flexibly, as a gtk2 theme with small changes in logic and hacks to make popups have custom title bars and stay within the game view (might involve interesting platform specific code). The second would probably be less work, however IMHO more hackish and more likely to have odd quirks. I'm not sure which I would deem better overall though. Actually, that isn't an issue. Within gtk/x11, there are several placement methods. There is the general I don't care where this window pops up, in which case some window managers let the user place it, other window managers decide for the user where it should go. There is the true pop up, which appears beneath the mouse pointer. Right click within a gnome-terminal and you get this. There is the window created by the application (what we've been calling pop ups, but aren't really). The application can set where these windows should appear, and the window manager will put them there. If the window manager doesn't, it is broken, and not something we can concern ourselves with. A basic example of this is the metaserver window within the gtk2 client. It is set to be centered on the parent, and that is where it shows up. We could do other things within gtk, like align on left edge, etc, if we so wanted. That said, these are still windows, so the window manager to still try to manager them (close the window, move them around by hand, etc). But if players start doing that, that is their decision. In fact, I could actually see that be a bonus for some players. The gtk2 client doesn't support splitwindows anymore, I don't think, but if we had an inventory window, being able to drag it of so it isn't on top of the client could be considered a plus. Well, at least for me it could be, given I run dual screens. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
I'm going to try and summarize the 20+ messages here. 19x19 map size: --- Didn't get many comments, but a few people expressed desire to be able to set this (either because of very small screens, or very large screens). Now scaling of the images (-mapscale already supports this) could be done to compensate for this, but that doesn't look really great. One thought is to at least set a minimum map size (must be set to 17x17 or something) so that map designers could know that a player can see 8 spaces away from them. Yes, people playing on a 25x25 display have an advantage, but so do those with faster connections, etc. I would also be inclined to require on display dimensions, so that the player is always in the center of the screen, not off by a tile. making client fullscreen: - General consensus seems to be no on this point. I don't think I saw anyone that actually said they would use full screen, and to me, that is a red flag right there (if no developer is using it, no one will find bugs, etc). But more so, I think it is that in a linux environment, people are not expecting full screen apps. Full screen could allow custom widgets, but some dislike expressed on that. And I do think that is a valid point - being able to use GTK2 makes coding a lot simpler/faster. There is a reason that the gtk clients have a lot more features/abilities than the X11 client, which isn't using any widgets and thus has to have the widgets it does have done by hand. standardize on one client (gtk2): - Generally OK, but gtk2 client would need to work better on low resolution displays. At lease some people are still using 1024x768, which has more space issues. My thought might be to make a different glade layout file for lower resolution, which also chooses some other defaults Client ui improvements: --- - pop up window for inventory handling: Mixed reviews on this one. It could be that some sort of compromise/hybrid be done. My thought: Have a pop up window for in town use, etc, which could present a lot more items or data than currently provided. Within that, allow for some custom filters or favorite items, and have tabs (in the main window) for those, and have those in a smaller inventory area. So while in a dungeon, you can easily get to the items you need (more easily in fact, because they would be the only thing in particular tabs), but in town, can do everything you need to do. The look window would always be active like it is now (but when the popup is in use, maybe have that data replicated in the popup also to make it easier to access stuff) - add theme support: No real issues, as long as the ability to keep default theme is allowed (it would be). My thought is to handle this like firefox and lots of other apps do - you can use the system theme, but it may have various custom themes which could make it appear more 'gamey' - display important info: Figuring out what is important is hard. Generally, it seems that protections and skills (both) is important, general stats less so. Maybe should investigate to see if we could display both of those in one tab. Overall exp displayed should be added to the scrollbar stats window (sp/hp/grace/food), with the scrollbar representing percentage to next level. For exp values, maybe in the 'compact' list, display the last 5 (or X, where X is not a really large number) of skills that have gained exp? Thus, while in the dungeon, you'd see your combat skills in that window, and could track progress, and in town, you'd see your town based skills. Range attack is also listed as an important to know item. Also suggested that within the protections themselves, that maybe they go red/green for some amount of time when they change, making it easier to see when a spell expires. Could be used for all values that change. Text messages are always an issue. Other than the space used, I don't think the way the gtk2 client does it now is bad. I'm not sure that writing them over the map area would be useful - crossfire generates so many text messages, I think you'd always be bringing up the console to see what you missed, so having the console (text area) always up probably makes more sense. - improved help - should be done, now to just do it. - Improved key binding - should removed duplicate keybindings (or present warning). Also, should have some method of different key binding profiles, so you could load up the mage vs fighter profile (or maybe the dungeon vs town profile). If loading different keybindings can be done by a keybinding itself, this would be doable. In addition, more data on how the keybindings work should be added. - background music should be added. - Better magic map handling (colored dots like cf+?) I had also thought that instead of sending colors, maybe magic map
Re: [crossfire] Improved/redone client.
The idea is that the current clients display way too much information; someone has described them as geeky. Typically, when playing, you're interested: in the map (always), hp/sp/grace/food (almost always), important messages (almost always), chat (often), exp (often), and look list (frequently). Everything else only needs to be looked at occasionally. By the basic rules of UI design, it follows that these are the elements that should be always there; if possible, progressively less intrusive in the order above. Other elements should be easy to bring up, but off by default. I have been giving this extra thought lately, and fired up the gtk2 client. I have to say I do not agree with the statement that the clients are too geeky, but then again, I score high on nerd tests too. At first I thought the gtk2 client tabbed information was cool, but, I still go back to the gtk1 client, again because I can see everything. The fact is, the more information you have at the ready, the better you can shoot the bogey's down. There really is no other way to do battle effectively. The resistances might qualify for hiding, but even they help remind you who not to go up against without checking equipment. Maybe if you are high-level, you never look at those things, but I would not find crossfire nearly as fun without the geek factor of the GTK1 client. Every time I try the GTK2 client I get frustrated at how much is not on screen. On another note, also probably indicating geekish tendency, I think the key binding interface would be just too cool if it supported some sort of rudimentary scripting capability... Why not have a client-embedded script that could trigger auto-keypresses, sound bites, or stuff like that? Maybe even some capability to glob things so, for instance, the same binding would work to equip, use, unequip a scroll, staff, or rod of something... and would work no matter which one you had. Now that... would be cool... ... and awesomely geeky How on earth does anyone come up with the idea that clients like this should not be geeky? ;-) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
On Mon, 09 Oct 2006 01:10:52 -0700, Mark Wedel wrote: 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) It may have happened while I was in Hong Kong, but from the UI discussions I've seen, I don't remember anyone defending fullscreen clients. Rather, we (myself included) used the term foolscreen loosely to describe something else entirely, which is probably more correctly termed fullwindow. The idea is that the current clients display way too much information; someone has described them as geeky. Typically, when playing, you're interested: in the map (always), hp/sp/grace/food (almost always), important messages (almost always), chat (often), exp (often), and look list (frequently). Everything else only needs to be looked at occasionally. By the basic rules of UI design, it follows that these are the elements that should be always there; if possible, progressively less intrusive in the order above. Other elements should be easy to bring up, but off by default. The solution usually thought of as the best is a design similar to other games, like experimented with in sdlclient and the cfplus client; the map is the main element, taking up almost the whole area, and the other important elements are around the map, possibly in the form of a HUD. Messages and chat could be overlayed on the top left / bottom left of the map, where they're less likely to obscure something important. Pressing ' brings up the console, where not only you can type, but you can scroll back trough old messages and maybe even see messages that your client was configured not to display in real-time. Other keys (or clicking on handles on the edges of the window) would bring up everything else -- basic stats, resists, inventory, spell list, the works. Then of course this raises a separate discussion of widgets. I think custom widgets are more appealing, but they have all the disadvantages pointed out by Quinet (specially, clipboard support), and they're obviously extra work. I think such a design is not at all impossible to implement using gtk+ widgets; it may even evolve from the codebase of the current v2 client. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Alex Schultz wrote: -If you try to make a keybinding over a key that is already bound something, it shouldn't just append to the list, it should warn you and if you choose to continue, remove the old binding first. Yes - that is a valid point - overbinding a key doesn't make sense. But it gets a little odd with modifiers. -One idea that might be good, is while it is waiting for you to press a key to bind to, it should come up with a graphical display of the keys on the keyboard, and with color coding showing which keys are already bound. Tooltips when hovering over a key show what is bound there and clicking a key counts as if you pressed that key. I don't know if there is a widget for that or not. That is not something I'd want to have to write ourselves. We just can have a universal looking keyboard - after all, laptops, different keyboards, etc, can have different layouts. Inventory control via keyboard: I'd be interested in how people think that should work - I really can't envision much any reasonable way to control the inventory only by keyboard, whether we use gtk2 widget or write our own. I'd personally consider this to be a pretty low thing to do. Personally I think this would make a big improvement if it could be pulled off in a reasonable manner. The best I've seen for keyboard inventory control in large inventories, would be how nethack does it even in it's gtk interface. That keyboard interface might work well if we used popups, however see the popup issues above. One could do something though with giving focus the inventory list and allowing keyboard scrolling of it and pressing keys to apply from it or drop etc. however one would need to make it VERY obvious to the player when they have focus on that, and also would have to make it very difficult to accidentally trigger while easy to trigger manually (and for fairly obvious reason I don't think focus on click would work well for it...) A valid question may be whether the inventory interface should be completely redone. The mouse buttons I believe kept what was used in the old X11 client. I don't think the current button presses conform to what people would expect from a GTK application. I'd say that a single button press being the expected behavior is not standard. What comes to mind could be something like this: Left click selects an item. A double click applies the item (most common operation). Double middle click drops item (second most common operation?) Right clicking on a selected item brings up a little pop up menu on additional item actions (drop, lock, apply, examine, mark, etc). I think that is better than having these odd shift and control combos. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
A nice thing would be to have a generic client, with an interface layer. This way we could apply different interfaces while retaining a common layer. Think something like Firefox's XUL, maybe? (as a concept, i certainly don't suggest to use that language for the interface). Maybe with a widget system? Let users write (in Python? LUA?) their own displaying widget to display game information? The problem/complication is that at some level, the UI becomes a pretty major portion of the code. And it probably makes more sense to spend our time to just get a good, thorough working client with (for lack of better term) hardcoded toolkits and not have some scripting writing language that no one really uses. Now an intersting side point to this is that the gtk2 client uses glade for all the layout. In theory, someone could write a new glade file/description, and as long as all the widgets remain the same, could just be dropped in place. This in fact may be the thing to do relative to high and low resolution clients - rather than trying to have layout to cover everything, having two glade files might not be that unreasonable. Now I do think the current code may need some additional work. In such a model, I could certainly see some versions not implementing all the widgets (for space reasons, whatever else). That can easily enough be handled I think in the code to make sure the widget isn't null, but that checking isn't there right now. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Quick note - the client reorganization/cleanup/entire discussion is aimed at the 2.0 branch. I don't really forsee many of things things going into the 1.x client. Will try to quickly catch up with all the issues at once : Keybind profiles: I think that is doable, and makes sense (keybinding for a spellcaster vs non spellcaster is quite a bit different). From what was described, it sounds like there would be two keybinding profiles in use at any time - the common set, and then the specialized one for the given character type. That gets more complicated, because if you add a new binding, have to record where it goes (specialized binding or general one). It certainly wouldn't be hard to have an option on what keybinding profile to use. OTOH, presumably players would want this somewhat intelligent (if I play character X, use this binding, if I player character Y, use that binding), but probably don't want one binding selection per character. And even keying on character names may not be good, as different types of characters with the same name could be played on different server. Keybinding interface: I don't think anyone mentioned this, but I know people have said they don't like the current interface in the gtk2 client (which is really the same as the one in the gtk client). Not positive how to improve it - it seems with the number of spells, etc, we're always going to have a lot of keybindings in crossfire, but would be interested in hearing ideas. GTK2 client resolution: Yes, it is/was aimed at higher resolution screens. One reason was there is lots of buggy/complicated code in the gtk1 client to try and adjust based on window size, etc, and I want to avoid that complication in the gtk2 client. And at some level, I think that making changes to layout based on screen resolution has other disadvantages (it's hard to optimize for both low and high resolutions, which is one problem I had with the gtk1 client - fine on moderate resolution systems, but not very good on high res). I'm not sure the perfect solution here, but perhaps designing a layout for 1024x768 and seeing how it works might be a good start. The doc that says I won't take patches for lower resolution is not accurate. Containers: How to handle them can always be a bit of pain. I never thought it opening on the ground beneath the player was very intuitive (and would then create odd issues like you can't get to objects on the ground with an open container, etc). A quick fix for closing containers in the inventory is a 'close all containers' button could be added to the top of the inventory area. Quick item handling: In the ideal world, the client should be able to support some better form of filtering, perhaps even having like a 'favorites' tab which only shows items marked as your favorite (in this way, you could put all your items that you frequently apply there). Some games have the 'paper doll' type interface - I think that could still be a good idea for equipping, but I'm not sure if it is good during general purpose play (I can't think where that would fit in the client) Map size: The 19x19 was to make that the only supported map dimension as far as protocol/setup is concerned for viewable player map. The game map files won't change. And the client could of course have a larger visible map, but just wouldn't get data from the server for it, so its only use would be to use that for fog of war. I tend to think that letting the player select map size doesn't have much in the way of downside (yes, some players may get more information, but that hasn't seemed to have been a big problem in the past) Fullscreen client: The reason I don't think changing resolutions should be a method is because I don't think that will be very well supported. There is no guarantee what resolutions the system may support. I can certainly see people with LCD only having 1 valid resolution defined (native resolution of the screen). And you get the complication of widescreen (its not 1280x1024, but 1280x800). So you're now in a case where you may still need to support several resolutions. The other problem is that the client has to be more bulletproof to change the resolution back to the original when done. But the interesting point about fullscreen client, is that while several people say it may be useful, I don't think I've seen anyone actually say that is what they would use (they would use windowed mode). Which to me sort of suggests that this isn't something really worth pursuing - we're trying to guess what other people want. Pop up inventory window: I'm perhaps seeing this more as a secondary interface to the inventory, not the only way. So the existing scrollbar exists, but when dealing with lots of store, or perhaps more advanced operations, a pop up window could provide a better interface. OTOH, having two different interfaces would seem confusing.
Re: [crossfire] Improved/redone client.
Standardize on 19x19 map size. It makes sense to have a common client size. Of course, whatever size we use, some people will find it too small, some will find it too big :) Make client fullscreen. As long as it's an option, no issue here. Note that I agree about the point concerning toolkits - it's nice to have coherence between applications. Standardize on one client Agreed, with the following conditions: * be available on as many platforms as we can, so people don't feel like writing another one * have as many options as possible - so people can customize it to their taste, and don't feel like writing another one :) Improve client UI 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) Optional :) - Maybe use themes to make the appearance more that of a game and less that of an application (font size, background colors, etc) The best thing would be to have game mode, either full screen or not, with a specialized toolkit, and integrated mode, integrated in the desktop (using style and such). - 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? Again, let's enable the user to customize the interface as much as possible. - 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. Agreed. A nice thing would be to have a generic client, with an interface layer. This way we could apply different interfaces while retaining a common layer. Think something like Firefox's XUL, maybe? (as a concept, i certainly don't suggest to use that language for the interface). Maybe with a widget system? Let users write (in Python? LUA?) their own displaying widget to display game information? Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Nicolas Weeger (Laposte) wrote: The best thing would be to have game mode, either full screen or not, with a specialized toolkit, and integrated mode, integrated in the desktop (using style and such). In my opinion this would be a great feature to have, however might be difficult to implement. The two ways I see to implement it would be: -Do something along the lines of what you say below, a much higher level common layer. -Less flexibly, as a gtk2 theme with small changes in logic and hacks to make popups have custom title bars and stay within the game view (might involve interesting platform specific code). The second would probably be less work, however IMHO more hackish and more likely to have odd quirks. I'm not sure which I would deem better overall though. snip A nice thing would be to have a generic client, with an interface layer. This way we could apply different interfaces while retaining a common layer. Think something like Firefox's XUL, maybe? (as a concept, i certainly don't suggest to use that language for the interface). Maybe with a widget system? Let users write (in Python? LUA?) their own displaying widget to display game information? Well, we already have a common layer of sorts with the common code, however what you suggest of making something much higher level would be a very interesting idea. How much work it is to implement may be another matter though. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
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
Re: [crossfire] Improved/redone client.
On Monday 09 October 2006 06:28 am, Kevin R. Bulgrien wrote: - 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. Add to that magic map interpretation/use. I never have figured out how to use them. === 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 Also, strongly suggest key-binding profiles, possibly for keyboard regions. When playing multiple characters with unique skill-sets, it is difficult to create one single key-binding profile that fits all of them. I can see that a profile for the function keys would add value. I could slide in a new function key set while keeping the alpha keys common since they are often bound in ways that help you memorize what they do better. I tend to keep the numeric/punctuation key binding constant too, but that might be another area that would benefit from being able to be profiled depending on the tastes of various players. The reason for profiling regions would be to reduce rework of bindings that a player keeps constant across various characters played. Additionally, without knowing the underlying infrastructure, it is hard to know if the following is practical or not. I think all clients suffer from buffer flooding. I think it would be exceptionally profitable to have an ability to flush the command buffer or to escalate the priority of certain emergency bindings. I don't know how many times I have helplessly watched as my character died because the buffer was flooded and there was nothing to be done except stop and hope you don't die before it emptied. Kevin ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
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
Re: [crossfire] Improved/redone client.
On Mon, 09 Oct 2006 09:37:29 -0600, Alex Schultz [EMAIL PROTECTED] wrote: Mark Wedel wrote: == 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. Well, sorry to disagree but I actually prefer to have the crossfire client using traditional widgets. Even if games can be considered as a special kind of application, I like to have all applications on my desktop using the same widgets and behaving in the same way. For me, consistency is as important or even more important than the looks of an application. I usually dislike the applications that try to design their own widgets because they do not obey the global options that the user has set for all applications. If I have a large display and bad eyesight and I want to use larger fonts or high contrast colors for all applications, I don't want the crossfire client to behave differently because it uses its own widgets or because it installs its own private theme. Custom widgets can also cause problems because they do not behave like the other ones: they may not support copy paste operations (I use that a lot for copying interesting messages from crossfire to a text editor) or they may have menus that pop up in a different way or text entry fields that do not support the usual shortcuts, etc. Another issue is cross-platform integration: there are themes for gtk2 that allow all applications (including the crossfire client) to look a bit more like Qt applications while running in KDE, like Windows applications while running in Windows, like Mac applications while running in MaxOS X, etc. Using custom widgets or private themes would imply that the crossfire client would look foreign on all desktops and would not respect the global settings such as the default colors, etc. In summary, I am happy with the crossfire client using traditional widgets and I would not like to change that. A separate client could be designed for full screen mode (a bit like the one developped for CFPlus: http://cf.schmorp.de/screenshots.shtml) but I would probably keep on using whatever client looks and behaves more like other applications on my desktop. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Raphaël Quinet wrote: On Mon, 09 Oct 2006 09:37:29 -0600, Alex Schultz [EMAIL PROTECTED] wrote: Mark Wedel wrote: == 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. Well, sorry to disagree but I actually prefer to have the crossfire client using traditional widgets. Even if games can be considered as a special kind of application, I like to have all applications on my desktop using the same widgets and behaving in the same way. For me, consistency is as important or even more important than the looks of an application. snip Hmm, I consider those points for using traditional widgets to be valid points, however using them creates a bit of a dilemma from my point of view. One thing that I think would be highly beneficial would be making the inventory easily controllable by keyboard controls. Sure one could use traditional widget focus on it and do things that way, however even if those were efficient controls (which they aren't IMHO), it would *not* be consistent with the feel of the rest of the keyboard controls in the game. To me, consistency within an application is much more important than consistency with the rest of the desktop. So, one is forced to either: 1. Make it inconsistent with the rest of the game's controls 2. Modify the widget behavior and be inconsistent with widgets that look exactly the same 3. Or one could make new widgets that though arn't consistent with the desktop, but wouldn't be confused with desktop widgets and would have keyboard controls fitting in with the rest of the game. 4. Leave out keyboard controls for such things So #4 is the current behavior. Personally I would prefer behavior #3, followed by #1, followed by #4, with the strongest dislike from #2. I don't believe it is just a matter of inventory keyboard control, I believe various aspects of the UI suffer from lack proper keyboard control, and that use of traditional widgets and their notion of focus eliminates the best solution in my opinion, the third one I listed. At that, I believe this is a problem with having complex interfaces that are primarily keyboard controlled implemented in any sort of traditional widget system. Of course if you have any ideas on a way to make something such as efficient keyboard controls that fit other game controls, to work in such an environment, that might be interesting :) Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Improved/redone client.
Yo. I am one of the players of Metalforge, and I have been monitoring this. Of most of the proposed elements, I have agreement. However, SDL should _not_ be removed because on some computers OpenGL and DRI are not implemented right. That or add in an option to disable OpenGL and rely on old drawing mode. SDL is really nice because of legacy and support issues. On the plus side, I do not think CF should be optimized for the uber-supported computers if it is an open source project. Consider all the people, not just the few with the perfect setups. Thanks, Ben Bort I posted some brainstorms ive had onto the wiki: http://wiki.metalforge.net/doku.php/dev_todo:better_client_ui ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
