I'm making a roguelike (-like) game, somewhat like Project Zomboid or Don't Starve. In my game, there are many different object in the world that the player can interact with; there are also many items, some of which may be required for a particular interaction.

Physically, all I have to trigger the interaction is the mouse click: when player clicks on an object, something happens (adding right-click is an option too, but staying with just one button is preferable).

There are several problems here:

  1. For a given object, there might be several interactions possible. I might want do drive the car, or access its truk, or refuel it etc.
  2. Some interactions may require an item: I need an axe to chop down trees or a fuel source to refuel a car.
  3. Some interactions may be non-obvious, so I need to have some sort of discovery mechanism. Some way to say to the player: "You could chop down this tree if you had an axe".
  4. Some interactions should be very quick. Whacking an enemy with a bat should NOT require clicking and then choosing an action from menu; just clicking should work.
  5. Added The list of objects, items and interactions is pretty open-ended. I'm still developing the game, and in the future players might make mods. This means that the interface must be generic enough to adapt to new interactions automatically.

Given these constraints, I'm really struggling to devise a good interface for interactions. I can't show a menu of all possible actions on click, because that would break (4). I can't just leave one single on-click action, because that would break (3) and probably (1).

How can I present all options to the player in a usable and preferably obvious way?


4 Answers 4



Click vs click-and-hold. Click performs the "default" action for the item. Attacking for enemies, opening for chests, etc.

Click-and-hold can pop up a radial menu. Player moves slightly toward the option they want and lets go of the mouse to initiate the action.

Optionally, if the user lets go once the menu is open (while the cursor is still in the central "dead zone"), then leave the menu open until the user clicks again.

It's also quite reasonable to use right-click for opening the alternatives menu.

You should also condider a mouse icon that indicates what the default action is and an extra symbol to denote if more options are available, or show the radial menu dimmed out / transparent to indicate that it is available.

This is a less-than-perfect system. You might consider gamepad support and contextual keys. e.g. X is always "attack" if available, "mount" for ridable objects, etc., and then you can pop up a small display for "(X) - Drive" when on such an object.

You can also just allow more keys or key modifiers, as suggested. Supporting more than one is only a problem if you don't tell the user about them in an adequate way. A small introductory/tutorial area that requires the user to use all the extra keys (in a fun, non-hand-holding way) works well. Small reminders or on-screen hints in appropriate places and obstacles that require a certain key use to pass in a natural "makes sense to be there" tutorial area works a lot better than a contrived tutorial location with forced "click X now or you can't do anything" kind of things and is easier to implement anyway.


Each Item Definition, shared by all instances of a particular item (some "unique items" may be the only instance of a particular definition) should contain a list of Actions. Each action should denote using a system-defined enumeration what Interaction Method it uses. This enum should map to a keyboard command list for keyboard input (if supported), gamepad buttons (if supported), and icons (for mouse input) plus string names (localizable, of course).

Each action then has a Response Type, which is what happens when that action is performed. It may make sense for this to be implicit by the interaction method, e.g. "Open" always opens the item's inventory. For maximal flexibility you might wants scripts or other special behavior attached to actions, such that you can have actions like "ring bell" or "kick" that do different things for different object. You could also simplify this by simple having an event sent for a particular interaction method type which can be intercepted by a script or go to a default system.

An item definition should not be allowed to contain multiple actions with the same interaction method. You might also want to have a way of denoting conflicts between interaction methods, especially for gamepad support (e.g. two methods that both map to the "x" button should never be on the same object).

At this point, you can generate mouse UI or gamepad UI for any object or check if a particular key press is relevant to the object. You can also invoke a particular response event handler or generic script.

You should also consider how you select the "defualt" action for the mouse assuming you go with the interaction ideas above. You might give each interaction method an innate priority, such that the most "important" method (like attack) is always the default. You might just use the first one listed on an item definition. You might allow the item definition to assign priorities. You might allow the item definition to just explicitly set a default. I would prefer anything explicit since it allows items to have no default, which is good if you want objects that should not be accidentally actionable but require a little more work. (for the mouse UI I presented, clicking an object with no default might do nothing or it might bring up the radial menu, your choice)

Lastly, consider supporting implicit actions. All enemies should have an implicit Attack->Combat action. Objects with inventories should have an implicit Open->Inventory action. Explicitly set actions that conflict with implicit ones should have priority.


You could change the mouse-pointer to show possible interactions and perform the appropriate action automatically, eg:

  • A steering-wheel icon when you hover over the car's driver's seat (clicking will drive the car)
  • A container icon when you hover over the car's trunk (clicking will open it)
  • A canister icon when you hover over the car's fuel-thingy (clicking will refuel it)
  • A bash-over-the-head icon when you hover over a monster

To avoid having to design a million icons, there could be just one for each type of interaction:

  • use (for driving, refuelling, chopping down trees etc)
  • pick-up (for picking up weapons, fuel, chopped wood)
  • inspect (for looking into the trunk)
  • attack (for shooting, bashing-over-the-head, "use chainsaw with zombie", etc)

If the player can't perform the action (don't have the car-keys, no fuel, no weapon, etc) you could give the icon a different colour or cross it out or have your character simply shrug their shoulders when you click

As for one-button input-methods: there's also double-click, click-and-hold, swipe-left/-right/-up/-down, holding the shift-key down, etc

(That being said, why would you be limited to just one mouse-button?! If even pigeons can figure out how to use multiple buttons, then certainly so can gamers :-D )

[edit:] ok, so the game-objects might be too small to target different areas. How about having to hold down keys while clicking?

  • just click: walk
  • W + click: run
  • A + click: pick-up
  • S + click: move the object
  • D + click: bash the object (to attack, dismantle, etc)

Other option: differentiate between critical and non-critical objects. I.e. clicking a living (or undead) enemy will always attack them. Clicking a dead enemy/tree/car/what-ever will perform the most recent action. To change the most recent action, hold down the mouse-button to bring up a context-menu.

  • \$\begingroup\$ I'm not "limited", I just don't think it's a good idea to make players figure out what button to press. I'd rather they figure out how to escape zombies (-8 \$\endgroup\$
    – Nevermind
    Jun 10, 2013 at 10:04
  • \$\begingroup\$ Also, changing mouse pointer is not very good in case there are multiple possible interactions. It works with a car, but what if you can "open" a chest or "move" it or "dismantle" it? And the chest is too small to reliably target different parts of it (as is the case with my game) \$\endgroup\$
    – Nevermind
    Jun 10, 2013 at 10:07
  • \$\begingroup\$ They don't have to figure it out, just tell them: left button = run, right button = attack, middle button = get carrot \$\endgroup\$ Jun 10, 2013 at 10:09
  • \$\begingroup\$ hm ok, in that case, how about this: clicking on the chest when it's full will open it, clicking on it when it's empty will dismantle it, dragging/swiping over the chest will move it? \$\endgroup\$ Jun 10, 2013 at 10:11
  • \$\begingroup\$ That's just for the chest. I'm adding new objects and actions constantly, and designing a custom interface for every object would be a huge annoyance. I'd really prefer some generic mechanism. \$\endgroup\$
    – Nevermind
    Jun 10, 2013 at 10:19

Even if "all you have is the mouse," you've got several mouse gestures available. Click, click-and-hold, double-click, and click-and-drag combine to give the effect you're after. A single click would be the default action. If the user tries to do something, but doesn't have a required item, launch a toast or similar non-blocking alert describing why. Click-and-hold or click-and-drag can bring up a menu to select an action-- this also becomes a discovery mechanism, in combination with the alert you give the user when they try to do something they can't do right now.

  • \$\begingroup\$ I like this idea where clicking gives the default action and click-and-hold brings up the menu. It allows for quick actions (IE fighting zombies) while still allowing for more exotic actions through the menu screen (IE throwing a grenade at a zombie). \$\endgroup\$ Jun 10, 2013 at 16:09

Keep in mind that limiting players to a left mouse button for all forms of interaction may be easier for you as the designer, but more complicated for them as players. We're used to standard interactions in games--WSAD to move, spacebar to jump, left click to attack, right click to inspect/zoom/target, etc.

The more you put on that one button, the greater the learning curve for your game. It also relies heavily on good mechanics. If you use click and drag right, but they click and drag slightly downward, will the menu respond correctly? See this in action: Play Sorcery on PS3 MOVE. If you shake the MOVE controller wrong, you don't get the desired spell.

Short answer? Use Button 3 to interact with everything. Left click to fight, scroll button to see item options/click on button to select the chosen option. Pop up clues are pretty standard ways of getting players to look for new ways to interact with an object or find a matching tool. "You need fire to create an explosion" leads them to find a way to make a fire.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .