Super glad that you're not demoralized. Your game is still technically very impressive, and maybe could have been great if you had had three weeks on it, but it's clear (like you say) that you didn't get time to do anything else other than "get everything in".

I don't think adding a third person to the team will help.

Expanding the team means more communication, more time spent getting everyone onto the same page and excited. The team will grow by 50% but the work you'll be able to do might increase by 25%... and you'll probably try be even more ambitious now that you have a third teammate (assuming nothing else changes).

I feel pretty confident it will play out that way, that you'll just be more ambitious with three people, because Twin Hydra seem to have a little bit of time blindness, and a lot of enthusiasm for new features.

I too have a lot of enthusiasm for adding more things into a game. At Free Lives I'm probably the person who is most inclined to over scope and just keep adding more. I don't think it's a harmful impulse when harnessed for good, but it can lead to disappointment and sorrow when used for evil (in my experience).

Maybe if you split up, each working on their own game, you'd find you are both less ambitious and so work more within your means, and maybe you'll have better outcomes...

But that seems sort of sad. And honestly I think you're just going to run into this problem at a later stage anyway.

Here's my advice... get your salt pinching fingers ready... I do a couple things these days that help me avoid overscoping:

A) I attach times to tasks. If the task says "implement a new major mechanic", for example movement, it's a day of work in a jam. This includes testing and iteration of course. If the thing needs to interact and actually feel good - it takes a day, if it can be janky then if can be a bit quicker.

Critically: the time a task takes isn't the raw implementation time, the time a single task takes includes all the iterations and time spent talking about how to fix it or improve it. Don't even try predict it, just mark it down as a day.

This means I can do two or maybe three mechanics in a jam, and I have to make the game enjoyable with just those. And I'm pretty damn fast at jamming.

For instance the robot movement is a day, the camera system is a day, puzzles in the robot space is a day, the moving from in world to computer screen is maybe half a day, the Clippy system is half a day, the carrying around a robot in FPS view is a day. The megazord fusion is a day. Some sort of doomsday ending is a day. 

i.e. I know before I've started that I couldn't have made the game you were trying to make in a jam. So, hopefully, I wouldn't have tried.

B) I don't move on from a task until it is tested and it is good (and it is tested again).

If moving a robot around is bad or untested, I won't start with movement/camera puzzles, if the puzzles at the robot level are bad or untested, I won't build the FPS part where you drop the robot in the hole, if the FPS part is bad or untested I won't build the fake Windows interface... and so on.

Generally in a jam I'm then designing games that have multiple exit points. Like if I'm running out of time it will still be good if it is just X, but if things go well we can do X and Y. 

i.e. My plan is always start small and expand in layers like an onion.

This obviously has some drawbacks... mostly that it makes it hard to write a narrative, literally not knowing what the game will do at the end of the jam, so I will start off with a vague idea of stories the game could tell are, and only fill in those details when the game has the elements to tell those stories. It's a compromise of course, but I think it's generally better than trying to tell the whole story despite the game not supporting that story.

Beyond narrative difficulties, in general this iterative approach means you cannot plan the entire game at the start. At best you can have a theory of what the game could be, but there will be a ton of "if this is fun" or "if we implement this really well". I'll have a plan B in case the ambitious elements need to be cut, and most often I am forced to fall back to a plan B, or plan C or D... but that's generally because plan A couldn't have been implemented well in the time.

The HUGE upside about working iteratively instead of sticking to a plan is that making games just isn't predictable. Sometimes one seemingly small feature turns out to be a massive challenge requiring a lot of iteration, sometimes the feature turns out to straight-up suck, and then the shape of the whole game needs to change because you actually only have half the time you'd expected to do the rest. Since this ALWAYS happens, in my mind it's better not to plan in detail in the first place because it makes it emotionally more challenging to pivot later.

Those are my thoughts.

A) Allocate realistic time for tasks when you are planning.

B) Don't plan, work incrementally and iteratively.