میں نے یہ تحقیق اس توقع کے ساتھ شروع کی تھی کہ براؤزر کمبیٹ کے چند دلچسپ تجربات ملیں گے۔ اس کے بجائے مجھے ایک کہیں زیادہ وسیع ایکوسسٹم ملا: حقیقی تھرڈ پرسن ایکشن پروٹوٹائپس جن میں لاک آن ٹارگٹنگ، شاخ دار کومبو ٹریز، پرفیکٹ پیری، ڈاج کے دوران ناقابلِ ضرب فریمز، پوسچر سسٹمز، فضائی حملے، باس ٹیلی گرافس، موشن وارپنگ، ہٹ اسٹاپ، ہتھیاروں کی حقیقی جسمانی ٹکر، گیم پیڈ سپورٹ، ٹچ کنٹرولز اور ڈیٹرمنسٹک سیمولیشن شامل تھے۔
یہی اہم نتیجہ ہے۔ یہ اب محض چھوٹے گیمز نہیں رہے جو اتفاقاً کسی ویب پیج کے اندر رینڈر ہو جاتے ہیں۔ ان میں سے کچھ وہی انجینئرنگ مسائل حل کر رہے ہیں جو روایتی ایکشن گیمز کرتے ہیں، مگر انہیں URL کی صورت میں تقسیم کیا جا سکتا ہے اور فوراً کھیلا جا سکتا ہے۔
ایک ویب ڈیولپر کے طور پر میرے لیے یہی حصہ سب سے زیادہ دلچسپ ہے۔ گیمز کے بارے میں پرانا ذہنی تصور انسٹالرز، بڑے ڈاؤن لوڈز، پیچرز، لانچرز اور کسی گیم کو دریافت کرنے سے حقیقتاً اسے کھیلنا شروع کرنے تک کی تاخیر کے گرد گھومتا تھا۔ براؤزر اس راستے کو ڈرامائی طور پر مختصر کر دیتا ہے: لنک کھولیں، اثاثے لوڈ کریں، اور کھیلنا شروع کر دیں۔
اس تحقیق میں میری توجہ ان پروجیکٹس پر تھی جن کا قابلِ کھیل براؤزر بلڈ اور عوامی سورس کوڈ موجود تھا۔ Unity WebGL ایکسپورٹس کو جان بوجھ کر خارج کیا گیا، کیونکہ میں ایسے گیمز کا مطالعہ کرنا چاہتا تھا جو ویب ٹیکنالوجیز کے گرد بنائے گئے ہوں، نہ کہ ایسے گیمز کا جو محض ویب پر ایکسپورٹ کیے گئے ہوں۔
سب سے مضبوط پروجیکٹس جو مجھے ملے
سب سے مفید دریافتیں سب ایک ہی وجہ سے مضبوط نہیں تھیں۔ کچھ میں سب سے گہرے کومبو سسٹمز تھے۔ دوسروں میں بہتر تھرڈ پرسن آرکیٹیکچر، زیادہ صاف کمبیٹ سیمولیشن، یا زیادہ قائل کرنے والی جسمانی ضربیں تھیں۔
| پروجیکٹ | بہترین پہلو | کیا مطالعہ کریں | ڈیمو | سورس |
|---|---|---|---|---|
| Long Wind | جدید تھرڈ پرسن کمبیٹ | لاک آن، پیری، پوسچر، ایگزیکیوشن، ہٹ ریکشنز | ڈیمو کھیلیں | GitHub |
| Voxel Musou | کومبو آرکیٹیکچر | شاخ دار مووز، فضائی حملے، کریکٹر کٹس، ہجوم | ڈیمو کھیلیں | GitHub |
| Rotten Souls | تھرڈ پرسن بنیاد | لاک آن، ڈاج، باس کمبیٹ، اینیمیشن اور کیمرے کی ساخت | ڈیمو کھیلیں | GitHub |
| Samurai Third-Person Template | موشن وارپنگ | حملے کی پوزیشننگ، ٹارگٹنگ، روٹ موشن حکمتِ عملی | ڈیمو کھیلیں | GitHub |
| Stick & Steel | فزکس پر مبنی میلی | ہتھیار کا رابطہ، گارڈ کی سمت، امپیکٹ کی توثیق، ناک ڈاؤنز | ڈیمو کھیلیں | GitHub |
| Jelly Colosseum | مختصر میلی لوپ | لائٹ/ہیوی حملے، پیری، اسٹیمنا، گارڈ بریک، ہتھیار کی شناخت | ڈیمو کھیلیں | GitHub |
| Hollowmere | کمبیٹ آرکیٹیکچر | ڈیٹرمنسٹک سیمولیشن، مرکزی دفاعی ریزولوشن، ٹیسٹنگ | ڈیمو کھیلیں | GitHub |
| Fabled Revolutions | گیم فیل | ہٹ اسٹاپ، کیمرہ شیک، ٹریلز، پارٹیکلز، ناک بیک، امپیکٹ فیڈبیک | ڈیمو کھیلیں | GitHub |
نتائج نے مجھے کیوں حیران کیا
حیرت کی بات صرف یہ نہیں تھی کہ گرافکس اچھے دکھائی دیتے تھے۔ ایک پالش شدہ منظر کو رینڈر کرنا گیم ڈیولپمنٹ کا صرف ایک حصہ ہے۔ نمایاں ہونے والے پروجیکٹس ایسے سسٹمز نافذ کر رہے تھے جنہیں قائل کن انداز میں نقل کرنا مشکل ہے: اِن پٹ بفرنگ، کمبیٹ اسٹیٹ ٹرانزیشنز، ٹارگٹ سلیکشن، اٹیک موومنٹ، اینیمیشن ٹائمنگ، ہٹ ڈیٹیکشن، دشمن کے ردِعمل، دفاعی ونڈوز، کیمرے کا رویہ اور امپیکٹ فیڈبیک۔
اس سے ایک مفید فرق واضح ہوتا ہے:
- اینیمیشن ٹائمنگ اور کمبیٹ ٹائمنگ ایک چیز نہیں؛
- رینڈرنگ فریم ریٹ اور سیمولیشن ریٹ ایک چیز نہیں؛
- کولیشن خود بخود درست ہٹ نہیں ہوتی؛
- اینیمیشن لازماً موومنٹ اتھارٹی نہیں؛
- نظر آنے والا رابطہ اور محسوس ہونے والا امپیکٹ ایک چیز نہیں۔
یہ فرق سب سے مضبوط پروجیکٹس میں بار بار سامنے آئے، اور README میں رینڈرر کے لوگو سے زیادہ اہم ہیں۔
Voxel Musou: براؤزر کمبیٹ میں حقیقی موو گرامر بھی ہو سکتی ہے
Voxel Musou ان واضح ترین مثالوں میں سے ایک تھا جن سے پتا چلتا ہے کہ براؤزر کمبیٹ کا مطلب اب یہ نہیں کہ ایک بٹن کے ساتھ صرف ایک اٹیک اینیمیشن بندھی ہو۔ اس کا سورس یہاں دستیاب ہے: mike007jd/voxel-musou۔
یہ پروجیکٹ مکمل طور پر لینیئر کومبو کے بجائے لمبی نارمل اٹیک چینز اور چارج برانچز استعمال کرتا ہے۔ آرکیٹیکچر کے لحاظ سے یہ اس لیے اہم ہے کہ سسٹم کو یوں ماڈل کیا جا سکتا ہے:
current move + buffered input + combat state -> next moveخاص حالتوں کے لیے شرطوں کے بڑھتے ہوئے مجموعے کے مقابلے میں یہ کریکٹر ایکشن گیم کے لیے کہیں بہتر بنیاد ہے۔ یہ فضائی حملے، خاص سیکوئنسز، متعدد کریکٹر کٹس، باس کا رویہ، ہٹ اسٹاپ اور دشمنوں کے بڑے گروہوں کے خلاف کمبیٹ بھی دکھاتا ہے۔
وسیع تر انجینئرنگ سبق یہ ہے کہ مووز کو ڈیٹا بننا چاہیے اور ٹرانزیشنز کو واضح ہونا چاہیے۔ ایسا ہو جائے تو ایک اور کریکٹر شامل کرنے کے لیے پورا کمبیٹ کنٹرولر دوبارہ لکھنے کی ضرورت نہیں رہتی۔
Long Wind: جدید براؤزر ایکشن گیم سے قریب ترین مثال
Long Wind سب سے مضبوط آل اِن ون حوالوں میں سے ایک تھا، کیونکہ یہ تھرڈ پرسن موومنٹ کے ساتھ لائٹ اور ہیوی حملے، لاک آن، گارڈنگ، پرفیکٹ پیری، ڈاج اِن ولنرایبلٹی، پوسچر پریشر، ایگزیکیوشنز، لانچ اور ناک ڈاؤن ریکشنز، پروجیکٹائلز، باسز اور متعدد دشمن آرکی ٹائپس کو یکجا کرتا ہے۔ اس کا سورس یہاں دستیاب ہے: jbang2004/long-wind۔
اس کی اہمیت اس وجہ سے نہیں کہ ہر الگ فیچر بے مثال ہے، بلکہ اس لیے ہے کہ یہ تمام فیچرز ایک ہی براؤزر-نیٹو ایکشن پروٹوٹائپ میں اکٹھے موجود ہیں۔ اس بنا پر اِن پٹ سے ٹارگٹ سلیکشن، اٹیک اسٹیٹ، اینیمیشن، رابطہ، ردِعمل، ہٹ اسٹاپ اور کیمرہ فیڈبیک تک پورا راستہ سمجھنے کے لیے یہ ایک مفید حوالہ ہے۔
موشن وارپنگ ایک ایسا مسئلہ حل کرتی ہے جسے ویب ڈیموز اکثر نظر انداز کرتے ہیں
Samurai Third-Person Template ThreeJS خاص طور پر دلچسپ ہے کیونکہ یہ تھرڈ پرسن میلی کے ایک کلاسیکی مسئلے کو حل کرتا ہے۔ اس کا سورس یہاں دستیاب ہے: achrefelouafi/SamuraiThirdPersonTemplateThreeJS۔
پہلے سے بنائی گئی ایک اٹیک اینیمیشن یہ فرض کرتی ہے کہ ضرب کے کانٹیکٹ فریم تک پہنچنے کے وقت ٹارگٹ ایک خاص فاصلے پر ہوگا۔ حقیقی گیم میں ٹارگٹ تقریباً کبھی بالکل درست جگہ پر نہیں ہوتا۔ اگر کریکٹر اپنی جگہ کھڑا رہ کر صرف اینیمیشن چلائے، تو گیم ڈیمیج دینے کے باوجود تلوار بظاہر نشانے سے چوک سکتی ہے۔ اور اگر کریکٹر کو ٹیلی پورٹ کر کے درست جگہ پر پہنچایا جائے، تو حملہ مصنوعی محسوس ہوتا ہے۔
موشن وارپنگ بہتر جواب دیتی ہے: حملے کے دوران روٹیشن اور ٹرانسلیشن کو اس طرح ایڈجسٹ کیا جائے کہ کریکٹر صحیح لمحے پر متوقع رابطے کی پوزیشن تک پہنچ جائے۔
اہم فرق یہ ہے:
animation intent != movement authorityایک کریکٹر پہلے سے بنائی گئی اینیمیشن کے بصری ارادے کو برقرار رکھ سکتا ہے، جبکہ گیم پلے کنٹرولر ہی اس بات پر اختیار رکھتا ہے کہ کریکٹر حقیقت میں کہاں جائے گا۔
کولیشن ڈیٹیکشن اور ہٹ ویلیڈیشن الگ مسائل ہیں
Stick & Steel ایک بہت مختلف کمبیٹ ماڈل آزماتا ہے۔ اس کا سورس یہاں دستیاب ہے: Rabneba/stick-steel۔
تلوار کو بنیادی طور پر ڈیمیج والیوم والی اینیمیشن سمجھنے کے بجائے، یہ پروجیکٹ ہتھیاروں کو حقیقی جسمانی موجودگی دیتا ہے۔ رابطے کی رفتار، ہتھیار کی سمت، جسم کا حصہ، گارڈز، ٹکراؤ، ناک ڈاؤنز اور غیر مسلح کرنا سب اہم ہوتے ہیں۔
سب سے آسانی سے دوسری جگہ منتقل ہونے والا سبق یہ نہیں کہ ہر ایکشن گیم کو مکمل طور پر فزیکل ہتھیار استعمال کرنے چاہییں۔ اصل بات یہ ہے:
کولیشن صرف یہ بتاتی ہے کہ دو چیزیں ایک دوسرے سے ٹکرائیں۔ یہ نہیں بتاتی کہ کوئی معنی خیز ہٹ ہوئی یا نہیں۔
ایک قائل کن کمبیٹ سسٹم کو اکثر دوسری تہہ درکار ہوتی ہے جو طے کرے کہ رابطے میں کافی رفتار تھی یا نہیں، سمت درست تھی یا نہیں، ہتھیار کا درست حصہ لگا یا نہیں، ٹائمنگ درست تھی یا نہیں، اور ٹارگٹ کی حالت ڈیمیج شمار کرنے کے لیے درست تھی یا نہیں۔
مرکزی کمبیٹ ریزولوشن پیچیدہ دفاع کو سمجھنا آسان بناتا ہے
Hollowmere، جس کا سورس euuuuuuan/hollowmere-public پر ہے، بصری تماشے کے بجائے سافٹ ویئر آرکیٹیکچر کی وجہ سے زیادہ نمایاں ہوا۔
اس کی کمبیٹ سیمولیشن کو رینڈرنگ سے الگ رکھا گیا ہے، اور دفاعی ریزولوشن مرکزی ہے۔ اس سے ایکشن گیمز کی ایک عام ناکامی سے بچا جاتا ہے، جہاں ڈاج سسٹم، پیری سسٹم، ہٹ ریکشن سسٹم اور اینیمیشن کی تہہ ایک ہی حملے کے لگنے یا نہ لگنے پر الگ الگ نتیجے نکال سکتے ہیں۔
زیادہ صاف ذہنی ماڈل یہ ہے:
incoming attack -> evade | parry | hitرینڈرر کو نتیجہ دکھانا چاہیے، کمبیٹ کی حقیقت کا دوسرا ورژن ایجاد نہیں کرنا چاہیے۔
کمبیٹ بڑھنے کے ساتھ یہ فرق زیادہ اہم ہوتا جاتا ہے۔ ڈیٹرمنسٹک سیمولیشن اور واضح اسٹیٹ ٹرانزیشنز کوئی چمک دار فیچرز نہیں، مگر یہ پیچیدہ کمبیٹ کو ٹیسٹ، ڈیبگ اور توسیع دینا آسان بناتے ہیں۔
گیم فیل ایک انجینئرنگ سسٹم ہے، سجاوٹ نہیں
Fabled Revolutions، جس کا سورس ericrius1/FabledRevolutions پر ہے، خاص طور پر اس لیے مفید ہے کہ یہ ان اثرات کو الگ دکھاتا ہے جو ہٹس کو وزنی اور مؤثر محسوس کراتے ہیں۔
منطقی طور پر درست کمبیٹ سسٹم بھی کمزور محسوس ہو سکتا ہے۔ کولیشن درست ہو سکتی ہے، صحیح فریم پر ڈیمیج لگ سکتا ہے، پھر بھی نتیجہ ایسا لگ سکتا ہے جیسے دو ماڈلز ایک دوسرے کے اندر سے گزر گئے ہوں۔
محسوس ہونے والا امپیکٹ اکثر مختصر مدت کے اثرات کی تہہ سے بنتا ہے:
- ہٹ اسٹاپ؛
- کیمرہ شیک یا کِک؛
- ہتھیاروں کی ٹریلز؛
- امپیکٹ پارٹیکلز؛
- چوٹ کا فلیش؛
- ناک بیک؛
- اینیمیشن ریکشن؛
- صحیح وقت پر آواز۔
یہ ایک اور مفید فرق کی طرف اشارہ کرتا ہے: کمبیٹ کی درستی اور کمبیٹ کا احساس ایک چیز نہیں۔ براؤزر گیم کو دونوں درکار ہیں۔
کمبیٹ کے معیار کا اصل پیش گو رینڈرر نہیں تھا
تحقیق میں ایک دلچسپ پیٹرن یہ تھا کہ بہترین کمبیٹ اس بات سے طے نہیں ہوا کہ کسی پروجیکٹ نے سب سے نیا رینڈرنگ API استعمال کیا یا نہیں۔
Three.js بار بار سامنے آیا۔ کچھ پروجیکٹس نے WebGPU سے متعلق رینڈرنگ ٹیکنالوجی استعمال کی، دوسروں نے روایتی WebGL پر مبنی اسٹیکس۔ پوری تحقیق میں ফزکس انجنز، TypeScript، JavaScript، Vite، WebAssembly اور رینڈرنگ کے مختلف طریقے نظر آئے۔
لیکن پیچیدہ کمبیٹ زیادہ مستقل طور پر آرکیٹیکچر پر منحصر تھا: فکسڈ اسٹیپ سیمولیشن، واضح اسٹیٹس، قابلِ اعتماد ٹارگٹنگ، اینیمیشن اونرشپ کا معقول نظام، ڈیٹا ڈرِون مووز، مرکزی ڈیمیج ریزولوشن اور اچھا امپیکٹ فیڈبیک۔
یہ ویب ڈیولپرز کے لیے حوصلہ افزا ہے۔ سنجیدہ کمبیٹ ڈیزائن آزمانے سے پہلے ہر صارف کے پاس جدید ترین گرافکس اسٹیک آنے کا انتظار ضروری نہیں۔
براؤزر کے ذریعے تقسیم حساب کیوں بدل دیتی ہے
براؤزر کو ایک ایسی برتری حاصل ہے جس کا گرافکس سے بہت کم تعلق ہے: تقسیم کی رکاوٹ انتہائی کم ہے۔
روایتی گیمز اکثر دریافت سے کھیلنے تک کئی مراحل رکھتی ہیں: اسٹور پیج تلاش کریں، بڑا پیکیج ڈاؤن لوڈ کریں، انسٹال کریں، لانچ کریں، اپ ڈیٹس کا انتظار کریں، اور کبھی کبھی بامعنی گیم پلے تک پہنچنے سے پہلے اکاؤنٹ بھی بنائیں۔
براؤزر گیم اس پورے راستے کو ایک لنک تک محدود کر سکتی ہے۔
اس سے پروٹوٹائپ شیئر اور ٹیسٹ کرنے کا طریقہ بدل جاتا ہے۔ ایک ڈیولپر بلڈ شائع کر سکتا ہے، URL بھیج سکتا ہے، دوسرے شخص کو فوراً اسی ورژن میں لا سکتا ہے، فیڈبیک لے سکتا ہے، اور ٹیسٹر سے نیا پیکیج دستی طور پر انسٹال کرائے بغیر اگلی اٹریشن ڈپلائے کر سکتا ہے۔
یہ فائدہ تجرباتی گیمز اور آزاد ڈیولپمنٹ کے لیے خاص طور پر اہم ہو جاتا ہے۔ براؤزر صرف رن ٹائم نہیں، تقسیم کا نظام بھی ہے۔
جہاں براؤزر اب بھی پیچھے ہے
اس تحقیق نے مجھے یہ قائل نہیں کیا کہ براؤزرز نے نیٹو گیم پلیٹ فارمز کی جگہ لے لی ہے۔ انہوں نے نہیں لی۔
کئی پابندیاں اب بھی اہم ہیں:
- بڑے اثاثہ جاتی پے لوڈز۔ اگر گیم کو شروع میں بہت بڑا ڈاؤن لوڈ چاہیے تو فوری رسائی فوری محسوس نہیں ہوتی۔
- میموری پریشر۔ براؤزرز کو دوسرے ٹیبز اور آپریٹنگ سسٹم کے ساتھ چلنا پڑتا ہے، اور مخصوص نیٹو پراسس کے مقابلے میں میموری کا رویہ کم قابلِ پیش گو ہوتا ہے۔
- موبائل تھرمل حدود۔ تکنیکی طور پر چلنے والا 3D گیم بھی طویل سیشن میں بری طرح تھروٹل ہو سکتا ہے۔
- براؤزر کے فرق۔ گرافکس، آڈیو، پوائنٹر لاک، فل اسکرین رویہ، کنٹرولرز اور کارکردگی کی خصوصیات ہر جگہ بالکل یکساں نہیں۔
- شیڈر اور اثاثوں کی تیاری۔ اگر پائپ لائن احتیاط سے ڈیزائن نہ کی گئی ہو تو کمپائلیشن یا اپ لوڈ کا کام اب بھی نظر آنے والے وقفے پیدا کر سکتا ہے۔
- آف لائن اور مقامی پائیداری کی حدود۔ نیٹو ایپلی کیشنز بڑی مقامی انسٹالیشنز اور فائلز پر زیادہ براہِ راست کنٹرول رکھتی ہیں۔
- مسابقتی سیکیورٹی۔ جب کلائنٹ ایک ویب ایپلی کیشن ہو تو سنجیدہ اینٹی چیٹ اور دشمن کلائنٹ سے متعلق مفروضے کہیں زیادہ مشکل ہو جاتے ہیں۔
یہ پابندیاں اہم ہیں کیونکہ یہی طے کرتی ہیں کہ آج براؤزر گیمز کہاں سب سے مضبوط ہیں: وہ گیمز جو فوری رسائی، تیز اٹریشن، کراس پلیٹ فارم ڈلیوری اور قابلِ انتظام اثاثہ/رن ٹائم بجٹس سے فائدہ اٹھاتی ہیں۔
AI پروٹوٹائپ سے URL تک کے لوپ کو بہت مختصر کر دیتی ہے
یہاں AI متعلق ہے، لیکن اس لیے نہیں کہ وہ جادو سے ایک جملے کو مکمل اعلیٰ معیار کے گیم میں بدل دیتی ہے۔ زیادہ حقیقت پسندانہ فائدہ اٹریشن کی رفتار ہے۔
جدید گیم ڈیولپمنٹ میں بہت سے چھوٹے کام ہوتے ہیں جو مجموعی طور پر مہنگے پڑتے ہیں: اسٹیٹ مشینز ترتیب دینا، ڈیبگ ویوز بنانا، ٹیسٹس لکھنا، دشمن کے رویوں کے تجربات کرنا، مووز کے ڈیٹا فارمیٹس بنانا، اِن پٹ کوڈ کو ری فیکٹر کرنا، شیڈرز کے پروٹوٹائپس بنانا، فزکس بگز کی جانچ کرنا، اور عارضی مواد کو جوڑنا۔
AI ان میں سے بہت سے لوپس مختصر کر سکتی ہے۔ ویب ڈسٹری بیوشن کے ساتھ مل کر ورک فلو غیر معمولی طور پر براہِ راست ہو جاتا ہے:
idea -> prototype -> deploy -> open URL -> test -> iterateبراؤزر پہلے ہی ڈپلائمنٹ تیز کرتا ہے۔ AI اسی لوپ کے امپلی مینٹیشن والے حصے کو بھی تیز کر سکتی ہے۔
اہم احتیاط یہ ہے کہ تیز جنریشن، ذوق یا توثیق کی جگہ نہیں لیتی۔ بنایا گیا کمبیٹ کنٹرولر ساختی طور پر غلط ہو سکتا ہے۔ اینیمیشن ٹائمنگ میں اب بھی انسانی فیصلہ درکار ہے۔ فزکس کو اب بھی ڈیبگ کرنا پڑتا ہے۔ کارکردگی کو اب بھی ناپنا پڑتا ہے۔ AI خیالات آزمانے کی لاگت کم کرتی ہے؛ یہ فیصلہ کرنے کی ضرورت ختم نہیں کرتی کہ کون سے خیالات اچھے ہیں۔
ویب ڈیولپرز کے لیے اس کا کیا مطلب ہے
ویب ڈیولپمنٹ اور گیم ڈیولپمنٹ کے درمیان حد کم سخت ہوتی جا رہی ہے۔
ایک سنجیدہ براؤزر گیم اب مانوس ویب ٹولنگ استعمال کر سکتی ہے، جبکہ اسے کلاسیکی گیم انجینئرنگ تصورات کی بھی ضرورت ہو سکتی ہے:
- فکسڈ سیمولیشن اسٹیپس؛
- اسٹیٹ مشینز؛
- اِن پٹ بفرنگ؛
- اینیمیشن گرافس؛
- اسپیشل کوئریز؛
- فزکس؛
- فریم بجٹس؛
- GPU ریسورس مینجمنٹ؛
- آڈیو ٹائمنگ؛
- ڈیٹرمنسٹک سسٹمز۔
اسی وقت براؤزر کو ہدف بنانے والے گیم ڈیولپرز کو وہ چیزیں بھی ملتی ہیں جن میں ویب پہلے ہی غیر معمولی طور پر اچھا ہے: URLs، فوری ڈپلائمنٹ، CDN ڈلیوری، تیز اپ ڈیٹس، ٹیلی میٹری، اکاؤنٹ سسٹمز، ریسپانسیو انٹرفیسز اور بغیر رکاوٹ شیئرنگ۔
اس تحقیق نے میرا اپنا ذہنی تصور بدل دیا۔ اب میں براؤزر گیمز کو بنیادی طور پر نیٹو گیمز کے آسان ورژن نہیں سمجھتا۔ میں براؤزر کو ایک ایسی گیم پلیٹ فارم کے طور پر دیکھتا ہوں جو مسلسل زیادہ قابل ہو رہی ہے اور جس کی طاقتیں مختلف ہیں: فوری تقسیم، تیز اٹریشن، بڑھتی ہوئی سنجیدہ 3D صلاحیتیں، اور ایک بہت بڑا موجودہ ڈیولپمنٹ ایکوسسٹم۔
ویب صرف کہیں اور بنائے گئے گیمز دکھانے میں بہتر نہیں ہو رہا۔ یہ مسلسل ایسی جگہ بنتا جا رہا ہے جہاں سنجیدہ گیم سسٹمز کو براہِ راست ڈیزائن، نافذ، ٹیسٹ، تقسیم اور کھیلا جا سکتا ہے۔