Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

up vote 5 down vote accepted

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:

enter image description here

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.

share|improve this answer
    
Thanks. I checked on your game and I have to say - really good job. It has a great gameplay and I love the idea with fluid. I'll check what those marching squares are all about and will try to use it. –  Rafał Łużyński Jan 10 '13 at 22:14
    
@RafałŁużyński Thanks! I enjoy working on it. Good luck with your game, 2D is a good choice. –  Byte56 Jan 10 '13 at 23:17
add comment

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.

share|improve this answer
    
OP never said their game was turn based and explicitly said they're not making an worms game. –  Byte56 Jan 10 '13 at 17:53
    
Thanks for fast and full answer. This game won't be turn based and I don't get few points of your post. How is it near impossible to cheat if I can't check on server if user didn't colide with terrain? EDIT: I pressed enter too fast while commenting and I sent it not finished by accident :P –  Rafał Łużyński Jan 10 '13 at 17:53
    
@Byte56 - I guess it will do? :) –  Jovan Jan 10 '13 at 17:54
1  
@RafałŁużyński - The clients are the ones who simulate the game. You will see a discontiunity in the data returned by one of the clients, and it means that something in their simulation of the game went wrong. It can come down to two things: a) the simulation is not deterministic, or b) the player is cheating. In short, we don't care about what happens in the game, we only care that all of the clients returned the same response to what happened. –  Jovan Jan 10 '13 at 17:59
    
Thanks for example, now I get what you mean. But what if I would like to make some coop with achievements, or just PvE. Then players can cheat togheter (or alone in PvE). Right now I'm not planning these features, but I might add it in a future so I would have to change whole networking. Another thing is in example "Windwalk", skill that makes unit invisible for enemy players. Enemy players don't know where my unit is, so I can freely change my position from A to B without noticing by enemy. –  Rafał Łużyński Jan 10 '13 at 21:48
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.