ตรรกะของเกมเดียวกันในไลบรารีกราฟิกแยกกันสองแห่ง


11

รหัสปรัชญา / โครงสร้างของนามธรรม / การออกแบบโปรแกรมจะอนุญาตให้เกมที่จะใช้กับกราฟิก 2D และ 3D (แยก) โดยไม่ต้องรหัสตรรกะเกมอีกครั้ง?

เรากำลังพูดถึงการใช้รหัสเดียวกันเปลี่ยนสิ่งต่าง ๆ น้อยที่สุด (ตัวอย่างเช่นแลกเปลี่ยนชื่อไฟล์สำหรับเนื้อหา 2 มิติด้วยชื่อไฟล์สำหรับเนื้อหา 3 มิติ) และอาจเสียบปลั๊กเฉพาะในคลาสพื้นฐานต่อ generics / เทมเพลต

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

หากต้องการวางไว้ในบริบท MVC: ตัวควบคุมเหมือนกัน (การกดปุ่ม "ขึ้น" จะตั้งค่าการเร่งความเร็วของผู้เล่นที่ 3.5 หน่วย / วินาที) มุมมองจะแตกต่างกันโดยสิ้นเชิง (2D กับ 3D) และโมเดลจะเหมือนกัน ยกเว้นสิ่งที่เกี่ยวข้องโดยตรงกับกราฟฟิค (ตรวจสอบการชนกันของสภาพแวดล้อมทุก 5 วินาทีและใช้อัลกอริธึมเดียวกันโปรดทราบว่านี่หมายความว่ามีพิกัด Z สำหรับวัตถุเกมทั้งหมดในรุ่น 2D แต่มันเป็น เพียงเพิกเฉยหรือแสดงต่อผู้ใช้ในอีกทางหนึ่งตัวอย่างเช่นเงาที่ปรากฏขึ้นทางด้านซ้ายเมื่อผู้เล่นอยู่ในอากาศ)

สิ่งที่ทำให้สิ่งนี้เป็นหัวข้อที่น่าสนใจคือมันจะบังคับให้นักพัฒนามีความคิดที่ชัดเจนว่าโครงสร้างข้อมูลของเขาและวิธีการควบคุมการไหล โปรดทราบว่าสิ่งนี้ไม่ได้หมายถึงการใช้สิ่งอื่นนอกเหนือจากห้องสมุดกราฟิกเช่น SDL, D3DX หรือ OpenGL ไม่มีเอ็นจิ้นเกม!

เนื่องจากนี่เป็นคำถามเชิงทฤษฎีส่วนใหญ่ฉันจะปล่อยให้ภาษาการเขียนโปรแกรมออกไปจากมัน แต่ถ้าคุณต้องการยกตัวอย่างคุณสามารถใช้ภาษาใดก็ได้ที่คุณชอบ C ++ ถ้าคุณต้องการที่จะไปทั้งหมูหรือแม้แต่ Brainfuck ถ้าคุณรู้สึก ขึ้นกับความท้าทาย (คำตอบที่เป็นรูปธรรมใด ๆ จะได้รับการชื่นชมเช่นเดียวกับคนที่เป็นนามธรรม!)


ฉันไม่แน่ใจว่ามันใช้งานได้จริง ตรรกะของเกมจำนวนมากใช้คณิตศาสตร์แบบเวกเตอร์คุณต้องทำทุกอย่างในแบบ 3 มิติก่อนที่จะแปลงเป็น 2D หรืออะไรก็ตามที่ใช้ในการเรนเดอร์
tenpn

ค้นหาคำว่า "Abstraction layer" และทำความคุ้นเคยกับมันเพราะคุณสองคนจะทำงานร่วมกันซักพัก
zaratustra

คำตอบ:


8

ฉันคิดว่าคุณจะต้องมีเลเยอร์ของนามธรรมที่ล้อมรอบไลบรารีกราฟิกของคุณ คุณจะต้องใช้ไลบรารีใหม่สำหรับแต่ละไลบรารีที่คุณจะใช้และแต่ละไลบรารีจะต้องมี API ภายนอกที่แน่นอน

คิดถึงการแปลสตริง: แทนที่จะเข้ารหัสสตริง "สินค้าคงคลัง" อย่างหนักในเกมของคุณคุณจะต้องเรียกห้องสมุดแปลโลคัล (อาจสร้างขึ้นเอง) ซึ่งจะทำกระบวนการบางอย่างและส่งคืนสตริงที่เหมาะสมทั้งนี้ขึ้นอยู่กับบริบทของ เกม.

ในทำนองเดียวกันการเรียกไปยังเอ็นจิ้นกราฟิคของคุณทั้งหมดจะทำผ่าน wrapper ของคุณรอบ ๆ

ในการทำเช่นนี้คุณจะ จำกัด / จำกัด คำสั่งที่คุณสามารถให้เครื่องมือกราฟิกของคุณ นี่คือบางสิ่งที่จำเป็น:

  1. วาด (วัตถุกราฟิก) ที่ (ตำแหน่ง)
  2. แก้ไขคุณสมบัติ (อัลฟาหมุน ฯลฯ ) ของ (วัตถุกราฟิก)
  3. ย้าย (วัตถุกราฟิก) ไปที่ (ตำแหน่ง)
  4. สร้างแผนที่ของ (ชื่อระดับ / โครงสร้างข้อมูล)

และคนอื่น ๆ ซึ่งคุณจะพบเมื่อคุณทำงานในโครงการของคุณ

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

ตอนนี้สร้าง wrapper ใหม่สำหรับแต่ละของห้องสมุดกราฟิกของคุณและดำเนินการของ API เมื่อได้รับคำสั่งให้วาด__ at __คุณต้องใช้รหัสเพื่อสร้าง sprite หรือ model และวาดลงในสภาพแวดล้อมของคุณ สิ่งนี้อาจต้องใช้กลอุบายบางอย่างเช่นการเก็บสไปรต์แต่ละอันในแฮชเพื่อให้สามารถเข้าถึงได้อีกครั้งในเวลาอื่นด้วยสัญลักษณ์ที่กำหนด

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

หวังว่าสิ่งนี้จะช่วยให้คุณเริ่มต้น =]


2

การสร้างสถาปัตยกรรมเกมของคุณด้วยกระบวนทัศน์ที่อยู่ใกล้กับ MVC มากพอที่จะทำให้โค้ดแสดงผลที่เป็นนามธรรมสมบูรณ์อาจเป็นเรื่องยากสำหรับโครงการขนาดใหญ่ อย่างไรก็ตามดูเหมือนว่าอุปสรรคที่ใหญ่ที่สุดในการสร้างเกมที่รองรับทั้งลูกค้า 2D และ 3D จะเป็นการออกแบบเกมที่ลูกค้าทั้งสองมีความสามารถเท่าเทียมกัน

จำเป็นต้องเริ่มการออกแบบเกมของคุณด้วยความตั้งใจอย่างเต็มที่ในการสร้างและสนับสนุนลูกค้าทั้งสองและมันอาจจะปลอดภัยที่สุดในการ จำกัด การทำงานของเกมทั้งหมดในสิ่งที่เหมาะสมสำหรับลูกค้า 2D

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

เป็นการดีที่สุดที่จะกำหนดจำนวนการรับชมมุมมองเฉพาะสำหรับไคลเอนต์ 2D (8 หรือ 16 หรือเช่นนั้น) และพัฒนาเนื้อหาทั้งหมดให้เหมาะสมกับข้อ จำกัด เหล่านั้น น่าเสียดายถ้าคุณมีระดับและวัตถุที่ออกแบบมาให้ดูได้เฉพาะจากชุดของมุมที่เฉพาะเจาะจงมันสามารถดูค่อนข้างแปลกจากภายในไคลเอนต์ 3 มิติ

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


0

ฉันคิดว่าคุณตอบคำถามของคุณเองแล้ว:

หากต้องการวางไว้ในบริบท MVC: ตัวควบคุมจะเหมือนกันทุกประการ (การกดปุ่ม "ขึ้น" จะเป็นการตั้งค่าผู้เล่นที่ 3.5 วินาที / วินาที) การดูจะแตกต่างกันโดยสิ้นเชิง (2D กับ 3D) และโมเดลนั้นเหมือนกัน ยกเว้นสิ่งที่เกี่ยวข้องกับกราฟิกโดยตรง

ดังนั้นโดยการให้สิ่งที่เป็นนามธรรมที่เพียงพอระหว่างอินพุตตรรกะของเกม ฯลฯ และกราฟิกคุณจะได้แก้ปัญหาได้แล้ว

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


0

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

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

หากคุณต้องการวิธีการที่ซับซ้อนมากขึ้นให้พิจารณาความหลากหลายรูปแบบของที่ระลึกรูปแบบตารางแฮชพอยน์เตอร์พอยน์ * ฯลฯ อย่าสร้างมันขึ้นมา

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.