คำถามติดแท็ก component-based

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

11 xna  c#  game-design  architecture  component-based 

เราเพิ่งเปลี่ยนจากเอ็นจิ้นเกมตามลำดับชั้นเป็นเอ็นจิ้นเกมตามองค์ประกอบ ปัญหาของฉันคือเมื่อฉันโหลดแบบจำลองที่มีลำดับชั้นของตาข่ายและวิธีที่ฉันเข้าใจคือเอนทิตีในระบบที่ใช้องค์ประกอบไม่สามารถมีองค์ประกอบหลายประเภทเดียวกัน แต่ฉันต้องการ "meshComponent" สำหรับแต่ละ ตาข่ายในแบบจำลอง ดังนั้นฉันจะแก้ไขปัญหานี้ได้อย่างไร ในเว็บไซต์นี้พวกเขาใช้เอ็นจิ้นเกมแบบอิงคอมโพเนนต์: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

11 architecture  component-based 

ขณะนี้ฉันกำลังพยายามใช้ระบบเอนทิตีที่อิงองค์ประกอบเป็นหลักโดยที่เอนทิตีนั้นเป็นเพียง ID และวิธีการช่วยเหลือบางอย่างที่ผูกส่วนประกอบหลายอย่างเข้าด้วยกันเพื่อสร้างวัตถุเกม เป้าหมายบางประการของที่รวมถึง: ส่วนประกอบประกอบด้วยสถานะ (เช่นตำแหน่งสุขภาพจำนวนกระสุน) => ตรรกะเข้าสู่ "ระบบ" ซึ่งดำเนินการส่วนประกอบเหล่านี้และสถานะของพวกเขา (เช่น PhysicsSystem, RenderSystem ฯลฯ ) ฉันต้องการใช้ส่วนประกอบและระบบทั้งใน C # และผ่านการเขียนสคริปต์ (Lua) โดยทั่วไปฉันต้องการที่จะสามารถกำหนดส่วนประกอบและระบบใหม่ทั้งหมดใน Lua ได้โดยตรงโดยไม่ต้องคอมไพล์ต้นฉบับ C # ของฉันอีกครั้ง ตอนนี้ฉันกำลังมองหาแนวคิดเกี่ยวกับวิธีจัดการสิ่งนี้อย่างมีประสิทธิภาพและไม่สม่ำเสมอดังนั้นฉันไม่จำเป็นต้องใช้ไวยากรณ์ที่แตกต่างเพื่อเข้าถึงคอมโพเนนต์ C # หรือส่วนประกอบ Lua ตัวอย่างเช่น แนวทางปัจจุบันของฉันคือการใช้ส่วนประกอบ C # โดยใช้คุณสมบัติสาธารณะทั่วไปอาจตกแต่งด้วยแอตทริบิวต์บางอย่างที่บอกบรรณาธิการเกี่ยวกับค่าเริ่มต้นและเนื้อหา จากนั้นฉันจะมี "ScriptComponent" ระดับ C ซึ่งเพิ่งล้อมตาราง Lua ภายในด้วยตารางนี้ถูกสร้างขึ้นโดยสคริปต์และเก็บสถานะทั้งหมดของประเภทองค์ประกอบเฉพาะนั้น ฉันไม่ต้องการเข้าถึงสถานะดังกล่าวจากด้าน C # มากเท่าที่ฉันจะไม่ทราบในเวลารวบรวมสิ่งที่ ScriptComponents พร้อมกับคุณสมบัติใดบ้างที่จะมีให้ฉัน ถึงกระนั้นผู้แก้ไขจะต้องเข้าใช้งาน …

11 c#  component-based  entity-system  scripting  lua 

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

11 component-based  validation 

ฉันเห็นเกมจำนวนมากที่กำหนดองค์ประกอบเอนทิตีในไฟล์สคริปต์ แต่เมื่อพวกเขากำหนดค่าแต่ละเอนทิตีและระบุว่ามีองค์ประกอบใดพวกเขาใช้รูปแบบไฟล์อื่น (เช่น XML) ทำไมพวกเขาทำอย่างนั้น? ฉันขอให้ส่วนใหญ่ดูว่าเหตุผลของคนอื่นคืออะไรสำหรับเรื่องนี้ ฉันยังกำหนดค่าเอนทิตีของฉันนอกสคริปต์ (แม้ว่าฉันเลือก JSON ไม่ใช่ XML) เหตุผลของฉันในการทำเช่นนี้คือทำให้ฉันง่ายต่อการใช้เกมบันทึกและเพราะฉันคิดว่าการกำหนดค่าประเภทนี้จัดระเบียบได้ดีกว่าในสิ่งที่ชอบ XML หรือ JSON คำตอบของ @ Christopher Larsenยาวเกินกว่าจะโพสต์เป็นความคิดเห็น ฉันกลัวว่าคุณอาจเบี่ยงเบนไปเล็กน้อยจากเรื่องของคำถาม ปัญหาที่คุณกำลังอธิบายเกี่ยวข้องกับหน่วยงานที่ใช้ลำดับชั้นมากกว่า ในคำถามของฉันฉันพูดถึงฉันกำลังพูดถึงเอนทิตีที่อิงองค์ประกอบ นี่คือตัวอย่างของสิ่งที่ฉันต้องการถาม ด้านล่างมีสองทางเลือกในการกำหนดค่าเอนทิตี: ผ่านสคริปต์และผ่านไฟล์ JSON ภายนอก คำถามของฉันคือทำไมผู้คนจำนวนมากต้องการกำหนดเอนทิตีนอกสคริปต์? คลาสเอนทิตีฐาน: class Entity: def __init__(self, name): pass def addComponent(self, comp): pass วิธีการสคริปต์: orc = Entity('Orc') orc.addComponent(PositionComponent(3.4, 7.9)) วิธีการ JSON: { "name" : …

11 component-based  scripting  entity-system  xml  configuration 

ฉันกำลังสร้างระบบเกมวัตถุ component-based เคล็ดลับบางอย่าง: GameObjectComponentsเป็นเพียงรายการ GameSubsystemsมี ยกตัวอย่างเช่นการแสดงผลฟิสิกส์ ฯลฯ แต่ละมีตัวชี้ไปยังบางส่วนของGameSubsystem เป็นนามธรรมที่ทรงพลังและยืดหยุ่นมาก: มันแสดงถึงส่วนใด ๆ ของเกม (หรือแง่มุม)ComponentsGameSubsystem มีความต้องการในกลไกของการลงทะเบียนComponentsในGameSubsystems(เมื่อGameObjectถูกสร้างและสงบ) มี4 วิธีคือ: 1: รูปแบบของความรับผิดชอบ ทุกคนมีให้แก่ทุกคนComponent ตัดสินใจในการลงทะเบียน (และวิธีการจัดระเบียบ) ตัวอย่างเช่น GameSubsystemRender สามารถลงทะเบียน Renderable Components ได้GameSubsystemGameSubsystemComponents มือโปร. Componentsไม่รู้อะไรเกี่ยวกับวิธีการใช้งาน คลัปต่ำ A.GameSubsystemเราสามารถเพิ่มใหม่ ตัวอย่างเช่นให้เพิ่ม GameSubsystemTitles ที่ลงทะเบียน ComponentTitle ทั้งหมดและรับประกันว่าทุกชื่อจะไม่ซ้ำกันและมีส่วนต่อประสานในการสอบถามวัตถุตามชื่อ แน่นอน ComponentTitle ไม่ควรเขียนใหม่หรือสืบทอดในกรณีนี้ B.GameSubsystemsเราสามารถจัดระเบียบที่มีอยู่ ตัวอย่างเช่น GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter สามารถผสานเข้ากับ GameSubsystemSpatial (เพื่อวางเสียง emmiter ทั้งหมดให้Componentsอยู่ในลำดับชั้นเดียวกันและใช้การแปลงแบบญาติสัมพันธ์) แย้ง …

11 c++  architecture  component-based 

ฉันทำเกมที่ออกแบบมาพร้อมกับกระบวนทัศน์นิติบุคคลองค์ประกอบว่าระบบที่ใช้ในการติดต่อสื่อสารระหว่างส่วนประกอบตามที่อธิบายไว้ที่นี่ ฉันได้มาถึงจุดในการพัฒนาของฉันที่ฉันต้องเพิ่มรัฐเกม (เช่นหยุดเล่นระดับเริ่มต้นรอบเริ่มเกมมากกว่า ฯลฯ ) แต่ฉันไม่แน่ใจว่าจะทำอย่างไรกับกรอบของฉัน ฉันได้ดูตัวอย่างโค้ดนี้ในสถานะเกมที่ทุกคนดูเหมือนจะอ้างอิง แต่ฉันคิดว่ามันไม่เหมาะกับกรอบงานของฉัน ดูเหมือนว่าแต่ละรัฐจัดการรูปวาดของตนเองและปรับปรุง เฟรมเวิร์กของฉันมี SystemManager ที่จัดการการอัพเดตทั้งหมดโดยใช้ระบบ ตัวอย่างเช่นนี่คือคลาส RenderingSystem ของฉัน: public class RenderingSystem extends GameSystem { private GameView gameView_; /** * Constructor * Creates a new RenderingSystem. * @param gameManager The game manager. Used to get the game components. */ public RenderingSystem(GameManager gameManager) { super(gameManager); …

11 architecture  component-based  entity-system  state 

ฉันกำลังติดตามหนังสือ "Learning LibGDX Game Development" เพื่อสร้างเกมอย่างง่าย ฉันอยู่ในส่วนการสร้างเมนูที่เราสร้างสเตจและแสดงผลด้วยเส้นขอบการดีบัก หนังสือเล่มนี้บอกว่าจะใช้Table.drawDebug(stage)แต่วิธีการแบบคงที่นี้ดูเหมือนว่าจะถูกลบออกจากTableชั้นเรียนกรอบทั้งหมด ฉันกำลังนำเข้าcom.badlogic.gdx.scenes.scene2d.ui.Table; ด้านล่างคือรหัสของฉัน: @Override public void render(float deltaTime) { Gdx.gl.glClearColor(0.0f, 0.0f, 0.0f, 1.0f); Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT); if (debugEnabled) { debugRebuildStage -= deltaTime; if (debugRebuildStage <= 0) { debugRebuildStage = DEBUG_REBUILD_INTERVAL; rebuildStage(); } } stage.act(deltaTime); stage.draw(); Table.drawDebug(stage); } บรรทัดสุดท้ายTable.drawDebug(stage);มีข้อผิดพลาดในการรวบรวม"The method drawDebug(ShapeRenderer) in the type Table is …

10 libgdx  unity  android  orientation  bug  rotate  game-design  ios  copyright  c++  rpg  statistics  java  android  andengine  music  eclipse  c++  directx  quaternion  shaders  lighting  java  libgdx  game-mechanics  unity  component-based  unityscript 

คำถามของฉันคือ: วิธีหนึ่งจะเก็บข้อมูลบริบททั่วโลกเช่น ข้อมูลข้อมูลโลกเวลาโลกปัจจุบัน ฯลฯ ในระบบองค์ประกอบเอนทิตี ฉันคิดว่าจะทำงานเพื่อสร้างเกมจำลองสถานการณ์แบบเปิดของ Dwarf Fortress สไตล์โลกใน C ++ ฉันได้สร้างเอ็นจิ้นเกมสไตล์เอนทิตีเพื่อความสนุกและตอนนี้ฉันกำลังพยายามหาวิธีที่ฉันจะทำงานในคุณสมบัติทั้งหมดที่ฉันต้องการ นอกเหนือจากการเล่นเกมมาตรฐาน (การเรนเดอร์ฟิสิกส์ข้อมูลส่วนประกอบเฉพาะเอนทิตี ฯลฯ ) แล้วฉันยังต้องการมีข้อมูลบริบทระดับโลกที่ระบบที่เกี่ยวข้องทั้งหมดสามารถเข้าถึงได้ (เช่นข้อมูลโลกเช่นปีปัจจุบัน ไม่ว่าจะเกิดภาวะโลกร้อนหรืออะไรก็ตามที่เกี่ยวข้องกับการจำลองโลก) เดิมทีฉันเคยคิดที่จะสร้างองค์ประกอบ "โลก" แต่มันดูไร้จุดหมายและยากหากระบบต่าง ๆ มากมายต้องการเข้าถึงข้อมูล "ทั่วโลก" อย่างมีเหตุผล มันจะสมเหตุสมผลไหมที่จะมีองค์ประกอบ "โลก" หรือฉันควรเก็บข้อมูลนี้ด้วยวิธีอื่น? ฉันยังคิดที่จะทำให้ข้อมูลนี้เป็นสากลดังนั้นจึงให้การเข้าถึงระบบใด ๆ ที่ต้องการใช้งาน ดูเหมือนเป็นการละเมิดหลักการองค์ประกอบเอนทิตี้โดยทั่วไปและอาจยุ่งเหยิงด้วยเหตุผลอื่น แต่ฉันคิดว่ามันอาจใช้งานได้จริง สิ่งอื่นที่ฉันคิดว่าน่าจะฝังข้อมูลบริบทโลกที่เกี่ยวข้องลงในระบบโดยตรง ตัวอย่างเช่นถ้าฉันมีAgeSystem"อายุ" เอนทิตีทั้งหมดที่มีgetsWeakerAsTimePassesส่วนประกอบหรืออะไรก็ตามบางทีระบบนี้อาจเก็บข้อมูลเวลาที่เกี่ยวข้องสำหรับโลกโดยตรงเป็นข้อมูลสมาชิกที่จะใช้ในการคำนวณเวลาที่ผ่านไปและจำนวนเท่าใด อายุและความอ่อนแอของผู้คน ฯลฯ ตัวเลือกที่สามนี้เป็นสิ่งที่ฉันชอบน้อยที่สุด แต่สิ่งที่เกิดขึ้นกับฉันในการระดมสมอง มีใครให้คำแนะนำได้บ้าง

10 c++  entity-system  component-based 

ขณะนี้ฉันกำลังประสบปัญหาต่อไปนี้: ฉันพยายามเขียน pong clone โดยใช้ระบบ component component (ECS) ฉันเขียน "กรอบงาน" ทั้งหมดด้วยตัวเอง ดังนั้นจึงมีคลาสที่จัดการเอนทิตีกับส่วนประกอบทั้งหมด จากนั้นจะมีคลาสคอมโพเนนต์เอง และสุดท้ายก็มีระบบของฉันที่เพิ่งได้รับเอนทิตีทั้งหมดที่มีส่วนประกอบที่ระบบต้องการ ตัวอย่างเช่นระบบการเคลื่อนไหวของฉันค้นหาหน่วยงานทั้งหมดที่มีองค์ประกอบตำแหน่งและส่วนประกอบการเคลื่อนไหว องค์ประกอบตำแหน่งเพียงแค่ดำรงตำแหน่งและองค์ประกอบการเคลื่อนไหวจะเก็บความเร็ว แต่ปัญหาที่แท้จริงคือระบบการชนของฉัน ชั้นนี้เป็นเหมือนหยดตรรกะ ฉันมีคดีพิเศษมากมายในชั้นนี้ ตัวอย่างเช่น: พายของฉันสามารถชนกับเส้นขอบได้ หากสิ่งนี้เกิดขึ้นความเร็วของพวกเขาจะถูกตั้งค่าเป็นศูนย์ ลูกของฉันสามารถชนกับเส้นเขตแดนได้เช่นกัน แต่ในกรณีนี้ความเร็วของมันจะถูกสะท้อนกลับตามปกติของเส้นขอบดังนั้นมันจึงสะท้อนออกมา เมื่อต้องการทำสิ่งนี้ฉันได้ให้องค์ประกอบฟิสิกส์พิเศษแก่ลูกบอลซึ่งเพิ่งบอกว่า: "เฮ้สิ่งนี้ไม่หยุดเลยมันสะท้อน" ดังนั้นองค์ประกอบทางฟิสิกส์ไม่มีข้อมูลจริง มันเป็นคลาสที่ว่างเปล่าซึ่งมีเพียงเพื่อบอกระบบว่าวัตถุสะท้อนหรือหยุด จากนั้นก็มาที่นี่: ฉันต้องการที่จะทำให้อนุภาคบางอย่างเมื่อลูกชนกับไม้พายหรือเส้นขอบ ดังนั้นฉันคิดว่าลูกบอลจะต้องมีส่วนประกอบอื่นที่บอกระบบการชนเพื่อสร้างอนุภาคในการชน จากนั้นฉันต้องการมี ups พลังงานซึ่งสามารถชนกับไม้พายได้ แต่ไม่ใช่กับเส้นขอบ หากเกิดเหตุการณ์เช่นนี้การเพิ่มพลังจะต้องหายไป ดังนั้นฉันจึงต้องการเคสและส่วนประกอบมากขึ้น (เพื่อบอกระบบว่าบางหน่วยงานสามารถชนกับคนอื่น ๆ ได้บางคนบอทไม่ได้อยู่ด้วยแม้ว่าคนอื่น ๆ จะสามารถชนกันได้จริง ๆ และระบบชนก็ต้องใช้พลังงาน -ups ไม้พายเป็นต้นและอื่น ๆ ) ฉันเห็นว่าระบบองค์ประกอบของเอนทิตีเป็นสิ่งที่ดีเพราะมีความยืดหยุ่นและคุณไม่มีปัญหาเกี่ยวกับการสืบทอด แต่ตอนนี้ฉันติดอยู่ทั้งหมด …

10 architecture  component-based  entity-system 

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

10 component-based 

ฉันกำลังพยายามออกแบบระบบเอนทิตีที่อิงองค์ประกอบเพื่อการเรียนรู้ (และใช้ในภายหลังในบางเกม) และฉันมีปัญหาบางอย่างเมื่อต้องอัพเดตสถานะเอนทิตี ฉันไม่ต้องการให้มีการอัปเดตวิธี () ภายในคอมโพเนนต์เพื่อป้องกันการพึ่งพาระหว่างคอมโพเนนต์ สิ่งที่ฉันมีอยู่ในใจในขณะนี้คือส่วนประกอบเก็บข้อมูลและส่วนประกอบการปรับปรุงระบบ ดังนั้นถ้าฉันมีเกม 2D ง่าย ๆ ที่มีบางหน่วยงาน (เช่นผู้เล่น, ศัตรู 1, ศัตรู 2) ที่มีองค์ประกอบการแปลง, การเคลื่อนไหว, สถานะ, ภาพเคลื่อนไหวและการแสดงผลฉันคิดว่าฉันควรจะมี: MovementSystem ที่จะทำการเคลื่อนย้ายส่วนประกอบการเคลื่อนไหวทั้งหมดและอัพเดทส่วนประกอบของรัฐ และ RenderSystem ที่อัพเดทองค์ประกอบภาพเคลื่อนไหว (องค์ประกอบภาพเคลื่อนไหวควรมีภาพเคลื่อนไหวหนึ่งภาพ (เช่นชุดของเฟรม / พื้นผิว) สำหรับแต่ละรัฐและอัปเดตหมายถึงการเลือกภาพเคลื่อนไหวที่สอดคล้องกับสถานะปัจจุบัน (เช่นการกระโดด, moving_left ฯลฯ ) และ อัปเดตดัชนีเฟรม) จากนั้น RenderSystem จะอัปเดตส่วนประกอบ Render ด้วยพื้นผิวที่สอดคล้องกับเฟรมปัจจุบันของ Animation ของแต่ละกิจการและแสดงทุกอย่างบนหน้าจอ ฉันเห็นการใช้งานบางอย่างเช่นกรอบงานของ Artemis แต่ฉันไม่รู้วิธีแก้ปัญหานี้: สมมติว่าเกมของฉันมีเอนทิตีต่อไปนี้ แต่ละเอนทิตีมีชุดสถานะและภาพเคลื่อนไหวหนึ่งรายการสำหรับแต่ละสถานะ: ผู้เล่น: …

10 animation  entity-system  component-based  state 

เพื่อให้ส่วนประกอบสามารถอัปเดตทุกเฟรม (และปล่อยให้ฟังก์ชันนี้ออกจากส่วนประกอบที่ไม่จำเป็นต้องใช้) ฉันมีแนวคิดที่จะสร้างคอมโพเนนต์ UpdateComponent ส่วนประกอบอื่น ๆ เช่นMovableComponent(ซึ่งมีความเร็ว) จะสืบทอดมาจากIUpdatableคลาสนามธรรม กองกำลังนี้MovableComponentจะใช้Update(gametime dt)วิธีการและอื่น ๆRegisterWithUpdater()ที่จะช่วยให้ชี้ไปUpdateComponent MovableComponentส่วนประกอบจำนวนมากสามารถทำสิ่งนี้ได้และUpdateComponentสามารถเรียกใช้Update(gametime dt)วิธีการทั้งหมดได้โดยไม่ต้องสนใจว่าเขาเป็นใครหรืออะไร คำถามของฉันคือ: สิ่งนี้ดูเหมือนจะเป็นสิ่งที่ปกติหรือเคยถูกใช้โดยทุกคนหรือไม่ ฉันไม่พบสิ่งใดในหัวข้อ ฉันจะรักษาคำสั่งซื้อส่วนประกอบเช่นฟิสิกส์แล้วเปลี่ยนตำแหน่งได้อย่างไร มันจำเป็นหรือไม่ มีวิธีอื่นใดในการประกันว่าส่วนประกอบที่ควรประมวลผลทุกเฟรมกำลังดำเนินการในความเป็นจริง แก้ไข ฉันคิดว่าฉันจะให้ความสำคัญกับรายการประเภทที่สามารถอัปเดตได้ จากนั้นองค์ประกอบทั้งหมดของประเภทนั้นสามารถอัปเดตได้มากกว่าการจัดการมันต่อเอนทิตี (ซึ่งเป็นเพียงดัชนีในระบบของฉัน) ยังคง คำถามของฉันยังคงใช้ได้สำหรับฉัน ฉันไม่รู้ว่านี่เป็นเหตุผล / ปกติหรือสิ่งที่คนอื่นมักจะทำ นอกจากนี้ผู้คนที่อินซอมเนียก็ยอดเยี่ยมมาก! / แก้ไข ตัวอย่างโค้ดก่อนหน้านี้: class IUpdatable { public: virtual void Update(float dt) = 0; protected: virtual void RegisterAsUpdatable() = 0; }; class …

10 c++  component-based  entity-system 

ฉันเพิ่งถามเกี่ยวกับวิธีแยกเอนทิตีออกจากพฤติกรรมและคำตอบหลักที่เชื่อมโยงกับบทความนี้: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ แนวคิดขั้นสุดยอดที่เขียนเกี่ยวกับที่นี่คือ: วัตถุประสงค์ในการรวมบริสุทธิ์ ฉันสงสัยว่าฉันจะทำอย่างไรเพื่อสร้างเอนทิตีเกมเป็นการรวมที่บริสุทธิ์โดยใช้ C # ฉันยังไม่เข้าใจแนวคิดเกี่ยวกับวิธีการทำงานนี้ (บางทีเอนทิตีเป็นอาร์เรย์ของวัตถุที่ใช้อินเทอร์เฟซหรือชนิดฐานที่แน่นอน?) ความคิดปัจจุบันของฉันยังคงเกี่ยวข้องกับการมีคลาสที่เป็นรูปธรรมสำหรับแต่ละประเภทเอนทิตีที่ใช้อินเทอร์เฟซที่เกี่ยวข้อง (IMoveable, ICollectable, ISpeakable และอื่น ๆ ) ฉันจะดำเนินการเกี่ยวกับการสร้างเอนทิตี้อย่างเดียวเป็นการรวมตัวโดยไม่ต้องมีรูปธรรมใด ๆ สำหรับเอนทิตีนั้น

10 c#  architecture  design-patterns  component-based  entity-system 

ฉันกำลังสร้างเกมที่ใช้วัตถุเกมตามองค์ประกอบและฉันมีเวลายากที่จะใช้วิธีการสำหรับแต่ละองค์ประกอบในการสื่อสารกับวัตถุเกม แทนที่จะอธิบายทุกอย่างพร้อมกันฉันจะอธิบายแต่ละส่วนของโค้ดตัวอย่างที่เกี่ยวข้อง: class GameObjectManager { public: //Updates all the game objects void update(Time dt); //Sends a message to all game objects void sendMessage(Message m); private: //Vector of all the game objects std::vector<GameObject> gameObjects; //vectors of the different types of components std::vector<InputComponent> input; std::vector<PhysicsComponent> ai; ... std::vector<RenderComponent> render; } การGameObjectManagerเก็บวัตถุเกมทั้งหมดและส่วนประกอบของพวกเขา นอกจากนี้ยังรับผิดชอบในการปรับปรุงวัตถุของเกม …

9 c++  entity-system  component-based