The discussion is hidden in comments, so lets do a basic example here.

Regular Example

We have a game with 3 players, A, B and C, and the Arbitrating Server, AS

1. Game Frame is started.

2. Player A selects their weapon, and their angle. They fire, and a "Fire" packet is sent with (WeaponId, Angle, Amount of Power) data.

3. AS receives this packet, sends it to all other players.

4. Players B and C simulate the game as well.

5. Player B is shot, so their worm is moved elsewhere, the position has changed.

6. All players send the state of the worms, what weapons they have, their position and their facing to the AS.

7. AS confirms that the data is the same from all the players, so players are in sync. This frame is concluded, and a new frame starts.

Cheating Example

Now what would happen if A was cheating and modified the number of ammo they had?

1. Game Frame is started.

2. Player A changes the number of rockets they have from 0 to 10.

3. Player A selects the Rocket weapon, and their angle. They fire, and a "Fire" packet is sent with (WeaponId, Angle, Amount of Power) data.

4. AS receives this packet, sends it to all other players.

5. Players B and C try to simulate the game, but notice that A has no ammo. They send this discontinuity to the AS.

6. AS broadcasts an "Out of Sync" message, and the game is terminated.

Keep in mind that this is a simplified look at how it works, but the premise always remains the same.

People in other threads were suggesting using bitmaps and perpixel collisions, but is it fast enough to handle i.e. 100 games simultaneously?

I think there is a middle approach here where you can use Client-Server, but you let your clients do all the hard work, and keep them in sync using an arbitrating server.

The basic premise is that instead of doing all the work on the server, you capture client input and broadcast it to all the other clients. This is the premise behind most RTS games (and people frequently mistake them as being peer-to-peer, where in fact one of the players runs a server inside their game instance).

Since Worms is turn-based, there are no real-time requirements. You can have the clients transmit their last frame state to the arbitrating server. If any of the clients has mismatching data, the game is out of sync and you can drop it completely.

This gives you several benefits:

1. You can have a lot of games running off of a basic machine, because it isn't doing any heavy lifting.

2. You still have a client-server architecture, you can go so far as to store replays if you want to.

3. Cheating in a synced game like this is near impossible.

People in other threads were suggesting using bitmaps and perpixel collisions, but is it fast enough to handle i.e. 100 games simultaneously?

I think there is a middle approach here where you can use Client-Server, but you let your clients do all the hard work, and keep them in sync using an arbitrating server.

The basic premise is that instead of doing all the work on the server, you capture client input and broadcast it to all the other clients. This is the premise behind most RTS games (and people frequently mistake them as being peer-to-peer, where in fact one of the players runs a server inside their game instance).

Since Worms is turn-based, there are no real-time requirements, which gives you plenty of CPU time between turns to ship some packets. You can have the clients transmit their last frame state to the arbitrating server. If any of the clients has mismatching data, the game is out of sync and you can drop it completely.

This gives you several benefits:

1. You can have a lot of games running off of a basic machine, because it isn't doing any heavy lifting.

2. You still have a client-server architecture.

3. Cheating in a synced game like this is near impossible.

4. You can go so far as to store replays if you want to.

In the end, the way you implement the terrain breakage doesn't really matter. You can use bitmaps and stencils, or vector fields. It's handled on the client-side.