Jump to content

  • Log In with Google      Sign In   
  • Create Account

Sound Effects with UDP packets


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 brokilodeluxe   Members   -  Reputation: 115

Like
0Likes
Like

Posted 15 March 2013 - 02:23 AM

I have a little top down fighter game I've been working on that uses unreliable sequenced UDP-packet networking.

 

I've just started to add sound effects. Some sound effects are dependant on certain hit collisions happening (fighter hits a wizard with his sword *CLANK*). I don't have hit collisions taking place client side for cheating/performance reasons, so I have to send the sound effects somehow. My level class has a sound list that certain entities within the level populate. The level plays each sound and then removes it from the list. The server sends it's level's sound list in every packet, and the client takes those sounds and populate's its level's sound list, which are then played and removed. The problem is, with packet loss, a lot of sounds never get played.

Any suggestions on how to approach this?


Edited by brokilodeluxe, 15 March 2013 - 02:24 AM.


Sponsor:

#2 starbasecitadel   Members   -  Reputation: 699

Like
0Likes
Like

Posted 15 March 2013 - 06:30 AM

What I do is I don't send the sound message at all.

 

The client plays the sound at the same time it generates the first frame of whatever event (ability, weapon use, explosion) occurs.  This simplifies things, and this way there is no way you will get a UDP packet with the sound and without the visual/gameplay effect, or vice versa.

 

 



#3 hplus0603   Moderators   -  Reputation: 5707

Like
0Likes
Like

Posted 15 March 2013 - 10:11 AM

For a good user experience, you typically want to simulate the same thing on the client as on the server. For anything that's visual, you'll go ahead and assume that the client gets the right result, and display/play that right away on the client. However, the actual game effects (changing hitpoints, scoring, etc) only update after the server has decided that it is so.
enum Bool { True, False, FileNotFound };

#4 brokilodeluxe   Members   -  Reputation: 115

Like
0Likes
Like

Posted 15 March 2013 - 12:17 PM

Let me try to elaborate a little bit.

If I create an explosion object for example, I want the sound to be played once whenever it is created/first frame or whatever. This works fine for single player.

 

But in multiplayer, the server sends the client the list of objects to populate the level, so entities are created a whole bunch of times on the client.

 

This leads to explosion sounds being played numerous times until they despawn. The only other option (as I saw it) was to create a sound list and only play sounds from there, so that's why I have it set up in this way. But this leads to packet loss if you rely on the server to send it to you, which leads to sounds not being played since they get removed from the list as soon as they are played once.

 

I could just send a bunch of flags for each entity like a "isSoundPlayed" boolean whenever I repopulate my level, but that's still relying on the server for sound information, which would lead to the same problems I would guess.


Edited by brokilodeluxe, 15 March 2013 - 12:23 PM.


#5 brokilodeluxe   Members   -  Reputation: 115

Like
0Likes
Like

Posted 15 March 2013 - 12:47 PM

Nevermind. I figured it out. Thanks guys.

You were right; just going to have to do hit collisions on the client side too.



#6 wodinoneeye   Members   -  Reputation: 876

Like
0Likes
Like

Posted 16 March 2013 - 05:04 PM

I recall that having something like a packet of white noise to fill-in for overdue packets in a sound sequence can often pad the sound sufficiently to not sound completely horrible.

 

---

 

Buffering ahead even a little to give sufficient resend time ???


--------------------------------------------Ratings are Opinion, not Fact




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS