Interfaces...

Page: 1 2
Oct 17 2010, 10:53 am
In response to Kaioken
My bad. I misunderstood your post. I know you're not criticizing. Furthermore, did I write that? That post is terrible. Anyway...

Kaioken wrote:
Why would it? You're talking as if there's a bomb with a motion sensor in there.

Fiddle with the game and take a look. The game is entirely dependent on the interface being the way it is. In order for the interface to populate properly.

The window size is determined by the client's view. So, if you were to unanchor the map, add something to the map window, etc., the window size would be wrong. Upon resizing, the game will adjust the window and client.view to the nearest multiple of world.icon_size.

In order to achieve the two maps feature of the game, each window has a child pane, anchored to the size of the window. Upon start up, and when switching window modes, the game will mess with the child's ... left and right and vertical splitter and splitter size, the visibility, focus, and size of each window.

The goal was to make an interface that was so good that no one would want to customize it.
Oct 17 2010, 11:28 am
In response to Loduwijk
Loduwijk wrote:
Which is their right to do.

You are using this argument too much. You also appear to let personal experience and/or frustration interfere with your judgment.

It's also quite flawed. From where does this right come? Let's break it apart.
First, if you acquire or even buy something, it does not automatically give you the right to do anything you want to do with it. It belongs to you, but you do not necessarily own it. Your rights depend on the agreement leading to your acquisition, they are not automatic.
You are certainly aware that software, too, are tradable possessions can come licensed under different terms and licenses, eh? Why are you ignoring this?

The license for software can even amount to you paying for using the software as intended. If the author didn't give you the rights to redistribute (even intact), sell, resell, modify, disassemble, etc, then you don't have the right to do any such act.
Naturally, you can do so anyway without having the right to, of course, even if you perhaps break commercial law -- but if the owning party is unaware or isn't sufficiently bothered, you're clear.

If it turns out you do own your copy of the program, and you own the system it's running on, then it's you right to do whatever you want with it. And you can. But it's not the author's duty to make it easy for you.

Of course, I'm no specialist, so the specifics may be off, but the above seems pretty simple and clear.

Restricting people from doing stupid things in no way makes the product better.

This is so obviously wrong I almost didn't respond. Even more so, since you're being general.

Allowing me to change the interface, even with the possibility of breaking it, is strictly better; even if I don't take advantage of it, the option is there.

Yes, the option is there for making things worse, so it's worse off. But no sane programmer would go purposefully as far as letting you actually break in the interface anyway (in a polished program, that is).

So perhaps I am unaware of how the interface could give someone an unfair advantage - please enlighten me.

Let's say you are using an interface which makes it easier to play well to play against someone whose interface does not. You have an unfair advantage in relation to him.

If you are thinking along the lines of "A player having an interface which is set up to ignore aesthetics and its only purpose is to be efficient for use to make for more aggressive gameplay." then that is not an unfair advantage, rather, it is a very fair advantage which is a great feature.

This is disgustingly wrong. You don't have to be 'aggressively cheating' to have an unfair advantages.
Have some examples.
Many First Person Shooters are created using engines that allow lots of customization (often they even add more). However, you'll find that in competitive gameplay scenarios (e.g. official clan matches), a LOT of these are disabled, as well as some practices are disallowed, in order to ensure fairness and balance.
These can range from settings which affect the display on your end (for example, a preference/performance setting that causes foliage not to be rendered -- which is obviously a big exploit in any competitive scenario. The same goes for 'standard' settings like brightness, view distance, field of view etc), changing game files (using brighter enemy character models to make them easier to spot or using models which mark hitboxes, using transparent models for the map, etc) and sometimes using certain scripts or 'macros' to easily do certain things efficiently in a way that can't be done in an unassisted manner (for example, a macro for a series of 8 commands which are all executed immediately that causes you to instantly turn around 180 degrees to your left/right). Then of course there's the use of external programs to make it easier for you to aim and see -- obviously, by your logic, these are no different and at least wallhacks should be most definitely allowed: it's customization. It's your computer and your copy of the game, hey, it's your rightful right and it's a sin to take it away!

Any reasons or arguments for that statement?

He said that because in BYOND you need to do so while disallowing DMF editing, since otherwise the editing is in a way absolute.

How so? I think it just makes complete sense. I don't understand how some people are thinking it is ridiculous.

I've supplied enough examples above. Spent too much time on this thread today anyway...
Oct 17 2010, 12:18 pm
In response to Loduwijk
Well, it would be almost rude not to reply to this post as well.

Loduwijk wrote:
given that the something more isn't bad, as mentioned above.

You didn't actually specify this before.

Full control over everything that's happening in the game (the ability to change your opponent's amount of health in a multiplayer online game, for example) is bad, but control over the interface does not allow for any such bad things.

Theoretical, limitless control over the interface can do anything from letting you access all of your possible actions much more easily than all the other players, to seeing enemies more easily, to seeing 5 locations at once...

If I can do more (nonbad) things, it is strictly a better product

Hence to make a better product, customization has to be limited so you cannot do non-nonbad things. This is different from what you've previously said. You are now more correct, but are still too assertive. I stated other reasons as well. Here's an illustration of one (click to enlarge):

These are two great programs, The KMPlayer and Miranda IM. They are great because they offer a lot of customization, options, and settings. But they offer too much and need to have work put into organizing the settings and making it easier to find what you want, as well as making more obscure, advanced settings more opt-in. Maybe even removing some over the top, junk settings (you can also go the Mozilla route and hide all advanced settings in about:config, but this creates its own issues).
In both programs, it is easy to get lost in the options dialog and have a hard time finding what you're looking for. Likewise, one can probably describe the work needed to get everything to be like you want it to be directly after first installing as 'a pain', for the quick-starting wizards are not nearly sufficient for this task and need more work.
This fact as well as the mere glancing at the options screen also appalls users and can scare them away. The average user will not know how to handle these programs like this. Fortunately, Miranda IM did have a 'simple' options dialog added for non-advanced users, complete with graphical buttons.

No control over button layout or interface is strictly worse than having control over it, and I say that with the same amount of assertiveness as before.

Compare having absolute control and being able to move buttons anywhere and being limited so you can't move the buttons out of screen boundaries or on top of each other, etc, then tell me if this assertiveness is good.
(Obviously the above is not a good or healthy way to facilitate customized hiding)

And, as the user, doing any or all of the above things is my right to do if I decide.

I don't feel like thinking. You decide whether this is irrelevant to how good the product is, or it IS relevant but in a manner that counteracts your point.

Even if I personally do something stupid with the ability, the product itself is still strictly better for having that ability.

Yes, because a blender is definitely better if you have the ability to make the food fly all over the kitchen or cut your hands using it than if you hadn't had that ability. A shaving razor is also better without anti-skin-cutting safety measures, because it doesn't limit what you can do with it. A microwave is also better if it allows opening its door while it's running than if it required pressing the stop button first. A remote should allow you to place the batteries in the flipped direction and ruin its electronics if you want. A motor or processor should not limit its frequency and allow you to customize to whatever you want and fry it as you will. It makes it so better because you CAN do it. Nobody is forcing you to it. Forget natural human mistakes and finger-slips, forget natural absentmindedness and lack of sleep, forget uncareful children, forget lack of user knowledge, forget safety, the list goes on.

If you think about it logically, it's not that much different with programs, only instead of your user's body or physical property getting hurt, your user's experience gets hurt.

Nobody is forcing me to use it. I can choose to ignore it and use the product in the vision that the developer had, or I can take advantage of the extra features if I decide to do so.

Not that simple.

Having that ability makes it strictly better.

I believe I've broken this apart by now.

If you are planning on expending your energy to make it difficult for users to customize the product, instead please do the opposite and expend that energy to make it easier for them to customize it.

If the limitations you expend energy on make the product better, as explained before, then there's no need to direct that energy elsewhere.

If it can truely negatively impact other players' experience, then it's not a feature that should be included.

Anything that gives you an advantage that another player may not necessarily have can negatively impact the other player's experience. You have 2 choices in getting rid of this possibility: 1) If the optimal setting for each user is discernible, force the setting to that in multiplayer. 2) Don't have that option in multiplayer, meaning only the default setting is usable.

then that is not a bad thing at all; it's just allowing you to personally play the game better. That is completely fair.

No, it is actually not fair objectively speaking. The typical, infamous wallhack and aimbot hacks are no different: they're just allowing you to personally play the game better!
In actuality, where the line between fair and unfair in your game depends on where you draw it. Game designers and game judges aren't so strict, so they choose subjective rules.
A ruleset example: you are allowed to map keys as you wish, you are allowed to even use scripts to map a key to a series of commands to quickly turn yourself around or to quickly notify your team of a threat and its location. You are allowed to modify your field of view and displayed colors, but only inside a certain, specified/limited range. You are not allowed to use external programs that influence the gameplay like aimbot and wallhack programs. BUT you are free to use external programs that influence the gameplay like a program allowing you to quickly minimize and return to it instead of having to wait a while because of the engine's default slow minimization, like a program allowing you to voice-chat with your team mid-game, like a program that automatically starts a visible countdown timer when a bomb is planted and perhaps even notifies the entire team when it's going to blow, etc...
There is no pattern other than "what is deemed by the decision-maker as too unfair is not allowed".


Yeah, going to sleep now.
Oct 18 2010, 9:54 am
In response to Kaioken
Wow, just wow. You have managed to take half of what I said out of context and to also put words into my mouth which I never said.

Loduwijk wrote:
given that the something more isn't bad, as mentioned above.

You didn't actually specify this before.

As I said in my later reply, I didn't dwell on this, in fact I barely mentioned it, but I did mention it.

"If I buy a game, I should be allowed to do with it whatever I want, especially if I'm playing it single-player."

I hardly gave it 2 seconds of thought, though, because that's not what the conversation was about. Nothing was even said about cheating until Falacy brought it up. This is not a discussion about cheating, it is a discussion about modifying the user interface.

Theoretical, limitless control over the interface can do anything from letting you access all of your possible actions much more easily than all the other players, to seeing enemies more easily, to seeing 5 locations at once...

No, it can not. And I specifically mentioned this in my post which you reply to. Those things have nothing to do with your interface. Those are game mechanics issues, not user interface issues. Limitless control over the interface should not (would not) give you any ability to access anything in the game mechanics that you would not already be able to access normally.

As I keep saying, I'm talking about the way the game is perceived, not the way the game mechanics work.

If I can do more (nonbad) things, it is strictly a better product

Hence to make a better product, customization has to be limited so you cannot do non-nonbad things. This is different from what you've previously said.

No, it is not different than what I previously said. You are trying to inject more subject matter into the context of this conversation. If I'm talking about subject A and I say "People always do B." it does not make sense to say "Nuh-uh, in subject C people might do D." If the conversation has a context, you don't have to keep saying over and over "Given the subject of this context, and assuming all other things remain the same, ..." every time you're about to make another assertive statement.

You are now more correct, but are still too assertive. I stated other reasons as well. Here's an illustration of one (snipped picture)
These are two great programs, The KMPlayer and Miranda IM. They are great because they offer a lot of customization, options, and settings. But they offer too much and need to have work put into organizing the settings and making it easier to find what you want, as well as making more obscure, advanced settings more opt-in.

This does not help you any. So the extra options might be disorganized; that does not detract from the quality of the overall program. The fact that the settings are there at all makes it strictly better. If they were organized well so that you could customize your experience even easier and better yet, then the product overall would be even better than it is now. Supplying the options but not organizing them does not make the product worse, and the products in your screenshot are not worse off having disorganized options than they would be if they didn't have the options at all.

This fact as well as the mere glancing at the options screen also appalls users and can scare them away.

If you are specifically going to a screen with extra options, then that means you are specifically looking to change your experience with the product. If a user is in this situation and abandons the entire product because of the disorganized options screen, then that is a lazy user, not a product made worse by not organizing the options. However, if another product had an organized list of options, then this might make the other product better than this one, and in that case it might make sense to leave this product and go to that one; still, that doesn't mean the first product is any worse for providing the options in the first place.

The average user will not know how to handle these programs like this.

The average user does not seek out the options that customize their experience, and, even if they do, having those options available but not in a good format does not make the product any worse than not having them in the first place. (See where I'm going with this? Do I sound like a broken record yet? I have yet to see any statements to the contrary, which is probably because such a statement does not exist.)

No control over button layout or interface is strictly worse than having control over it, and I say that with the same amount of assertiveness as before.

Compare having absolute control and being able to move buttons anywhere and being limited so you can't move the buttons out of screen boundaries or on top of each other, etc, then tell me if this assertiveness is good.
(Obviously the above is not a good or healthy way to facilitate customized hiding)

If the user only has buttons as part of their UI, then being able to move the buttons is having absolute control. Being able to move the buttons out of screen boundaries is fine as long as you have a way to get them back in. If not, then that's just stupid; just include a button in the customization interface that moves the buttons for the app interface back into view.

As for buttons on top of each other for customized hiding, sure, it's not as good as having an option to make the button invisible (with the ability to bring it back when desired), and yet, again, letting users move buttons and not providing for button-hiding such that they have to pile them to hide them, well, this still makes the program strictly better. This does not make the program worse in any way than not letting them move the buttons in the first place.

Even if I personally do something stupid with the ability, the product itself is still strictly better for having that ability.

Yes, because a blender is definitely better if you have the ability to make the food fly all over the kitchen or cut your hands using it than if you hadn't had that ability. A shaving razor is also (more silly stuff snipped)

And yet none of those are user interface issues, so my comment does not apply to that. A UI issue for a blender would be buttons for variable speeds between just "hi" or "lo," or maybe a switch for making the blender "pulse" instead of continuously spin (a feature some of them have).

Again, keep the context in mind. Safety features do not apply in the context I am talking about. I can therefore safely say that the "features" you listed are stupid and make the product worse without contradicting anything else I have been saying.

If you think about it logically, it's not that much different with programs, only instead of your user's body or physical property getting hurt, your user's experience gets hurt.

Not if you only provide a framework for customizing UI. (Context? I think my broken record is getting another title on it)

Having that ability makes it strictly better.

I believe I've broken this apart by now.

I believe the only statements you've broken apart are statements which I never made. You seem to be arguing some points which I agree with you about, things which I never argued against. Other things you "break apart" you are taking out of context.

If you are planning on expending your energy to make it difficult for users to customize the product, instead please do the opposite and expend that energy to make it easier for them to customize it.

If the limitations you expend energy on make the product better, as explained before, then there's no need to direct that energy elsewhere.

Again, if you mean that comment out of context, then sure, it's true. If you mean it in the context of user interface, then the limitations will never make the product better.

Anything that gives you an advantage that another player may not necessarily have can negatively impact the other player's experience.

I never said anything about any advantages that another player might not have. With the user interface customizations I'm speaking of, any advantage that I have is an advantage that you can have too.

then that is not a bad thing at all; it's just allowing you to personally play the game better. That is completely fair.

No, it is actually not fair objectively speaking. The typical, infamous wallhack and aimbot hacks are no different: they're just allowing you to personally play the game better!

And those have nothing to do with the UI. Context! This conversation has a context!

In actuality, where the line between fair and unfair in your game depends on where you draw it. Game designers and game judges aren't so strict, so they choose subjective rules. (snipped examples)

And a lot of those things you mention are not UI issues. Some of them are questionable: changing colors of in-game objects so that you can see them better is questionable as to whether you want to call that UI or game mechanics. Making enemies every bright and red so that you can spot them even when they are hiding behind foliage is not changing the UI as much as it's changing game mechanics.

Even if I were to include a full UI customization API with a game like I mentioned before, I would not include with it any way to change the way in-game objects look, because I would not consider that part of the UI. I specifically said that you have to decide what is a UI issue and what is not.

If the boss at the end of the level normally has a health meter, and you want to change it in some way (move it, change its appearance, making it blink when it's low, whatever) then that's a user interface issue. If the boss at the end of the level normally does NOT have a health meter and you're not supposed to know how close to death it is, then adding a health meter is NOT a user interface issue; it is a game mechanics issue and has nothing to do with the user interface.

First, if you acquire or even buy something, it does not automatically give you the right to do anything you want to do with it. It belongs to you, but you do not necessarily own it. Your rights depend on the agreement leading to your acquisition, they are not automatic.
You are certainly aware that software, too, are tradable possessions can come licensed under different terms and licenses, eh? Why are you ignoring this?

I am not ignoring anything. I specifically mentioned that in my original post. I said that the user should have the right to change the interface however they please, and that is correct: the user should have that right. I also said that some companies abuse the law to restrict you from this. These companies have the legal right to do this, but it is stupid and does not benefit anyone (not the users or developers).

There are a few specific situations where this becomes questionable. For example, when a new version of Windows comes out, the reduced versions are generally the same thing as the better versions except that they delete a few files and change some registry settings to disable certain features. If you buy Windows XP Home edition you can basically turn it into XP Pro edition by copying some files over to it and making some registry changes to re-enable the features you want which were disabled. In some cases, you can even get some of the functionality in Windows Server versions of the OS this way.

Still, none of this is a UI issue. Windows does provide support for changing your UI. You can change the theme, screensaver, you can change the locations of some things, sounds, etc. And this is a good thing; Windows would be strictly worse without this. They never had to spend the time and effort to make this available, just as Byond game developers never have to spend their time and effort to add such features to their games; I never said they have to. But the fact that Microsoft DID do this makes Windows strictly better than it would be without.

If it turns out you do own your copy of the program, and you own the system it's running on, then it's you right to do whatever you want with it. And you can. But it's not the author's duty to make it easy for you.

And I never said the author has to make it easy for you. I specifically said the author never has to do anything. The author never had to put a single feature into the program; they do because it makes the program better. The customizations I talked about make the program better, but I never said the author had to do it. I did say, though, that the author should never do the opposite and specifically deny it.

I still cannot think of any reason that specifically expending effort to reduce UI control would ever be a good thing or how it could ever improve anything at all.
Oct 20 2010, 2:29 am
In response to Falacy
Falacy wrote:
Abstract them how?

mob
    verb
        Attack()
            attack()
    
    proc
        attack()
            if(!can_attack) return
            can_attack = 0
            
            // do the attack
            
            spawn(attack_delay) can_attack = 1


The attack rate is limited by attack_delay. You can use a macro but it won't do anything that you can't already do.

Maybe (in another thread) you could describe how players are using macros to get an advantage and we could figure out ways to prevent that.
Oct 20 2010, 2:36 am (Edited on Oct 20 2010, 2:41 am)
In response to Forum_account
Forum_account wrote:
Maybe (in another thread) you could describe how players are using macros to get an advantage and we could figure out ways to prevent that.

Pfft, let the moderators split this off into another thread =P

Anyway, they can create multi-verb macros. Which, for instance, attack and use a potion at the same time, or attack and then step away from the enemy to avoid being hit, or attack, switch skill, use skill, all at the same time, etc. Sure, you could do this with bots, but that's a bit more complicated and outside the developer's control.
They could also modify the interface to make non-visible windows visible, though prevention should probably be coded for use of these windows in the first place. The same goes for using otherwise hidden verbs.
They could also edit the interface/macros to give them quicker access to things that other players wouldn't have. Which, though it should probably be implemented into the game in the first place, is still an unfair advantage that shouldn't be allowed.

In HU1, players create macros to (among other things) add senzu beans, use after image, and then eat a senzu bean. Which basically gives them infinite uses. A delay shouldn't be added to this, because its a legit tactic. Just not legit when somebody is spamming it all in 1 button press.

EDIT: Also, did they mean obstruct, not abstract?
Oct 20 2010, 2:45 am
In response to Falacy
A delay shouldn't be added to this, because its a legit tactic. Just not legit when somebody is spamming it all in 1 button press.

But that's exactly what a delay is. It prevents the user from performing multiple actions in the same tick (whether its the result of one keypress or many, your issue seems to be with the rate at which the action is performed). It sounds like a delay, even a one tick delay, would solve all of these problems.
Oct 20 2010, 2:47 am
In response to Forum_account
Forum_account wrote:
But that's exactly what a delay is. It prevents the user from performing multiple actions in the same tick (whether its the result of one keypress or many, your issue seems to be with the rate at which the action is performed). It sounds like a delay, even a one tick delay, would solve all of these problems.

There's a 1 tick delay on multi-line macros by default, I'm pretty sure. It still makes things a lot easier.
Oct 20 2010, 3:10 am
In response to Falacy
Actually, given the discussion is about allowing or disallowing players access to editing the interface, reasons for either thesis are rather on topic, at least in my eyes. I doubt that they would warrant splitting the thread.
But thank you for allowing the moderation team to take the potential workload.

As for what you describe could basically be defined as security through obscurity. Instead of applying a proper check and restriction (which should really be the preferred solution of a polished product) an additional layer is added to shield the player from native, easy access to functionality you define that they should not obtain.

If taking multiple actions in a given time-frame should be prevented, then simply include a check. Similarly, the server should validate if a verb is to be accessible at a certain stage instead of relying on purely hiding it from the player.
Oct 20 2010, 4:36 am
In response to Falacy
Falacy wrote:
There's a 1 tick delay on multi-line macros by default, I'm pretty sure. It still makes things a lot easier.

Then this goes back to [link]. If the macros make up for a clumsy interface then the game doesn't have cheaters, it has a bad interface.
Oct 20 2010, 4:49 am
In response to Forum_account
Forum_account wrote:
Then this goes back to [link]. If the macros make up for a clumsy interface then the game doesn't have cheaters, it has a bad interface.

Creating custom macros for a BYOND game is no different from an aimbot for any FPS. In fact, you could do just that, considering most mouse procs are macroable .DblClick Target
Oct 28 2010, 6:24 pm
In response to Falacy
Falacy wrote:
Forum_account wrote:
Then this goes back to [link]. If the macros make up for a clumsy interface then the game doesn't have cheaters, it has a bad interface.

Creating custom macros for a BYOND game is no different from an aimbot for any FPS. In fact, you could do just that, considering most mouse procs are macroable .DblClick Target

Really a global delay that's short is pretty reasonable, given lag and the act of pressing buttons people are fairly unlikely to end up doing two radically different actions manually in consecutive ticks, so a 1-2 tick global delay should be enough to mess with BYOND's macros, without appreciably restricting manual commands. If you've got people using external macro programs that can delay between sending commands I don't think there's much you can do other than fix your design though.

As for BYOND's click macros:
// Disabling .click and .dblclick macros
mob
    verb
        no_click(argument as command_text)
            set name = ".click"
        no_dbl_click(argument as command_text)
            set name = ".dblclick"

Similar things can be applied to the other default .commands, since BYOND will look for them as verbs first.
Page: 1 2