เอกสารประเภทใดสำหรับการออกแบบเกม? [ปิด]

คุณใช้การสนับสนุน / รูปแบบใดในการจัดเก็บและกระจายเอกสารการออกแบบเกมของคุณ? วิกิพีเดีย? ไฟล์ Doc หรือไม่ ไฟล์ในที่เก็บ? แชร์โฟลเดอร์หรือไม่ Google Doc

โปรดระบุข้อดีข้อเสียของแต่ละข้อ

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

คุ้มค่าอีกตัวเลือกหนึ่งที่กำลังมองหาที่จะใช้Dropbox วางเอกสาร Word ลงในนั้นและคุณจะมีสภาพแวดล้อมการทำงานร่วมกันพร้อมการควบคุมเวอร์ชันทันที

วิกิพีเดีย

ข้อดี:

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

จุดด้อย:

• บางครั้งเกินไปง่ายต่อการเปลี่ยนแปลง (* ดูด้านล่าง) และต้องมีวินัย
• หน้าจะไม่ซิงค์กันเมื่อมีการแก้ไขแบบแยกส่วน (มักจะไม่ใช่ 'การค้นหาทั่วโลกและแทนที่' ตัวอย่างเช่น)
• หน้าได้รับกำพร้าหรือ superceded และซ้ายเป็นที่วางทุ่นระเบิดที่มีศักยภาพสำหรับ coders ในภายหลัง ( "คุณหมายถึงอะไรเราไม่ได้ใช้สิ่งนั้นอีกแล้วยังอยู่ในวิกิการออกแบบ!" )
• ไวยากรณ์อาจเป็นเรื่องลึกลับเล็กน้อยเว้นแต่คุณจะได้รับแพ็คเกจที่ถูกต้อง
• ต้องจัดการโฮสต์สำหรับหรือยอมรับสิ่งที่พร้อมใช้งานออนไลน์ฟรี
• ไม่มีเส้นทางที่ชัดเจนผ่านเอกสาร - คุณจะอ่าน 'ทั้งหมด' ได้อย่างไร?
• ยากที่จะพิมพ์ คุณสามารถพิมพ์ทุกอย่างได้ด้วยคลิกเดียว? คุณสามารถพิมพ์ทุกสิ่งที่เกี่ยวข้องกับคุณลักษณะที่กำหนดเพื่อนำมาใช้ในการประชุมได้อย่างง่ายดายหรือไม่? คุณสามารถใส่คำอธิบายประกอบแบบดิจิทัลได้อย่างง่ายดายโดยไม่ต้องปิดบังเอกสารอ้างอิง?

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

ไฟล์ข้อความ

ในโครงการปัจจุบันของฉันฉันใช้ไฟล์ข้อความธรรมดาในโฟลเดอร์ "เอกสาร" ของโครงการที่เก็บในที่เก็บข้างรหัส

ข้อดี:

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

จุดด้อย:

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

ไม่ใช่สิ่งที่คุณต้องการใช้สำหรับการทำงานเป็นทีมทุกประเภท แต่พลังของไฟล์ข้อความใน repo เพื่อให้คุณได้รับสิทธิในการทำงานไม่ควรประเมินต่ำเกินไปสำหรับนักพัฒนาเดี่ยว ขณะนี้ฉันใช้เอกสารหนึ่งชุดเป็นภาพรวม / ตัววางแผนหลักที่มีการออกแบบทั่วไปเอกสารที่สองที่ทำหน้าที่เป็นรายการสิ่งที่ต้องทำในสิ่งที่เกมต้องการเอกสารที่สามเป็นตัวติดตามบั๊กที่หลวมและเอกสารประกอบเพื่อ อธิบายรายละเอียดเกี่ยวกับ "คุณสมบัติ x" ตามต้องการ

อย่าใช้รูปแบบเอกสาร / เครื่องมือแก้ไขที่ไม่มีผู้ใช้หลายคน (เช่น MS Word, Open Office Writer) มีเพียงคนเดียวเท่านั้นที่สามารถแก้ไขเอกสารและแม้กระทั่งกับการควบคุมแหล่งที่มามันง่ายเกินไปที่จะเริ่มทำงานกับรุ่นที่ล้าสมัยและโดยการบันทึกว่าคุณทำลายทุกสิ่งที่ผู้ใช้รายอื่นทำไว้ตั้งแต่ครั้งล่าสุดที่ผู้ใช้อัพเดตเวอร์ชันของเขา ของเอกสาร

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

ควรใช้ Wiki แต่เป็นสิ่งที่ผู้ใช้เข้าใจง่ายและเป็น WYSIWYG อย่างแท้จริง ฉันขอสาบานด้วยตัวเองโดยConfluenceซึ่งใช้ในสตูดิโอเกมขนาดใหญ่กว่าและมีราคาเพียง $ 10 สำหรับผู้ใช้มากถึง 10 คนและผู้ชมไม่ จำกัด

วิกิอื่น ๆ ส่วนใหญ่ (MediaWiki, TikiWiki ฯลฯ ) มีข้อเสียที่พวกเขามีช่วงการเรียนรู้ที่สูงชันหรือแม้แต่ในทางปฏิบัติโดยบุคลากรที่ไม่ใช่ช่างเทคนิค ไม่ใช่ว่าพวกเขาไม่สามารถเรียนรู้ได้ แต่พวกเขา (ถูกต้อง) ไม่ยอมรับการใช้ระบบเอกสารที่จำเป็นต้องให้คุณเขียนโค้ดเช่น HTML นี่คือสัตว์เลี้ยงที่ฉุนเฉียวของฉัน: Wikis ที่บอกว่าพวกเขาเป็น WYSIWYG แต่สิ่งที่พวกเขาทำคือใส่ไวยากรณ์ลงในข้อความที่คุณกำลังเขียน นั่นไม่ใช่ WYSIWYG!

คำแนะนำสำหรับการใช้วิกิคือใส่ทุกหัวเรื่องในหน้าแยกดังนั้นคุณสามารถตัดเอกสารออกเป็นหลายส่วนที่จัดการได้ Confluence นำเสนอคุณสมบัติที่คุณสามารถรวมหน้าย่อยทั้งหมดเหล่านั้นกลับไปไว้ในไซต์เดียวหรือเอกสารเดียวซึ่งสามารถส่งออกเป็น PDF ได้

ฉันคิดว่าOne Noteเป็นตัวเลือกที่ดี มันเป็นเหมือน Wiki แต่มีการแก้ไขข้อความมากมายที่รองรับ นอกจากนี้ยังมีลูกค้าเดสก์ทอปมาตรฐานที่มาพร้อมกับสำนักงานมีรุ่นตามเว็บกับOffice Liveห้องสวีท จริง ๆ แล้วฉันคิดว่าเวอร์ชันที่ทำงานบนเว็บซึ่งฟรีควรเพียงพอสำหรับความต้องการส่วนใหญ่และเมื่อรวมกับ Skydrive คุณมีระบบที่ดีพอที่จะทำงานร่วมกันในเอกสารสด

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