2D destructable terrain with collisions in MMO

Question

Task

What I want is to create destructable terrain (like in Worms) and collisions with this terrain (with calculated normals) that will be fast enough to work on server machine.

Basically lets say that I want to make Worms Online (I don't really) using model CLIENT-SERVER, not peer2peer.

Approaches I read about

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

• Another approach is using vectors to track outline of terrain, but it seems also really CPU heavy and I didn't find any good example of that.

So guys what is your proposal?

Answer 1

One good option is to use something larger than pixels and use marching squares to create smooth terrain. The server and client only talk to each other in grid terms, thus reducing bandwidth. The client is responsible for running marching squares and interpolating the grid into a smooth terrain. However, all the collisions and terrain interactions use that grid for their calculations, making them faster.

Additionally, this allows you to easily test the performance of one size square and easily scale the squares up or down depending on where you find your performance. For example, create a grid that's 5X pixel size. Test the performance, if it's good, scale the grid down to 3X pixel size for smoother terrain and more accurate collisions.

As an example, there's a Ludum Dare game from a while back that used marching squares for destructible terrain:

As you can see, the result is fairly smooth terrain. A change in textures could help if you wanted something more realistic looking without the dark outlines.

Answer 2

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.

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.