Interface vs client.screen in Design Philosophy

Page: 1 2 3 4 5
ID:151906
 
Oct 20 2008, 7:13 am
I have been wondering for a while now what people out there are thinking about this subject.
What do you think is better to use, the new Interface, client.screen (on map display), or a mixture of both?

I'm actually unsure about performance issues and stability when it comes to comparing an interface and client.screen... is there anyone to enlighten me?

A pro point for using the interface is that every customer can change things and set up things as s/he likes them best.

From a programming point of view, I'd say using the interface kind of forces you to use modular concepts, so that might be considered another pro.

Now the question is, how would you solve the following tasks:

Title screen
a) as pane (img background and buttons), sharing and switching a child container with the map at runtime
b) as seperate area on your map or as client.screen "overlay"

Status bars (e.g. health bar)
a) as label / grid
b) as client.screen image

Status effects (e.g. poisoned)
a) as clickable grid
b) as clickable client.screen object

Quickbar (e.g. Attack / Cast Spell XYZ)
a) as drag&drop and clickable grid
b) as drag&drop and clickable client screen object

Equipment (e.g. Armor / Weapon / Shield)
a) as drag&drop and clickable grid (around a label)
b) as list in Info

Communication (e.g. say)
a) as inputs with preset comands in a Tab
b) as verbs in Info / as Macros/ as type in by user

Communication with NPCs
a) as searching via findtext to find user input directed to an NPC
b) as prompt / input

Macros
a) as Interface macros
b) as macro in client.script


I'm kind of hoping for opinions and creative input!
Thank you in advance!
#1 Oct 20 2008, 9:05 am
I generally always go for interface elements rather than client screen elements where possible. The reason for this is that I find it easier to lay out and interact with elements on the interface, and that changing client.screen means that the whole list is resent to the client so you end up with a fair bit of network traffic. Optimisations to client.screen access can be made (such as by operating on a list rather than directly on client screen, and then setting client.screen to the list once you're dong with changes) but for fancy animations and such like it still isn't fast enough.
Interfaces also allow arbitrary-sized elements more easily than screen objects.
#2 Oct 20 2008, 11:39 am
I think client.screen is good for things like buttons, where I want things to be easy for the client to macro. For everything else, the interface controls have major advantages.
#3 Oct 20 2008, 2:02 pm
Title screen
a) as pane (img background and buttons), sharing and switching a child container with the map at runtime
b) as seperate area on your map or as client.screen "overlay"

Here it's a mix up really. A will work nicely when 430 comes out (there's a bug that hurts these setups at the moment), but b is also pretty good.

Status bars (e.g. health bar)
A hands down one 430 comes out; there's a new bar control specifically for this (how would you use a grid for this, by the way.

Status effects (e.g. poisoned)
a) as clickable grid
b) as clickable client.screen object

Wut? You mean attacks in general? If so, A, for simplicity mostly.

Quickbar (e.g. Attack / Cast Spell XYZ)
a) as drag&drop and clickable grid
b) as drag&drop and clickable client screen object

Another mix up here, it's slightly more complicated to do A if you want exact positions.

Equipment (e.g. Armor / Weapon / Shield)
a) as drag&drop and clickable grid (around a label)
b) as list in Info

Grid, hands down. Games should try to phase out info in general, really.

Communication (e.g. say)
a) as inputs with preset comands in a Tab
b) as verbs in Info / as Macros/ as type in by user

A, it interrupts game play less.

Communication with NPCs
a) as searching via findtext to find user input directed to an NPC
b) as prompt / input

B, it requires less overhead and sounds simpler. I prefer to limit the players talking options, though.

Macros
a) as Interface macros
b) as macro in client.script

A. A is simpler, and B is an older feature.
#4 Oct 20 2008, 2:34 pm
client.screen gives you a lot more freedom, but takes more time to code/test/perfect.

Lag isn't a problem with client.screen if you do it correctly. I like to create every single one of my screen objects when the world boots up, and sort them into different lists depending upon what part of the interface they are in. Then opening closing a window at runtime is as easy as going:

Open: src.client.screen += src.Inventory_HUD
Close: rc.client.screen -= src.Inventory_HUD
#5 Oct 20 2008, 2:47 pm
In response to SilkWizard (#4)
I'd actually go so far as to claim that all repeated interface elements absolutely must be handled globally like this, for fear of breaching the object limit otherwise.
#6 Oct 20 2008, 2:58 pm
In response to SilkWizard (#4)
SilkWizard wrote:
client.screen gives you a lot more freedom, but takes more time to code/test/perfect.

Lag isn't a problem with client.screen if you do it correctly. I like to create every single one of my screen objects when the world boots up, and sort them into different lists depending upon what part of the interface they are in. Then opening closing a window at runtime is as easy as going:

Open: src.client.screen += src.Inventory_HUD
Close: rc.client.screen -= src.Inventory_HUD

Bump for tutorial reminder!
#7 Oct 20 2008, 4:19 pm
In response to Jeff8500 (#3)
There are more than two solutions for some number of those examples you produced and some are a matter of opinion (specifically the Equipment label).
#8 Oct 20 2008, 5:05 pm
In response to Tom (#6)
Tom wrote:
Bump for tutorial reminder!

That and a video, coming right up :)
#9 Oct 20 2008, 5:11 pm
In response to Jtgibson (#5)
Jtgibson wrote:
I'd actually go so far as to claim that all repeated interface elements absolutely must be handled globally like this, for fear of breaching the object limit otherwise.

Indeed. Besides, there is no reason to run more stuff through the cpu in the middle of the game when you can get it out of the way when the world boots up.

In both Proelium 2 & AA I have two different types of screen objects that are created when the world boots up... what I call "World HUD Objects" and "Player HUD Objects". There is only one set of World HUD Objects that everyone shares. For stuff that needs to be unique to the player because it changes on the fly (an onscreen status bar, etc), I create 70 or so sets of Player HUD Objects that are assigned to the player when they log in, then put back in the pool of available sets when they log out.

Anyway, like Tom says, I need to finish up a tutorial on all of this to demonstrate the concept in action to people.
#10 Oct 20 2008, 7:44 pm
client.screen is really only useful if you need to display something to a specific client directly over the map. For example, a selection box or fog of war. If you can accomplish your feature without covering the map, I'd suggest not using client.screen. There's no real reason a HUD has to be made up of screen objects, since most HUDs don't actually cover the map, but are instead displayed below, or beside it in its own screen space. A grid system or a more complex interface can make a HUD that's just as functional and aesthetically pleasing as a HUD system composed of screen objects. In the past, we were limited to only using screen objects if we wnted a HUD, but now that 4.0 is out and we have all these interface options to choose from, there's no really good reason to continue using screen objects for HUDs.
#11 Oct 20 2008, 8:07 pm
In response to Xooxer (#10)
Xooxer wrote:
there's no really good reason to continue using screen objects for HUDs.

This isn't true... there is no single "best way" to make an interface for a game. Some games are better suited to 4.0 style interfaces, some games aren't. Creating your own HUD with screen objects allows much more customization and unique functionality. As cool as the interface stuff in 4.0 is, it certainly doesn't come close to replacing what you can do with screen objects.
#12 Oct 20 2008, 8:26 pm
In response to SilkWizard (#11)
SilkWizard wrote:
Xooxer wrote:
there's no really good reason to continue using screen objects for HUDs.

This isn't true... there is no single "best way" to make an interface for a game. Some games are better suited to 4.0 style interfaces, some games aren't. Creating your own HUD with screen objects allows much more customization and unique functionality. As cool as the interface stuff in 4.0 is, it certainly doesn't come close to replacing what you can do with screen objects.

I agree with this. I think that, done properly, a screen-object based interface looks more fluid than one based on external interface components, and is probably more along the lines of what gamers expect. On the other hand, the 4.0-style components are easier to work with and allow for efficient operations that would be pretty challenging through the map/screen (for instance, creating a color selector via a browser component, or pretty much anything involving text input or output). So there's no reason to restrict yourself to one style.

On a related note, we've been talking about expanding the graphical capabilities of BYOND in a manner that effectively merges these two systems. While it's doubtful BYOND will support multiple maps anytime soon, it may very well be possible to support multiple surfaces for screen-drawing. So you might have the ability to indicate a particular control when outputting your client.screen, giving us the best of both systems.
#13 Oct 20 2008, 8:31 pm
In response to SilkWizard (#11)
Can you give a good example of how screen objects can accomplish something an interface can't? Aside from being able to hover directly over the map, I can't think of anything you can do with a client screen you can't do with the interface elements, with respect to HUDs.
#14 Oct 20 2008, 8:43 pm
Schnitzelnagler wrote:
From a programming point of view, I'd say using the interface kind of forces you to use modular concepts, so that might be considered another pro.

Interfaces are also more in your control and can be more efficient. Consider a classic grids vs info controls comparison: grids, you can control more effectively how everything is displayed, and you control exactly when they are changed or updated. Statpanels however, have a pretty much hardcoded set of 'rules' in how they behave in displaying given data, and also always update periodically internally, every few ticks, which is rather inefficient and impossible to change to update only when needed (ie a value is changed). The only thing you can do is make them update in a slower rate (by a 'technicality' of using sleep() in Stat()) which of course isn't so desirable.

client.screen also similarly has hardcoded behavior - but, it does have its uses for playing with atoms in ways that could be messy with interface controls. Generally speaking however, interface controls are more controlled by, and up to you. This also means you ultimately have more work to do, though. But an important bonus of sticking to interface controls is uniqueness - let's face it, most interface-less games are 'bland' in the sense that they all partly look like the same game - if you have yourself a wee info control that uses statpanels to display anything with an output under it and the map beside, other than actual disadvantages your game just seems a 'yet another YOUR_GENRE_HERE game'. A nice custom interface can make your game really shine in comparison to others, since it gives it a unique appearance and usability (though it is actually susceptible to being stolen, but generally everything is).

Now the question is, how would you solve the following tasks:

Title screen
a) as pane (img background and buttons), sharing and switching a child container with the map at runtime
b) as seperate area on your map or as client.screen "overlay"

Probably b). I'd just have it as an inaccessible map area which the eye is moved to - since the "actual game map" doesn't need to be used while at the title screen, there's nothing holding you from using it. You could always use switch a pane, but it's simpler to simply move the eye to a location than mess with controls; possibly even more efficient.

Status bars (e.g. health bar)
Status effects (e.g. poisoned)
Quickbar (e.g. Attack / Cast Spell XYZ)

Grid/label. As others have said, you should try to keep HUD stuff off of obstructing the map. You also gain an advantage in that you're using up no atoms, so you're a little farther from the object limits...
This might vary though based on the actual purpose any of these holds.

Equipment (e.g. Armor / Weapon / Shield)
a) as drag&drop and clickable grid (around a label)
b) as list in Info

This is somewhat according to your personal preference. As far as I'm concerned, equipment doesn't even need to be continuously displayed and take space on the game screen - but opened on demand. Would probably stick to a grid.

Communication (e.g. say)
a) as inputs with preset comands in a Tab
b) as verbs in Info / as Macros/ as type in by user

Verbs... handier, and take less space (could even remove/hide in info control).

Communication with NPCs
a) as searching via findtext to find user input directed to an NPC
b) as prompt / input

a) is inherently rather crappy and probably annoying, so b).

Macros
a) as Interface macros
b) as macro in client.script

As mentioned previously, pretty much everything you can do via client.script can now be done considerably better through the interface editor. It has limited current uses - perhaps one is if your game doesn't have an interface control and you don't wish/need to have one, but even then this isn't so beneficial because you could always use a modified copy of BYOND's default skin. You could consider client.script partially obsolete, so whether to use it or not is an easy question.
#15 Oct 20 2008, 8:52 pm
In response to Xooxer (#13)
But being able to hover directly over the map *is* a powerful thing. This has to do with where the player focuses their eyes.

When I played World of Warcraft, I'd move my player and target frames to the lower middle of the window, right above my hotbars. This allowed me to get a central area where time-sensitive information was displayed, and allowed the rest of the screen to be taken up by view real-estate.

Part of being a solid programmer is being aware of the technical limitations of the resources you have at hand. The fact that a resource has a limitation doesn't mean its useless - It means use with care.
#16 Oct 20 2008, 9:15 pm
In response to Alathon (#15)
And? Is that all? So... it's better because it is close to the the viewing area? What makes an interface not close to the viewing area? I don't think that's a good reason to go with screen objects over, say, a grid in the same position.
#17 Oct 20 2008, 9:18 pm
In response to Xooxer (#16)
Xooxer wrote:
And? Is that all? So... it's better because it is close to the the viewing area? What makes an interface not close to the viewing area? I don't think that's a good reason to go with screen objects over, say, a grid in the same position.

Well, I think the main advantage is that you can really fine-tune the positions. For example, if you wanted to make an inventory screen that showed where on the body the corresponding objects were equipped. I suppose one could probably do this with a browser control, but it'd be just as difficult (maybe more so) and wouldn't look as good.
#18 Oct 20 2008, 9:25 pm
In response to Xooxer (#16)
Xooxer wrote:
And? Is that all? So... it's better because it is close to the the viewing area? What makes an interface not close to the viewing area?

It matters because my eyes don't need to move, thus taking my eyes away from the action. I don't see how the aesthetics of GUI design don't matter when discussing... GUI design. There are any number of books on this which will re-iterate what I've already said. The more pleasant the interface feels to use, the more naturally things are positioned in accordance to their importance - The better things will feel for the player.

The bar for UI's today is very high, and being able to go over the map alone is a great reason to be using screen objects. Interface elements and screen objects both have their own powers, pros and cons - I don't think its a good idea to so easily dismiss being able to render over the map, especially with pixel precision.
#19 Oct 20 2008, 9:30 pm
In response to Tom (#17)
Um... that's something grids can do, and is quite beyond what I'd call a HUD. A full body inventory is usually a full screen menu, but even if it is required to share screen space, there's a whole bag full of lag that says grids would be more player-friendly.
Page: 1 2 3 4 5