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

นอกจากนี้ด้วย F # ในฐานะสมาชิกใหม่ของตระกูล. NET มันสามารถใช้งานโดยตรงกับ XNA ตัวอย่างเช่นซึ่งลดระดับของเกณฑ์ลงเล็กน้อยเมื่อเทียบกับ LISP, Haskell, Erlang ฯลฯ

หากใครมีประสบการณ์ในการเขียนเกมด้วยโค้ดที่ใช้งานได้สิ่งใดที่เป็นผลบวกและเชิงลบ มันเหมาะกับอะไรไม่ได้

แก้ไข: พบว่ายากที่จะตัดสินใจว่ามีคำตอบที่ดีเพียงข้อเดียวดังนั้นจึงน่าจะเหมาะกว่ากับโพสต์ของวิกิชุมชน

ฉันกำลังเล่นเกมใน Haskell ฉันไม่สามารถพูดสำหรับการเขียนโปรแกรมใช้งานทั่วไป แต่สำหรับ Haskell โดยเฉพาะ:

ดี

นี่คือสิ่งที่ยอดเยี่ยมที่ทำให้ Haskell โดดเด่น

• ความบริสุทธิ์หมายถึงการให้เหตุผลเกี่ยวกับรหัสของคุณนั้นง่ายกว่ามาก คุณไม่ต้องกังวลเกี่ยวกับค่า "ปัจจุบัน" ของตัวแปรหรือว่าการใช้ฟังก์ชั่นที่กำหนดจะขัดแย้งกับสถานะทั่วโลกของคุณในบางวิธี นอกจากนี้ยังหมายความว่าการทำงานแบบคู่ขนานและการทำงานพร้อมกันนั้นง่ายกว่ามากในการทำงานกับ (และในหลายกรณี สิ่งเหล่านี้อาจเป็นสวรรค์สำหรับนักพัฒนาเกม
• Haskell ทำให้มันง่ายมากที่จะเขียนในระดับสูงมากโดยใช้ abstractions ของการสร้างของคุณเอง บ่อยครั้งที่การเขียนโค้ดทั่วไปง่ายกว่าโค้ดเฉพาะใน Haskell และประโยชน์ของการแสดงออกนี้ในเวลาน้อยกว่าการพัฒนาและการเข้าใจโค้ดง่ายขึ้น มันเป็นเรื่องจริงใน Haskell มากกว่าในภาษาอื่น ๆ ที่ฉันรู้ว่าการใช้อินเทอร์เฟซเหมือนกับการใช้ภาษาใหม่ทั้งหมด (ในขณะที่ยังคงรักษาประโยชน์ของระบบนิเวศ Haskell ที่เหลืออยู่) สิ่งที่ภาษาส่วนใหญ่เรียกคุณสมบัติภาษา Haskell เรียกห้องสมุดและมันไม่รู้สึกว่าถูกบังคับ หากคุณเคยคิดที่จะให้เหตุผลเกี่ยวกับเกมของคุณใน psuedocode คุณอาจจะเขียนอินเทอร์เฟซที่เรียบง่ายและทำให้มันเป็นรหัสจริงและมันก็คุ้มค่าที่จะทำเช่นนั้น
• สิ่งนี้อาจขัดแย้งกับคำตอบอื่น ๆ แต่ Haskell นั้นดีกว่าในการจัดการโค้ดที่จำเป็นกว่าภาษาอื่น ๆ ที่ฉันรู้จัก ข้อ จำกัด ของความบริสุทธิ์หมายความว่า Haskell มีการแยกระหว่างแนวคิดของ "การประเมิน" (การลดนิพจน์) และ "การกระทำ" (การแสดงผลข้างเคียง) คุณสามารถควบคุมเวลาและวิธีการทำงานของผลข้างเคียงได้อย่างง่ายดายด้วยภาษาที่เรียกว่า "ความจำเป็น" แม้จะมีสิ่งที่ฉันพูดเกี่ยวกับความบริสุทธิ์ก่อนหน้านี้การผูก C บางอย่างยังคงมีความจำเป็นมาก (OpenGL ฉันกำลังมองคุณอยู่) ดังนั้นการควบคุมอย่างละเอียดของโค้ดที่จำเป็นนี้ก็ยินดีต้อนรับ แม้แต่โปรแกรมเมอร์ซีที่มีประสบการณ์มากที่สุดก็มักจะชื่นชอบเมื่อพวกมันคุ้นเคยกันแล้ว
• GHC สร้างไบนารีที่ค่อนข้างเร็ว พวกเขาจะไม่เป็นอย่างที่ไบนารีที่สร้างขึ้นจากคอมไพเลอร์ C เหมือนกัน แต่อยู่ในลำดับความสำคัญและมีความห่างไกลเร็วกว่าสิ่งที่คุณจะประสบความสำเร็จกับแปลภาษา แม้ว่าคุณจะไม่สามารถเขียนเกมของคุณในภาษาระดับสูงอื่น ๆ เช่น Python เพราะมันจะช้าเกินไป แต่ก็มีโอกาสดีที่คุณจะทำได้ใน Haskell
• แม้จะมีห้องสมุดที่เกี่ยวข้องกับเกมจำนวนมากใน Haskell ดังที่ได้กล่าวไว้ในหัวข้อ "แย่" ด้านล่างส่วนต่อประสานฟังก์ชั่นต่างประเทศของ Haskell นั้นง่ายที่สุดที่ฉันเคยใช้ คุณสามารถผูกกับ C โดยเขียนเกือบเฉพาะใน Haskell

เลว

สิ่งเหล่านี้เป็นสิ่งที่ไม่ดี แต่สามารถแก้ไขได้โดยไม่ต้องใช้ความพยายามมากเกินไป

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

น่าเกลียด

นี่คือสิ่งที่จะต้องใช้ความพยายามอย่างมากที่จะเอาชนะ

• หากคุณกำลังเขียนเกมที่เน้นทรัพยากรนักเก็บขยะของ GHC อาจกัดคุณอย่างหนัก มันเป็น GC แบบ generational และหยุดโลกดังนั้นทุก ๆ ครั้งในขณะที่คุณอาจวางเฟรมไม่กี่ สำหรับบางเกมมันก็โอเค แต่สำหรับคนอื่นมันเป็นปัญหาใหญ่ ฉันและผู้พัฒนาเกมอื่น ๆ ที่ใช้ Haskell ต้องการเห็น GC แบบเรียลไทม์ที่ใช้กับ GHC แต่ยังไม่มีการใช้ความพยายามเพื่อความรู้ของฉัน ขณะนี้ฉันไม่กังวลเกี่ยวกับการทำงานนี้ (และยังไม่เคยเห็นเฟรมที่หล่นลงมาจากมัน) แต่อย่างน้อยหนึ่งทีมอื่นได้หันไปใช้การวนรอบการเรนเดอร์หลักใน C

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

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

เรากำลังใช้ FRP คล้ายกับ Yampa และมีเส้นโค้งการเรียนรู้ที่เกี่ยวข้องกับมัน แต่เมื่อมันจบลงด้วยประสบการณ์จะเป็นบวกมาก ห้องสมุดไม่ได้เป็นปัญหาสำหรับเรา - ทุกสิ่งที่เราต้องการมีให้ ความล่าช้าในการรวบรวมขยะเป็นปัญหาเฉพาะเนื่องจากเป็นแพลตฟอร์มแบบฝัง เราใช้ C ++ เพื่อจัดการภาพเคลื่อนไหว ประสิทธิภาพการทำงานยังเป็นปัญหาด้วยสิ่งนี้เป็นแพลตฟอร์มฝังตัว (= โปรเซสเซอร์ช้า) เราได้ทำ C แล้วและเราก็กำลังมองหาเทคโนโลยีใหม่ของ Haskell เช่นเร่งความเร็ว อนิเมเตอร์ C ++ นั้นเป็นการตัดสินใจออกแบบก่อนหน้านี้และสถานที่ที่โค้ดช้าเกินไปนั้นเป็นเพียงพื้นที่เล็ก ๆ เท่านั้น ในระยะยาวเราต้องการแปล C ทั้งหมดของเราเป็น Haskell

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

เดฟกล่าวถึงบางจุดที่ยอดเยี่ยมแม้ว่าฉันจะต้องชี้ให้เห็นว่า Haskell ได้แก้ไขปัญหาของเขาทั้งสอง ไร้สัญชาติสามารถข้ามได้โดยใช้ monad รัฐ(แก้ไข: ไม่ได้จริงๆ - ดูรายละเอียดด้านล่าง)และลำดับสามารถจัดการได้โดยใช้ monad IO (แก้ไข: หรือ monad อื่น ๆ สำหรับเรื่องที่ ... )

ความท้าทายที่คุณจะได้รับ (และสิ่งที่ฉันได้พยายามเรียนรู้ทั้งการเขียนโปรแกรมเกมและ Haskell) นั้นมีมากกว่าในสายเหล่านี้ (นี่คือเฉพาะ Haskell เนื่องจากฉันยังไม่ได้ลึกลงไปกับภาษา FP อื่น ๆ เลย)

• FP Learning curve: FP ต้องการการเปลี่ยนแปลงที่สมบูรณ์ของความคิดจากการเขียนโปรแกรมซ้ำ การเรียนรู้ที่จะคิดในแง่ของแผนที่และการพับมากกว่าการวนซ้ำนั้นจำเป็นต้องมีการฝึกจิตหากคุณไม่คุ้นเคย
• โค้งการเรียนรู้ทางคณิตศาสตร์: Haskell มีทั้งความสุขและการสาปแช่งโดยความซับซ้อนทางคณิตศาสตร์ของนักออกแบบเพราะหลังจากที่คุณเรียนรู้พื้นฐานของ FP แล้วคุณจะติดอยู่กับ Monads, morphisms, ลูกศรและโฮสต์อื่น ๆ ในและของตัวเองเป็นนามธรรมมาก
• Monads:ลูกสุนัขเหล่านี้ไม่ได้ยากเป็นพิเศษที่จะปิดล้อมใจของคุณโดยเฉพาะถ้าคุณยอมรับคำสั่งของ Eric Raymondว่าพวกเขาเป็น "แฮ็คที่จะเปลี่ยนการจัดองค์ประกอบของฟังก์ชั่นเป็นวิธีบังคับให้เรียงลำดับการเรียกใช้ฟังก์ชัน" โชคไม่ดี (แม้ว่านี่จะดีขึ้นเมื่อ Haskell ได้รับความนิยม) คำอธิบายมากมายของ monads ก็มุ่งไปที่หัวของโปรแกรมเมอร์ส่วนใหญ่ ("พวกเขากำลัง monoids ในหมวดหมู่ของ endofunctors!") หรือในการเปรียบเทียบที่ไม่ช่วยเหลือ (เช่น ตัวอย่างที่แม่นยำของ Brent Yorgey“ monads เปรียบเสมือน burritos !” คุณคิดว่าเขาล้อเล่นใช่ไหมไม่มีใครเคยคิดแบบนี้ในการสอนแบบคร่าวๆลองคิดดูอีกครั้ง )
• ระบบนิเวศ:หากคุณสามารถก้าวข้ามอุปสรรคอื่น ๆ ในท้องถนนได้คุณจะได้สัมผัสกับความเป็นจริงในชีวิตประจำวันของการทำงานกับภาษาที่ยังคงทดลองอยู่เป็นส่วนใหญ่ พระเจ้าช่วยคุณเมื่อคุณมาที่นี่ นี่คือสิ่งที่ผมเริ่มอย่างจริงจัง jonesing สำหรับ Scala หรือ F # หรือบางภาษาอื่น ๆ ที่มีอยู่อย่างน้อยบางรับประกันการทำงานร่วมกันกับห้องสมุดอื่น ๆ กาลครั้งหนึ่งฉันได้ Haskell เพื่อเชื่อมโยงและโหลดไลบรารี OpenGL ใน Windows นั่นทำให้ฉันรู้สึกดีทีเดียว จากนั้นการผูกของ OpenGL จะได้รับการเผยแพร่อีกครั้งและทำลายทุกสิ่งที่ฉันได้ทำไป นั่นคือชีวิตใน Haskell-land สุจริตอาจเป็นความเจ็บปวด คุณต้องการ wrapper สำหรับเครื่องยนต์ Bullet หรือไม่? มันอยู่ใน Hackage - เป็นabandonwareตั้งแต่เดือนพฤศจิกายนปีที่แล้ว คุณชอบ Ogre3d? แฮกเกอร์มีการเชื่อมโยงกับไลบรารีบางส่วนเท่านั้น บรรทัดล่างคือถ้าคุณยึดติดกับภาษานอกเส้นทางตีสำหรับการพัฒนาเกมคุณจะใช้เวลามากขึ้นในการทำงานเกี่ยวกับการประปาพื้นฐานกว่าที่คุณจะถ้าคุณเพียงแค่ติดตามฝูงและติดกับ C ++

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

Antti Salonen มีบล็อกที่น่าสนใจโดยมีรายละเอียดเรื่องเกี่ยวกับการเขียนโปรแกรมเกม Haskell มันคุ้มค่าที่จะอ่าน

แก้ไข (หนึ่งปีต่อมา):ตอนนี้ฉันได้ศึกษารัฐ monad เพิ่มเติมฉันรู้ว่ามันไม่ใช่ทางออกที่ดีโดยเฉพาะอย่างยิ่งสำหรับรัฐที่มีจุดประสงค์เพื่อคงอยู่ข้างนอกหน้าที่เฉพาะ โซลูชั่นที่แท้จริงสำหรับการไร้สัญชาติพบได้ใน Haskell ใน IOVar, ST, MVar (สำหรับความปลอดภัยของเธรด) หรือผ่านทาง Yampa ซึ่งใช้ Arrows และ FRP เพื่อจัดการสถานะภายในที่ยังไม่ถูกซ่อนจากนักพัฒนา (รายการนี้เรียงตามลำดับความยากลำบากแม้ว่าสามรายการแรกนั้นไม่ยากโดยเฉพาะเมื่อคุณเข้าใจพระ)

Caml วัตถุประสงค์!

การใช้ภาษาที่ใช้งานได้นั้นมีประโยชน์อย่างมากในการพัฒนาซอฟต์แวร์เกือบทุกประเภทส่วนใหญ่เป็นเพราะพวกเขาลดเวลาในการพัฒนาลงอย่างมาก ฉันเห็นศักยภาพที่ยิ่งใหญ่สำหรับการเขียนแบ็กเอนด์เซิร์ฟเวอร์ไปยังเกมหรือ AI และเลเยอร์ตรรกะบนไคลเอนต์ในภาษาที่ใช้งานได้ และอย่างที่ทุกคนรู้ LISP ถูกใช้เพื่อการสร้างสคริปต์ NPC

ถ้าฉันพยายามเขียนส่วนหน้าของเกมในภาษาที่ใช้งานได้ฉันจะไปหาObjective Camlซึ่งเป็นภาษาไฮบริดแน่นอน มันเป็นลูกหลานของ ML และอนุญาตให้ผสมผสานรูปแบบการวนซ้ำและการทำงานมีระบบเป้าหมายกับวัตถุที่เป็นรัฐ (Caml เป็นภาษาที่ F # เป็นแบบอย่าง)

การผูก OpenGL ดูเหมือนจะทำงานได้อย่างไร้ที่ติและผู้คนต่างทำเกมใน OCaml มาเป็นเวลานาน ภาษาสามารถรวบรวมและอาจเร็วมาก (มันมีชื่อเสียงมากกว่า C ในบางมาตรฐานเมื่อนานมาแล้วไม่ใช่สิ่งที่ยืนอยู่ตอนนี้)

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

ไม่ใช่คำตอบสำหรับทุกสิ่ง แต่ฉันรู้สึกเหมือนการสนทนาของการเขียนโปรแกรมเกมในภาษาที่ใช้งานได้ไม่สมบูรณ์โดยไม่ต้องพูดถึง Functional Reactive Programming (FRP) - http://www.haskell.org/frp/ - และการใช้งานที่พบบ่อยที่สุด ( ผมคิดว่า) YAMPA? - http://www.haskell.org/yampa/

สำหรับประโยชน์ให้ตรวจสอบ Clean Game Library (http://cleangl.sourceforge.net/) และตรวจสอบเกม platformer เมื่อคุณเข้าใจไวยากรณ์แล้ว (ฉันขอแนะนำให้คุณลองทำ) คุณจะเห็นความสง่างามของโครงสร้างและความใกล้เคียงของแหล่งแผนที่กับแนวคิดที่พวกเขาแสดงออกมา ในฐานะที่เป็นโบนัสเพิ่มเติมความเป็นนามธรรมของรัฐและความจำเป็นที่จะต้องส่งผ่านรัฐอย่างชัดเจนทำให้โค้ดของคุณเป็นมิตรกับมัลติคอร์มากขึ้น

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

จากมุมมองของฉันความท้าทายที่ยิ่งใหญ่ที่สุดจะเป็น:

• การไร้สัญชาติของภาษาที่ใช้งานได้: แนวคิดในเกมคือแต่ละเอนทิตีมีสถานะและสถานะนี้กำลังถูกแก้ไขจากเฟรมหนึ่งไปอีกเฟรมหนึ่ง มีกลไกในการเลียนแบบพฤติกรรมนั้นในบางภาษา (ตัวอย่างเช่นฟังก์ชั่นที่มี "!" ในรูปแบบ plt) แต่มันรู้สึกแปลก ๆ
• ลำดับของการดำเนินการ : ในเกมบางส่วนของรหัสขึ้นอยู่กับส่วนของรหัสอื่น ๆ ที่จะเสร็จสิ้นก่อนที่จะดำเนินการ โดยทั่วไปภาษาที่ใช้งานได้จะไม่รับประกันใด ๆ เกี่ยวกับลำดับการเรียกใช้ของอาร์กิวเมนต์ของฟังก์ชัน มีวิธีในการเลียนแบบพฤติกรรมนี้ (ตัวอย่างเช่น " (begin..." ในรูปแบบ plt)

อย่าลังเลที่จะขยายรายการนี้ (และอาจเพิ่มคะแนนบวก ^^)

คุณสามารถเขียนรหัสของคุณใน C / C ++ และใช้ภาษาที่ฝังเช่น Embedded Common LISP สำหรับการเขียนสคริปต์ของคุณ แม้ว่าการทำให้สิ่งเหล่านี้รวบรวมบนแพลตฟอร์มอื่นอาจเป็นเรื่องยาก คุณอาจดู Lisp In Small Pieces เพื่อเรียนรู้วิธีการเขียนภาษาสคริปต์ของคุณเอง ไม่ใช่เรื่องยากจริง ๆ ถ้าคุณมีเวลา

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

ฉันไม่ได้เรียนรู้ F # แต่มันอาจจะง่ายกว่าที่จะทำงานด้วย

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