multi-button mouse and middle button functions

Case number:845813-985815
Topic:Game: Tools
Opened by:Alazarus_long
Opened on:Wednesday, March 18, 2009 - 22:53
Last modified:Saturday, December 1, 2012 - 01:40

In PULL mode, the middle button on the mouse is used for 3 things (I think...more?):

1. Shift-ZOOM
2. Click (or double click) to apply/remove Freeze
3. Drag-Rubberband

Although #1 is fine the way it is, I am discovering that #2 and #3  are not so happy together.

It seems like a size-able number of the times I try to freeze something, a rubber band will accidently appear. Does this happen to any of you?

And then I wonder how many people still use single button mice.

Then I think, well... if they are few, then it might make sense to start using the dual-button capabilities and make either #2 or #3 respond to some other combination of buttons (Right/Left for instance, like Shift-Click for a key/mouse specifier). Just to reduce the accidental misapplications...

I don't know what other people think, but that's how I see it.

I suggest left/right mouse drag for placing rubber bands, for two main reasons:

1. It is easier to perform a double click with one button, rather than two, due to human reaction error. Although a double click night be clumsy, freezing or un-freezing a section is already done that way, so placing rubber bands would seem to be the likely candidate for that button.

2.  Ergonomically speaking, I would think that most people's fingers would already be positioned right where they need to be, naturally, for a dual button hold/drag using the left and right buttons.

(Wed, 03/18/2009 - 22:53  |  5 comments)

axcho's picture
User offline. Last seen 7 years 10 weeks ago. Offline
Joined: 12/18/2007
Groups: None
Status: Open » Open

I've always held to the position that it should be possible to play the game entirely without using more than one mouse button. Standard practice for any casual game.

Given that this probably won't change right away, I do like your idea of using left+right as a substitute to a middle click or drag. Currently the intro puzzles tell new players to hold shift and click (as an alternative to middle click) for locks and rubber bands, which seems to work decently for the players I've had test the game.

What I think we're moving toward (or at least I hope we are) is making every action independent of the things that trigger it, so not only will you be able to choose your own hotkeys, but also assign mouse buttons, and even make macros to execute actions. There will need to be some sort of easy-to-use inventory/customization system to manage all this stuff, which as far as I know hasn't been given any thought yet. Hopefully the appropriate attention will be given to the design of this system...

Joined: 03/02/2009
Groups: None

Show me a game of this calibre (sophistication) that uses only one button, I'll show you an old game or one that isn't terribly successful. I've always held that things should be designed so they makes sense, regardless of the number of buttons or hot keys used. Foldit falls under the category of CAD, not Pacman. We are long  gone from the days where Macintosh one-button mice ruled the world.

If even 10-20% of the time rubber bands are accidently applied when using this multi-function button, then the dual assignment to this button for rubber band application and freeze was conceived incorrectly from the start. It's a time waster as it is.

I've noticed you talking about "an inventory system". You said the same thing last time I posted a suggestion. I don't see that qualifier in all your replies though. In fact, for many, you enthusiastically discuss the proposed features brought to the game by the suggester and suggest that you will be or will try to implement the feature request. I'm not sure why my request is being dismissed to some nebulous future implementation of some vague "inventory system". The need is real and immediate, since this button combo presently used results in errors. and wasted time.

I am particularily leery after having read the following lines back to back:

'What I think we're moving toward (or at least I hope we are) is making every action independent of the things that trigger it,
Hopefully the appropriate attention will be given to the design of this system..."

In both lines, there is an overt implication that this "inventory system", whatever that actually means, (presumably some odd way of saying "configuration menu" may not in fact be implemented, unless yor team decides to complete it that task.

For instance, in your reply to the suggestion for moving side chain notes to pull mode, you replied

"I like this too"

"I'll see if I can get this added in soon."

I thought there will be an inventory system that will handle such changes... . Sorry, but since you respond to one as though it was valid and the other is dismissed with little more than a suggestions that maybe sometime in the future the player might be able to control the behavior themselves seems a bit "puzzling"

finally, for what it's worth... this isn't a biochem is a game tool request. I don't know why it was reassigned as such. I selected "tool" when I first posted. If you would reassign it to its original selection I would apreciate it.

axcho's picture
User offline. Last seen 7 years 10 weeks ago. Offline
Joined: 12/18/2007
Groups: None
Topic: Biochem » Game: Tools

It sounds like you are feeling frustrated because you would like your requests to receive the same degree of enthusiasm and assurance that you have seen others receive? And that you would like more certainty in what the responses are promising?

If it may help, I can give you the facts on what I know to be true about the inventory system, and what, conversely, is simply my hope.

This is for sure:

We are making all the actions in the game encapsulated and independent of the things that trigger them. So far only the Tweak and Rebuild tools remain to be converted to this "Action" framework. By Monday all the Foldit tools will be "Actions".

We are connecting up those Actions to macros, so that you can create a sequence of Actions that will be performed automatically. This is already functional, to the extent that today I witnessed the creation of a "backbone walk" macro and saw it running in the game.

This is likely:

Once we have our Actions all nice and encapsulated, it is likely that people will begin thinking about how we can best take advantage of this new infrastructure. The first obvious step I'd imagine would be to make hotkeys assignable, which would require rewriting the way hotkeys are assigned and creating an interface for choosing hotkeys. Perhaps the developer who implemented macros would be the one to take care of this, perhaps not.

The second thing I imagine might happen is to make actions assignable to any mouse button. This would require a more significant addition to the interface to allow you to assign functions to mouse buttons. I know I will push for this, and I imagine that Seth would too, but I cannot guarantee when it will happen, as to the extent that there is a hierarchy of decision-making on the Foldit team, I am at the very bottom of it.

However, I know that there is a nontrivial amount of flux in the way the control scheme is headed, as there have been experiments with a new selection approach as a result of implementing the macros. What this means is that now is probably the best time to suggest and experiment with new control schemes, before it solidifies again.

This is what I hope:

With such a transition point in Foldit's interface, I can imagine changes as drastic as completely redesigning the lower
left menu with the actions tab to be modular and customizable, to be entirely feasible and likely to occur. The sum of the changes I've mentioned so far - hotkey settings, mouse button settings, and modular actions palettes - make up what I refer to as the "inventory system".

I'm pretty sure that at least some of these inventory system components will be implemented, if not all of them. What I don't know is whether they will be combined in any coherent or organized way, into a unified "system". I also don't know if the appropriate attention will be paid to usability, game design, impacts on level design, graphic design, whatever. I hope that it will be.

The feasibility of your suggested change would only depend on the existence of a way to assign actions to mouse buttons, which I think is very likely to happen, though I don't know when.

But there have been many suggestions for this tool or that tool, to which I have replied that once we get an inventory system set up, those would be great additions. What I envision there is a consistent and more-or-less automated way to take a new Action, created perhaps through a Macro by combining atomic Actions or by a developer implementing a new Atomic action from scratch, and add it to the game packaged with a name, a description, icon, any associated tutorial puzzles (which would require a level editor also) and maybe even a cost in Foldit points (or whatever) that you can earn through playing the game. The new tool would be added to a catalog of tools that would be easily browse-able and search-able both in-game and on the website, and could easily be downloaded to your game, organized into your tool collection and from which you may assign it to a button, hotkey, and/or slot in your actions palette(s).

That's what I'm hoping for. You tell me whether it will ever happen.

"Show me a game of this calibre (sophistication) that uses only one
button, I'll show you an old game or one that isn't terribly successful."

Sure thing: World of Goo. My favorite example.

But yes, the idea is not too restrict players to one button, simply to make it possible. I mean, if I can't even conceive of a one-button mouse control scheme for a game, that's a problem. But in my imagining, that possibility would be a mere side effect of a much greater system scaling to an arbitrary amount of complexity.

axcho's picture
User offline. Last seen 7 years 10 weeks ago. Offline
Joined: 12/18/2007
Groups: None

The following text copied from The Princess Rescuing Application: Slides by Daniel Cook:


When you start turning your tools into modular swappable elements, you need an easy way to manage them. So you create a new basic tool that you teach players to use immediately. It is called an inventory system. This is one of the earliest tools you introduce the player to and you make sure that they know how to use it. By doing so, you unlock all the other modular tools out there.

The basic inventory pattern is simple:
Long term storage: Any items or tools that you collect over the course of learning the game.
Short term active usage: The current items or tools that you are using right now. There are often a fixed number of slots based off ‘best practices’
Item acquisition: A system for slowly introducing tools into your long term storage.

Some modern apps have inventory systems as well. They tend to have a few problems.
Optional: They are treated as optional. Many users don’t know how to use them and the inventory systems are often quite baroque.
Set up for expandability, not best practices: Product customization is typically seen as the domain of experts, not everyday users. As such the systems focus on power user’s need for massive flexibility They don’t  focus on the 80-90% of scenarios that a moderately skilled user will encounter. Contrast the power of the Adobe palette system with the ability to switch out a single weapon slot in Zelda. In the latter, quick inventory switches are easy and common so that you have the minimal set of tools that you need at any one moment. Most apps err on the side of having too many features up on the screen at once since the cost of switching is high.

• Active list is short and contains only the tools necessary for the tasks at hand.
• Active list is pre-organized: Armor, helmet, runes
• Storage list is easy access but usually modal.
• Ability to discard excess items"

Joined: 12/06/2008
Groups: Contenders
Status: Open » Closed

No action, no comments in three and a half years. Poster is no longer a player. Closing this feedback.


Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, RosettaCommons