เอ็นจิ้นสำหรับเกมบนเว็บในที่สุดควรเริ่มเป็นบริการเว็บหรือไม่?


10

ฉันเพิ่งตัดสินใจเริ่มเขียนโปรแกรมสำหรับเกมไพ่ ฉันไม่ใช่ผู้เล่น "ไพ่" ที่ยิ่งใหญ่ แต่มีเพื่อนแนะนำฉันให้รู้จักกับเกมนี้ (มันเป็นการหมุนเกมเดนมาร์ก) และฉันตกหลุมรัก

ฉันต้องการพัฒนาเกมใน 3 ส่วน:

  1. เครื่องมือพื้นฐานจัดการไพ่ / สำรับ / เกม ฯลฯ
  2. ส่วนต่อประสานผู้ใช้ (ในรูปแบบของมือถือ / เดสก์ท็อปเว็บแอพ)
  3. ปัญญาประดิษฐ์ที่มีกลยุทธ์ / ปัญหาต่าง ๆ เป็นต้น

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

เครื่องยนต์เป็นตัวต่อชิ้นใหญ่มาก สิ่งที่ฉันอยากรู้คือ: คุณจะพัฒนา "API สาธารณะ" สำหรับเครื่องมือนี้อย่างไร?

ฉันคิดว่าเอ็นจิ้นอาจเป็นบริการบนเว็บที่ธรรมดามากซึ่งส่งคืนสถานะผ่านเคียวรีไปยัง RESTful API แต่ฉันกังวลว่าการพัฒนาเอ็นจิ้นเองเนื่องจากเว็บแอพอาจนำไปสู่การตัดสินใจเขียนโปรแกรมที่ไม่ดี (ตัวอย่างเช่นถ้าฉันเลือก MVC micro-framework API นี้จะไม่มีมุมมองจริง ๆ ... มันแค่คืนค่าวัตถุที่ถูกทำให้เป็นอนุกรมผ่าน JSON หรืออะไรบางอย่างที่ส่งผลกระทบนั้นมันไม่ดีที่จะใช้ MVC สำหรับบริการเช่นนั้น นี้? )

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

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

ขอบคุณ Robbie

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

ฉันไม่ได้มีบัญชีที่นี่เลยช่างเถอะ :)


เอ็นจินของคุณจำเป็นต้องจัดการกับเกมพร้อมกันกี่เกม
Darien

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

คำตอบ:


5

เส้นทางบริการเว็บน่าจะดีที่สุดและปรับขนาดได้มากที่สุด

ฉันยังเห็นว่าไม่มีปัญหาในการใช้กรอบ MVC เพื่อส่งคืน JSON (asp.net mvc ยอดเยี่ยมสำหรับเรื่องนี้) หากคอนโทรลเลอร์ของคุณส่งคืน JSON ในตอนแรกเท่านั้นคุณสามารถทดสอบหน่วยโดยไม่มีมุมมองใด ๆ เมื่อคุณพร้อมที่จะเพิ่มส่วนต่อประสานเกมของคุณคุณสามารถเพิ่มมุมมอง หาก html / css ธรรมดาหรือ flash / silverlight ของพวกมันไม่สำคัญเพราะอย่างที่คุณได้บอกไปแล้วว่าคุณได้สร้างเอ็นจิ้นพื้นฐานแล้ว

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

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


ฉันยังใหม่กับการพัฒนาเกมและฉันจะเป็นผู้พัฒนาเพียงคนเดียว แต่ไม่ต้องกังวลรหัสจะทำให้ฉันสนใจมากกว่าเกม;) ฉันคิดว่าจะใช้ Padrino ซึ่งเป็นกรอบ MVC น้ำหนักเบาที่เขียนใน Ruby สิ่งที่ดีคือมันมีแอพที่ติดตั้งได้ ฉันไม่คุ้นเคยกับพวกเขามากนัก แต่ฉันคิดว่าฉันสามารถ "ติดตั้ง" เอ็นจิ้นและแอป UI ได้แบบเคียงข้างกันในกระบวนการเดียวกัน แต่พวกเขายังคงแยกแอปด้วย [อาจ] ฐานข้อมูลของตนเองและทรัพยากรแบบคงที่ .
Robbie

ฟังดูเหมือนแผนการที่ดีสำหรับฉัน ถ้ารหัสจะทำให้คุณสนใจฉันพูดไปเลย
เนท

1

มุมมองเป็นเอนทิตีที่ลงทะเบียนกับโมเดลที่จะได้รับแจ้งเมื่อมีการเปลี่ยนแปลงเกิดขึ้น

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

ให้บอกว่าคุณมีเกมที่เล่นอยู่

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/

คุณสามารถใช้ URL

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/playCard?id=3&place=stack 

เพื่อปรับเปลี่ยนรูปแบบและ

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify 

เพื่อรอการแจ้งเตือน

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

ลูกค้าสามารถทำการร้องขอ ajax ที่ยาวนานไปยัง / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / แจ้งเตือนและลงทะเบียนการเรียกกลับการแจ้งเตือนที่จะปรับปรุงมุมมองและโพสต์คำขอการแจ้งเตือนครั้งต่อไปอีกครั้ง

หากเกม / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / แจ้งการหมดเวลาบนไคลเอนต์การร้องขอใหม่จะดำเนินการถ้าหมดเวลาบนเซิร์ฟเวอร์ทรัพยากรที่ปันส่วนจะถูกปล่อยให้เป็นอิสระ

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

หากคุณกำลังมองหาเทคโนโลยีคุณสามารถพิจารณาสร้างเอ็นจิ้นเกมของคุณบนเซิร์ฟเวอร์ Couchdb Couchdb เป็น RMS DBMS ที่ไม่เกี่ยวข้องซึ่งใช้ HTTP เป็นโปรโตคอลและ JSON เป็นรูปแบบเอกสาร นอกจากนี้ยังสามารถใส่ PUT และ GET ไฟล์ไบนารีหรือ HTML เป็นไฟล์แนบดังนั้นจึงเป็นไปได้ที่จะเขียน webApp แบบเต็มโดยใช้เฉพาะ DBMS (couchApp)

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


2
การวางบัตรควรเป็น POST (หรือ PUT หากเป็น idempotent แต่ไม่น่าเป็นไปได้และไม่ได้รับการสนับสนุนเป็นอย่างดี) ไม่ใช่ URL สำหรับ GET

@Joe Wreschnig คุณถูกต้อง URL นั้นมีวัตถุประสงค์เพื่อเป็นตัวอย่างเท่านั้นและฉันไม่ได้กล่าวถึงวิธีการที่ควรใช้
FxIII
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.