Ossa Sepia

I don’t care how many angels can dance on the head of a pin! What I want to know is how many tiny details can one devil simultaneously be in.

The only reason why my love for graphical user interfaces (GUI) suffered no loss over this past week or so is that I hadn’t any such love to start with. The clientside required bits and parts for performing actions turned out to be a considerable pile of small but quite detailed pieces that seem tiny each on its own but add up quickly to eat a lot of time while remaining otherwise hidden internals so that there is at first nothing to actually show for all the work. As I looked in more detail at what the GUI needed to be able again to fully interact with the world, the work seemed at first to just keep growing at every step instead of shrinking: there were GUI elements missing and then new methods required for querying the local cache and new configuration options and synchronizing and whatnot.

Experience helped here a lot, as I know this sort of pile-of-details stage for exactly what it is, part and parcel of work at times. So I just kept the work as contained as possible and otherwise I kept going with it until I finally brought it all to the point where there are enough of the required internal mechanisms in place so that they can support the desired GUI interaction itself. As a result, I can illustrate now at least some of the new additions, if still not all. At any rate, Eulora’s client has now in place the basic mechanisms for interacting via mouse or console (text) with any items or characters in the world, whether they are contained in one another or simply directly in the world, on their own. There are still all sorts of details that will have to be sorted out – or possibly altered even – as everything else comes together but those are secondary details, those that can never be fixed in stone at the first pass anyway, nor should they ever be so inflexible as to have to be fixed in the first place.

To start with, the Console has increased usefulness and usability. The most important improvement from my point of view is that there is now in place a generic mechanism to deal with any command from the user: the first word is the command itself, while any following text is read as a list of “parameter=value” tuples, where the order does *not* matter and there is no restriction whatsoever on what “parameter” might be. Basically the Console simply grabs the full text, uses the first word to find the action that goes by that name (if any) and then passes whatever text follows to the action itself to handle. The action in turn has its own default values for all parameters but then goes through the given text and sets the given values as found, if and when found. As an interesting effect of this approach, the user can even set the same parameter several times in a single command but the value used will simply be the last one encountered. Moreover, as much as possible the same letter stands for the same thing for *all* actions – the most obvious example is the target which is t everywhere, not like it’s all that difficult, really. Anyway, by means of illustration, here are two screenshots with some commands:

The above new wiring of commands to actions means also that I can now easily add new actions at any time, since it’s just a matter of implementing what the action is meant to do and otherwise adding it to the list, nothing more – all the wiring from Console and even from the rest of the GUI will simply adjust and include it too, as it should. In addition to this, there are a few more small but rather very useful improvements including clearer feedback from entered commands, resizing of the Console window so that it correctly resizes the two internal parts as well and a 1-line “history” so that one can recall the previous command at any time. In funny inherited weirdness that I’ll probably have to look at later on, it turns out that a resize has as side effect the reset of the font’s colour though! Such is the underlying nature of the inherited core widgets, this ever plentiful source of surprises of the most… surprising kind.

As you can perhaps notice in the illustration above, the GUI offers now the full list of actions defined in the communications protocol but also a few additional “actions” of its own, such as “pos” or “examine”. The reason for those additional actions is that they are simply quite convenient for the user and entirely a clientside concern: one might want to find out their exact position for instance and the GUI can expose that easily so I’d very much rather it did. There is of course no limit to what can be added there either but I didn’t spend time to polish this: the point for now was to have the very basics in and otherwise have it there as an example rather than anything else. For illustration, here’s the result of “examine” applied to the character itself:

While the Console remains to my eye the easier interaction option the user can have, I’ve nevertheless put in the work required to have a working mouse-powered option as well. So the skin.zip file got bigger and includes now at least one icon for each type of (inter)action known to the client. (And don’t ask me why is the “repair” icon showing a hammer crossed over by a rolling pin, I can’t begin to imagine where that combination comes from!) Those icons are then used in a new Context window that can be accessed with a right click on any item ¹ and provides links to all the known actions. And since my GUI is not made with love ² but with calculations whenever possible, this Context window simply uses basic trigonometry to just figure out where each icon goes so that all actions are shown neatly in a circle. As a consequence, if a new action is added, the Context window will simply adapt and include that too, there’s no need to add it manually and fiddle with its position through xml until the cows come home. Such are the results of bringing the ancient magic of the sine and cosine to the innocent lands of GUI and other computer ruralia! Lo and behold the euloran outer wheel of perfect roundness and plentiful context interaction (see the console in there for feedback on clicked actions):

Getting back to the actions itself, with the exception of lock and exchange, all the other protocol-defined actions are currently fully wired into the client, meaning that the relevant messages are created and sent to the server. The movement action is at the moment rather annoying and choppy so there is certainly more work needed there but I think it should still wait as some of the issues are likely to get smoothed out anyway as everything else advances (part of the choppiness is likely to be more a matter of the values I have currently set for the sync intervals for the whole world, for instance). Although I didn’t fully go into all the remaining movement part at this time, I start thinking that I’ll have to do that too at some point, most probably to finally kill that stupid of “leg length” and “falling below 0”, if nothing else. Nevertheless, it can still wait a bit, perhaps.

Arguably the most time-consuming “action” in all the above was the move/pickup since it required the whole inventory GUI with slots and equipped vs non-equipped and stacks and splitting stacks and moving items in inventory too and everything under the sun in there. There was a bit of mini-puzzle fun with the formula for inventory (non-equipped) slots, some annoying further misbehaving of that listbox that has the handy scrollbars and all sorts of weird discoveries regarding the number-prompt window. Nevertheless, the whole thing is now working, the Contents window got basically an upgrade, can move items about and is quite ready to be of further use as half of an exchange of any sort. The “move” action on items in the world is effectively a “pickup” – it will attempt to move the items to the next empty slot (calculated on the fly, too) in inventory and won’t care a bit whether that is possible or not possible. After all, you never know unless you try so my GUI here is not at all in the business of telling the user what they can and can’t do: it provides the widest set of options to everything and then dutifully executes what the user asked for. The inventory window updates with server-given data only on reopen (all it takes is to press i for that) but otherwise it will happily show the user whatever they thought they could do, pretty much. I’m quite sure that there are all sorts of details to change here on future iterations but for this first pass, I think it does as much as can be done for now:

For the number input window, I initially wanted to reuse the original window as it was since it had in place some input checks and limits and all those things that are in principle quite useful. The fun part started though when it turned out that it had of course all sorts of silly expectations – that got therefore cut away – and otherwise it used a horizontal scrollbar to allow the setting of the amount via mouse movement. This horizontal scrollbar was simply not able to use 64-bits integers without requiring otherwise a full update throughout the whole client, basically in all places where a scrollbar is used at all. So rather than indulge in such waste of time, I just dropped the silly scrollbar-set from this window and otherwise updated the remaining small part to deal with 64-bits integers, what else. Since I was at it, I added also overflow guards, as there were none but other than thatm the thing is (at least now) small enough to be perhaps of some use currently.

On a side note related to inventory and slots in general, I added again the quantity and quality labels to each slot but the trouble is that the maximum 64-bits value has 20 characters and to fit as many as that onto a slot, the font ends up so tiny as to be unreadable. So for the time being I let them be as you can see in the screenshots above, using a reasonably small font that means however that the full value might simply not be visible at times. I suppose this might remain as one of those low-hanging fruit to pick for any client developer out there.

Regarding the actions themselves, on serverside, at the moment, those action messages that the client sends are received, unpacked, recognised as what they are and otherwise promptly discarded. There’s quite a lot to implement on serverside before they can fully be acted upon as intended. Nevertheless, for current testing and illustration purposes, the serverside simply has some mock data that it sends to the client as “the world” and that is quite enough for the moment (though it won’t be for much longer, by the looks of it all).

With all the above in place and working, there would still be the exchange and lock actions and corresponding GUI elements as such. Other than that, there are various non-GUI parts that could be done (and need done at some point anyway) on the client, such as the management of Serpent keys and actually dealing with a change of connection/server on the fly.

Let me know in any case if there’s anything else/different you want done for the GUI part at this stage and otherwise if there’s something else specifically burning/best to tackle next. I should also mention perhaps that in the interest of documentation and seriously applying myself to learning the craft of GUIs, I have indeed reinstalled Diablo as well and gave it a spin – the windows are a pleasure, the tick-tock of idiotic walking is more annoying than any skeletons that might appear from the barrels. Nevertheless and purely for work interests, I shall therefore endure Diablo re-plays whenever required!

1. This ran at first into a weird “attachment” thing that apparently was required in order to have a direct link between CS meshes and the game objects that the remaining client core works with more directly. And when that in place, there was the repeated and infuriating further run into the PS notion of “any item”, such as it still remained in the various parts that are still in use in any capacity: “Oh, by any you surely *don’t* mean meshes AND moving items, do you?” and “Even if moving items too, then *surely not* your own character, too!!” and so on and so forth, it’s like the devil is not in the details but rather the devil is a detail inside a detail inside a detail inside… [↩]
2. By now this made-with-love advertisement stands as far as I can tell for “it will blow up in your face but you should be happy about the blow up, because it didn’t mean to do you any harm!!”. Here’s an illustration, too, some typical result of the made with love approach.[↩]

This report brings to you the latest news from the lively Euloran development grounds: the GUI is shedding code and growing in usefulness, the Core adds to its services the packing and unpacking of all user actions known so far, the Data cache refuses to be led astray into unnecessary sync swamps and gets its responsibilities right, while overall all three parts arrive at a clearer way of working well together and working well apart, providing what’s needed for others but minding otherwise their own business at all times. This last part of “minding their own business” took a bit of thinking over those past few days, as the newly added user actions didn’t yet have a clear place of their own and it’s precisely the clear and fitting definition of “own business” for each component that makes or breaks the whole: do it right and everything fits afterwards quite “efortlessly” or do it poorly and then you’ll fight at every step to fit all sorts of square pegs into round holes (and rebuild the swamps, too, as a result of that sort of mindless fight).

To describe the whole thing, it’s clearest (and not too long) to start from the beginning: Eulora’s client has currently implemented 2 main components, namely the Core and the GUI. The responsibilities of those components have been defined initially at a high level only, as the details were not yet clear. That initial definition got gradually more detailed as I implemented more and more of the actual communication protocol but broadly speaking, the original scope is still valid: the Core is responsible for handling *all* aspects of communication with server, from network data packing and encryption to actual logic for data acquisition and storage; the GUI (as stated in its name itself) is responsible for data presentation to the user and handling all user interaction.

While the above high level view is clear enough as it is, the trouble with going into the more detailed, concrete user interaction is that its very purpose is precisely to *change* the data so carefully acquired by the Core and so neatly presented by the GUI. Add to it that any user actions in the game are more accurately defined as *attempts* to change the data, with no guaranteed outcome until and unless the server actually changes the tiniest bit of the game-world in response to them and it would seem that those user actions are indeed straddling most uncomfortably the responsibilities of both Core and GUI: get the action from the user (GUI), send the request to the server (Core) but also change the data already so that the user promptly sees the effect of their action (Core *and* GUI?). At which point, the reader familiar in the slightest with the PS coding swamps might recognise that old pattern of “all GUI elements require a connection to the server and direct knowledge of message types.” Because indeed, it can easily *seem* like a …solution of sorts, except it’s of course no solution at all but simply the path of least resistance and even less reflection: it “seems” and therefore it is, why bother with anything else at all. Well, to keep this short, I’ll note only that I’ve been toiling for quite a few years precisely cleaning up the results of others’ even *more years* of following that path of least resistance.

The change to data as result of a user action is further problematic in that any change done by the client is essentially a guess: at best it gets confirmed in time by the server and therefore all is fine but at worst it gets undone (while *other* things may change too!) and that brings with it the potential further invalidation of all sorts, even of later user actions! Quite the thorny problem to handle, as any synchronizing problem ever is. So the naive approach to handling those thorns goes (again!) the route of yet another part of the PS swamps: we’ll effectively mark data in the cache as “dirty” or “clean” and then go back and forth and over it all to attempt sync with the server and to handle all possible cases that are not even all that clear in advance, since they can’t possibly be. For the most obvious trouble, there is no guarantee as to *which data* changes as a result of any given action so going this silly route of marking dirty data is at best a pretense to solve the problem but certainly no solving it at all. So no, naive doesn’t work any better than lazy above did but it serves at least to highlight more clearly the root of the whole trouble, namely that there are in fact and inescapably TWO data caches on the client: one is indeed the explicit data cache that is held by the Core but the other is the implicit data cache that the GUI keeps in the graphical engine itself! There is no way in which the GUI can show a persistent representation of data without having therefore a cache of that data and as a result, the GUI can’t shirk taking on the full responsibility for the *local* data cache where it can make whatever changes it wants, without however expecting to have any direct access to making changes on the authoritative data cache that the Core maintains.

In a nutshell, the Core aims to maintain its data cache as closely as possible to the server’s view of the world, without caring at all about anything else, while the GUI aims to maintain its data cache as a reasonable guess of the world essentially: as responsive as possible to user actions and as close as possible to what the Core provides. This means that there is really no need to mark some data as dirty and some as clean in either of the two data caches: the one in Core is always and by definition as clean as the client can ever get; the one in the GUI is at best a fresh copy of that in the core and at all other times a… guess. The Core will regularly refresh its full data view by asking the server for a World Bulletin (and then following up through the world hierarchy as relevant), while the GUI will regularly refresh its full data view by asking the Core for what is in view at any given time. Whenever a user action happens, the GUI will promptly provide to the user whatever feedback it can and otherwise it will simply ask the Core to communicate that action to the server. There’s no need for anything further really: whatever the result of that communication, the changes (if any!) or the undo of attempted changes (if any!) or in other words whatever effect the action has or doesn’t have will be obtained anyway as part of the regular refresh of the data done by both the Core and the GUI on their respective caches.

While the above general principle works for all user actions, there are indeed some that are easier to handle than others. In particular, movement is quite apart from the rest, as it’s basically a “continuous” sort of action that moreover needs to have an immediate effect shown to the user. So the GUI will have to balance here the need to synchronize the player’s position with the server to avoid annoying abrupt relocations and the need to keep the user’s costs low as all messages sent to the server have a cost and nobody will be all that happy to use a client that racks up huge costs just for moving about the land. Nevertheless, the great part in all of this is that it’s all clearly and entirely the responsibility of the GUI and so it can be all contained in one single place and none of Core’s concern. The less than great part in all of this is that the actual movement part in the current GUI is still afflicted to some degree by planeshittism ¹ and so it will still take some work to figure out a way to make this work, preferably cutting out or at least avoiding that remaining bit of swamp.

Other than the above specific trouble with the movement, there is still some work to be done to implement in detail everything needed for all the other, more straightforward actions. For now and mainly as a basic test, I’ve implemented on the client side just the simplest of them all, the “explore” so that I could confirm indeed that the whole approach works: the GUI reacts promptly to the user command and asks the Core to send the request to the server, the Core packs it correctly and sends it, the server correctly unpacks it and recognizes it as such. For that matter, I’ve implemented already the packing and unpacking (+tests for them) for all the actions, so the next steps will focus specifically on the higher level part of this and first in line, the clientside required bits and parts for performing those actions.

1. Without even counting all the parts that have been shed already in this area, there’s still a psCharControl and otherwise a psLinearmove that does the actual calculations and heavy lifting but also a psMovementManager that can anyway “manage” only ONE actor at any given time and through a tangled web of back and forth calls from actor to manager and the other way around as well as from other parts to both actor and manager or to actor through the manager as well as to the manager through the actor – the usual PS “style”, really[↩]

There’s no other title fitting this. Here’s the priceless context for the question above, context worth not one thousand but 100 000 lines of open source code, at the very least:

The above is the amazing result of trying to make use of all those psSlot and psSlotManager and pawsManager with their drag-and-drop wonder and marvel functionality, a true crowning achievement and glory of open source development. I ask the bloody “manager” class to drag something across the screen, as it claims it does and as a result it… breaks everything else pretty much, as nothing really updates anymore and the thing leaves a trail wherever it goes. But all is well, I’m sure, at least according to the manager and to everyone else working very hard and tirelessly and wonderfully and so on ¹.

As I am apparently still naive enough to try and debug even the above sort of madness, I ended up in short order following a back and forth web of calls that are increasingly bringing to mind the way chaotic systems tread their path, ever random when it concerns the very next step, ever building nevertheless the same known shape in the end, as predictable as it can be. To give a clear view of how this goes, here it is: the widget calls the manager and the manager calls then the mouse class that calls back the widget that calls its parent class that calls back the manager that calls -at another time- the mouse class that calls…

Fortunately, those days I get at least faster out of such naivety and optimism and so I stopped just about there and didn’t waste any further time with it but looked instead at some way to do it more directly. I suppose by now it’s not surprising that all that crazy web of shit for “drag and drop” was anyway on top of and to the side of a somewhat less crazy “move with mouse” and then it turned out that even that was spurious and in fact the core class of ALL widgets in that bloody gui even had a method specifically for …”center on mouse” sort of thing – and it even worked! So I made therefore my own “drag” as I had made my own prototype inventory window and my own prototype console overlay and my own seedling for the rest and let the many managers rot and fester in there unused and increasingly cut away from everything until that day when I’ll finally get around to delete the whole mess too and there won’t be any difference other than having suddenly a much smaller client that is however way more useful. At any rate, as a result of this most recent adventure, I stand corrected in my initial opinion that there might still be at least a tiny amount of utility in all that PS code – there isn’t, there never was, there never can be.

As to the current status of those windows and overlays on my list: I have now a perfectly working way to drag stuff about (not yet to drop it but I don’t expect that to be a huge problem, seeing how I am not going to touch any of the PS shit for it, not anymore), as well as working prototypes for both “Console” and “Contents” windows, with a few commands wired in already mainly for testing and poking that Contents view. Everything in those is created from code and without any xml in the loop so that the Contents view for instance can easily create as many slots as one wants, there is no limit of any sort anymore. The logical thing is probably to simply create slots *as needed* and without limit but for now I disentangled (and cut and wrote anew) enough of that underlying widget that has scrollbars – the scrollbars are useful but the design of it otherwise required a bigger hammer to bend into something usable in the least. As you might notice, I even gave in and added arrows for the scrollbars! In any case, all the images and graphics and colours are just for testing for now and I’ll gladly use better ones /let someone else design any window whatsoever. For now, here’s how the prototypes look like (in order: a test with adding and replacing stuff in the contents view, based on id of the *underlying* object instead of id of slot and other madness; the successful dragging of ‘shrooms with icon and everything else):

For the next steps, there would still be first a bit of cleanup around those latest parts and assorted cuts made for it. Then I’ll have to see if it makes perhaps more sense to get back one round to adding more working parts on the data side + communications and then let that drive any further development of the GUI itself. At least I’m now quite satisfied that I’ll be able indeed, one way or another, to add to the GUI what may be required, even if some parts are very likely to throw some more wtf of the sort illustrated in the very introduction to this and eat as a result rather more time than I’d like to spend on them.

1. It could never not be great and wonderful anymore either, there is no such thing as something *not* being well, nowadays it’s either great or otherwise forgotten or simply not mentioned for it’s surely the mentioning that is causing the problem in the first place, obviously.[↩]

Until such time that you make any buttons of your own at least, it’s now all settled, clear and without a choice: on all Euloran soil, it will really be my buttons you’ll have to push ¹ and my views you’ll have to use and my winPAWS ² that you’ll look at. For there was/is barely anything useful in all those 100 windows that were each terribly important on their own, each with their own layout xml file and own hand-rolled loader and own parser and own further numerous attendant misfortunes that are inevitably linked back to that mighty struggle of trying to have a singleton manager without admitting however of having any *specific* manager. It’s a riot reading the code and the famous “software patterns” and even all the Object Oriented paradigm in this obvious key. It’s even funnier now as the end of the swamps is otherwise in sight and as the intelligent idiots are out of my way and staying there in their narrowly delimited circle where they are taking over the world, I’m certain, only it’s each of them taking over their own world but that tiny detail is entirely unimportant and can’t possibly matter, can it? They are after all solving problems with code and moreover solving “problems” picked and ranked based first and foremost on what they are familiar with and the sort of solving that they have done before since that has to be the best way – the more independent, upright, sane and intelligent way. Not that this has anything to do with it being also the only way that is still in the least open to them, no, absolutely not.

Back to that fast growing life of Eulora, the dive into the full depths of PAWS was essentially successful if not lacking in crashing, segfaulting and downright maddening experiences: the whole thing is not unlike a carefully constructed castle of sticks that stands for as long as it’s untouched and then unravels entirely at the merest movement of air around it. There is in fact already a set of “basic” elements and those 100+ windows are on top of that but even those “basic” ones are at times anything but basic. The most screaming out loud example of this would be the humble title of a window/widget/whathaveyou – in order to show *any* title (as in text, a few letters, nothing more), the “widgets” require a border and that requires buttons and styles among other things and those in turn require preferences and all sorts that further require the requirements of requiring required requirings… Why does the title part require buttons or borders or all that? I suspect it’s because someone was solving there with his code a lot of problems that I don’t have! So I took instead the smallest thing that I could find, trimmed it further and added it directly to the core “pawsWidget” class so that any damned thing CAN now show some text as title without requiring anything more than the… text itself! Shock and horror, I know, just look how violent I am with titles and buttons over here!

Moving paws on the path further, I started to simply write the code for some generic “views” – the sort of windows that can be used for a purpose and otherwise displaying whatever information is relevant. At first, this ran fully into all sorts of intricate weird: the show that won’t show, the click that won’t click and other such crazy stuff from working with the castle of sticks where everything interacts with everything else and that results in a whole ritual -where order of steps is important, too!- necessary for achieving the tiniest effect. Disentangling all that was no pleasure but it’s still the fastest way I know of to get to the point where something useful can be done with the whole mess and it worked with this mess as it has always worked with any and all messes I ever encountered. As a result, I am quite confident now that I *can* make my views, windows and overlays in a reasonable amount of time and *without* a whole lot of clutter sticking to them.

For the initial practice, I first cut to pieces that “bar” at the top and then put back together only a skeleton of it, as an overlay that has so far only the quit and help buttons – and those are my buttons indeed, made through my code and in a more direct way than the original entangled messes. The reason why the whole bar itself is still there as a thing at all is that it holds also quite a bit of the keyboard interaction part so there’s more that needs to come away before it becomes fully clear if it comes off entirely or not. At any rate, otherwise I changed that pawsManager to actually act as one and therefore I have now in place the building blocks to allow the desired approach of “one window at a time and otherwise overlays”. This also cut a lot of crap dances around all sorts but mainly in the sense of not using a lot of code, not yet in the final stages of deleting and discarding it too. For illustration, here’s the new “menu bar” overlay and the confirmation window that a click on the Quit button made appear:

Once I had those buttons showing and working as I wanted them, the next step was to add various bits and pieces that arguably come in handy and could at least build on what I had so far. So I enhanced that minimal “helpwindow” of last time, as it’s in my view the prototype for a generic view aimed to show structured text ³: it has now a title and there are also functioning scrollbars that use Eulora’s own icon as tracker – I rather like them; the +/- signs for opening/collapsing a topic get shown now with their own icons in the skin.zip file; there’s also further experimenting making sure that both background and text colour can indeed be set as desired:

I’ll have to note here that the above is still not giving a damn about stuff like “borders” and stuffing buttons everywhere, from title to sidebars and anywhere in between. To be honest, I personally prefer by far the transparent and minimalistic windows and I make a half-hearted exception only for text really (as it’s rather easier to read when it’s the traditional black on white or gray on black). So if you’d really, really want those windows to have anything further, please say it sooner rather than later, as left on my own I doubt I’ll find much reason to add even “title bars” as separate things, let alone stuff like border-this and border-that or decoration-here and decoration-there.

For further practice with making whole windows really from scratch rather than starting with a previous overgrown thing and cutting thorns at all steps while still remaining with a crooked trunk, I made also an “Info” view that is meant to show an image + name + description for anything in the world: it’s barely a page of code and it even sets its size depending on how big your screen/eulora is, aiming only to maintain the ratio of its minimal size. The image gets indeed re-sized to fit exactly the space available in its side of the whole view so that’s perhaps not ideal but it can be changed for sure. To fill it with something for testing purpose, here’s the very info on Eulora itself, first in the transparent version and then with the black background for that half-hearted concession to showing text on a non-transparent background:

With the above done, my current list of generic views (aka windows+overlays) reads like this:

1. Command line – TO DO. This is in my opinion crucial as it’s meant to be the game’s console basically, the only place for the player to enter commands and thus be able to do anything, whether there is a button for it yet or not. This would be an overlay, I should think.
2. Confirmation – prototype DONE. This is a very basic yes/no type of window, aka one question + 2 buttons, modal thing. The current prototype is perfectly and fully working, if entirely transparent. The wiring of the buttons is now mine too, entirely circumventing the several layers of passing the buck that used to be “the way this is to be done”. I don’t know if there really is a need for any sort of other “view” as such – if it’s just a text message, it can still be shown either directly on the screen (that fading sort of thing, dropping down as it faded) or otherwise in the console/command line thing above, I guess.
3. Waiting – prototype DONE. This is meant as a placeholder/information for when the game is not available/unable to display the world as such. It simply takes over the whole game window and it displays an image + a label/text at the bottom. The prototype is fully functional and even wired in its correct place aka displaying at the start while the client is waiting to obtain from the server the most basic stuff such as who am I, where am I and what does this world even look like. I kept that boceto drawing as I quite like it (even more so than the “splash” thing).
4. Info – prototype DONE. This is meant to show image+name+description (or any subset of those) of anything in the world.
5. Contents – TO DO. This would show everything that is “inside” any given object in the world. As such, it could show the contents of some container but equally well the player’s inventory or the equipped items or a storage or the contents of an exchange of any sort. In my current hazy view of it, this will simply show as many “slots” as required, each with their own icon + text (e.g. stack count and quality or similar) + tooltip (to show the name of whatever is in there).
6. Exchange – TO DO. This would be made out of 2 Contents essentially, with wiring as appropriate for whatever specific exchange is shown at any given time. Basically the “inputs” would be the 2 items whose contents are to be shown on each side of this view. In my opinion and just as an example, this can even work to provide a GUI for activities such as “equip” since it’s an exchange – stuff from inventory being moved into equipped and the other way around.
7. Management/Ownership – TO DO. The details of this are not very clear to me currently but as I gather that there will be various types of managing involved (e.g. jobs or land), I’ve added this to the list as a generic window that can hopefully be made to cover adequately the management of whatever is needed. I’d say there is still time to figure out this in more detail and there’s no rush – it’s on this list as a type, not much more so far.
8. Skills/Self – TO DO. This is quite hazy too but what I mean here is mainly a view that is able to show also things that require something other than image or text: perhaps bars/percentages or the like. I am not fully clear on this part yet but there’s certainly time for it to clarify.

As next steps, I would push this a bit further still to fully transform that “helpwindow” into its intended generic structured content view and make otherwise at least a prototype of the Console/Command Line and Contents generic views. The Contents one is quite important because it means figuring out all that slots business and dragging stuff from one place to another, which is another potentially big chunk of this. Hopefully as part and parcel of that, I should be able also to finally delete another pile of useless code, as it ends up entirely stranded. In terms of specific GUI bits and icons, the more I work with this, the fewer of them I want in there so do let me know if there are *any* parts that you absolutely want in there as otherwise I’m afraid I might easily end up ditching just about *all* of them and have the whole “skin” consist in something like a plus, a minus, a quit icon, a help icon and a tracker for scrollbars, not much else really. Of course, anyone can otherwise ship to the client any .zip file with anything at all but the default client will not use anything else and keep those windows as minimal and as invisible as possible, by the looks of it.

Other than the above, let me know also if the approach of “generic views” makes sense to you and whether you’d like any others added to that list, even if just as general types, to be perhaps fleshed out (or discarded) later, as everything gets into more concrete shape.

1. Heh. I know.[↩]
2. Well, they’d be windows except when they are overlays and otherwise they are made still on top of and with various bits of the paws that apparently would really, really want to be of some use, if only it hadn’t been so thorougly misdesigned and abused by means of pointerfuck…[↩]
3. By structured text I mean here text that has a hierarchy of parts that can be shown/viewed separately and allow navigation through a tree of contents.[↩]