เกมที่สร้างมาเพื่อเบราว์เซอร์เริ่มจริงจังขึ้นแล้ว: โปรเจกต์ระบบต่อสู้โอเพนซอร์สเผยให้เห็นอะไร

ตอนเริ่มงานวิจัยนี้ ผมคาดว่าจะเจอเพียงการทดลองระบบต่อสู้บนเบราว์เซอร์ที่น่าสนใจไม่กี่ชิ้น แต่สิ่งที่พบกลับเป็นระบบนิเวศที่กว้างกว่านั้นมาก: มีต้นแบบเกมแอ็กชันมุมมองบุคคลที่สามจริง ๆ ที่รองรับการล็อกเป้า สายคอมโบแบบแตกแขนง การปัดป้องแบบสมบูรณ์ เฟรมไร้ความเสียหายระหว่างการหลบ ระบบท่วงท่า การโจมตีกลางอากาศ สัญญาณเตือนท่าของบอส การปรับการเคลื่อนที่ให้เข้ากับแอนิเมชัน การหยุดเฟรมเมื่อโจมตีโดน การปะทะของอาวุธด้วยฟิสิกส์ การรองรับเกมแพด การควบคุมด้วยการสัมผัส และการจำลองแบบกำหนดผลได้แน่นอน

นี่คือผลลัพธ์ที่สำคัญที่สุด เกมเหล่านี้ไม่ใช่แค่เกมเล็ก ๆ ที่บังเอิญเรนเดอร์อยู่ในหน้าเว็บอีกต่อไป บางโปรเจกต์กำลังแก้ปัญหาทางวิศวกรรมแบบเดียวกับเกมแอ็กชันทั่วไป เพียงแต่เผยแพร่ผ่าน 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 ที่จริงจังขึ้นเรื่อย ๆ และระบบนิเวศการพัฒนาขนาดมหาศาลที่มีอยู่แล้ว

เว็บไม่ได้เพียงเก่งขึ้นในการแสดงเกมที่สร้างจากที่อื่นเท่านั้น แต่กำลังกลายเป็นพื้นที่ที่ระบบเกมจริงจังสามารถออกแบบ พัฒนา ทดสอบ เผยแพร่ และเล่นได้โดยตรงมากขึ้นเรื่อย ๆ