Alright, I got a question then. Why can't finished products utilize the interface stuff like labels? Labels can be customized a bit, including run-time with the win...() commands, plus they can be replaced with images.

I feel as though interface objects are much easier to control with different screen resolutions than screen_objs though.

Just trying to gather some input to see what everyone else is using and why.

GreatPirateEra wrote:

You'd be going through a lot of trouble customizing labels, buttons and whatnot. The interface bars are absolutely atrocious. The grid is horrible. It's limiting in that everything needs to be rectangular unless you're willing to make everything by hand and use them as images in the interface.. but if you're going through all of that trouble, you might as well just go with screen objects.

Yeah, that's what I was basically thinking when I made this post. Mind you, the only reason I'm using this skin-based interface is because it's from an older project that I am revisiting. I guess I'm just going to switch over to screen_obj since I've had better experience with customization. I use a grid-based system for screen_obj, so moving boxes and such would be somewhat easy if I group the box pieces together (ex; inventory, stats, etc.)

I guess I just needed someone else to tell me the skin sucks too. :\

Have you not heard of anchors?

It *really* depends. Screen objects are probably a great way to go about getting consistent information from the server to the client, but interface elements do have their advantages in that they can be manipulated on the client-side using Javascript from within a browser.

The browser ?winset/winget and .winset and .winget commands allow you to create responsive client-side interfaces. This is not available if you choose to use screen objects.

The problem with interface elements is that you lack positional control and the ability to do quite a few things that modern game UIs expect, like providing resize handles for anchored elements, or doing partially-transparent anchored UI elements. You can't anchor windows inside of one another either, and you can't control the resize handle styling, scrollbar styling, etc.

With screen objects, simple things like maptext scrolling or for that matter, dynamic layouts using maptext width/height accounting are impossible without a ton of brittle server->client->server workarounds. Not only that, but for retro games that use chunky pixels, it's very difficult to ensure that interface elements' visual appearances properly update with the overall resolution scaling of the map elements. This creates a very bad experience for your regular developers, and a lot of busywork for your power users.

BYOND's User Interface for game development on both the interface and onscreen UI stuff is really showing its age, and there are glaring holes in the implementation that make it completely impossible to do many things that modern game developers and modern players expect from even the most simplistic games.

Top all of this off with the fact that we're tied to IE, have no ability to inmix rendered HTML content into the map, and lack the ability to control IE's atrocious anti-aliasing and interpolation without asking the client to muck around with their registry, and you have an engine whose UI is one of the single worst chores imaginable, completely and totally alienating the ONE niche of game developer that would actually find the engine's other limitations appealing: those interested in 8 and 16 bit fetishism.

Devirian wrote:

Ter13 wrote:

The problem with interface elements is that you lack positional control and the ability to do quite a few things that modern game UIs expect, like providing resize handles for anchored elements, or doing partially-transparent anchored UI elements.

If you pull the size of a maximized window, you can use that as a reference point for positioning for pos. Gives you a lot more control for positioning elements.
If you really wanted to get into it you could probably mess around with the maximized window's size to create a formula for font sizes in labels.

However it is a lot of work when you could just use screen objects.

Actually, I think I was overly vague there. What I mean by the lack of positional control is more about user interface management and control over information presentation at a glance.

- I can't restrain a subwindow to show on top of a parent window.

- I can't restrict a subwindow's position to only be movable inside of another window.

- I can't allow the user to resize the window without windows' ugly resizing handles.

- I can't disable the default window without triggering options and messages box showing up --This means that prompts can be ignored and further input actions can trigger further prompts to show up when an interface prompt is demanding exclusive input.

- I can't manage focus traversal by detecting when the client has changed focus to another window.

- I can't detect when a window has been moved, and I can't disable the ability to move a window.

- I can't easily anchor a window to another window in any way.

- I can't change the default window.

- I can't control the cursor graphics consistently between ui element types.

- I can't ping the location of the user's mouse cursor in order to create custom tooltips/popout menus.

- I can't customize any kind of scrollbar whatsoever without writing my own custom UI in HTML5/Javascript (I've done this. It always has input flow problems)

- I can't retarget macro controls from one element to another without risking input loss due to latency.

- I can't consistently ping the keyboard state from the server.

Every solution for the above problems requires a total rewrite of the native skin system using Javascript and HTML5, which results in some nasty, messy hacks.

W32-based skin elements was a mistake that we're stuck with. Tom should have never adopted W32 as a basis for our client-facing UI elements. It's ugly, inflexible, and our implementation is poorly exposed.

Honestly, life would have been a lot better if everything in 3.5 and 4.0 exposed a client-side limited script interpreter that allowed us to draw elements and process input commands on the client-side without involving W32 or Internet Exploder at all.

The webclient is a step in the right direction, but for a number of reasons I have been unable to adopt it.

Someone needs to go and make a decent library to easily handle UIs for BYOND.

Almost every game needs a UI, but very few BYOND games have them (well not good ones). They're a pain to make too, especially when it comes to things like moveable/resizeable windows. I've tried it, and it's harder to do than it looks and my end result was something that sort of worked but was still lacking features I didn't even know how to begin implementing.

I'm surprised no ones tried tackling it yet, good UIs are something games around here desperately need.

I swear, I've given up making more games than most people have started just because making UIs is the worst thing ever, but something that has to be done.

The Skin Interface desperately needs an update because indeed it shows its age, we need better looking stuff and more features to it.

Skin interfaces should just be dropped. Anything they can do, a simple browser can do better.

Agreed, if it weren't for the ugliness of dealing with dropped macros and trying to drag a browser element, or layer a browser element over the map and have it be partially transparent in some parts.

I don't know about other people, but after designing about 9 billion UIs too many I just got lazy. Now all I do is make a map, place the UI objects I want on said map, then to display the UI I just loop through objects on a specific part of the map and display them on screen (for objects that change, like text for stats and so on, I just have a proc that is also called to do what is needed).

It's maybe not the best way of handling a UI, and it doesn't allow me to create very flexible UIs (cannot be moved, scaled and so on), but it's quick and easy to do.