GodotTouchInputManager: gesture recognition bolted onto Godot's input system

What the addon does with touch events

Godot Touch Input Manager, abbreviated GDTIM, is an asset that improves touch input support in the Godot game engine, adding new gestures and translating mouse input to touch input. The mechanism is the interesting part, and it is not a separate input system that you poll.

The addon analyses touch input, and when a gesture is detected it creates a Custom Input Event corresponding to that gesture and feeds it up to Godot's built-in Input Event system through the parse_input_event path, so it triggers functions like _input(InputEvent event). There is also a signal for each gesture if you prefer signals to the event callback.

That design decision is what makes the addon worth considering. A gesture recogniser that emits its own signals only is usable if you rewrite your input handling to listen to those signals. One that injects custom InputEvent subclasses into the standard event stream works with the input code you already have, and with the editor's input map, and with anything else in the engine that consumes input events.

The audience is a Godot developer adding touch controls to a game, and the scope is deliberately a plugin rather than a fork. The repository is not archived, the last push was on 2026-06-24, and the tagged releases are 4.x-v2.1.2 from 2023-05-02 and v2.1.2 from 2022-12-31, with v2.1.1 before that. The separate 3.x and 4.x tags matter, because a Godot 3 addon and a Godot 4 addon are not interchangeable.

The licence is MIT, and the project is sponsored by Scoundrel Cats, a roguelike card game.

Twelve gestures, and one shared event class

The gesture table is the API, and it is worth reading closely because there is a detail in it that will bite you if you skim.

Five gestures are single finger. Single finger touch with the single_touch signal, single finger tap, single finger long press, single finger drag, and single finger swipe. Four are multi-finger. Multiple finger tap, multiple finger long press, multiple finger drag, where the description notes the same direction, and multiple finger swipe, described as a fast drag and release with multiple fingers.

Then there are the two-finger combinations. Pinch, described as a drag with multiple fingers inward or outward, and twist, a drag with multiple fingers rotating. A twelfth entry, raw_gesture, exposes the raw gesture state rather than a classified gesture.

The detail worth catching is in the multiple finger swipe row. The table lists its custom input event and signal argument as InputEventMultiScreenTap, the same class the multiple finger tap row points to, and it links to the same wiki page. Everywhere else the mapping is one to one, so this reads as a copy and paste slip in the documentation rather than a deliberate reuse, but the README is the specification you are working from, and if you branch on multi_swipe you should check the class you actually receive.

Every one of these has a matching custom InputEvent class, and the wiki pages for them are linked from the table, so the event classes are documented rather than left to inference.

Autoloading InputManager.gd is the whole installation

The install is four steps and there is no package manager involved.

Download the latest release from the releases page of the repository, extract the downloaded zip file somewhere in your project, locate the extracted InputManager.gd and Autoload it, and you are done. After that you can use the GDTIM signals and custom input events.

That third step is the one that carries design consequences. An autoload in Godot is a singleton that lives for the whole life of the application, registered in the project settings and available to every scene. The README frames the benefit simply: you just need to autoload a script and it will start analyzing the touch input.

The tradeoff is that the recogniser is always running, even on menus and cutscenes where there is no touch input to interpret, and even on a desktop where the project is being tested with a mouse. The documentation does not describe a way to disable it per scene, and the mouse-to-touch translation feature, which is described as part of what the asset does, is exactly the kind of behaviour you might want to turn off while testing with a mouse and on if a touchscreen is present.

The repository layout is small and matches the documentation. At the top level there is InputManager.gd as the autoloaded entry point, a CustomInputEvents/ directory holding the event classes, RawGesture.gd for the raw gesture state, and Util.gd for helpers. There is no plugin.cfg visible in the listing, so this is wired in as a plain autoload rather than installed through the editor's plugin system, which means the project settings change is manual.

Gesture emulation, and the input actions that trigger them

The gesture emulation section is the feature that makes the addon testable, and it works in the opposite direction from normal gesture handling.

The gestures can be triggered by named input actions with specific names. If the input action does not exist, there is a default event that will trigger the gesture. The documentation then gives a table of the default event and the input action names that will trigger each emulatable gesture.

So instead of a tester physically performing a two-finger twist on a phone, you can bind a key combination to an input action and have the addon synthesise the twist. That is a considerable quality-of-life difference for a mobile game, where every gesture is otherwise awkward to exercise on a desk.

The mechanism runs through Godot's input map, the same named action system used for ordinary key bindings, and the addon looks for those actions as triggers. The names matter, because they are the contract between your project settings and the addon, and the documentation lists them.

The default event behaviour is worth noting as well. If the action does not exist, a default event fires the gesture, so an unconfigured project still gets behaviour rather than silence. For a project that ships to devices, that fallback is a reasonable default, and for a project where a stray key combination would trigger a camera zoom it is a thing to override.

Mouse-to-touch translation, and why it cuts both ways

The description lists translation of mouse input to touch input among the things the asset does, and this is the feature most likely to be either your main reason for using it or your main reason to leave it alone.

The value is obvious in the testing case. A desktop build of a mobile game has no touchscreen, so a developer who cannot simulate touches cannot test any of the touch code they wrote. If the addon maps mouse input to the touch stream, then the same gesture recogniser runs in the editor, on a desktop build and on a phone, and the touch code path is exercised everywhere.

The cost is that a project which already handles mouse input separately now has two input streams that might overlap. A drag on the mouse is a single finger drag, so an action bound to a mouse drag and an action bound to a single finger drag can both fire from one gesture unless the project is careful about which paths it consumes.

The documentation visible here does not describe a setting to scope the translation, or a way to restrict it to specific scenes. The Configuration section is listed in the table of contents, and its options are the place to check what can be scoped or disabled. If mouse translation is central to your plan, that wiki page is the first place to read, because it decides whether you can turn the behaviour off for the parts of your game that handle the mouse directly.

Two pull requests to the engine, and the version split

There are two active pull requests that add some of the GDTIM gestures as native Godot events, one for version 3.x and one for version 4.x, and the README invites readers to show support there.

That tells you something about the long-term position of the project. Godot has its own input event model, and a gesture recogniser that lives in a third-party addon will always be one layer above the engine. If the gestures become native events, the addon either becomes redundant for those specific gestures or has to translate native events into its own classes, which is exactly the kind of duplication that creates version friction.

For an adopter, the practical consequence is a decision about coupling. Using the addon means adopting a class hierarchy that upstream may eventually provide. Not using it means writing the recogniser yourself, which is a substantial piece of work involving touch tracking, timing thresholds and multi-pointer state, but leaves you free of the addon's release cadence.

The repository tags make that choice concrete. The 4.x branch has a tag at v2.1.2 from 2023-05-02 and the 3.x branch has its own v2.1.2 from 2022-12-31, with v2.1.1 in between. Two branches with the same version number is a maintenance hazard for a plugin, because a project on Godot 4 and a project on Godot 3 will report the same plugin version while running different code.

The two example projects linked from the README are the fastest way to see the intended usage: GodotTouchInputManager-Demo, which is a general demo, and GestureControlledCamera2D, which shows a specific case, a camera driven by gestures, which is the situation where pinch and twist matter most.

Where this addon is the wrong choice

The first case is a project that only needs taps and swipes. Godot's own input system handles single touch, and a swipe is not a hard problem to implement for a single pointer. An always-on autoload that runs a recogniser over every touch event is more machinery than the job needs, and the recognition cost is paid on every frame that has input activity, whether or not the game cares about gestures.

The second case is a game with a hard performance budget on low-end mobile hardware, which is exactly the kind of game that needs touch gestures. The recogniser runs in GDScript, on the main thread, alongside your game logic, and the documentation does not describe any way to move that work off the main thread or to skip recognition when a scene does not use it. For a project where the frame budget is already tight, that is a real concern, and it is one the README does not address.

The third case is a project that needs the gestures to be native engine features, for instance because the project wants to share its input handling with another Godot project, or because it needs the gestures to work in the editor's own UI rather than only in the game. An addon cannot provide that.

The alternative worth comparing is a different addon or your own recogniser. There are other Godot gesture libraries, and the difference in approach between them and GDTIM would be in what they emit and how they hook into the engine, which is exactly what you would compare by reading the two gesture tables side by side. The other alternative is writing it yourself, which for a project needing only two or three specific gestures can be less work than adopting and configuring someone else's recogniser, and gives you full control over timing thresholds, which is where most gesture bugs live. The engine pull requests suggest that upstream recognition is the direction the ecosystem is heading, so a project that can wait has an option that no addon can match.

Editorial conclusion

GodotTouchInputManager fits a Godot project that needs pinch, twist, long press or multi-finger gestures and does not want to write gesture recognition from scratch, because the gestures arrive as ordinary InputEvent subclasses and your existing _input handling picks them up. It is the wrong choice for a project that only needs taps and swipes, since the engine already covers those, and it is the wrong choice for a game with a tight frame budget, because the recognition runs as an always-on autoload. Before adopting it, check the release branch you need against your engine version, since the repository carries separate 3.x and 4.x tags, and read the gesture emulation table so you know which input actions will trigger a gesture before you bind your own.

Frequently asked questions

Official sources

1. Federico-Ciuffardi/GodotTouchInputManager on GitHub
2. Issues
3. License: MIT
4. README
5. Releases