<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Voice Chat for Games</title>
	<atom:link href="http://weblog.probablynot.com/2007/01/06/voice-chat-for-games/feed/" rel="self" type="application/rss+xml" />
	<link>http://weblog.probablynot.com/2007/01/06/voice-chat-for-games/</link>
	<description>-emptying my brain onto the internet since 1998...</description>
	<pubDate>Wed, 07 Jan 2009 23:00:24 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: jason</title>
		<link>http://weblog.probablynot.com/2007/01/06/voice-chat-for-games/comment-page-1/#comment-21939</link>
		<dc:creator>jason</dc:creator>
		<pubDate>Mon, 08 Jan 2007 16:16:10 +0000</pubDate>
		<guid isPermaLink="false">http://weblog.probablynot.com/2007/01/06/voice-chat-for-games/#comment-21939</guid>
		<description>A solution to many of these problems would be to simply make the voice chat "press to talk", or at least a "click-on/click-off".

... and yeah, I'm not thinking of using this for a fantasy setting, although as time goes on the acceptance of things like Ventrilo going up, people will be less likely to think the voice chat breaks the immersion.

I'm also thinking that this is something moving toward bandwidth becoming cheaper.  You say devs can't be paying for the bandwidth, but why not?  If $15 a month covers the current costs, new development and makes a profit, would $30 month cover the additional bandwidth for a voice chat system?  I don't know myself, but I think its worth looking in to, perhaps even look at aligning with one of the Voice over IP providers.</description>
		<content:encoded><![CDATA[<p>A solution to many of these problems would be to simply make the voice chat &#8220;press to talk&#8221;, or at least a &#8220;click-on/click-off&#8221;.</p>
<p>&#8230; and yeah, I&#8217;m not thinking of using this for a fantasy setting, although as time goes on the acceptance of things like Ventrilo going up, people will be less likely to think the voice chat breaks the immersion.</p>
<p>I&#8217;m also thinking that this is something moving toward bandwidth becoming cheaper.  You say devs can&#8217;t be paying for the bandwidth, but why not?  If $15 a month covers the current costs, new development and makes a profit, would $30 month cover the additional bandwidth for a voice chat system?  I don&#8217;t know myself, but I think its worth looking in to, perhaps even look at aligning with one of the Voice over IP providers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chas</title>
		<link>http://weblog.probablynot.com/2007/01/06/voice-chat-for-games/comment-page-1/#comment-21930</link>
		<dc:creator>Chas</dc:creator>
		<pubDate>Mon, 08 Jan 2007 14:07:44 +0000</pubDate>
		<guid isPermaLink="false">http://weblog.probablynot.com/2007/01/06/voice-chat-for-games/#comment-21930</guid>
		<description>Such a system has merit.

It would probably be better implemented in a Sci-fi game than a fantasy game, as the quality of audio that's available better serves the "static-filled commlink" than real personal talk.

I'd have to admit- I'd be royally irritated every time a cough or a RL problem interfered with gameplay.  Even the fumbling of a microphone could easily exceed the volume of a "shout" (bringing an entire mob down on the team).  Flu season would put an entirely different level of requirement on my pickup groups.

Then there are the people that can't use that interface- the ones that can't talk in their house at 2am without waking the kids, let alone shout.  Sure, you can tone the tolerances down until every breath is transmitted into the game.  Sure, he could text-chat... maybe even with a real tactical advantage over others' accidental audio bloopers.

As for the sound engine:  That's not necessarily technically difficult- you can see... err... hear... such things already in some single-player games.  The limiting factor to the MMO would thus be more one of capacity.  It'd much easier if these ranges coincided with pre-existing detection ranges than their own, as each tier could add to the server's tracking limits.  Also, area increases faster than distance, and tracking processes get very cumbersome as they have more area to manage.  

The different "tiers" of noise has to be tracked as a separate "detection box" or the longest range detection box needs tracked, the data's sent to each client, and the client then determines the proper "volume" there.  That would violate the "trust no client" rule and opens us up for hacks for players that might want the advantage of the whisper with the clear communication of a "shout."

Finally, we have to deal with the bandwidth challenge.  Devs can't be paying for all the bandwidth caused by all the audio, meaning they can't have the audio transmitted to their servers for re-broadcast.  Audio's considerably more bandwidth-laden than text, and it would greatly increase the hosting costs should that be necessary.  

Instead, the mapserver would have to send regularly updated lists to all client machines identifying who should get the audio data and where that computer is.  The client would then send to these addresses. 

The downside to such a system: The game host has no record of what's being said (a potentially critical issue for CSR's handling interplayer complaints) and players will have lists of listeners that their characters may not necessarily have detected (stealthed foes).  That's an inherent risk in breaking the "trust no client" rule though.</description>
		<content:encoded><![CDATA[<p>Such a system has merit.</p>
<p>It would probably be better implemented in a Sci-fi game than a fantasy game, as the quality of audio that&#8217;s available better serves the &#8220;static-filled commlink&#8221; than real personal talk.</p>
<p>I&#8217;d have to admit- I&#8217;d be royally irritated every time a cough or a RL problem interfered with gameplay.  Even the fumbling of a microphone could easily exceed the volume of a &#8220;shout&#8221; (bringing an entire mob down on the team).  Flu season would put an entirely different level of requirement on my pickup groups.</p>
<p>Then there are the people that can&#8217;t use that interface- the ones that can&#8217;t talk in their house at 2am without waking the kids, let alone shout.  Sure, you can tone the tolerances down until every breath is transmitted into the game.  Sure, he could text-chat&#8230; maybe even with a real tactical advantage over others&#8217; accidental audio bloopers.</p>
<p>As for the sound engine:  That&#8217;s not necessarily technically difficult- you can see&#8230; err&#8230; hear&#8230; such things already in some single-player games.  The limiting factor to the MMO would thus be more one of capacity.  It&#8217;d much easier if these ranges coincided with pre-existing detection ranges than their own, as each tier could add to the server&#8217;s tracking limits.  Also, area increases faster than distance, and tracking processes get very cumbersome as they have more area to manage.  </p>
<p>The different &#8220;tiers&#8221; of noise has to be tracked as a separate &#8220;detection box&#8221; or the longest range detection box needs tracked, the data&#8217;s sent to each client, and the client then determines the proper &#8220;volume&#8221; there.  That would violate the &#8220;trust no client&#8221; rule and opens us up for hacks for players that might want the advantage of the whisper with the clear communication of a &#8220;shout.&#8221;</p>
<p>Finally, we have to deal with the bandwidth challenge.  Devs can&#8217;t be paying for all the bandwidth caused by all the audio, meaning they can&#8217;t have the audio transmitted to their servers for re-broadcast.  Audio&#8217;s considerably more bandwidth-laden than text, and it would greatly increase the hosting costs should that be necessary.  </p>
<p>Instead, the mapserver would have to send regularly updated lists to all client machines identifying who should get the audio data and where that computer is.  The client would then send to these addresses. </p>
<p>The downside to such a system: The game host has no record of what&#8217;s being said (a potentially critical issue for CSR&#8217;s handling interplayer complaints) and players will have lists of listeners that their characters may not necessarily have detected (stealthed foes).  That&#8217;s an inherent risk in breaking the &#8220;trust no client&#8221; rule though.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
