It shouldn't be hard to finish, and if I had Game Maker Studio right now, I'd probably play around with it myself. I had an easy enough time making a partner follower on my engine. It was mostly spawning a second copy of the player object, storing object IDs of both in variables, telling it upon creation, using its ID number, that it was Player 2, (So it would ignore the controls code, which I handled entirely in the step event.) defining which character skin it was going to use, and giving it its own code for following Player 1 in the step event, and this could only be triggered if the player object knows it's defined as Player 2.
The only annoying side effect, after implementing it, was having to make sure the rest of the engine was exclusively calling for Player 1's actual object ID, instead of obj_player directly, and when Player 1 needed help from 2, calling it by its actual ID; otherwise both players would be called and screw with the simplest of gimmicks, like swingable vines or Tails' ability to grab Sonic.
So yeah, not much to do, really. I didn't even need a second variant object for Player 2. Just spawning a slightly gimped player object, guided by my poor excuse for AI logic (Tails will think to jump if Sonic is ahead of him, and short wall is in his way; mostly simple stuff like that.) and input delays from Player 1. Although it's still something you always have to consider when writing code for any object that interacts with the player, (Like monitors and enemies.) so store their IDs in a way that's convenient for most objects to obtain whenever the players are alive, otherwise it will get very annoying to make even something simple as a pulley or door cooperate.
Outside of all that, you'd also have to worry about the follower flying out of view, and outside the instance deactivation range, as well, but with flying characters, writing a way for them to respawn is pretty easy. Although you can have non-flying characters drop in from above with falling animations as well.
00
