Oct 21 2008, 9:45 pm
In response to SilkWizard
|
|
Kaioken
 |
Wow, talk about a snob. xD Think what you want. Though I'm also interested in hearing why you don't think your fancy inventory/equipment display system can't be replicated and done better through interface controls.
|
You see, the problem with this post is that "threatened" isn't a synonym for "annoyed" and "pride" isn't a synonym for "arrogance" or "hubris".
| |
Schnitzelnagler wrote:
Now the question is, how would you solve the following tasks: Child element on the main window, which will swap as necessary. Status bars (e.g. health bar) id:667990 located under the map. Status effects (e.g. poisoned) Represented on players icon. Be it giving the player a slight green colour or placing a green object above the players head. Or, if the other two options aren't very appealing, changing the players health bar to green until cured or death. Quickbar (e.g. Attack / Cast Spell XYZ) Buttons customisable from the menu which will need to control it. If a player has a quickbar for spells, they'll customise it via the spell book window. Equipment (e.g. Armor / Weapon / Shield) Grid. Communication (e.g. say) Depends on the circumstances. Out of Character chat in a separate window, effectively disassociated (not using the interface theme, etc) with the game in all aspects other than the fact you require to be inside the game to use it. Standard character chat displayed under the map echoing only to view. Communication with NPCs I don't quite understand what you mean. But a method would be giving the player a set of responses based on their character-alignment. And having the NPC react as you would expect when a specific reply is made. This is done inside a separate window. Macros Interface macros with no commands assigned until the player is allowed to use them. I'm kind of hoping for opinions and creative input! Sorry, I chose option C for most of your questions. As for the current argument on Interface Elements verses Screen Objects. I'm going with Interface Elements. Why you ask? Personal preference, that's why. I find them much easier to control and do exactly what I expect them to do, when I expect them to do it. You can argue the same is possible with screen objects, but I have far less trouble with the interface. It was created to be used, so I'm going to use it. No more, no less. | |
Xooxer wrote:
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. I don't know if someone else mentioned this or not. I'm far from the mood to read an entire thread of people bickering on which method is better. But you can actually already do this with a little help from the transparency feature in the windows. IIRC, Mikau managed to place an output control over the map with a slight transparent look, effectively allowing for the effect of on-map chatting. And with 430 properly taking into account element layers, it'd probably be pretty easy to do this for other things as well. Just make sure the map element is created before any elements you wish to place on top of it. | |
SilkWizard wrote:
But hey, go ahead and forsake screen objects! While you're going on about how you could technically do the same thing with 4.0, my games will look and play better -- because I won't be making them with one hand tied behind my back. In addition to what Hazman has replied... You do realize that there is a client.screen list limit and you could hit it at any point? You do realize you are forsaking efficiency just to use screen objects? You do realize that client.screen just does some things better than interfaces, and your on-screen windowing system just isn't one of them? You do realize that pixel-perfect positioning means jack-squat when people can move the interface windows around but not yours? | |
SilkWizard wrote:
Based upon every other BYOND game I've seen, I've had more experience working with screen objects than any other developer. There's no way you can claim that. I've done things with screen objects that no one else has done. Proof? Or are you just making more grand false claims? My games are playable examples of the power of screen objects. Furthermore, the use of screen objects makes them look a hell of a lot better than most other BYOND games. Opinion. I think your HUD looks like crap, but then, your interfaces probably look worse. I certainly don't need to toot my own horn, as I'm happy to let my games speak for themselves. Then shut up already. My point was this: the people in this thread criticizing the use of screen objects aren't the types of people who would be using them anyway. False. We all use them. My intention was not to claim that "I'm better than everyone else". Frankly, the title of "Best Game Developer on BYOND!" would be about as meaningful as a gold medal at the Special Olympics. It's not your intentions, it's your words and insults, audacious claims and outright disregard for your peers or their abilities. One last thing: I'm not going to sit back and pretend like I don't make quality games, Good, because you don't. or feign modesty for the sake of others. Here's a clue: we're not competing with your games. The fact that so many people are <s>threatened</s> outraged by my <s>pride in my games</s> arrogance is<s>n't</s> my problem<s>; it's theirs</s>. Fixed! ^_^ The only reason certain individuals suddenly care about screen objects vs. 4.0 interfaces is because I'm the one defending screen objects. Oh, but I thought you replied to me, to which I replied back, to which yo went off the deep end. Sounds like you're the one who took an interest.... | |
Tom wrote
On the flip side, by no means do I consider the skin to be a replacement to the screen-object interface, and I'm shocked that some of the users here feel that way. I'd take the strong opinions people are throwing out about screen objects with a grain of salt. I have a feeling that if I had come out in support of 4.0 Interfaces, those same users would have bashed 4.0 instead ;) Both features are incredibly useful and neither should be disregarded. Anyway, it's probably about time for a moderator to lock up this thread. I'm all for letting people vent their problems with me in a separate "We HATE Silk Wizard!" thread, but it's a shame that a potentially valuable discussion about quality interfaces has turned so sour. | |
SilkWizard wrote:
Anyway, it's probably about time for a moderator to lock up this thread. As stated by your following paragraph, this thread is potentially valuable and offers a lot for anyone who's suffering from the choice of screen objects or interfaces (I don't see why they would be, I don't know of any defined BYOND golden rule that says "YOU CAN'T USE BOTH!") to read this and maybe supply an opinion. If this thread can get back on track, I wouldn't see a reason to lock it personally. If another moderator feels differently, then they will no doubt do so. But I feel this discussion to be important, it's a shame it was sidetracked with personal insults. I'm all for letting people vent their problems with me in a separate "We HATE Silk Wizard!" thread, but it's a shame that a potentially valuable discussion about quality interfaces has turned so sour. Nah, that thread would be locked/deleted the moment it was seen by a moderator. (I'd personally go for the delete button. Unless of course I wanted to make an example of the post starter by stating that kind of thing isn't required or necessary... I guess it depends on how bad the post and it's replies are. Who knows, we'll cross that bridge when we come to it (I personally hope we don't come to it.)) | |
Tom wrote:
I wish you guys would stop fighting. There are situations where both of these styles are useful, and I'm glad to have them both be a part of the system. On the risk of sounding like a complete <insert random swearword of your liking>, I'd want to use these words of Tom and make a little suggestion. There have been two very different attempts of solving the problem to display information for the player and, like it is human spirit, both have been argued about intense. Now, wouln't this be a great chance for a nice article in Dream Makers? As kind of introduction: SilkWizard wrote: (...)there is no single "best way" to make an interface for a game. Tom wrote: (...)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. Alathon wrote: 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. If SilkWizard and Xooxer (or the others that spoke for or against one side) would each compile a little demo (maybe even with a library as offspring?) with a detailed article to explain what they did and to mention the advantages of their approach, this heated discussion I unfortunately started unintendedly would bear some wonderfull fruits that I'm sure would not only help me to decide and learn, but many others as well! In the end, someone (neutral ;)) with a talent in writing could assemble both and release a lovely little gem for the Deam Makers guild. SilkWizard wrote: client.screen gives you a lot more freedom, but takes more time to code/test/perfect. Alathon wrote: (...)This has to do with where the player focuses their eyes. Xooxer wrote: client.screen is really only useful if you need to display something to a specific client directly over the map.(...) 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.Xooxer wrote: Can you give a good example of how screen objects can accomplish something an interface can't? (...) Both demos would require an equal task to work with in order to be comparable. If two people would agree to make an effort in using this heated atmosphere for a productive/constructive "contest" like demo competition, we would have to fix a little list of things the demos need to do first. Thank you in advance for considering and I'm sorry as this is asking you to dedicate a lot of time on the matter, which might make me look rather bad, but I felt the possible outcome might be worth looking like a spoiled b.... | |
I hope you don't take this wrong. I think your idea is fine, but there's no way I'm working with Silk on anything. I doubt that he would even bother writing an article to explain himself, considering he refused to even answer the one question that started this whole fiasco. Don't blame yourself, though. Silk and I have some history that got in the way here, though I would have liked that it did not.
| |
That can all be done with BYOND's 4.0 interface much more easily :P (toggle the visibility of labels, grids etc.). However, you're definitely correct on some of the other things you mention.
| |
Xooxer wrote:
(...) I think your idea is fine, but there's no way I'm working with Silk on anything. I guessed that by the postings in this thread, though my idea never intended for you two to work together (due to my guess). I meant for both of you to work completely for yourself, without even knowing what the other one does! Just that both of you would have the same starting point/task. As an example: The demo should have a title screen. Silk would have to do that with client.screen (or a seperate map area) and you would have to use an Interface element (e.g. a pane (win)set to the child holding the map on client/mob connect events) Xooxer wrote: I doubt that he would even bother writing an article to explain (...) I never meant him, or you to do that, or I should say not in the way it should normally be done if the article was made by a single person. I think SilkWizard is working on a client.screen tutorial/demo (for Tom) anyway and that was what ignited the virtual spark in my head, since here would be the perfect place and timing to have the same done for Interfaces. By having two excellent DM veterans like you working on the same base, but with completely different means and approaches without knowing what the other does, it should provide the community with two very valuable demos of how some general problems in games can be handled. And then in the end, someone else would have to combine both in one article. See it like buying a couch. It's always going to be a couch, but in a big market you are presented with many different realisations of the general idea "couch" and the best way to find the one that suits you, is to compare ;) | |
I have the distinct feeling that some things a best left to interfaces, others are best left to on-screen objects.
For example, a splash screen. For that to have a professional effect you see in games-of-today, there's no window about them, they are centre screen and pretty much an image with some buttons. You can't get this effect with on-screen objects. Of course it's not necessary at all, but it does give a touch of professionalism to a game, in my opinion. (Yes, I did just write a tutorial to prove my point...) Doing this in DM is very easy. (Please note, all the slashes in the winsets() are to make this actually display mildly nice for Firefox 3. overflow isn't really Firefox 3's thing...) Here's what we need: A Window with a child element. A pane with a browser element, and two buttons. A pane with a label. We'll name the various elements: window_main pane_splash pane_game window_main.child_display pane_splash.browser_resolution pane_splash.button_play pane_splash.button_quit pane_game.label_hello window_main specifications: Nothing. Uncheck every checkbox, clear it of all macros and menus, the only thing it should have checked is "is-default". -- First thing we'll need to do is define a client variable "resolution". And while we're at it, we'll set up client/New() as well. client Resolution is a temp variable, because a users resolution can change at any time, so we don't want to save any instance of it at all ever. Working it out isn't that much of a hassle anyway. Now we'll want to make some procs, the first one being "resolution", this is where our invisible browser element comes into play. We're going to use javascript to figure out what the users screen resolution is, and send the results to client Topic. As shown below. Let's take a look at what our code looks like now: client That's fine and dandy, but we still don't have a window displaying (remember, it's invisible), and nor do we actually do anything with our new resolution variable. So we need to make a proc we call, "centre_window()". Note: There are probably better ways to do this, I don't use this exact method personally, but in demand for simplicity, this is how I'm choosing to do it. If you have a better method, please share.
centre_window(client/C, window, additional)Now we have a proc which can centre our window of any size, to the clients screens centre. Now we're going to put it all together! client That's a fair bit of code to pull this off, but if you have an actual image and some decent effects, it's well worth it! For the two buttons on the pane_splash, set their commands for ".play" and ".quit" for the respective buttons button_play and button_quit. We're going to write up a quick client/Command() to turn that window into a fully functional window.
Command(C as command_text).quit is a predefined DM macro, which means that calling it will cause the player to quit the game. So we don't need any code for that at all. Here's the full code of the project, and the project files for you to mess around with if you see fit. client | |
Wouldn't it be better to just call the center_window() procedure in the block where client.Topic() defines client.resolution to avoid an unnecessary loop?
| |
CaptFalcon33035 wrote:
Wouldn't it be better to just call the center_window() procedure in the block where client.Topic() defines client.resolution to avoid an unnecessary loop? Good thinking! Completely missed that. | |
The center script is handy, but otherwise there's nothing there that that couldn't be handled using just the map either. The map would also give you freedom to add effects that can't be handled by the Windows 95 era controls the interface provides.
| |
SilkWizard wrote:
client.screen gives you a lot more freedom, but takes more time to code/test/perfect. client.screen gives you a lot more freedom Single instances of all the interface objects can also be used. Best method I've found is using areas tagged for each individual screen element, then its simply a matter of locating that area and adding the objects to the screen. A little simple math and you can even avoid having to manually set screen_loc for each piece. It also wouldn't be difficult to allow users to move around the different windows of the HUD via clicking and dragging to allow them customization similar to the 4.0 interfaces. but takes more time to code/test/perfect. Keeping it to client.screen also keeps things away from the rather clunky interfaces. They're fine if you want to slap some stuff on and allow for resizing, but if you want (or need) to be changing stuff around at run time it can quickly become a headache dealing with things beyond handling simple window creation. | |
Nick231 wrote:
The center script is handy, but otherwise there's nothing there that that couldn't be handled using just the map either. The map would also give you freedom to add effects that can't be handled by the Windows 95 era controls the interface provides. I'll agree that the map can be used as well. Place a map on the pane and you have the best of both worlds. However, the present argument is the use of client.screen OR the user of the interface. I'm taking it the most literal form I can think of, and that being, you either get the option of one, or the other. As a result, you're cheating if you use anything but the default interface. A lot of people in this argument seem to think one or the other is the be-all and end-all of the design process. Screen Objects, or interfaces. I choose interfaces because they're client side, and I find them to be overall quicker than map objects. That being said, they're also far easier to control. If you're really good at graphic work, it shouldn't be too hard to make an interface that blends in with the map you've created. | |