কেস স্টাডি - দ্য সাউন্ডস অফ রেসার

Plan 8

ভূমিকা

রেসার হল একটি মাল্টি-প্লেয়ার, মাল্টি-ডিভাইস ক্রোম এক্সপেরিমেন্ট। একটি রেট্রো-স্টাইল স্লট কার গেম স্ক্রিন জুড়ে খেলা হয়। ফোন বা ট্যাবলেটে, অ্যান্ড্রয়েড বা আইওএসে। যে কেউ যোগ দিতে পারেন. কোনো অ্যাপ নেই। কোন ডাউনলোড নেই. শুধু মোবাইল ওয়েব।

14দ্বীপে আমাদের বন্ধুদের সাথে Plan8 একত্রে জর্জিও মোরোডারের একটি মূল রচনার উপর ভিত্তি করে গতিশীল সঙ্গীত এবং শব্দের অভিজ্ঞতা তৈরি করেছে। রেসারে প্রতিক্রিয়াশীল ইঞ্জিন সাউন্ড, রেস সাউন্ড ইফেক্ট, তবে আরও গুরুত্বপূর্ণভাবে একটি গতিশীল মিউজিক মিক্স রয়েছে যা রেসার যোগদানের সাথে সাথে বিভিন্ন ডিভাইসে নিজেকে বিতরণ করে। এটি একটি মাল্টি-স্পিকার ইনস্টলেশন যা স্মার্টফোনের সমন্বয়ে গঠিত।

একাধিক ডিভাইস একসাথে সংযুক্ত করা এমন কিছু ছিল যা আমরা কিছু সময়ের জন্য বোকা বানিয়েছিলাম। আমরা সঙ্গীত পরীক্ষা করেছি যেখানে শব্দ বিভিন্ন ডিভাইসে বিভক্ত হবে বা ডিভাইসগুলির মধ্যে লাফ দেবে, তাই আমরা সেই ধারণাগুলি রেসারে প্রয়োগ করতে আগ্রহী ছিলাম।

আরও নির্দিষ্টভাবে আমরা পরীক্ষা করতে চেয়েছিলাম যে আমরা ডিভাইস জুড়ে মিউজিক ট্র্যাক তৈরি করতে পারি কি না কারণ আরও বেশি সংখ্যক লোক গেমটিতে যোগ দিয়েছে — ড্রাম এবং বেস দিয়ে শুরু করে, তারপরে গিটার এবং সিনথ যোগ করা ইত্যাদি। আমরা কিছু মিউজিক ডেমো করেছি এবং কোডিংয়ে ডুব দিয়েছি। মাল্টি স্পিকার প্রভাব সত্যিই ফলপ্রসূ ছিল. এই মুহুর্তে আমাদের কাছে সমস্ত সিঙ্কিং ছিল না, কিন্তু যখন আমরা শুনেছিলাম যে শব্দের স্তরগুলি ডিভাইসগুলিতে ছড়িয়ে পড়েছে তখন আমরা জানতাম যে আমরা ভাল কিছুতে ছিলাম৷

শব্দ তৈরি করা

গুগল ক্রিয়েটিভ ল্যাব শব্দ এবং সঙ্গীতের জন্য একটি সৃজনশীল দিক নির্দেশ করেছে। আমরা প্রকৃত শব্দ রেকর্ডিং বা শব্দ লাইব্রেরি অবলম্বন না করে সাউন্ড ইফেক্ট তৈরি করতে অ্যানালগ সিন্থেসাইজার ব্যবহার করতে চেয়েছিলাম। আমরা আরও জানতাম যে আউটপুট স্পিকার, বেশিরভাগ ক্ষেত্রেই, একটি ছোট ফোন বা ট্যাবলেট স্পিকার হবে তাই শব্দগুলিকে স্পিকারের বিকৃতি এড়াতে ফ্রিকোয়েন্সি বর্ণালীতে সীমাবদ্ধ থাকতে হবে। এটি বেশ চ্যালেঞ্জ হিসাবে প্রমাণিত হয়েছিল। যখন আমরা জর্জিওর কাছ থেকে প্রথম মিউজিক ড্রাফ্ট পেয়েছি তখন এটি একটি স্বস্তি ছিল কারণ তার রচনাটি আমাদের তৈরি করা শব্দগুলির সাথে পুরোপুরি কাজ করেছিল।

ইঞ্জিন শব্দ

শব্দের প্রোগ্রামিংয়ে সবচেয়ে বড় চ্যালেঞ্জ ছিল সেরা ইঞ্জিনের শব্দ খুঁজে বের করা এবং এর আচরণকে ভাস্কর্য করা। রেস ট্র্যাকটি একটি F1 বা Nascar ট্র্যাকের অনুরূপ, তাই গাড়িগুলিকে দ্রুত এবং বিস্ফোরক বোধ করতে হয়েছিল। একই সময়ে গাড়িগুলি সত্যিই ছোট ছিল তাই একটি বড় ইঞ্জিনের শব্দ সত্যিই শব্দটিকে ভিজ্যুয়ালের সাথে সংযুক্ত করবে না। আমরা যাইহোক মোবাইল স্পীকারে একটি বীফি গর্জনকারী ইঞ্জিন বাজতে পারিনি তাই আমাদের অন্য কিছু বের করতে হয়েছিল।

কিছু অনুপ্রেরণা পাওয়ার জন্য আমরা আমাদের বন্ধু জোন একস্ট্র্যান্ডের মডুলার সিন্থের সংগ্রহের কিছু অংশ নিয়েছি এবং এলোমেলো করতে শুরু করেছি। আমরা যা শুনেছি তা পছন্দ করেছি। এটি দুটি অসিলেটর, কিছু চমৎকার ফিল্টার এবং এলএফওর সাথে এটির মতো শোনাচ্ছে।

এর আগে ওয়েব অডিও API ব্যবহার করে অ্যানালগ গিয়ারটি দুর্দান্ত সাফল্যের সাথে পুনরায় তৈরি করা হয়েছে তাই আমাদের উচ্চ আশা ছিল এবং আমরা ওয়েব অডিওতে একটি সাধারণ সিন্থ তৈরি করতে শুরু করেছি। একটি উত্পন্ন শব্দ সবচেয়ে প্রতিক্রিয়াশীল হবে কিন্তু ডিভাইসের প্রক্রিয়াকরণ ক্ষমতা ট্যাক্স করবে। ভিজ্যুয়ালগুলি মসৃণভাবে চালানোর জন্য আমাদের সমস্ত সংস্থান সংরক্ষণ করার জন্য আমাদের অত্যন্ত জোঁক হওয়া দরকার। তাই আমরা পরিবর্তে অডিও নমুনা চালানোর পক্ষে কৌশল পরিবর্তন করেছি।

নমুনা থেকে একটি ইঞ্জিন শব্দ করতে ব্যবহার করা যেতে পারে যে বিভিন্ন কৌশল আছে. কনসোল গেমগুলির জন্য সবচেয়ে সাধারণ পদ্ধতি হল বিভিন্ন RPM-এ (লোড সহ) ইঞ্জিনের একাধিক শব্দের একটি স্তর (যত বেশি ভাল) এবং তারপর তাদের মধ্যে ক্রসফেড এবং ক্রসপিচ করা। তারপর একই RPM-এ শুধু রিভিং (লোড ছাড়া) ইঞ্জিনের একাধিক শব্দের একটি স্তর যোগ করুন এবং এর মধ্যে ক্রসফেড এবং ক্রসপিচ করুন। গিয়ারগুলি স্থানান্তর করার সময় এই স্তরগুলির মধ্যে ক্রসফ্যাডিং, সঠিকভাবে করা হলে, খুব বাস্তবসম্মত শোনাবে তবে শুধুমাত্র যদি আপনার কাছে প্রচুর পরিমাণে সাউন্ড ফাইল থাকে। ক্রসপিচিং খুব বেশি চওড়া হতে পারে না বা এটি খুব সিন্থেটিক শোনাবে। যেহেতু আমাদের দীর্ঘ লোডের সময় এড়াতে হয়েছিল এই বিকল্পটি আমাদের জন্য ভাল ছিল না। আমরা প্রতিটি স্তরের জন্য পাঁচ বা ছয়টি সাউন্ড ফাইল দিয়ে চেষ্টা করেছি, কিন্তু শব্দটি হতাশাজনক ছিল। আমাদের কম ফাইলের সাথে একটি উপায় খুঁজে বের করতে হয়েছিল।

সবচেয়ে কার্যকর সমাধান এটি প্রমাণিত হয়েছে:

• ত্বরণ এবং গিয়ার শিফটিং সহ একটি শব্দ ফাইল সর্বোচ্চ পিচ / RPM এ একটি প্রোগ্রামড লুপে শেষ হওয়া গাড়ির ভিজ্যুয়াল ত্বরণের সাথে সিঙ্ক করা হয়েছে। ওয়েব অডিও এপিআই সুনির্দিষ্টভাবে লুপ করার ক্ষেত্রে খুব ভালো তাই আমরা এটিকে কোনো সমস্যা বা পপ ছাড়াই করতে পারি।
• একটি সাউন্ড ফাইল ক্ষয়/ইঞ্জিন রিভিং ডাউন সহ।
• এবং অবশেষে একটি সাউন্ড ফাইল একটি লুপে স্থির / নিষ্ক্রিয় শব্দ বাজছে।

এটা এমন দেখতে

প্রথম স্পর্শ ইভেন্ট / ত্বরণের জন্য আমরা প্রথম থেকে প্রথম ফাইলটি চালাব এবং প্লেয়ার যদি থ্রটলটি ছেড়ে দেয় তবে আমরা রিলিজের সময় সাউন্ড ফাইলে যেখান থেকে ছিলাম সেখান থেকে আমরা সময় গণনা করব যাতে থ্রটল আবার চালু হলে এটি লাফ দেয়। দ্বিতীয় (রিভিং ডাউন) ফাইলটি চালানোর পরে ত্বরণ ফাইলের সঠিক স্থানে।

function throttleOn(throttle) {
    //Calculate the start position depending 
    //on the current amount of throttle.
    //By multiplying throttle we get a start position 
    //between 0 and 3 seconds.
    var startPosition = throttle * 3;

    var audio = context.createBufferSource();
    audio.buffer = loadedBuffers["accelerate_and_loop"];

    //Sets the loop positions for the buffer source.
    audio.loopStart = 5;
    audio.loopEnd = 9;

    //Starts the buffer source at the current time
    //with the calculated offset.
    audio.start(context.currentTime, startPosition);
}

এটি একটি যেতে দিন

ইঞ্জিন চালু করুন এবং "থ্রটল" বোতাম টিপুন।

<input type="button" id="playstop" value = "Start/Stop Engine" onclick='playStop()'>
<input type="button" id="throttle" value = "Throttle" onmousedown='throttleOn()' onmouseup='throttleOff()'>

তাই মাত্র তিনটি ছোট সাউন্ড ফাইল এবং একটি ভালো সাউন্ডিং ইঞ্জিন দিয়ে আমরা পরবর্তী চ্যালেঞ্জে যাওয়ার সিদ্ধান্ত নিয়েছি।

সিঙ্ক করা হচ্ছে

14দ্বীপের ডেভিড লিন্ডকভিস্টের সাথে একসাথে আমরা নিখুঁত সিঙ্কে ডিভাইসগুলি চালানোর জন্য আরও গভীরভাবে দেখতে শুরু করেছি। মৌলিক তত্ত্ব সহজ। ডিভাইসটি সার্ভারকে তার সময়, নেটওয়ার্ক লেটেন্সির কারণগুলি জিজ্ঞাসা করে, তারপর স্থানীয় ঘড়ি অফসেট গণনা করে৷

syncOffset = localTime - serverTime - networkLatency

এই অফসেটের সাথে প্রতিটি সংযুক্ত ডিভাইস সময়ের একই ধারণা শেয়ার করে। সহজ, তাই না? (আবার, তত্ত্বে।)

নেটওয়ার্ক লেটেন্সি গণনা করা হচ্ছে

আমরা অনুমান করতে পারি যে সার্ভার থেকে অনুরোধ করতে এবং প্রতিক্রিয়া পেতে অর্ধেক সময় লাগে:

networkLatency = (receivedTime - sentTime) × 0.5

এই অনুমানের সাথে সমস্যা হল যে সার্ভারে রাউন্ড ট্রিপ সবসময় প্রতিসম হয় না, অর্থাৎ অনুরোধটি প্রতিক্রিয়ার চেয়ে বেশি সময় নিতে পারে বা এর বিপরীতে। নেটওয়ার্ক লেটেন্সি যত বেশি হবে, এই অসাম্যতা তত বেশি প্রভাব ফেলবে—যার ফলে শব্দগুলি বিলম্বিত হবে এবং অন্যান্য ডিভাইসের সাথে সিঙ্কের বাইরে বাজবে৷

সৌভাগ্যবশত আমাদের মস্তিস্ক ওয়্যারড থাকে যাতে শব্দ কিছুটা বিলম্বিত হয় তা লক্ষ্য করা যায় না। গবেষণায় দেখা গেছে যে আমাদের মস্তিষ্ক আলাদা আলাদা শব্দ বুঝতে 20 থেকে 30 মিলিসেকেন্ড (ms) দেরি করে। যাইহোক, প্রায় 12 থেকে 15 এমএস এর মধ্যে, আপনি বিলম্বিত সংকেতের প্রভাবগুলি "অনুভূত" করতে শুরু করবেন এমনকি যদি আপনি এটি সম্পূর্ণরূপে "অনুভূত" করতে অক্ষম হন। আমরা কয়েকটি প্রতিষ্ঠিত সময় সিঙ্ক্রোনাইজেশন প্রোটোকল, সহজ বিকল্পগুলি তদন্ত করেছি এবং সেগুলির মধ্যে কিছু বাস্তবে প্রয়োগ করার চেষ্টা করেছি। শেষ পর্যন্ত—Google-এর কম লেটেন্সি পরিকাঠামোর জন্য ধন্যবাদ—আমরা সহজভাবে অনুরোধের একটি বিস্ফোরণ নমুনা করতে সক্ষম হয়েছি এবং একটি রেফারেন্স হিসাবে সর্বনিম্ন লেটেন্সি সহ নমুনাটি ব্যবহার করতে পেরেছি।

যুদ্ধ ঘড়ি প্রবাহ

এটা কাজ করেছে! আমাদের 5+ ডিভাইস নিখুঁত সিঙ্কে একটি পালস বাজছিল—কিন্তু শুধুমাত্র কিছু সময়ের জন্য। কয়েক মিনিটের জন্য বাজানোর পরে ডিভাইসগুলি আলাদা হয়ে যাবে যদিও আমরা অত্যন্ত সুনির্দিষ্ট ওয়েব অডিও API প্রসঙ্গ সময় ব্যবহার করে শব্দ নির্ধারণ করেছি। ব্যবধান ধীরে ধীরে জমা হয়, এক সময়ে মাত্র কয়েক মিলিসেকেন্ডে এবং প্রথমে সনাক্ত করা যায় না, কিন্তু দীর্ঘ সময়ের জন্য বাজানোর পরে মিউজিক্যাল স্তরগুলি সম্পূর্ণরূপে সিঙ্কের বাইরে চলে যায়। হ্যালো, ঘড়ি প্রবাহ.

সমাধানটি ছিল প্রতি কয়েক সেকেন্ডে পুনরায় সিঙ্ক করা, একটি নতুন ঘড়ি অফসেট গণনা করা এবং এটিকে অডিও শিডিউলারে নির্বিঘ্নে খাওয়ানো। নেটওয়ার্ক ল্যাগের কারণে সঙ্গীতে উল্লেখযোগ্য পরিবর্তনের ঝুঁকি কমাতে, আমরা সর্বশেষ সিঙ্ক অফসেটের ইতিহাস রেখে এবং গড় গণনা করে পরিবর্তনটি মসৃণ করার সিদ্ধান্ত নিয়েছি।

সময়সূচী গান এবং সুইচিং ব্যবস্থা

একটি ইন্টারেক্টিভ সাউন্ড এক্সপেরিয়েন্স করার মানে হল যে গানের কিছু অংশ কখন বাজবে তা আপনার আর নিয়ন্ত্রণে নেই, যেহেতু আপনি বর্তমান অবস্থা পরিবর্তন করতে ব্যবহারকারীর ক্রিয়াকলাপের উপর নির্ভর করেন। আমাদের নিশ্চিত করতে হয়েছিল যে আমরা একটি সময়মত পদ্ধতিতে গানের ব্যবস্থাগুলির মধ্যে স্যুইচ করতে পারি, যার অর্থ আমাদের সময়সূচীকে পরবর্তী ব্যবস্থায় স্যুইচ করার আগে বর্তমানে বাজানো বারটির কতটা অবশিষ্ট আছে তা গণনা করতে সক্ষম হতে হবে। আমাদের অ্যালগরিদম এইরকম কিছু খুঁজছে:

• Client(1) গান শুরু করে।
• Client(n) প্রথম ক্লায়েন্টকে জিজ্ঞাসা করে কখন গানটি শুরু হয়েছিল।
• Client(n) একটি রেফারেন্স পয়েন্ট গণনা করে যখন গানটি তার ওয়েব অডিও প্রসঙ্গ ব্যবহার করে শুরু করা হয়েছিল, সিঙ্কঅফসেটে ফ্যাক্টরিং করা হয়েছে এবং এটির অডিও প্রসঙ্গ তৈরি হওয়ার পর থেকে যে সময় অতিবাহিত হয়েছে।
• playDelta = Date.now() - syncOffset - songStartTime - context.currentTime
• Client(n) গণনা করে কতক্ষণ গানটি প্লেডেল্টা ব্যবহার করে চলছে। বর্তমান বিন্যাসে কোন বারটি পরবর্তী বাজানো উচিত তা জানতে গানের সময়সূচী এটি ব্যবহার করে।
• playTime = playDelta + context.currentTime nextBar = Math.ceil((playTime % loopDuration) ÷ barDuration) % numberOfBars

বিচক্ষণতার জন্য, আমরা আমাদের ব্যবস্থা সবসময় আট বার লম্বা এবং একই টেম্পো (প্রতি মিনিটে বিট) এর মধ্যে সীমাবদ্ধ রেখেছি।

সামনে দেখো

JavaScript-এ setTimeout বা setInterval ব্যবহার করার সময় আগে থেকে সময় নির্ধারণ করা সবসময় গুরুত্বপূর্ণ। এর কারণ হল জাভাস্ক্রিপ্ট ঘড়িটি খুব সুনির্দিষ্ট নয় এবং নির্ধারিত কলব্যাকগুলি সহজেই লেআউট, রেন্ডারিং, আবর্জনা সংগ্রহ এবং XMLHTTPR অনুরোধের মাধ্যমে দশ মিলিসেকেন্ড বা তার বেশি দ্বারা তির্যক করা যেতে পারে। আমাদের ক্ষেত্রে সমস্ত ক্লায়েন্টদের নেটওয়ার্কের মাধ্যমে একই ইভেন্ট পেতে যে সময় লাগে তাও আমাদের বিবেচনা করতে হয়েছিল।

অডিও sprites

এইচটিটিএমএল অডিও এবং ওয়েব অডিও এপিআই উভয়ের জন্যই একটি ফাইলে শব্দগুলিকে একত্রিত করা HTTP অনুরোধগুলি হ্রাস করার একটি দুর্দান্ত উপায়। এটি অডিও অবজেক্ট ব্যবহার করে প্রতিক্রিয়াশীলভাবে শব্দগুলি চালানোর সর্বোত্তম উপায় হতে পারে, যেহেতু এটি চালানোর আগে একটি নতুন অডিও অবজেক্ট লোড করতে হবে না। সেখানে ইতিমধ্যে কিছু ভাল বাস্তবায়ন রয়েছে যা আমরা একটি সূচনা পয়েন্ট হিসাবে ব্যবহার করেছি। আমরা আইওএস এবং অ্যান্ড্রয়েড উভয় ক্ষেত্রেই নির্ভরযোগ্যভাবে কাজ করার পাশাপাশি ডিভাইসগুলি ঘুমিয়ে পড়ে এমন কিছু অদ্ভুত কেস পরিচালনা করার জন্য আমাদের স্প্রাইটকে প্রসারিত করেছি।

অ্যান্ড্রয়েডে, আপনি ডিভাইসটিকে স্লিপ মোডে রাখলেও অডিও উপাদানগুলি বাজতে থাকে। স্লিপ মোডে, জাভাস্ক্রিপ্ট এক্সিকিউশন ব্যাটারি সংরক্ষণের জন্য সীমাবদ্ধ এবং আপনি কলব্যাক ফায়ার করতে requestAnimationFrame , setInterval বা setTimeout উপর নির্ভর করতে পারবেন না। এটি একটি সমস্যা কারণ অডিও স্প্রাইটগুলি জাভাস্ক্রিপ্টের উপর নির্ভর করে প্লেব্যাক বন্ধ করা উচিত কিনা তা পরীক্ষা করা। বিষয়টিকে আরও খারাপ করার জন্য, কিছু ক্ষেত্রে অডিও উপাদানটির currentTime আপডেট হয় না যদিও অডিওটি এখনও বাজছে।

একটি নন-ওয়েব অডিও ফলব্যাক হিসাবে আমরা Chrome রেসারে যে AudioSprite বাস্তবায়ন ব্যবহার করেছি তা দেখুন।

অডিও উপাদান

আমরা যখন রেসারে কাজ শুরু করি, তখনও Android এর জন্য Chrome ওয়েব অডিও API সমর্থন করেনি। কিছু ডিভাইসের জন্য HTML অডিও ব্যবহার করার যুক্তি, অন্যদের জন্য ওয়েব অডিও API, উন্নত অডিও আউটপুটের সাথে মিলিত যা আমরা অর্জন করতে চেয়েছিলাম কিছু আকর্ষণীয় চ্যালেঞ্জের জন্য তৈরি। সৌভাগ্যক্রমে, এই সব এখন ইতিহাস. ওয়েব অডিও API Android M28 বিটাতে প্রয়োগ করা হয়েছে।

• বিলম্ব/সময় সমস্যা। আপনি যখন এটি চালাতে বলেন তখন অডিও উপাদানটি সবসময় ঠিকভাবে বাজতে পারে না। যেহেতু জাভাস্ক্রিপ্ট একক থ্রেডেড, ব্রাউজারটি ব্যস্ত থাকতে পারে, যার ফলে দুই সেকেন্ড পর্যন্ত প্লেব্যাক বিলম্ব হতে পারে।
• প্লেব্যাক বিলম্ব মানে মসৃণ লুপিং সবসময় সম্ভব নয়। ডেস্কটপে আপনি কিছুটা ফাঁকহীন লুপগুলি অর্জন করতে ডবল বাফারিং ব্যবহার করতে পারেন, তবে মোবাইল ডিভাইসে এটি একটি বিকল্প নয়, কারণ:
  • বেশিরভাগ মোবাইল ডিভাইস এক সময়ে একাধিক অডিও উপাদান চালাবে না।
  • স্থির ভলিউম। Android বা iOS উভয়ই আপনাকে অডিও অবজেক্টের ভলিউম পরিবর্তন করতে দেয় না।
• কোনো প্রিলোডিং নেই। মোবাইল ডিভাইসে, touchStart হ্যান্ডলারে প্লেব্যাক শুরু না করা পর্যন্ত অডিও উপাদানটি তার উৎস লোড করা শুরু করবে না।
• সমস্যা খুঁজছেন. আপনার সার্ভার HTTP বাইট-রেঞ্জ সমর্থন না করলে duration পাওয়া বা currentTime সেট করা ব্যর্থ হবে। আপনি যদি আমাদের মতো একটি অডিও স্প্রাইট তৈরি করেন তবে এটির জন্য সতর্ক থাকুন।
• MP3-এ মৌলিক প্রমাণীকরণ ব্যর্থ হয়। কিছু ডিভাইস বেসিক প্রমাণ দ্বারা সুরক্ষিত MP3 ফাইল লোড করতে ব্যর্থ হয় , আপনি কোন ব্রাউজার ব্যবহার করছেন না কেন।

উপসংহার

ওয়েবের জন্য শব্দের সাথে মোকাবিলা করার সর্বোত্তম বিকল্প হিসাবে নিঃশব্দ বোতামটি আঘাত করার পর থেকে আমরা অনেক দূর এগিয়েছি, তবে এটি কেবল শুরু এবং ওয়েব অডিও শক্ত হতে চলেছে। একাধিক ডিভাইস সিঙ্ক করার ক্ষেত্রে কী করা যেতে পারে তা আমরা কেবলমাত্র স্পর্শ করেছি৷ আমাদের ফোন এবং ট্যাবলেটগুলিতে সিগন্যাল প্রসেসিং এবং প্রভাবগুলিতে (যেমন রিভার্ব) ডুব দেওয়ার জন্য প্রক্রিয়াকরণ শক্তি ছিল না, তবে ডিভাইসের কার্যকারিতা বাড়ার সাথে সাথে ওয়েব ভিত্তিক গেমগুলিও সেই বৈশিষ্ট্যগুলির সুবিধা নেবে৷ শব্দের সম্ভাবনাগুলিকে ঠেলে দেওয়ার জন্য এই উত্তেজনাপূর্ণ সময়গুলি।