มีการบรรยาย (หรืออย่างน้อยก็ไม่ใช่ spatiotemporal) ที่เน้นกลไก / กรอบงานหรือไม่? [ปิด]

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

ในขณะที่ฉันจะไม่เสแสร้งฉันได้ทำการตรวจสอบที่ลึกกว่านี้ฉันสังเกตว่าเอ็นจิ้นเกม / เฟรมเวิร์กทั้งหมดที่ฉันดูดูเหมือนจะเป็นอะไรที่เหมือนกับเอ็นจิ้นกราฟิคที่น่ายกย่องในแง่ที่ว่าพวกเขาพูดถึงรูปร่าง / เอนทิตี้ หรือปริภูมิแบบยุคลิดแบบสามมิติด้วยอาจเป็นรูปแบบหนึ่งของรูปแบบการทำงานพร้อมกัน "ซ่อนตัว" อนุญาตให้มีการระบุรูปแบบของตรรกะที่ติดอยู่กับ "เอนทิตี้" เหล่านี้

เกม "กฏ" และการบรรยายจะถูกเขียนด้วยวิธี ad-hoc (เทียบกับเอ็นจิ้น) ทางด้านบนของสิ่งเหล่านี้

เห็นได้ชัดว่าคำอธิบายข้างต้นค่อนข้างง่าย (ใช้เครื่องมือพิเศษเช่นเครื่องยนต์อินฟินิตี้ซึ่งรวมถึงรูปแบบของการสืบเสาะ / ระบบการเล่าเรื่อง) และฉันรู้ว่าแบบจำลองนี้ทำงานได้ค่อนข้างดี (ผู้คนจำนวนมากดูเหมือนจะใช้มัน) .

ฉันสงสัยว่าสิ่งใดที่พยายามสร้างเอ็นจิ้น / เฟรมเวิร์กที่ใช้ความคิดเช่น (ระดับสูง) คำอธิบายเกี่ยวกับกฎของเกม / ตรรกะหรือการเล่าเรื่อง (หรืออย่างน้อยก็เป็นแง่มุมที่ไม่ใช่เชิงพื้นที่ของเกม) เป็นหลัก พื้นฐาน?

แก้ไข (4): นี่ไม่ได้หมายความว่าเกมจะไม่รวมลักษณะเชิงพื้นที่ / กราฟิกเพียงแค่นั้นแทนที่จะมีหน่วยงานเชิงพื้นที่ที่คุณเชื่อมโยงตรรกะคุณมีแนวคิดเกี่ยวกับพล็อต (หรือเพลย์หรือ "กฎของเกมกระดาน" ) ซึ่งคุณจะอธิบายถึงส่วนต่อประสานกราฟิกกับ / การทำให้เป็นจริง

โดยเฉพาะอย่างยิ่งฉันจะสนใจวิธีการประกาศใด ๆ ที่พยายามที่จะจับความหมายบางอย่างของกึ่งทางการของเกมที่มีขนาดใหญ่พอสมควรในทางที่เป็นประโยชน์สำหรับการนำไปใช้จริง (ตรงข้ามกับตัวอย่างเช่นกรอบสำหรับ การวิเคราะห์เชิงคุณภาพของเกม / การบรรยาย)

สิ่งที่ผมเคยเห็นมีการตรวจสอบบางอย่างในการสร้างแบบจำลอง / การวิเคราะห์การเล่าเรื่องที่มีรูปแบบสุทธิตาม Petriและบางวิธีที่น่าสนใจในlangauges สำหรับการเขียนนิยายแบบโต้ตอบ

แก้ไข (1): ฉันคิดว่าฉันจะเพิ่มตัวอย่างของเล่นเพื่ออธิบาย

สมมติว่าเราสนใจสร้างจุด & คลิกสไตล์การผจญภัย (คิดว่าเกม SCUMM) หนึ่งอาจวิเคราะห์สิ่งเหล่านี้ตามความคิดของความก้าวหน้าเชิงเส้นมากขึ้นหรือน้อยลงจากสถานการณ์เริ่มต้นไปยังจุดสิ้นสุด

การมุ่งเน้นไปที่แนวคิดเรื่องความก้าวหน้าแบบไม่ต่อเนื่องและการอนุญาตให้มีความไม่เป็นเชิงเส้นบางคนอาจเลือกทฤษฎีของDAG (จำกัด ขอบเขต) เป็นทฤษฎีพื้นฐาน การระบุเกมประเภทนี้ในรูปแบบนามธรรม (เมื่อเทียบกับทฤษฎีนี้) ส่วนใหญ่จึงสอดคล้องกับการเพิ่มสัจพจน์เพิ่มเติมกับทฤษฎีนี้ (เพื่อให้ทฤษฎีระบุกราฟที่เฉพาะเจาะจงหรือเพียงพอที่จะจับสิ่งที่คิดว่าจำเป็นต้องจับภาพ "พล็อต")

การเปลี่ยนสิ่งนี้ให้กลายเป็นเกมจริงตอนนี้กลายเป็นปัญหาการออกแบบ HCI / ส่วนต่อประสานของการฝังทฤษฎีนี้ลงในสิ่งที่สามารถเล่นได้ (เช่นการสร้างแบบจำลองของทฤษฎี / การค้นหา homo (iso?) morphism ของกราฟจากการรวบรวม ลงใน DAG "ระบุเกม")

ในสถานการณ์สมมติข้างต้นฉันสามารถเห็นสิ่งต่าง ๆ อย่างน้อยสามสิ่งที่ควรเป็นไปได้ในการจับภาพในห้องสมุด ประการแรกต้องการเครื่องมือสำหรับการแปลง / การให้เหตุผลเกี่ยวกับ DAG หรือกราฟโดยทั่วไป ประการที่สองห้องสมุดส่วนต่อประสานผู้ใช้ฉลาดพอที่จะช่วยในการตรวจสอบว่าการแสดงกราฟของเราเป็นเกมที่เล่นได้จริงสร้างกราฟ (เช่นอย่างน้อยบางส่วน / อย่างไม่เป็นทางการพิสูจน์ว่าเกมไม่มีสถานะติดขัดเนื่องจากเงื่อนไขขอบเขต) . ในที่สุดก็สามารถรวบรวมห้องสมุดระดับสูงเพื่อระบุกราฟได้ เช่นไลบรารีสำหรับการแสดงอักขระและกราฟการโต้ตอบและการสร้าง (ส่วนต่าง ๆ ) ในแง่ของ

เหตุใดจึงต้องรักษาทฤษฎี "DAGs" ไว้กลางคันแทนที่จะนำไปใช้ในระดับต่ำโดยมีไลบรารีความช่วยเหลืออยู่ด้านบน คำตอบคือเหตุผลทั้งหมดสำหรับความหมายที่เป็นทางการ เนื่องจากเราได้ตัดสินใจบนพื้นฐานที่เป็นทางการเราสามารถตรวจสอบคุณสมบัติบางอย่างของเกมเพื่อให้เหตุผลเกี่ยวกับสิ่งต่าง ๆ เช่นการปรับให้เหมาะสมในอินเทอร์เฟซไลบรารีระดับต่ำ (ตราบใดที่มันเป็นแบบจำลองของ DAG ที่เราสามารถทำได้ กังวลเกี่ยวกับความไม่สามารถเทียบเคียงได้กับคำอธิบายระดับสูง (ของตัวละคร / บทสนทนา ฯลฯ ) เนื่องจากคำอธิบายเหล่านั้นต้องอธิบายโครงสร้างดังกล่าวด้วยตนเอง

ฉันไม่ได้หมายถึงวิธีการข้างต้นโดยเฉพาะจะทำงานและความคิดไม่ได้ว่า DAG จะต้องเป็นสิ่งที่ถูกเก็บไว้ในความทรงจำจริง ๆ แต่ฉันหวังว่านี่จะแสดงให้เห็นถึงวิธีการที่ฉันอยากรู้

ในระยะสั้นฉันเดาว่าอาจมีชื่ออื่นสำหรับคำถามนี้: Dijkstra จะเขียนเกมคอมพิวเตอร์ได้อย่างไร

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

ฉันสังเกตเห็นว่าเอ็นจิ้นเกม / เฟรมเวิร์กทั้งหมดที่ฉันได้มองดูเหมือนจะเป็นอะไรที่คล้ายกับเอ็นจิ้นกราฟิคที่ได้รับการยกย่องในแง่ที่ว่าพวกเขาพูดถึงรูปร่าง / เอนทิตีในพื้นที่สองมิติหรือสามมิติ [... ]

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

มีความพยายามใดในการสร้างเอ็นจิ้น / กรอบที่ใช้ความคิดเช่น (ระดับสูง) คำอธิบายของกฎของเกม / ตรรกะหรือการเล่าเรื่อง

มีความพยายามอย่างจริงจังเล็กน้อยไม่ประสบความสำเร็จเท่าที่ฉันรู้

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

ในระดับที่มีความทะเยอทะยานน้อยมีผู้คนมากมายที่คิดหาวิธีง่ายๆในการแสดงเกมง่ายๆ หนึ่งกระดาษจากหลายเรื่องคือMultigame - ภาษาระดับสูงมากสำหรับอธิบายเกมกระดาน (ลิงก์อยู่ด้านหลังการเข้าสู่ระบบ แต่คุณอาจจะสามารถค้นหาได้) แต่สิ่งที่คุณมีในตอนท้ายคือคอมพิวเตอร์ที่สามารถอ่านได้ สถานะการเปลี่ยนสถานะและเงื่อนไขชัยชนะหรือฟังก์ชั่นการเก็บคะแนน - ดีสำหรับเกมกระดานที่ไม่ต่อเนื่องเช่นหมากรุกหรือเกมไพ่เช่นโป๊กเกอร์ แต่พวกเขาไม่ได้พูดคุยกับเกมที่มีสถานะต่อเนื่องจำนวนมากหรือผู้ที่มีความหมายมากกว่า เช่นเกมจำลอง (เช่นเกมยิงปืน) หรือกีฬา (เช่นเกมแข่งรถ) เกมดังกล่าวไม่สามารถแสดงผ่านทรีเกมอย่างง่ายได้

วิธีหนึ่งในการเข้าถึงความเข้าใจของระบบที่ซับซ้อนมากขึ้นเหล่านี้คือการลองและจัดหมวดหมู่กลไกที่มีอยู่เป็นหนึ่งในหลาย ๆ รูปแบบพื้นฐานและจากนั้นหาวิธีที่รูปแบบพื้นฐานสามารถรวมกันเป็นรูปแบบการเล่นที่ซับซ้อนมากขึ้นได้ จะประกอบด้วยหน่วยพื้นฐานเหล่านี้หรือการรวมกันของมัน Dan Cook มีบทความที่ชื่อว่า " What Game Mechanics ?" และการติดตาม " เคมีของการออกแบบเกม"ซึ่งพยายามที่จะจัดทำเอกสารการจัดองค์ประกอบแบบนี้กับการออกแบบเกมในทางทฤษฎีมันอาจเป็นไปได้ที่จะสร้างระบบการประกาศด้านบน แต่ในทางปฏิบัติกลไกจะเป็นเพียงส่วนเล็ก ๆ ของเกมเท่านั้น ภายในกรอบการนำเสนอที่ไม่ยืดหยุ่นพอที่จะดึงดูดความสนใจของนักเล่นเกมส่วนใหญ่

ความพยายามอื่น ๆ ในการออกแบบเกมอย่างเป็นทางการมักเรียกว่า "เกมหลักไวยากรณ์" - บทความดังกล่าวหนึ่งชื่อ " ผู้เล่นหลายคนเกมอะตอม " แต่นั่นหมายถึงกลับไปทำงานต่าง ๆ ก่อนหน้านี้

สมมติว่าเราสนใจสร้างจุด & คลิกสไตล์การผจญภัย (คิดว่าเกม SCUMM) [... ] บางคนอาจเลือกทฤษฎีของ DAG (จำกัด ขอบเขต) เป็นทฤษฎีพื้นฐาน [... ] ประการแรกต้องการเครื่องมือสำหรับการแปลง / การให้เหตุผลเกี่ยวกับ DAG หรือกราฟโดยทั่วไป ประการที่สองห้องสมุดส่วนต่อประสานผู้ใช้ฉลาดพอที่จะช่วยในการตรวจสอบว่าการแสดงกราฟของเราเป็นเกมที่เล่นได้จริงสร้างกราฟ (เช่นอย่างน้อยบางส่วน / อย่างไม่เป็นทางการพิสูจน์ว่าเกมไม่มีสถานะติดขัดเนื่องจากเงื่อนไขขอบเขต) . ในที่สุดก็สามารถรวบรวมห้องสมุดระดับสูงเพื่อระบุกราฟได้ เช่นไลบรารีสำหรับการแสดงอักขระและกราฟการโต้ตอบและการสร้าง (ส่วนต่าง ๆ ) ในแง่ของ

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

ตอนนี้ฉันทำงานกับทีมเกี่ยวกับผลิตภัณฑ์ที่ชื่อว่าStorybricksซึ่งพยายามอนุญาตให้มีการสร้างเกมการเล่นที่น่าสนใจผ่านการระบุกฎต่าง ๆ และกฎเหล่านี้อาจระบุสถานะเริ่มต้นของบุคคลความต้องการของพวกเขาและอื่น ๆ เป็นการง่ายที่จะใช้กฎเหล่านี้และตรวจสอบว่าความต้องการของบุคคลนั้นสามารถตอบสนองได้หรือไม่และถ้าเป็นเช่นนั้นอย่างไรและอย่างไรจึงจะสร้างงานที่ต้องทำให้เสร็จในเกม อย่างไรก็ตามสิ่งนี้เองไม่ได้สร้างรูปแบบการเล่นที่น่าสนใจเพราะเมื่อคุณสรุปสิ่งต่างๆลงไปจนถึงระดับของ "X ต้องการ Y - ดึงมันมาให้พวกเขา" ผู้เล่นจะเริ่มเห็นรูปแบบและหยุดสนุกกับมัน (ตัวอย่างเช่น: ผู้คนเหนื่อยกับการทำเควสอัตโนมัติใน Skyrim เพราะพวกเขาเห็นว่าไม่มีความหมายโดยธรรมชาติของภารกิจที่สร้างขึ้นตามขั้นตอนเมื่อเทียบกับภารกิจที่สร้างขึ้นโดยนักออกแบบ ) ดังนั้นงานของเราคือการใช้วิธีการ AI เพื่อทำให้สถานการณ์เหล่านี้น่าสนใจยิ่งขึ้นและนั่นคือสิ่งที่เรายังคงดำเนินการอยู่ (Storybricks ยังอยู่ในช่วงต้นอัลฟา) แต่งานวิจัยของเราระบุว่ามีคนไม่กี่คนที่พยายามทำสิ่งนี้และเป็นปัญหาที่ยากมาก

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

ฉันกำลังพิจารณาวิธีการตอบกลับชั่วขณะหนึ่งและฉันก็ไม่แน่ใจว่าจะนำสิ่งนี้ไปใช้อย่างไร

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

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

นั่นคือสิ่งที่อยู่ในระดับต่ำ บางคนจำเป็นต้องใช้ความคิดอย่างลึกซึ้งในประเด็นทางเทคนิคเล็กน้อยเหล่านี้ทั้งหมด

เท่าที่กฎการเล่าเรื่องและเกมไป? นั่นอยู่นอกขอบเขตของสิ่งที่เอ็นจิ้นเกมควรทำ นี่คือส่วนที่กลุ่มพัฒนาเข้ามา

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

ดังนั้นในใจแล้วภาษาสามารถสร้างขึ้นเป็นพิเศษสำหรับเกมที่เน้นการบรรยายได้หรือไม่? ฉันจะบอกว่าอาจจะไม่ อีกครั้งทั้งหมดนี้ลงมาเพื่อเป็นตัวแทน ภาษาจะต้องสามารถอธิบายรายละเอียดได้ในลักษณะที่คอมพิวเตอร์รู้ว่าต้องทำอะไร หากจุดประสงค์คือการสร้างภาษาที่เฉพาะเจาะจงสำหรับการสร้างเกมดังนั้นการตัดสินใจการออกแบบใด ๆ ควรอยู่ตรงกลางของสิ่งนั้น

และอีกครั้งมีตัวเลือกภาษามากมาย และผู้คนมากกว่าแค่ผู้ที่อยู่ในอุตสาหกรรมเกมเท่านั้นที่พัฒนาพวกเขา โดยทั่วไปแล้วมันสมเหตุสมผลที่จะใช้หนึ่งในนั้น

โดยสรุปคุณถามคำถามที่น่าสนใจ แต่ยากมาก และฉันก็ไม่แน่ใจว่ามันคืออะไรหรือถ้าฉันตอบมันจริงๆ

* แก้ไข: ในความเข้าใจย้อนหลังฉันรู้ว่าฉันเพิ่งพิจารณาเอ็นจิ้นเกม 3D ราวกับว่ามันเป็นเกมเดียวที่มีอยู่ เกมบางเกมไม่มีคนทำหน้าที่ในพื้นที่ทางกายภาพเลย แม้ว่าในกรณีเช่นนี้ฉันไม่แน่ใจว่าเอ็นจิ้นเกมจะมีส่วนช่วยมาก

ในช่วงต้นของประวัติศาสตร์ของงานอดิเรกการคำนวณ (เช่นยุค 80) มีชุดพัฒนาเกมเชิงพาณิชย์สำหรับเกมทั้งแบบข้อความและแบบสไปรต์ สไปรต์ที่ใช้นั้นคล้ายกับ "กราฟิคเอ็นจิ้น" ในปัจจุบัน

ประเภทอื่นรวมถึงสิ่งต่าง ๆ เช่น parsers ภาษาธรรมชาติ ประเภทนี้ดูเหมือนจะอยู่ใน "บรรณาธิการระดับ" ที่ทันสมัย ส่วนใหญ่ดูเหมือนจะมีการสนับสนุนบางอย่างเช่น Lua หรือ Python scripting ฉันจะทราบด้วยว่าฉันไม่เห็นกิจกรรมมากมายในการแก้ไขระดับโอเพ่นซอร์ส แต่นั่นเป็นเพราะสิ่งเหล่านี้มักจะควบคู่ไปกับความเฉพาะของเกมที่มีปัญหา ฉันกำลังคิดเกี่ยวกับสิ่งที่เหมือนกับชุดการก่อสร้างของ Elder Scrolls

Kinect อาจนำ parser กลับมา ในฐานะที่เป็นแฟนของเกมผจญภัยแบบข้อความเก่าฉันตื่นเต้นกับทิศทางของ Bethesda ที่นี่เช่นกัน แน่นอนที่สุดมันเป็นกรรมสิทธิ์ แต่อาจอัจฉริยะบาง ...