Unzip the files somewhere - perhaps a separate directory, for convenience.

If the game is a single executable, but you know that it's made with GM, try extracting it via 7-zip - it might be a self-extracting cabinet;

If you downloaded (from the sheet, etc.) any game-specific configuration files (GMT.ini / GMT-Gamepad.lua / custom cursors), unzip them into the game directory.

This opens a lobby menu without actually hosting a server on a port.

There are several uses for this:

• You can verify that GMT doesn't break the game in some way without needing a second player/window.
• You can use gamepad remapping feature to use the desired gamepad in games that do not natively support gamepad selection.
• You can use/test KB+M -> gamepad mapping scripts.

You enter a (UDP) port, and GMT hosts a server on that port.
Perhaps you've been here before, an absolute classic of P2P networking.

Also, don't forget to allow the game in your firewall if you have it enabled - since the game didn't do networking before, Windows most likely didn't prompt you to add a firewall whitelist entry for it.

Once connected, you can adjust delay setting (make sure it's high enough), remap gamepads if you need to, and start the actual game.

You enter an IP and port, and we'll try to connect to it - by which I mean, repeatedly ping that endpoint with "hello" packets until they respond or you cancel.

Once connected, remap gamepads if you need to, and wait for host to start the game.

The absolute classic option of lockstep networking, delay determines input latency but also how long we can wait for remote player's inputs before we have to pause the game and wait for them.

This peculiarly named option is actually very simple:
Let's suppose that you have a friend who cannot port forward, but they do have way more stuff unlocked in-game, or a large collection of downloaded content, or something else of great value for your sessions.

This option lets you swap places with them, instead making them the game host (as far as sync logic is concerned).

The new host can swap authority back if they need to.

This small menu allows to rearrange gamepads as seen by the game.

Doing so allows you to pick non-overlapping gamepad slots (suppose both of you have a gamepad in slot 1, but the game should see them as 1 and 2), as well as being able to assign a simulated gamepad to one of the slots.

First you can view the current positioning of gamepads per slot, then you pick the source slot, then you pick the destination slot, and the gamepads are swapped between them.

Note that some games might only listen to gamepads in the first 4 slots.

Before you start with this section, see if someone already made a configuration for the game in question via the supported games sheet.

Possible causes:

• The game is not made with GameMaker.
  As in, so different from GM that it doesn't even initialize in the same way.
• The game is a self-extracting archive.
  (try extracting it via 7-zip)
• The game relaunches for one or other reason.
  GMT will auto-detect use of Steam API and prompt for steps required to workaround this, but other platform-specific launchers may require different approaches.
• You have some software (perhaps an overzealous antivirus?) that disables DLL injection or other key components of Detours library.

Possible causes:

• The game isn't actually made in GameMaker at all
• The game is made in a much older version of GameMaker
  (to the point that it doesn't look like a GM game to GMT)

This means that the game is made with GameMaker: Studio, but an old enough version that GMT is unable to use the normal approach to processing functions.

If the game is spotting a data.win file in its directory, you can try copying an executable from a slightly newer game to its directory and running that instead.

You can also try asking the game's author to try compiling the game in a slightly newer version of GameMaker: Studio if they have time.

Same as with Troubleshooting section, it is possible that someone already figured out the issue and contributed a configuration file that fixes the issue(s) - see supported games sheet.

As with any tool that might seem to be working through means of pure magic, there's ought to be some sort of a catch - and I don't mean selling your soul or anything.

In case of GMT, some games might desynchronize. A desync is a game state divergence to the point where you aren't really playing the game together anymore, rather sending inputs to a remote player in an unlike situation.

GMT will auto-detect desyncs based on a set of common metrics (number of active game objects, RNG state, active game level, etc.) and notify both of you of the fact.

GMT will also save a screenshot and a summary of game state for each of the players, which can then be combined for inspection (either by eye in case of screenshots, or via "text diff" tools for states) to figure out what might've went wrong.

This is perhaps the biggest curse of GMT: GameMaker games do a reasonable thing and store mouse cursor coordinates as a fraction-less number relative to window's top-left corner.

As result, if your windows are of different sizes (or, if you are running in fullscreen, your screens are), mouse position will not match up between players.

This being a common issue, GMT supports a number of workarounds:

• If one player's screen is larger than the other's, GMT will attempt to fix this automatically by adjusting reported window size and offset (thus acting as if the smaller screen is centered in the middle of the larger screen).
  This should take care of oddities in most games.
• Many games support running in windowed mode and adjusting window size, so you can try that first.
• GMT-Windowed.bat will run the game in a window and prevent it from going full-screen through common means.
• Adjusting window_set_size in tweaks section of GMT.ini allows to override game window size and prevent the game from changing it normally.
• Adjusting display_get_size in tweaks section of GMT.ini allows to override screen resolution reported to the game.

Some games use Steam User IDs for determining save directory name, which you can usually tell by navigating there and checking if there's a long-number-name directory (e.g. 76561198025072099).

To force the game to report the same Steam ID for both players, you can use steam_get_user_steam_id in tweaks section of GMT.ini.

In theory yes, but in practice this requires a complete rewrite for both of them.

This is due to runtime differences, OS differences, CPU instruction differences, and differences in how hooking/instrumentation is done per-OS.

In other words, unless we suddenly invent infinite time or something, you might have to use WINE/Crossover/Proton to play the win32 versions of the games.

While some of the work I've done for GMT is non-GameMaker-specific, supporting arbitrary games is an impressive task to undertake, as pretty much any goal can be achieved in multiple ways, and there is no warranty of any given game using any given approach for doing so.

Maintaining such a tool is likely also a full-time job, so, yeah.

While you may have any number of players per computer, GMT only supports having 2 computers in a game session.

The decision was made to keep the tool's (already strange-looking) netcode bearable to work with - things are so much easier when you just have to make sure that the other player is good to go rather than making sure that all players are good to go, and also making sure that if someone drops out, everyone are up to date with they were doing, and also account for possibility of some players losing connections to each other, and...

So, yeah, complexity. Maybe someday.

In theory yes, but it would be less cool (or far more costly) than you think.

So, as is evident from the Lua API for gamepads, having Lua code that interacts with GML instances is a possibility, albeit with noticeable development costs in terms of making GML functions available to Lua and not easily crashing the game.

However, "simply" being able to change variables and call functions isn't nearly enough - to be able to actually introduce new content to the game you most often need to be able to add new objects, scripts, or even segments to existing scripts (for example, Nuclear Throne handles all weapon firing code in one massive script with a 125-case switch-block).

Doing so in a way that works with both VM and YYC games and a wide variety of GameMaker versions (which had fairly drastic internal structure changes in past) is a task of great complexity and development/maintenance cost.

There are also ethical considerations with it suddenly being possible to inject arbitrary code into arbitrary games, especially for games with online interactions, leaderboards, or active speedrunning communities.

Great question!

Firstly, it is nice to release things for free when you can - moreso when they can change how people can play (some of the) games as such.

But also it is impossible to warrant that the tool would work for every single game, and it would surely be a shame to buy a tool only to find that it doesn't work for what you were going to use it for. And other option? Having to write fancy DRM for a trial? Surely is own kind of fun, but also I have better things to do.

• Tell your friends!
  (it helps more than you might think)
  (if you have no friends, tell people that you talk to often?)
• Test some games!
  (helps iron out bugs/figure out tweaks for oddities)
• Contribute configuration files for games!
  (if you are tech-savvy enough to do so)
• Stream/record videos of playing games via the tool!
  (if that's your thing)

I may be available for consultation or hire for debugging issues;

See limitations for things that are known to not work.

Given a budget, previously unsupported features can be covered instead of tweaking the game (to not use them).

Overall, you can get in touch.

Yes and no, but mostly no.

For players, it means that your game not having online multiplayer isn't the end of the world anymore (as in, people can still play it alright if they want), but you'd still want an actual integration for it to be a selling point.

Or, at least, to the next point,

If you are content with how GMT works and would love that as an official option in your game, you can get in touch about licensing - custom features/UI are possible, along with actually having it built-in rather than as a piece of external software.

In general, GMT working well enough for a game is a sign that deterministic netcode is an option, which is also something that you can hire me for (or someone else, for that matter). Or just picking what is the best option if you can tell that there's community interest in this.

Otherwise you can make an announcement/prominently feature it as a well-working option to play your game online.

GMT allows to write game-specific configuration files.

These offer a wide variety of tweaks to get the games running correctly, a few features to reduce perceived latency (such as native cursors), a few "quality of life" features (such as mouselock), and some miscellaneous options.

The included GMT-Example.ini has examples of all supported options alongside with explanations of their functions. To make use of it, copy it to the game directory, rename it from GMT-Example to GMT, and edit it to your liking.

Options are loaded on game startup.
Game-affecting options will automatically apply to both players, so only the host player will usually need to edit the file.

local dx = 0
local dy = 0
for p in with(obj_player) do
	if (p.index == 0) then
		dx = mouse_get_x() - p.x
		dy = mouse_get_y() - p.y
		break
	end
end
-- normalize the offset into a length-1 vector:
local dl = math.sqrt(dx * dx + dy * dy)
if (dl ~= 0) then
	dx = dx / dl
	dy = dy / dl
end
gamepad_axis_set(i, gp_axisrh, dx)
gamepad_axis_set(i, gp_axisrv, dy)

Example:

keyboard_ignore(vk_anykey)
mouse_ignore_button(mb_any)
mouse_ignore_move()
function update()
	local i = gamepad_virtual
	gamepad_set_connected(i, true)
	--
	local lx, ly = 0, 0
	if (keyboard_check(string.byte("D"))) then lx = lx + 1 end
	if (keyboard_check(string.byte("A"))) then lx = lx - 1 end
	if (keyboard_check(string.byte("S"))) then ly = ly + 1 end
	if (keyboard_check(string.byte("W"))) then ly = ly - 1 end
	gamepad_axis_set(i, gp_axislh, lx)
	gamepad_axis_set(i, gp_axislv, ly)
	--
	gamepad_button_set(i, gp_start, keyboard_check(vk_enter))
	gamepad_button_set(i, gp_face1, keyboard_check(vk_space))
end