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!
ID:151906
 Oct 20 2008, 4:13 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.
| |
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. | |
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 | |
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.
| |
SilkWizard wrote:
client.screen gives you a lot more freedom, but takes more time to code/test/perfect. Bump for tutorial reminder! | |
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).
| |
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. | |
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.
| |
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. | |
SilkWizard wrote:
Xooxer wrote: 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. | |
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.
| |
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: 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) 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) 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) Verbs... handier, and take less space (could even remove/hide in info control). Communication with NPCs a) is inherently rather crappy and probably annoying, so b). Macros 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. | |
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. | |
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.
| |
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. | |
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. | |
Interfaces also allow arbitrary-sized elements more easily than screen objects.