สไปรท์ในฐานะนักแสดง

ฉันไม่ได้มีประสบการณ์ในคำถามการพัฒนาเกม แต่เป็นโปรแกรมเมอร์ ในภาษาสกาล่าคุณสามารถปรับขยายการทำงานแบบมัลติทาสกิ้งกับนักแสดงได้อย่างมั่นคงในขณะที่ฉันได้ยิน คุณสามารถมีหลายแสนคนทำงานพร้อมกันโดยไม่มีปัญหา

ดังนั้นฉันคิดว่าบางทีคุณสามารถใช้สิ่งเหล่านี้เป็นคลาสพื้นฐานสำหรับ 2D-Sprites เพื่อแยกสิ่งลูปเกมที่ต้องผ่านสไปรต์ทั้งหมดและย้ายพวกเขา โดยพื้นฐานแล้วพวกเขาจะย้ายตัวเองขับเคลื่อนเหตุการณ์

นั่นจะสมเหตุสมผลสำหรับเกมหรือไม่? หากมีหลายภารกิจเช่นนั้น ท้ายที่สุดมันจะทำงานบน JVM แม้ว่าจะไม่เป็นปัญหามากในปัจจุบัน

แก้ไข:

หลังจากเล่นน้ำไปซักพักผมสังเกตเห็นว่ามีข้อได้เปรียบเพียงข้อเดียวที่แท้จริงสำหรับแนวคิดนี้: การสนับสนุนมัลติคอร์ เกมวนง่ายจะทำงานบนแกนเดียวเท่านั้นและจะทำงานทุกอย่างตามลำดับ

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

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

ฉันตั้งใจจะสร้างสิ่งนั้นลงในเอ็นจิ้น Scala 2D ของฉันโดยเร็วที่สุด

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

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

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

ฉันได้ติดตั้งเอ็นจิ้นเกม isometric 2d ใน Scala แล้ว ฉันใช้นักแสดงระดับโลกเพียง 1 คนเพื่ออัปเดตสไปรต์ที่มองเห็นซึ่งเป็นภาพเคลื่อนไหว

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

ยังถ้าฉันเป็นคุณฉันจะลองเพียงเพื่อดูว่าเกิดอะไรขึ้น

ดังนั้นฉันคิดว่าบางทีคุณสามารถใช้สิ่งเหล่านี้เป็นคลาสพื้นฐานสำหรับ 2D-Sprites เพื่อแยกสิ่งลูปเกมที่ต้องผ่านสไปรต์ทั้งหมดและย้ายพวกเขา โดยพื้นฐานแล้วพวกเขาจะย้ายตัวเองขับเคลื่อนเหตุการณ์

เหตุการณ์อะไรที่ทำให้พวกเขาเคลื่อนไหว?

มันจะเป็นเหตุการณ์ที่คุณปล่อยหนึ่งครั้งต่อเฟรมหรือไม่?

และถ้าเป็นเช่นนั้นสิ่งนี้มีการเปลี่ยนแปลงระบบในทางปฏิบัติอย่างไร?

เมื่อเริ่มศึกษาการวางแนววัตถุในบริบทของ C ++ ฉันได้เรียนรู้ว่าบางคนชอบคิดข้อความเช่นxyz.doThis(x)ความหมาย 'ส่งข้อความ doThis ไปยัง xyz (พร้อม payload ของ x) และรอการตอบกลับทันที' เมื่อดูในระดับนี้ไม่มีความแตกต่างที่แท้จริงระหว่างเหตุการณ์หรือระบบตามข้อความและขั้นตอนปกติ

นั่นเป็นวิธีการที่ยอดเยี่ยมในการคิดเกี่ยวกับการอัพเดตออบเจ็กต์เกมของคุณ ฉันไม่รู้ Scala แต่ฉันว่าให้ลองดูและดูว่ามันจะเปิดออกได้อย่างไรและโพสต์ผลลัพธ์ของคุณได้ดียิ่งขึ้น!

คำถามหลักที่ผุดขึ้นในใจของฉันคือ: คุณจะจัดการกับวัตถุเกมบางอย่างที่อัปเดตเมื่อเทียบกับคำถามอื่น ๆ ได้อย่างไร คุณจะต้องกังวลเกี่ยวกับนักแสดงสไปรท์ที่ทำรอบมากเกินไปหรือไม่เช่นนั้นระบบการเรนเดอร์ไม่มีเวลาในการวาดเฟรมทุกๆ 1/60 | 30th | 24 วินาที

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

ฉันก็ไม่ได้เป็นโปรแกรมเมอร์มากนัก แต่ฉันก็ไม่เห็นปัญหาใด ๆ กับข้อเสนอของคุณ ฉันไม่ได้คิดถึงวิธีพัฒนานักแสดง

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

ถ้าโดยเทพดาคุณหมายถึงเอนทิตีของเกมแล้วแน่นอน

เอนทิตีของเกมไม่ควรวาดเอง ควรปรับปรุงหมายเลขอ้างอิงกราฟิกที่อธิบายตำแหน่งและวิธีการวาด ระบบเรนเดอร์หรือกราฟฉากหรืออะไรก็ตามที่เป็นรูปวาดจริง มีการ์ดกราฟิกเดียวหนึ่งการ์ดและต้องมีการซิงโครไนซ์การ์ดทุก ๆ 16ms การตั้งค่าแบบนั้นทำงานได้ไม่ดีสำหรับการประมวลผลแบบอะซิงโครนัสแบบกระจาย

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

ฉันไม่ได้เป็นนักพัฒนา Scala แต่ฉันทำกับ Erlang ได้ค่อนข้างน้อย ดังนั้นหากคำศัพท์สกาล่าของฉันไม่ถูกต้องโปรดยกโทษให้ฉัน