I've noticed stat panels have become less and less common use in BYOND, and that's understandable. I imagine that is the simplest, but least liked method. However. I am wondering what both the new standard, and the most commonly desired display are.
I figure grids is a possibility, but that doesn't seem much different from stat panels. They're only a little better. A HUD may be the likely standard, perhaps in menu form, who knows.
So when it comes to stat display, what do you find the most appealing? and what stat display method do you see the most often in BYOND games? Hopefully this reveals what the 'best' style is.
Apr 15 2012, 9:46 pm
|
|
LordAndrew
   |
Personally I prefer good ol' on-screen HUDs, like how NEStalgia and Regressia have. Grids and things like that are all pretty fancy, but from what I understand the Flash client won't support those sort of elements. Don't quote me on that though.
|
I haven't seen Regressia, but NEStalgia certainly has that classic game appeal. I've heard the same thing about the Flash client, but they may find a way to make that stuff work. Who knows.
Huh, that approach is pretty nice. Looks more professional than what I am use to in BYOND. I definitely prefer that look over what I've seen from stat panels and grids so far, though. I remember a while back I was really impressed with this but that image actually looks a lot better to me as far as stat displaying goes. | |
Some of the better known games such as Casual Quest, and as LordAndrew listed, NEStalgia and Regressia use HUDs. I actually prefer this method of displaying information. With the addition of on-screen text, I feel that HUDs are less clunky looking, and to use, than the interface elements.
| |
with the advent of atom.maptext, i believe "HUDs" will make a resurgeance. making something polished and pretty in a full .dmf interface is a lot of effort and relatively limited in the types of effects that are possible when compared to what is possible in a "HUD" interface.
| |
It definitely seems like on screen objects might be becoming the new standard. Most of the best games seem to be utilizing them as well.
The only thing that concerns me with using them is the empty space that is left around the map. Any player with a resolution larger than 1024x768 will have a lot of empty space left around the map when the game is in full screen mode. As far as I know resolutions larger than that, and playing in full screen mode are each very common. Both even apply to me when I am playing games. So far the best way I know to deal with this is simply using a good background image to fill out the background around the map, but it can be tough to find one that looks good and flows well on full screen mode in multiple resolutions. This really makes me wonder how professional 2D multi-player games manage to handle full screen on all resolutions so well. I'm guessing they have some kind of way to stretch the map without hurting the graphic quality. | |
Toddab503 wrote:
The only thing that concerns me with using them is the empty space that is left around the map. Any player with a resolution larger than 1024x768 will have a lot of empty space left around the map when the game is in full screen mode. As far as I know resolutions larger than that, and playing in full screen mode are each very common. Both even apply to me when I am playing games. You can make the icons stretch to fill the map control without preserving their aspect ratio, so you don't have black areas around the map. You can also resize the window to force it to maintain the aspect ratio of the view size or only give the player a few options for the window's size (ex: 100%, 150%, 200%). You can also change the view size to make it more closely fill the window based on how the player sized the window. Though, for many games, you wouldn't want to increase the player's view size. | |
Ah, interesting. I hadn't heard about that stretch trick yet. Does it eliminate the blurred issue regular stretching usually tends to cause? In my experience a lot of detail is lost in the stretch, though that may depend on the screen size.
I've actually been looking into using the on-screen object method more lately, and it's pretty nice. The only tough part to them seems to be inputs, and choices that involve displaying a long list of players like you usually would in alerts. I'm thinking input can be handled easily by simply moving an input around to the locations you need whenever it becomes visible, but not sure on an alternative for displaying choose-able players yet. Grids are an option, but kind of defeat the point of avoiding them on everything else. | |
Toddab503 wrote:
Ah, interesting. I hadn't heard about that stretch trick yet. Does it eliminate the blurred issue regular stretching usually tends to cause? In my experience a lot of detail is lost in the stretch, though that may depend on the screen size. Graphics are still stretched like they normally are (if normal stretching makes it blurry, this will too), but if you're maximizing the window graphics will be stretched anyway. I've actually been looking into using the on-screen object method more lately, and it's pretty nice. The only tough part to them seems to be inputs, and choices that involve displaying a long list of players like you usually would in alerts. Some on-screen controls are easy to create, the HUD Groups library provides on-screen labels, buttons, textboxes, checkboxes, and radio buttons. Things that require more mouse-based input (ex: scrollbars) would be difficult to create because BYOND has very limited mouse input. I'm thinking input can be handled easily by simply moving an input around to the locations you need whenever it becomes visible, but not sure on an alternative for displaying choose-able players yet. Grids are an option, but kind of defeat the point of avoiding them on everything else. It could be handled easily with screen objects. Interface controls or the input() proc would be quicker (in terms of performance and implementation), but lack the personality and graphical consistency that screen objects have. | |
Forum_account wrote:
Graphics are still stretched like they normally are (if normal stretching makes it blurry, this will too), but if you're maximizing the window graphics will be stretched anyway. Makes sense. I guess it depends more on the graphics than the stretch. Some on-screen controls are easy to create, the HUD Groups library provides on-screen labels, buttons, textboxes, checkboxes, and radio buttons. Things that require more mouse-based input (ex: scrollbars) would be difficult to create because BYOND has very limited mouse input. Yeah, scroll bars aren't the best in terms of appearance anyway. I would imagine a better method would be to try and create additional 'pages' for selections. I.E: listing 5 players on 'page' 1, click on a number 2 to see 5 more, and so on; much like you would do on a website. Should be do-able in a game, if the designer works with it enough. It could be handled easily with screen objects. Interface controls or the input() proc would be quicker (in terms of performance and implementation), but lack the personality and graphical consistency that screen objects have. Well, at least there are more options than I thought. I suppose it just depends on the project, the HUD design, and the designers preference. | |
I'd prefer stats to be on a separate html pop-up. I never really liked that stat panel. Makes the game look homebrew, no offense. I just know there's a better way to code a HUD on byond.
| |