Against my own expectations, it seems there's little resistance left even in that mess of paws: it took less than a week to map it all out quite fully this time, discard yet another set of dead parts of it, cut its remaining tendrils and pretense to "independent plugin, part of a common trunk, not just some code in the client", bring it therefore quite in line (though not to internal sanity, it still is what it is) and ready to be made use of, without crashing and without complaining that it doesn't have graphics or skins or resources or whatever else it previously imagined that the user must provide. For instance, here's the gui just using the system's mouse pointer if nothing else is available and the help window gladly showing whenever it's asked to show, looking as best it can with whatever is available at that time:
Having thus made sure that indeed, I can make paws do something useful after all, I'm literally staring at the pile of neatly sorted entrails of the whole thing and I can't make up my mind for the life of me - *what* is even the desired use of this paws-paste? So I'll first write down the brief description of what's there and then I'll spell out this generic question into several more specific questions that can hopefully be answered.
The current client's GUI interface is essentially a lame and broken attempt at implementing the world hierarchy from a... visual perspective1. There's a top "controlling"2 window that keeps track of all the others and does in fact the generic figuring out as to what window is the user interacting with, which ones should show and which ones should hide, all that sort of thing. Being of course a visually controlled world, the top window ends up being... that menu bar at the top (see? it's at the top, right?) of the screen, with the inventory and the quit button and whatnot. It's true that there is otherwise *also* a "mainwidget" thing but... that's just the overall container and doesn't do much at all. Don't ask me why can't that mainwidget be actually main and therefore control the rest, it just isn't. And because those are just windows and the whole codebase at the time simply couldn't do without managers, there's on top of this top a pawsManager with its very own textureManager.
The pawsManager is meant as far as I can tell as the entry point to the paws itself - at least when entertaining the delusion that paws is or can somehow be separate of the rest. The textureManager is one of those endless glorified list-keepers: it keeps its own list of filename-resourcename equivalencies for all images that the GUI uses and otherwise interfaces load/find from the engine's own textureManager, of course. The meagre claim to purpose it has beyond that of list-keeping would be that it packs in one place some format-related processing of 2D images that are supposedly helpful in some cases (though it's unclear if there are all that many such cases in current use). Anyways, aiming to keep changes to a minimum, it can live as such and keep its list too, since I have no intention of saddling EuCore with any internals of the GUI/skin now. There's of course a whole dance around in both pawsManager and its textureManager with translating strings (literally, the "localization" because apparently it makes somehow sense to shove that concern in there), defining "styles" (there's skins and then there's... styles; because one S is not enough and nevermind there's no game worth even one capital letter, yet, we'll add styles to the interface and that'll be grand!) and making oh-so-sure that one is never, ever, under any possible circumstances somehow left without - gasp! - a loaded "skin". Additional, even smaller concerns abound too but by now we get to the microscopic so I'll let them be already, suffice to say that if I'll ever need an example of pointless polishing of irrelevancy, I can certainly use that code.
Past the 2 managers and 2 top-widgets, there is the indistinct mass of ...more widgets. Basically *everything* in the GUI is a widget, from one single slot in the inventory window to the whole inventory window itself. Here I can happily report that indeed, the "off with its dolly" task was most satisfyingly carried out: there were 2 (two!) classes on top of all the usual widget+xml defined just to *support* that and several tendrils sneaking out into non-paws parts too and oh, what joy to cut them out already!
Dolly cast aside and readily forgotten, the reduced pile of widgets is still a considerable pile and otherwise waiting for either full chop or partial cut, depending on what exactly turns out in the least useful in there. The "design" of the whole thing is that each widget has a code class (in client/gui mostly) that is meant to implement what the widget does (and even if it doesn't - there still has to be this code present as a means to register and create the thing, useless as it might be) and an .xml file (in data/gui currently) that defines in principle the layout of the corresponding window to be shown in game, including size, position, contained widgets and used "resources" aka icons and other images. In practical terms this means that new or different widgets still require touching the client, there's no "download this" and run with it really. At a stretch, the .xml layout files could be made perhaps part of the "GUI" .zip and so something that can be downloaded from the server and used but there's a very tight coupling between the code and the .xml so that it's unclear to me if there's much point to it anyway. So Q1 of those more specific questions would be here: is the layout of various GUI windows something we even consider part of a "skin" definition and hence up to GUI designers to produce as part and parcel of offering a client skin for use?
Even after the above trim, there still are about 100 widgets with their corresponding 100 .xml files, so I would rather not list them in here - the list is anyway quite easy to get with a simple ls data/gui in the deployed client's dir. The more specific question here is Q2: what windows do we actually need in the whole interface anyway? I can't quite see the point of 100 windows and it really all seems to me more a matter of ill-thought "design" in the first place, fitting slots in places by hand and adjusting them to be just-so, the usual sort of "artistic" approach to it all. I rather think there has to be a small subset of elements that will do it all and better anyway but at least currently I don't even quite know where to start from with it, as it's not all that clear to me what sort of things we need in the first place. I can even see the point in saying it's too early to bother with that and move on to implementing more of the functionality so that what is needed emerges from there but on the other hand the GUI has to start with something/from somewhere too.
Going through the list of main things as seen from a player perspective so far in Eulora, the Q2 above can get further refined: the most complex window in there is the chat window - does this even still make any sense or should this be only and at most a cli window in fact? Windows like the storage for instance were relatively ok in the beginning and then an utter pain when one has a full storage, reminding me quite precisely of the more generic windows-vs-cli computer use really - do we still want a storage window at all? And where does this stop anyway, as on one hand I can keep going and wonder if the inventory window is useful as such (perhaps it's at least pretty to see them all!) or the container or ...which of those 100 total, in the end? (Then again, I'm a cli radical apparently (hence my asking here), regardless of all the fun I had making textures, heh.)
Windows and widgets aside for a moment, the GUI graphical elements as such would be a set of tiny icons like arrow-this-way and that-way, backgrounds, buttons, scrollbars and the like. Currently even this is a bit of a mess in that there's no standard set at all, but a proliferation of arrow-up and arrowUp that are two different arrows pointing "up" (and this is probably what they tried to solve with the whole "styles" layer of grime on top, myeah). Nevertheless and as boring as it sounds to do it, a basic set can certainly be extracted and then forced even upon the existing widgets, certainly. The potentially troublesome part though comes from a current ugly mix of actual GUI elements (e.g. buttons) and 2D representations of game objects (e.g. a key in inventory). The currently deployed client makes no real difference and effectively lists those 2D representations as GUI "resources" like all the rest (so for all the fun, one could in principle very well set their buttons to look like Omlette Du Disgorge, why not). While I have nothing against buttons looking like omlette-du-disgorge, game objects are a very different category from GUI elements and I don't think they should be mixed at all. Even focusing solely on the very practical perspective, GUI elements get their representations (if any) from a skin.zip file (if it exists at all), while game objects are first of all a potentially infinite set, not known upfront and even potentially changeable on an item by item basis during play. So question Q3 here would be: does this separation make sense or is there some better way to go about sorting this out? (As I'll need to sort out this part at some point anyway, it can't really remain as it is.)
All the above out of the way and in the open for discussion, I can happily report that the client's code continues to shrink for now as it increases in usefulness and otherwise there are still parts that will end up most likely discarded in the end, as they get increasingly left behind (the original net part comes first to mind). While there is still quite a lot to implement on both client and serverside, I think the next steps will have to be alternating client and server development, introducing the new things (finally!) and sorting out otherwise what troubles remain, as they pop up. In other words, there's still a lot of hard work ahead but finally getting out of the swamps and it's such joy to be out of them too!
The attempt is so visible and the whole thing is so broken from so many points of view that I don't even have the heart to laugh at it anymore. It's one of those things that are not even wrong yet. ↩
The corresponding parent classes are even called exactly that, for bonus points of similarity of names being a great thing in code: controlwindow and controlledwindow. ↩
Comments feed: RSS 2.0
Actually that looks pretty cool, all sleek and futuristic in its transparent jem'enfiche-ism.
I deeply disliked the "windows" approach to game management, wherein the user could open a bunch of windows as if he was in Windows, which will lay on top of each other and interact and be selected and all that crap. The impression formed, firm and indelible, back in the days of the initial Windows 3.1 attempts at fucking the world that this is how imbecile academics think games should go, and nothing besides their lame-ass, inefectually useless "educational games" should ever work that way.
I still hold this view, never seriously challenged through the decades in any of its facets. The only way it is permissible to have windows in games is like Diablo did it : FIXED size, FIXED selection (meaning, opening any window closes all others and the user only ever interacts with the last window opened). No multi, no overlap, no tileing/flowing/arranging in any way, NOTHING LIKE THAT.
Let's try and understand this with a structured example :
I. Suppose we decide that the inventory, to be brought up upon pressing I, consists of a half-screen window which contains so and so things (and which if opened also re-defines the game viewport, such that the character is still centered in the remaining half screen).
II. Suppose we provide the "default" negative space (this'd be you know, the "margin" of the window) as a full color (maybe with a border) for this window.
III. Suppose a skinner produces a "better" skin, which includes drawn negative space for the inventory window (say demons or naked lillies or whatever in there).
My expectations at this juncture would be that his thing is clipped to size (if dragon tails or whatever expand past where my window normally goes, they're clipped rather than have the thing resized) and that'd be it. I do not expect the skinner to be able to alter, for instance, the count of inventory slots displayed, or their arrangement.
Similarily, if we provide default inventory slot graphics, in the form of I guess a square with rounded corners, my expectation would be that the skinner is capable to transform that into say a heart shape ; but not change its size, or positioning, or anything else.
There could be some argument for things like "but MP, I'm trying to make a skin for left handed people, so I want to open the inventory window on the other side of the screen", to which I'll answer a "maybe someday" an' no more. I don't see there could be any argument for anything else, the skinners provide alternate graphics for the exact slots already defined, there's no "re-done interface" without redoing the fucking default client. Which they're more than welcome to do, yes, but I ain't gonna have you do it for them.
Does this cut the knot without remainder ?
This is a difficult question to answer in the general. We absolutely need an inventory window, a crafting/worker management window and a land ownership interaction window. There are some windows we will need that I do not even wish to discuss yet. What do we do ?
For some reason I wasn't even really counting this, it seems more of an overlay than a window (in that contrary to the foregoing I would actually have scaleable at the user's leisure, from nothing to whole screen ; and it should also have adjustable transparency). So in my (apparently, more convoluted than I had realised) mind, the chat is an always-on overlay. Does that even make sense ?
Yes.
I think it does, yes. I've no problem with all the items involved in guy display being in their skins.zip or w/e named file.
It was exactly Windows that the whole thing brought to mind, certainly. That aside though, it seems I should perhaps reinstall Diablo and have another go at it as I utterly don't recall the windows (possibly they were so nicely out of the way that I didn't register them that much, can be). While in general I even like the idea of one window at a time & fixed etc, I guess it ends up then with redefined windows entirely because there are actions requiring views of different things at the same time (e.g. trading I suppose, or even crafting), unless I misunderstand something in what you're saying.
At any rate, having one single window and of fixed size would most likely mean with the current code that at the very least the whole set of existing widgets gets ditched and the "mainwidget" is repurposed while the whole interaction has to be redone/perhaps at best re-covered out of the ditched stuff. Alternatively I suppose I could go into looking to ditch the whole paws as apparently all of it is quite opposite to what you have in mind but that clashes with the other idea of keeping changes to a minimum.
I think it quite does, yes, although pretty much along the lines of ~all existing gui is useless at best and in the way at worst. I'll have to look into that viewport redef for instance because atm it's entirely separate part, not caring one iota about widgets of any sort. The thing is that the more this is pushed towards what would be nice to have, the more parts of existing stuff fall down so basically we get to ~re-write the client anyway, what reuse, all "reuse" was at best a stage during development.
This might require more thought in that the exact shape of the answer depends on the concrete approach we take in the end for making this interface. It is kind of a pain in that all of a sudden I can't therefore quite "not care about the GUI" in EuCore, not anymore, it gets shoved in whether I care about it or not. So basically the game's world contains even such objects as "GUI windows" with their respective attributes. Sigh.
What is an overlay? Currently it is very well exactly a window like all the rest (and ALL windows in there can have adjustable transparency and size, it's just a matter of setting the respective flags). Also, what chat is there supposed to be in Eulora's client since the server doesn't enter into it?
> they were so nicely out of the way
Just about.
> things at the same time
Trading will have to be its own special window, I guess, though in my foggy design mind it was more the inventory screen with the other side also taken up.
> So basically the game's world contains even such objects as "GUI windows" with their respective attributes. Sigh.
Wait, what ?
No, the sort of window I'm contemplating would be whole-screen, really.
> Also, what chat is there supposed to be in Eulora's client
I don't know that there's supposed to be any in the default client. I was discussing the chat window as a thing in principle.
Meanwhile I had another look at the available options re GUI at all in there, all the way from existing client down to cs: it's not that rosy at all. Basically CS used to have its own system but that has been thrown away and currently it has a version of CEGUI as single option for the GUI. This CEGUI thing is still based on widgets (sounds like the thing PAWS copied perhaps) so I don't see all that much gain to it at all. The paws itself is one set and then on top of it there are the more specific widgets and more specific manager and more specific whatnot that are currently in use and otherwise in general referenced from all around the (remaining) code. So probably the only real option is still to use that, only ending up with having to extract a set of reasonably useful basic building blocks and forcing the rest to somehow become able to use them.
There's some disconnect here. Whether whole-screen or part-screen is not a big deal at all. The big deal is whether it's a known upfront or previously unknown sort of window. If it's a different, previously unknown sort of window, the client will have to become aware of it somehow and the only way that can happen is via getting its description from the server, hence ...an object and corresponding type.
Hm, if I get this at all, I think you are essentially aiming for what I'm describing a bit above ie "window" is just an outline and then it gets populated with whatever building blocks make sense. The current implementation is at best not entirely and directly forbidding this - in that each building block is a widget itself, perhaps they can be forced to work this way, once I make a basic set.
Essentially though, it seems to turn out that the "no windows tiling etc" is a red herring - it's just one *view* at any given time but then this view itself is meant clearly to contain various windows in it, only fixed and each in its predefined position and so on. The overall thing sounds doable even if not straightforward - it's more the data connections that sound like potential trouble esp for unknown/new views basically.
I was asking what was an overlay in your view as I don't get how is it different from a window/view - just that it can be resized or set transparent and it doesn't close the other opened stuff?
You mean in the sense of, if there's any logic involved ("click here to X" or anything at all) beyond displaying a full sized image, it needs to be in the code rather than a downloadable asset ?
I suppose pushing a point this could even be deemed true ; but there's still no issue of windows overlapping and figuring out "who's active" and so on.
An overlay is a window that is always displayed and not active (in the sense of input focus) by default. A window is an overlay that is called to display and is always active if displayed. I happen to think there's a lot of meat under and flowing from this distinction, and that it serves one well to actually think in such terms (rather than "everything's a window" or whatever became fashionable since the 90s).
Yes and specifically there, even if it is "display a row of items from player's inventory and a row of items from counterparty's inventory" sort of thing.
Indeed, no issue with overlapping, merely the mapping of click position to some element as such.
I looked at the very gory details of how those widgets are displayed - they are literally painted rectangles on the 2D canvas. The real gain of keeping though the monstrosity such as it is turns really on not having to reimplement this basic level painting stuff and otherwise the wiring between keys + clicks on one side and executed code depending on context (window/view/whatever is shown there) on the other, I guess.
Honestly I think too much optimization work here is yet premature, leave some for later.
The specifics of the "either dead images, or else recompilation, or else I guess some kind of scripting language baked in" are contundent at the moment. I'll have to think about this a little.
Makes sense & will do.
At any rate, I wasn't going to focus on that at all right now. Instead what came out very useful from the discussion is the overall approach and essentially the need to ditch the 100 current windows + extract a set of basic elements. Possibly this will also give me a better idea afterwards as to what and how can even be done there exactly.
Word.