I don't really like the idea of allowing users to edit the skins or even have access to it for that matter.
Just wanted to know what other people thought about it.
ID:132471
 Oct 15 2010, 11:04 am
|
|
|
Oct 15 2010, 11:08 am
|
|
Falacy
 |
control_freak
|
Why would this be even the slightest of problems?
If someone edits your interface and you have control_freak enabled, it doesn't matter and your default interface you made will be present. They can't really extract anything from your interface. The only problem would be jealousy if you and (an)other individual(s) share the same code to handle interface things and their's turns out better. | |
Akushumi wrote:
I don't really like the idea of allowing users to edit the skins or even have access to it for that matter. I don't personally mind if anyone is modifying the interface to my games (as some have already) but I unintentionally enact a form of anti-skin editing with the code I use to check and construct interfaces -- BGC, for example, compacts its layout to a 20-character string and tries to load it up again on client/New, and making any significant change to the skin file will completely bork the entire thing. | |
Akushumi wrote:
I don't really like the idea of allowing users to edit the skins And users really don't like the idea of not being able to. If you do not allow users of your product to change things how they like them, or, even worse, specifically take efforts to reduce what users can do with your product, then your product is strictly worse than it otherwise would be. No ifs, ands or buts, and it's not an opinion, it's a fact. This is specifically the reason why (Android > iPhone), and this is a perfect analogy. The greatest example of this perfect analogy is that, with previous versions of the iPhone, user-created apps that used the phone like a flashlight were frowned upon by Steve, which he later said was because "It used up the battery too fast, and I don't want people consuming their batteries in a quarter the normal time." And there was even an iPhone OS update whose only purpose was to block people from being innovative with their phones like this. I don't care if Stevie doesn't want people using "his" phones in ways that he didn't anticipate. If I buy the phone, it's MY phone, and I'll do with it what I want, even if that uses up the battery faster, because that's MY prerogative. It's not his choice to make, and making updates to block me from using MY phone the way I like should be illegal. The same could be said of commercial games. If I buy a game, I should be allowed to do with it whatever I want, especially if I'm playing it single-player. If I want to edit my stats, reverse engineer the game to change the way it works, or do anything else, that should be my right; but most companies put it in their terms that you cannot do such things, thus abusing the law to restrict us from doing what we want with what we paid for. Granted, in your game, you're not selling CDs via Wal-Mart that people buy and can call their own. You are instead running your own world online that others simply connect to with a client that they never had to pay for in the first place. But the principle still applies; many users hate it when the developer restricts them because of their arrogance in thinking that their user interface, graphics, sounds, or whatever, is the only way the product should be experienced. Developers everywhere should do us all a favor: if you're thinking of going out of your way to do any extra work to restrict what users can do with your product, please, instead do the opposite and expend extra work to make it so players have MORE control over changing their experience with your product. I guarantee you, your product will be strictly better, and anyone who bothers to take the time to customize their experience with the tools you provide will be very grateful and will like your game more. | |
Akushumi wrote:
"or even have access to it for that matter." ? I'm pretty sure control_freak removes access to it as well. Though I haven't looked into it myself, I have had people ask why the HU2 skin isn't available, and I would assume that is why. Loduwijk wrote: And users really don't like the idea of not being able to. If you do not allow users of your product to change things how they like them, or, even worse, specifically take efforts to reduce what users can do with your product, then your product is strictly worse than it otherwise would be. No ifs, ands or buts, and it's not an opinion, it's a fact. Wrong, in pretty much every way, along with almost every following argument you made. Even more-so when it comes to BYOND, considering vast majority of the users are complete noobs who do nothing but break the interface when attempting to modify it. Even if they do succeed, its almost entirely to gain an unfair advantage in the game. Not something any developer should support. Customization can be great. However, it should be completely handled through the game/interface itself, implemented by the developer(s). Allowing people to change anything they want, to anything else they want, is just ridiculous, and as we both mentioned, just leads to cheating more than anything. | |
Why would this be even the slightest of problems? If someone edits your interface and you have control_freak enabled, it doesn't matter and your default interface you made will be present. They can't really extract anything from your interface. The only problem would be jealousy if you and (an)other individual(s) share the same code to handle interface things and their's turns out better. I'm currently making a game where a lot is going into the interface. I'd say about... 20-30% of the game. I know that having a copy of the interface wouldn't be much use, but I don't really like the idea of a player having it. I don't really get the rest of what you're saying though. @Loduwijk - I completely agree with Falacy. The reason I want to deny users the ability to edit the skin is because of people that would seek an unfair advantage. | |
If players could gain an unfair advantage through modifying your interface, I think you might have a bigger issue at hand.
| |
DivineTraveller wrote:
If players could gain an unfair advantage through modifying your interface, I think you might have a bigger issue at hand. I doubt many people are editing interfaces for any reason other than that. Its the same concept as allowing people to create custom macros. For every 1 person who uses it for a legit reason (of which there are a lot fewer for editing an interface) there are 100 who use it to gain unfair advantages, or to just flat out cheat. | |
Every time I've had someone modify an interface of mine, it was because they were suggesting an improvement. I still don't see why you would make your game that attached to the interface; you could abstract a lot of things away from it so it doesn't allow them access to those verbs or controls that you don't want them to see anyway.
| |
DivineTraveller wrote:
Every time I've had someone modify an interface of mine, it was because they were suggesting an improvement. I don't see why they would need access to the interface, or to actually edit it themselves for that purpose. Simply suggesting the changes should be enough. I still don't see why you would make your game that attached to the interface; you could abstract a lot of things away from it so it doesn't allow them access to those verbs or controls that you don't want them to see anyway. Abstract them how? Using the interface, instead of lame stat panels or right click menus, is exactly the way things should be going. The only better solution could be full HUD systems, but those are far more complex to design. | |
My method for preventing skin editing was to design my own interface. The skin in Ultimate Jigsaw is a hidden main window and two no-titlebar, non-resizable, no-statusbar windows, each with a child pane, and only a map and a browser in one child and a map in the other. Everything else, minimizing, maximizing, resizing, closing; it's all handled in the programming. In fact, the skin had to modified in Notepad to work properly as the skin editor would not let me use some of the specifications I needed.
| |
Falacy wrote:
Akushumi wrote: Yes, it most likely "removes access" to it through Dream Seeker's Options & Messages. But it's still just as accessible as every other resource file (icon, sound...) in your game. Loduwijk wrote: I don't quite agree. He has nice points. However, ... If you do not allow users of your product to change things how they like them, or, even worse, specifically take efforts to reduce what users can do with your product, then your product is strictly worse than it otherwise would be. No ifs, ands or buts, and it's not an opinion, it's a fact. This is his opinion and is, most definitely, wrong, due to the highlighted parts. If he wasn't so assertive about it, he could be given the benefit of the doubt and as such, but that wasn't the case. I'll also expand in a different direction: this easily falls into one of those few 'surprisingly actually always true' adages*: too much of something, even a good thing, is bad. Like too little. Generally in life, balance is very significant. Everything can be generally described in this way: no matter what it is, it's not good to have too little of it, and it's not good to have too much of it, either. The ideal is always somewhere in the middle. The key to 'good' is to find ways to reach that balance. Yes, this includes both seemingly positive and negative things, like money and disease. Possessing too much money can actually ruin your life. Being completely immune to disease would deprive you of the benefits of having small-time diseases once in a while, which range from sick day breaks and 'change of pace' of your lifestyle to finding out how nice your acquaintances are etc and how much they care about you. Product customization, especially application customization, is the same. Too little customization is obviously bad and will stand in the way of the users. Too much customization is quite obviously bad. It can make the user fail to grasp the actual intended experience of the product, perhaps even causing him to miss the author's vision when he otherwise wouldn't have. It can confuse and/or appall him. It may cause the user to become dependent on over-the-top customization. It may cause the user to waste so much time on doing so much customization that he barely actually uses the product anymore (yes, this happens). And it can make the application take much longer to design and program. Not to mention the issues it brings up in multiplayer games with balance, fairness, other players' experience, etc. * I don't remember at the time, but another one of those is probably this: Nothing in life is absolute. See what I did there? ;) But even so, I still mean everything I've said before, and that the previous (first) one is so very true it's surprising at first. Customization can be great. However, it should be completely handled through the game/interface itself, implemented by the developer(s). You directly went a step ahead. It should be this: Customization can be great. But it should be limited. | |
Hiro the Dragon King wrote:
My method for preventing skin editing was to design my own interface. You mean "populating the interface in runtime", don't you? You also probably mean "preventing skin viewing" rather than "preventing skin editing", as, though I may be wrong, I don't see how it does actual prevention. It's actually a nice way to prevent skin viewing through Options & Messages and hamper skin editing*. Obviously though, this is not absolute, as everything that's running on your computer is on it in plain form at some point in time, by necessity. And this is not even nearly a little bit close to absolute as the actual interface file is still locally stored in the project's RSC archive and the in the user's byond.rsc archive. Furthermore, while I haven't tried, it seems it'd probably be easier than you'd think to view and edit the interface using a standard memory editor. *Of course, doing all of the interface work via server-side commands in this manner has its own couple of disadvantages, so it probably shouldn't be done unless You're Really Paranoid or similar. | |
What you said and what I said are not mutually exclusive. While I did populate it at runtime, I did also design the entire interface system.
Yes but what would you do to the interface? If you ad anything, remove anything, move anything, the whole interface will break down. Every setting in the interface is pretty important to making the game work. While not actual prevention, I'd say messing with it and the game breaking would be deterrent enough to prevent it from happening again. Honestly, I designed the interface around features that I wanted which is what I hope that most people do. Sticking to a traditional interface would have made certain features impossible, such as resizing client.view with the window. I also did it just to say that I could. | |
Falacy wrote:
Wrong, in pretty much every way, along with almost every following argument you made. Even more-so when it comes to BYOND, considering vast majority of the users are complete noobs who do nothing but break the interface when attempting to modify it. Which is their right to do. Restricting people from doing stupid things in no way makes the product better. 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. Even if they do succeed, its almost entirely to gain an unfair advantage in the game. Not something any developer should support. I still have never bothered to use anything but a default interface in Byond for anything. Even when I've developed, I still used the default Dream Seeker interface. So perhaps I am unaware of how the interface could give someone an unfair advantage - please enlighten me. 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. If you are thinking of macros making it easy to create bots for games for real cheating, you don't need macros for that. It's barely more complex at all to make a bot click buttons, click specific objects on the map, fill in text fields, or do other such things; macros only make that a slight bit easier. If there's something else that I'm unaware of or am just overlooking, enlighten me please. Customization can be great. However, it should be completely handled through the game/interface itself, implemented by the developer(s). Any reasons or arguments for that statement? Allowing people to change anything they want, to anything else they want, is just ridiculous, How so? I think it just makes complete sense. I don't understand how some people are thinking it is ridiculous. and as we both mentioned, just leads to cheating more than anything. "just leads to cheating more than anything" is completely wrong. It does not "lead to cheating" at all. Maybe cheaters can help use alternate interfaces to make cheating a slight bit easier, but that does not mean that "this leads to cheating." It barely makes cheating easier anyway, and even where it makes it a tiny bit easier it's still not going to prevent someone from cheating if they can't modify the interface. So what? A bot has a few lines of code more now because it has to deal with your complicated interface instead of an easier one that someone designs for ease-of-use for a bot. That's not going to stop it at all, but it does stop people like me from increasing our enjoyment with your product. | |
Kaioken wrote:
This is his opinion and is, most definitely, wrong, due to the highlighted parts. I disagree. I can see how someone could misconstrue it as oppinion, but if you think about it logically, it's not really an oppinion at all. "Strictly better" means that it does not make anything worse, yet it does (or at least has the possibility of) make things better. If someone restricts what you can do, that means you can do less. If someone adds to what you can do, that means you can do more. In multiplayer online games, you need to add in such a way that it does not negatively impact the other players (I merely hinted at this in my original post though did not spend much time on it). It is really as simple as that. If I can do less, that is strictly worse than being able to do more, given that the something more isn't bad, as mentioned above. 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. If I can do more (nonbad) things, it is strictly a better product, even if I don't use those more things. Even if I do not use the added features, the product in and of itself is still strictly better and someone else might make use of that extra part and be happy they could do so. 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. Too much customization is quite obviously bad. It can make the user fail to grasp the actual intended experience of the product, perhaps even causing him to miss the author's vision when he otherwise wouldn't have. It can confuse and/or appall him. It may cause the user to become dependent on over-the-top customization. It may cause the user to waste so much time on doing so much customization that he barely actually uses the product anymore (yes, this happens). And, as the user, doing any or all of the above things is my right to do if I decide. Even if I personally do something stupid with the ability, the product itself is still strictly better for having that ability. 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. Having that ability makes it strictly better. And it can make the application take much longer to design and program. Which I took into consideration originally. That was why I didn't say "All developers should go out of their way to make it easy to alter the user interface." Rather, I said "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." (Not an exact quote of what I said: paraphrased) Not to mention the issues it brings up in multiplayer games with balance, fairness, other players' experience, etc. If it can truely negatively impact other players' experience, then it's not a feature that should be included. If it allows you to cheat, it's a bad feature, but merely having control over the interface (I'm thinking keyboard-button command layout and GUI-buttons and displayed information) does not allow you to cheat. If it only affects balance because a user happens to use a very nice keyboard layout which allows them to play the game much more efficiently and allows the player to react better and press things faster (for example, maybe moving keyboard buttons -> command mappings so that commands you use frequently are closer to the hand you use more), then that is not a bad thing at all; it's just allowing you to personally play the game better. That is completely fair. You directly went a step ahead. It should be this: In multiplayer games, it should be limited to the interface (in Byond terms, the skin). Nothing more, but also nothing less, unless there's something about altering skins that allows you to cheat which I'm unaware of. I'm so dead-set on this, that I think it would be awesome (though impractical) if all games came with an API that you could hook into which allows you full and complete control over the user interface. For example, if Starcraft 2 allowed you to provide it a DLL file which handled keyboard command mappings, how the on-screen information looked, which on-screen components showed up and which did not, and where they were placed, and so on, then I would take advantage of that for sure, and I would enjoy the game even more for it. I would start by removing all the HUD stuff that I don't care about, I would change the hotkeys for certain commands (some of them don't seem intuitive to me and I keep accidentally pressing the wrong buttons, like P for "build pylon" when it's something like E or Y now). I played Ragnorok Online for a short while. One of the most frustrating things for me was that it has such a huge number of commands, windows, and other interface features that were difficult to remember. If I could have customized everything completely, I would have had a MUCH better experience with the game and probably would have played it more. I definitely would have taken the time to write my own DLLs in C or C++ to hook into a UI API if it provided such a feature. Don't include anything as part of the user interface that should not be part of the user interface. Obviously players should not be able to add an element to the UI that displays "Boss HP: 50/100" if the user isn't normally able to see the boss' HP amount; it's not part of the UI! But if it is, there's no problem with making me able to customize its display however I want. And remember, players altering the UI to make it easier for their bots to use it (that seemed to me to be Falacy's main problem with it) does not ENABLE the player to cheat, it only makes it very slightly easier for them to cheat. And not a lot easier either. Anyone who really knows how to make cheating tools in the first place either knows how to use the interface as-is anyway and would only modify the UI to save themselves 5 minutes of work, or, if they don't know how to do that, they already know 90% of what they need and figure out the rest 2 minutes of Googling, and these are going to be the people that know how to use Google and are not afraid to do so. So, to recap: #1 Do not include any way to cheat in the UI against other players in multiplayer games. #2 Do not waste your time and resources to artificially restrict what the player can do with their interface (ie: specifically program your product to do less). #3 You never have to bother making your game better (it's your choice as the developer to make whatever good or stupid choices you want), but you have the ability to give your users more features by letting them have control over the interface! (A feature! What a novel idea) Given the three above points, if you follow 1 and 2, your game is strictly better than if you did not follow 1 and 2. If you then choose to take the time to implement #3, then your game is strictly even better yet than if you do just 1 and 2. Strictly better because it has not made anything worse, nothing at all, yet it has the possibility of making things better for users that want to take advantage of it. | |
Hiro the Dragon King wrote:
What you said and what I said are not mutually exclusive. That doesn't have anything to do with what I said. While I did populate it at runtime, I did also design the entire interface system. You're missing the point. 1) Designing the entire interface system is fairly standard. 2) Doing so does not tie in to hampering skin viewing or editing at all. Populating the interface at runtime does. Hence I corrected you by using the relevant description instead of the irrelevant one. Yes but what would you do to the interface? If you ad anything, remove anything, move anything, the whole interface will break down. Why would it? You're talking as if there's a bomb with a motion sensor in there. Globally speaking, even if the developer actually polls for the current windows every second etc and filters out ones that shouldn't be there, you could find out a valid window ID and should be able to freely add your own windows, with whatever customization you want. Of course, it may take some experimenting to get everything you want to work correctly (if you wanted you could always go as far as copying from the default by taking a look at the interface commands using a memory or packets viewer). Since you apparently did not realize it: rest assured, I'm not criticizing your interface. | |