Many options:

1. Model the stick - player relation by external force and torque (means doing it in game code not physics engine)

2. Try to model it with a single joint (which would require a motorized joint that drives both angular and linear properties)

3. Use multiple joints and model anatomy of both arms or just one arm (requires only angular motors, easier to set up limits)

Most physics engines only have limited or no support for motorized joints. They often give some basic choices for limits, e.g. ball and socket, hinge, 6-dof etc, with or without motor options, and you model your setup given what's possible.

Newton is an interesting exception as it allows the user to implement any joint quite easily, so you could look there for inspiration. 

But that's all very complicated. Depending on realism you aim for it should be much easier to use any kind of tricks instead of simulation. At the end you would change the velocity of a hit puck anyways, because something like that is hard to control with simulation running at just 60 Hz.

You'd to tell more about the game so we have a bit if  imagination.

Is it top down view with arcade like gameplay, or angled view?

Characters 2D sprites or animated 3D models?

2D physics or 3D physics?

Does your physics engine already have some sort of constraints, e.g. contacts to calculate resting contact forces for box stacks?

A sports game modeled by full physics has not been made yet - the hardest hing i can imagine. Even this: https://www.youtube.com/watch?v=CpLNyrt53kU is not just physics (judging with my eyes), and i don't know if they ever finished it.

So what kind of realism between that and an old top down NES game do you aim for?

I have some experience with things like simulating walking ragdoll, but i know nothing about how sports games work and i've never played one

So i hope other will answer too, but they likely need to know more about your goal as well.

Ok, sounds you're on a practical (and doable) road

So the easiest way to get going would be just to attach something like a box to the player, which you control in some simple procedural way in the players reference frame.

Because both stick and puck have tiny mass in comparison to the player, you probably don't need a joint to model the forces. For stick-wall collisions you could just add a small impulse to the player and resolve the stick collision with some simple geometrical projection.

If you want to implement joints in your physics engine for general use, you need to look at how constraint solvers work (usually by multiple iterations resolving each joint in isolation and accumulating, or rarely by resolving all joints of a system at once with some graph traversal).

For the latter you do not only need to work on the constraint solver, you also need to work on the control problem afterwards to steer the motors. That's also quite some task and harder than procedural animation. The former approach should be easier.

5 hours ago, Cacks said:

What technique should I use to combine these 2 objects in my physics engine?

You will want to take a look at compound collisions. This image is from the Unity manual:

By using two or more collision boxes you can create a rough collision shape for any odd object. It's fast and practical.

One thing to remember is that compound collisions work best with gravity on. Because each collision box will calculate on it's own local matrix and without gravity to balance it in a model, the 3D object will rotate in the wrong direction.

46 minutes ago, Scouting Ninja said:

One thing to remember is that compound collisions work best with gravity on. Because each collision box will calculate on it's own local matrix and without gravity to balance it in a model, the 3D object will rotate in the wrong direction.

What do do you mean this? I'm confused. Sounds like a bug in Unity?

For me a compound is just a single rigid body that recalculates mass and inertia from multiple input bodies. The purpose is to combine multiple convex shapes to support concave shapes for collisions. So yes, that's the preferable option if the transform from player is static, but no option if the stick should move independently. (should not have anything to do with gravity or rotations)

Edit: I assume what you see could eventually be the result of a badly aligned inertia frame. Usually physics engines support only to express the inertia of an ellipsoid (not even a simple box can be expressed accurately). If the frame is chosen badly, the ellipsoid will not fit the game object and it seems as if it would behave strange. Eventually Unity uses the parent frame (or worse any child) and does not try to find the best orientation.

3 hours ago, JoeJ said:

For me a compound is just a single rigid body that recalculates mass and inertia from multiple input bodies.

Yes, that is exactly how Unity and most engines uses it. As an example a compound collision works like this:

Of Course it doesn't really matter what direction the axis look like the important part of compound collisions is that each collision box is treated as a object "stuck" to an object.

3 hours ago, JoeJ said:

What do do you mean this? I'm confused. Sounds like a bug in Unity?

The confusion comes from developers assuming that a compound collision will act as one solid body. However this isn't true, so they mistakenly think that if the ball hits the new shape it will act as one solid body:

It looks simple now because clearly the compound collision is correct, however this is a simple straightforward collision.

let's say it was a character with a arm, and to prevent the character from falling the developer constraint the collisions to rotate only around the upwords axis. Then this happens:

What the developer wasn't expecting is that when the arm is hit, it sends the character tumbling, instead of spinning. This is a very common mistake in a lot of games, because developers forget that a compound collision is made of individual parts and not a single object.

Another common mistake is to use a global up direction to lock the constraint, but that would act weird when the character is on a incline.

So often the total force is used like a gyroscope, gravity is checked for downwards force that already considers mass. This way a character can spin and fall over spinning correctly.

A global down vector multiplied by total mass should also work for this, since that is what gravity is most of the time. However in space like games with multiple gravity points, or a Super Mario Galaxy like game, gravity as a variable would be better.

So you say, if we take the arm picture and both bodies are a compound, and we use an up vector constraint on the compound, then both bodies are allowed to rotate around their blue axis? That's really bad, because for the physics engine a compound IS one sold body until you open it for modification. (not 100% sure, but i don't think PhysX is en exception here.)

I assume what's happening here is that Unity applies the rotation just on the visual objects and there is an offset matrix between physics and graphics to allow this. Or more likely, Unity just changes the individual bodies ignoring simulation, which also either leaves the physics engine with outdated data or a need for expensive recalculation of mass properties. In any case, to me this really looks like a bug or at least an unintended feature.

It would be interesting to look if there are two kinds of up vector constraints, one for Unity objcets, and another on top of a PhysX joint which works as expected. 

Is this the same with UE?