Hi Guys!

I'm currently working on adding impact response to trees/bushes etc in my game (2d ARPG).

Exactly what I mean is that when a tree, for example, gets hit it springs back & forth to create some more dynamics in the game.

I have one solution I've come up with but I'm not really sure if it's a good choice so I would love to hear if you have som feedback on the proposed solution and If you would have done it differently, and if so, how?

I'm just going to hadnwave the general code, although i'll be more than happy so supply it if anyone wants but at this point I think it will only clog up the post.

Here goes:

The game is oriented as a server/client using TCP/IP with the map divided up in blocks. Since motion of trees etc is really only a visual aspect right now the server detects any collisions done to a block and sends a description of this impulse to any nearby players.

On the clientside the game records any received impulses and applies a decaying oscillation to the relevant blocks. (Right now it is fixed but my plan is to have different blocks/trees/etc have different spring constants and decay time for variety) which then is rendered

Pros/Cons I Can See

The main reason for the approach is to reduce load on the server, collisions are handled anyway so the actual physics calculations can be dumped to the client

However, this increases the datarate (albeit at a small rate) since now these impulses has to be sent to the player

Also, there might me some discrepencies between clients

I currently have no predictions clientside (I know, very latency sensitive but havent gotten so far yet, working solo here ;) ) so the server-side map has to be involved somehow

A small video showing the current performance/behaviour

[media]https:

[/media]

Any suggestions? Good? Bad? Clobber it with a club until it is no more?

Looks interesting. Maybe tie the sections of each tree/bush to one another loosely, so that when one section gets a strong bump the energy propagates a little through the tree/bush.

Know what I mean?

As for server/client, I'd have the impact event (only event) bounce through the server and then have the clients execute the response at their own end.

Why TCP rather than UDP?

That is definitately a good idea, I will try it out this evening and report back on it it fairs. It would definately make it better, the only drawback would be if it would req to much performance but I'll definitely give it a shot!

As for the TCP vs UDP question (Lets try not to make a flamewar of this thread now ) It's mostly be chance, kinda... I'm not that used to do network programming (I do have some experience working on the lower levels though but mainly down towards the phy) So it was kinda a cointoss but I figured the packet ordering and packet loss prevention would make it easier for me to start with TCP. I did have some latency issues at first but disabling Nagle (only on Win for now) helped with that, at the cost of some overhead though but for now I'll stick with it. In the end UDP is probably better, but well...

I'll report back with the updates!

So, I update the foilage quite a bit!

Thanks for the suggestion about linking them togheter, the foilage code ended up structured like this

1) A 2D Array holds the current visable viewport (+ some beyond edges) with a small oscillator source for each block

2) Impulses are applied to all corresponding blocks in area, the impulse variables togheter with block height, stiffness and foilage radius sets the oscillator source

3) Any set oscillator sources are set to affect nearby blocks with some phaseshift and decaying amplitude depending on distance

4) Global modifiers are applied, in this case the current wind in the area, affecting all foilage blocks

5) Offsets vectors are calculated for all affected blocks based on the state of the local oscillators and used to offset the foilage when rendering

A small video update below, definitely feels more dynamic now, also sofar I havent noted to much performance drop so the code seems to run quite efficient

[media]https:

[/media]

Looks nice. You may want to tune the amplitude decay a little more so that it decays faster.

The UDP/TCP thing isn't really a "holy war" issue in this case. For games of this sort with rapid state updates UDP is recommended because lost packets can simply be skipped, rather than waiting for timeout and retransmission. TCP may work over a LAN with limited connections, but beyond that the added latency and packet loss make it untenable. TCP is really tuned for bulk data transmission (file downloads) or transactional exchanges (card games, for example), where latency is less important than reliable delivery and ordering.

Gaffer has a good article about this that explains the reasoning succinctly.

http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

That was a nice article, thank you for that!

Yeah, switching to UDP will very likely be something to do, like was mentioned in the article I have disabled buffering of small packets which has helped to the point that I at least can test play with a couple of people without any significant lag (although those people are sitting at quite good broadband connections so its not really a completely fair test ) So I'll stick with the current TCP solution for now, but you may very well be right and I would have to end up switching to UDP at the end. However, since the actual server/client handling is already in place am going to wait with reworking it until I have to

That said I do agree with your suggestion and If I would start from scratch I would probably have gone UDP directly

As for the topic at hand I did some fine tuning but overall I will not add any more to this section for now (unless some questions would pop up), I thank you for the advices!