ব্রাউজার-নেটিভ গেম এখন সিরিয়াস পর্যায়ে: ওপেন-সোর্স কমব্যাট প্রকল্পগুলো কী দেখায়

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

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

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

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

আমি যে সবচেয়ে শক্তিশালী প্রকল্পগুলো পেয়েছি

সবচেয়ে উপকারী আবিষ্কারগুলো একই কারণে শক্তিশালী ছিল না। কিছু প্রকল্পে ছিল গভীরতম কম্বো সিস্টেম। অন্যগুলোতে ছিল ভালো থার্ড-পার্সন আর্কিটেকচার, আরও পরিষ্কার কমব্যাট সিমুলেশন, কিংবা আরও বিশ্বাসযোগ্য শারীরিক আঘাত।

ফলাফল আমাকে কেন অবাক করেছে

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

এতে একটি উপকারী পার্থক্য পরিষ্কার হয়:

• অ্যানিমেশন টাইমিং আর কমব্যাট টাইমিং এক জিনিস নয়;
• রেন্ডারিং ফ্রেম রেট আর সিমুলেশন রেট এক জিনিস নয়;
• কলিশন হলেই সেটি স্বয়ংক্রিয়ভাবে বৈধ হিট হয় না;
• অ্যানিমেশনই সবসময় মুভমেন্ট অথরিটি নয়;
• চোখে দেখা সংস্পর্শ আর অনুভূত ইমপ্যাক্ট এক জিনিস নয়।

এই পার্থক্যগুলো সবচেয়ে শক্তিশালী প্রকল্পগুলোতে বারবার দেখা গেছে, এবং 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 রিসোর্স ম্যানেজমেন্ট;
• অডিও টাইমিং;
• ডিটারমিনিস্টিক সিস্টেম।

একই সময়ে ব্রাউজারকে লক্ষ্য করে কাজ করা গেম ডেভেলপাররা এমন সুবিধা পান, যেগুলোতে ওয়েব আগেই অসাধারণ দক্ষ: URL, তাৎক্ষণিক ডিপ্লয়মেন্ট, CDN ডেলিভারি, দ্রুত আপডেট, টেলিমেট্রি, অ্যাকাউন্ট সিস্টেম, রেসপনসিভ ইন্টারফেস এবং সহজ শেয়ারিং।

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

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