ขยับให้เร็ว และยอมเลิกให้เป็น
(engineersneedart.com)- ระหว่างกระบวนการกู้คืนเกม Mac ที่ทำไม่เสร็จราวปี 1991 พบว่ามีการทำซ้ำรูปแบบการพัฒนาแบบ ลงมือทำไอเดียอย่างรวดเร็ว แล้วตัดทิ้งอย่างเด็ดขาดหากไม่สนุกหรือไม่น่าจะทำให้เสร็จได้
- ในรายการตอนนั้นมี 27 ไตเติล แต่ผลงานที่เผยแพร่จริงมี 5 ชิ้น ส่วนที่เหลือใกล้เคียงกับต้นแบบแบบทำเร็วที่สร้างขึ้นตลอดราว 18 เดือน
- ด้วย เชลล์ร่วม สำหรับเกมที่ใช้สไปรต์ ทำให้ต้นทุนของการทดลองใหม่ต่ำลง และฟีเจอร์อย่างเสียง ไฮสกอร์ และการบันทึกเกมก็ถูกเลื่อนไปทำทีหลังเมื่อยืนยันแล้วว่าเกมนั้นมีอนาคต
- การทดลองอย่าง kite-fighting, K-10 และ Thief of Baghdad ถูกตัดสินว่าจะทำต่อหรือไม่จากความสนุกของการบังคับเล่น เป้าหมายของเกม และ ปริมาณงานด้านอาร์ตและการพัฒนา ที่นักพัฒนาเดี่ยวรับไหว
- โปรเจ็กต์ที่ถูกทิ้งก็ไม่ได้สูญเปล่า เพราะโค้ดอย่าง Fisher–Yates shuffle, การสลับความลึกสีของหน้าจอ, การตรวจจับการชน, และตาราง lookup ของตรีโกณมิติ ถูกนำกลับไปใช้ในโปรเจ็กต์ถัดมา
การกู้คืนโปรเจ็กต์เกม Mac เก่า
- ระหว่างกู้คืนไฟล์เกมที่เขียนไว้เมื่อราว 35 ปีก่อนจากฮาร์ดไดรฟ์เก่า สิ่งที่น่าสนใจกว่าเกมที่ออกวางจำหน่ายกลับเป็น งานทดลองที่แทบไม่เคยเสร็จสมบูรณ์
- เกม shareware ที่เคยเผยแพร่ในอดีตถูกรวมเป็น disk image และอัปโหลดไว้ที่ Soft Dorothy Software — Early Shareware Projects
- disk image เหล่านี้อยู่ในรูปแบบที่สามารถลากไปใช้กับอีมูเลเตอร์ Mac แบบ 68K หรือ PPC เช่น Basilisk II, Sheepshaver และ MiniVMac ได้
- ซอร์สและเครื่องมือ build ที่เกี่ยวข้องกับ Glider 4.0 ซึ่ง Casady & Greene เป็นผู้จัดพิมพ์ในปี 1991 อยู่ใน disk image ของ Casady & Greene Projects
- AirBikes หากทำเสร็จคงจะเป็นเกมแข่งรถล้ำยุค แต่ในความเป็นจริงมันถูกทิ้งไว้ในสภาพไม่สมบูรณ์
จาก 27 ไตเติล มีออกจริงแค่ 5
- เอกสารที่ทำขึ้นราวปี 1991 ได้สรุป creator code, ชื่อ และสถานะของแต่ละเกมไว้
- creator code มีลักษณะใกล้เคียงกับ bundle identifier แบบหยาบมากของยุค Macintosh ก่อน OS X และต้องไม่ซ้ำกันในแต่ละแอปพลิเคชัน
- ในรายการมีทั้งหมด 27 ไตเติล และในนั้นมีเพียง 5 ชิ้นที่ออกเผยแพร่
- ที่เหลือส่วนใหญ่เป็นต้นแบบแบบทำเร็ว
- โปรเจ็กต์เหล่านี้ถูกสร้างขึ้นตลอดช่วงเวลาประมาณ 18 เดือน
- ณ เวลาที่เขียนรายการนั้น มีบันทึกไว้ว่ากำลังทำพร้อมกันอยู่ 3 ไตเติล
- ยังมีการเผยแพร่ยูทิลิตีชื่อ UnMask ด้วย แต่เพราะเป็นเครื่องมือที่ใช้เวลาทำราว 10 นาที จึงถือว่าไม่ค่อยอยู่ในขอบเขตที่ควรวิเคราะห์
วิธีทำต้นแบบอย่างรวดเร็ว
- ผู้เขียนเขียนโค้ดจนดึกแทบทุกคืนเพื่อสร้างการทดลองจำนวนมาก และใช้ เชลล์ร่วม สำหรับเกมที่อิงสไปรต์เพื่อลดต้นทุนในการทำต้นแบบใหม่
- ในการสเก็ตช์เกมใหม่ เวลาส่วนใหญ่หมดไปกับการสร้างสไปรต์และงานอาร์ตด้วย MacPaint ส่วนโค้ดที่ต้องเพิ่มมักเป็นเรื่องวิธีรับอินพุตเฉพาะ กลไกของเกม และฟิสิกส์บางส่วน
- ฟีเจอร์อย่างเสียง ไฮสกอร์ และเซฟเกมจะไม่ทำตั้งแต่ต้น แต่เลื่อนไปไว้ทีหลังเฉพาะกับ เกมที่คุ้มจะไปต่อ
- แก่นสำคัญคือการตรวจให้เร็วที่สุดว่าไอเดียนั้นสนุกจริงหรือไม่
- ไอเดียที่ดูสนุกบนกระดาษอาจไม่สนุกเมื่อเล่นจริง
- แค่ทำระบบบังคับและฟิสิกส์ให้เล่นได้ภายในไม่กี่วัน ก็พอจะรู้แล้วว่าควรไปต่อหรือไม่
เกณฑ์ในการเช็กความสนุกอย่างรวดเร็ว
- เกม kite-fighting สามารถทำระบบบังคับการบินและฟิสิกส์เพื่อทดสอบได้ภายในไม่กี่วัน
- ถ้าการบังคับว่าวยากเกินไป คนที่จะสนุกกับเกมก็น่าจะมีน้อย
- แต่ถ้าแค่การชักว่าวโดยไม่มีองค์ประกอบการต่อสู้ก็ยังสนุกอยู่ ก็แปลว่ามันมีแวว
- เกมอาร์เคด Joust แม้ก่อนศัตรูจะโผล่มา ตัวการควบคุมการบินด้วยปุ่ม flap ก็สนุกในตัวเองอยู่แล้ว
- ทั้งจังหวะที่ต้องกระพือปีกช้า ๆ และจังหวะที่ต้องกดรัวเพื่อพุ่งขึ้น ล้วนสร้างความรู้สึกในการเล่น
- แม้แต่เกมเครื่องบินกระดาษที่ได้แรงยกจากช่องลมพื้นในบ้านที่รก ก็ยังพอสนุกได้ตั้งแต่ก่อนจะเข้าใจว่าต้องผ่านห้องต่าง ๆ และหลบสิ่งอย่างเครื่องปิ้งขนมปัง
- K-10 เป็นเกมแข่งรถอีกเกมที่ตั้งชื่อตาม Kansas highway 10 แต่ก็ไปไม่พ้นแค่ ขั้นต้นแบบ
การตัดสินใจว่าจะหยุดหรือไปต่อ
- บางเกมพัฒนาไปถึงช่วงต้นได้แล้ว แต่หลังจากนั้นกลับไม่ชัดเจนว่าควรทำอะไรต่อ
- ในรายการมีเกมบางเกมถูกเขียนไว้อย่างตรงไปตรงมาว่า
<no point>
- ในรายการมีเกมบางเกมถูกเขียนไว้อย่างตรงไปตรงมาว่า
- เกมแพลตฟอร์ม Thief of Baghdad ช่วงที่กระโดดโลดแล่นบนพรมวิเศษนั้นสนุก แต่หลังจากนั้นเป้าหมายของเกมกลับไม่ชัดเจน
- สำหรับการพัฒนาแบบคนเดียว ต่อให้เกมดูมีศักยภาพ ก็ยากจะเดินหน้าต่อหากต้องใช้เวลามากกว่าหนึ่งปีกว่าจะเสร็จ
- เกมผจญภัยแบบสไปรต์สไตล์ Dungeons and Dragons นั้นน่าสนใจ แต่ปริมาณงานที่ต้องทำ ทั้งแอ็กชันของอาวุธแต่ละแบบ มอนสเตอร์ เอฟเฟกต์เวท และระบบต่อสู้ ล้วนมากเกินไป
- พอทำท่าทางแทงและปัดป้องด้วยดาบเสร็จ ก็ต้องต่อยอดไปยังอาวุธและอุปกรณ์แบบอื่นอย่างกระบอง คันธนู หรือผ้าคลุม ทำให้งานอาร์ตบานปลาย
หยิบกลับมาทำใหม่ และรีไซเคิลโค้ดด้วย
- เกมที่พับเก็บไว้ไม่ใช่โปรเจ็กต์ที่ตายสนิท เพราะหากยังหาไฟล์ซอร์ส รีซอร์ส และไฟล์โปรเจ็กต์เจอ ก็สามารถหยิบกลับมาทำใหม่ได้
- Thief of Baghdad ถูกเริ่มใหม่ในเวอร์ชันสีราว 18 เดือนให้หลัง ได้ชื่อใหม่ว่า Scheherazade และเริ่มมีจุดมุ่งหมายมากขึ้นบ้าง
- แต่แม้ในความพยายามครั้งที่สอง มันก็ยังไม่เกิดเสน่ห์ที่อธิบายยากมากพอ สุดท้ายจึงถูกหยุดอีกครั้ง
- โค้ดจากโปรเจ็กต์ที่พักไว้สามารถนำไปใช้ซ้ำในงานถัดมาได้
- Fisher–Yates shuffle algorithm
- โค้ดสำหรับเปลี่ยนความลึกสีของจอภาพบน Mac รุ่นแรก ๆ
- โค้ดชนกันแบบ polygon-point
- ตาราง sine lookup สำหรับตรีโกณมิติความเร็วสูง
- รูทีน dot-product และ cross-product
- งานต้นแบบเหล่านี้จึงไม่ถูกมองว่าเป็นความสูญเปล่า
แนวทางแบบวนซ้ำนี้ยังต่อเนื่องที่ Apple
- เมื่อเข้าสู่ช่วงทศวรรษ 1990 ยุคของ indie Mac game developer ดูเหมือนกำลังสิ้นสุดลง และเมื่อได้รับข้อเสนอให้ย้ายไป California เพื่อทำงานที่ Apple ผู้เขียนก็ตอบรับ
- หลังเข้า Apple ผู้เขียนเข้าใจว่าไม่สามารถทำโปรเจ็กต์นอกงานที่ไม่ใช่ของ Apple ในเวลาว่างได้
- พูดให้เคร่งครัดคือ หากจะเขียนโค้ดนอกงาน ต้องมีการอนุมัติเป็นลายลักษณ์อักษรจากผู้จัดการ
- แม้ Apple จะไม่ได้ทำธุรกิจเกม จึงอาจขออนุมัติได้ แต่ความกังวลว่าขอแล้วอาจถูกปฏิเสธก็ยังเป็นภาระใจ
- แม้ในโปรเจ็กต์งานที่ไม่ใช่เกม วิธีทำต้นแบบเร็วก็ยังดำเนินต่อไป
- เพื่อนร่วมงานคนอื่นมักวนออกแบบบนไวต์บอร์ดและวางแผนอย่างรอบคอบก่อนเขียนโค้ด
- ส่วนผู้เขียนชอบวิธีที่กระโดดลงมือก่อน คอมไพล์ไปพร้อมกับวนปรับแก้
- วิธีรวบรวมโค้ดอย่างรวดเร็วเพื่อหาคอขวดให้เจอไว และถ้าจำเป็นก็ค่อยเริ่มโปรเจ็กต์ใหม่แทบทั้งหมด ถูกใช้ซ้ำแล้วซ้ำอีก
- แม้จะเริ่มโปรเจ็กต์ใหม่อยู่ราวสามครั้ง แต่สุดท้ายก็มักไปถึงสภาพที่ดีพอในช่วงเวลาใกล้เคียงกับตอนที่เพื่อนร่วมงานสายออกแบบละเอียดเริ่มทำให้โค้ดรันได้
- การรีวิชันโค้ดครั้งสุดท้ายมักเป็นการทำให้เรียบง่ายลง และการปฏิบัติต่อโค้ดตั้งแต่แรกให้ พร้อมถูกเปลี่ยนครั้งใหญ่ได้เสมอ ก็ช่วยสร้างสัญชาตญาณว่าโค้ดควรถูกจัดระเบียบอย่างไร
- ยังมีประสบการณ์ที่สามารถตอบเพื่อนร่วมงานซึ่งแนะนำให้ใช้ Bloom Filter ได้ว่าได้ลองแล้วและเลิกใช้ไป เพราะข้อมูลจริงมีขนาดเล็กเกินกว่าจะได้ประโยชน์ด้านประสิทธิภาพอย่างมีนัยสำคัญ มีแต่เพิ่มความซับซ้อนให้ codebase
Always Be Iterating
- เมื่อใกล้เกษียณ ผู้เขียนรู้สึกว่าตนเป็นทั้งพนักงานผู้มีส่วนร่วมและเป็นเพื่อนร่วมงานคนหนึ่งที่ Apple
- ต่างจากสมัยที่นั่งเขียนโค้ดคนเดียวทั้งคืน สิ่งที่ดีที่สุดของการทำงานที่ Apple คือเหล่าวิศวกรที่ได้ร่วมงานด้วย
- ในบรรดาคนที่ทำงานด้วย มีโปรแกรมเมอร์ที่เก่งกว่าผู้เขียนไปอีกหลายระดับ
- ผู้เขียนรู้สึกว่าตัวเองเป็นหนึ่งในโปรแกรมเมอร์ที่ทำงานได้เร็วที่สุด และถ้าต้องมีต้นแบบสำหรับเดโมในที่ประชุมประจำสัปดาห์ ก็เป็นคนประเภทที่ทำออกมาได้ถึงสองเวอร์ชัน
- วลีที่ผู้เขียนพูดซ้ำกับลูกสาวคือ A.B.I.
- “Always”
- “Be”
- “Iterating”
- หรือก็คือ “Always Be Iterating”
- โปรเจ็กต์ ซอร์ส และเครื่องมือของเกมที่ไม่เคยออกวางจำหน่ายเหล่านี้ ถูกจัดรวมเป็น disk image และเผยแพร่บน GitHub
- ยังมีแผนสำหรับ Volume 3 เช่นกัน แต่เพราะยังมีงานจัดแต่ละโปรเจ็กต์ให้อยู่ในสภาพที่ “release” ได้ จึงยังไม่รับปากช่วงเวลาการเผยแพร่
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตั้งแต่เริ่มเขียนโปรแกรมราวปี 1989 ผมมีโปรเจกต์ที่ปล่อยทิ้งไว้ตั้งแต่สิบกว่าโปรเจกต์ไปจนถึงราวร้อยโปรเจกต์ ส่วนใหญ่เป็นเกม ส่วนใหญ่ทำสำหรับ Mac Plus หรือ Mac LC และหลายอันก็มีกลไกหรือสไตล์ศิลป์คล้ายกับที่กล่าวถึงในบทความ
โปรเจกต์ไม่กี่อันที่ผมปล่อยออกมาหรือมีส่วนร่วมด้วย รู้สึกเหมือนเป็นเงาของตัวผมเอง เรซูเม่และเส้นทางอาชีพก็เช่นกัน มันเหมือนลายนิ้วมือของตัวตนที่สมบูรณ์ซึ่งเคยใช้ชีวิตตามความฝันที่ไม่อาจเป็นจริงได้ เพราะไม่มีโอกาสสะสมความสำเร็จตั้งแต่ช่วงต้น ดังนั้นผมจึงคิดว่า รายได้พื้นฐาน อาจเพิ่มศักยภาพของมนุษย์ได้ 10 เท่าหรือ 100 เท่า ทำให้เราขยับจากเศรษฐกิจบริการไปสู่ความเป็นเจ้าของชีวิตและการเติมเต็มตัวเอง และช่วยให้แต่ละคนสร้างรายได้คงเหลือได้ อีกอย่าง ผมเล่น Pararena เยอะมากจริง ๆ
รอบตัวคุณอาจต่างออกไป หรือประเทศของคุณอาจไม่ได้ใช้แนวทางแบบนั้นก็ได้ ผมสงสัยว่าความต่างระหว่างการทำเกมหลายเกม กับการโฟกัสเกมเดียวจนเสร็จคืออะไร ถ้ามีรายได้พื้นฐาน เราจะทำสิ่งเหล่านี้ต่อไปได้จนมีโปรเจกต์ที่เสร็จสมบูรณ์ออกมาจริง ๆ ไม่ใช่แค่ช่วงสั้น ๆ แต่ต่อเนื่องหรือเปล่า? ในบางช่วงของชีวิต เช่น ช่วงเป็นพ่อแม่หรือวัยเด็ก รายได้พื้นฐานอาจสมเหตุสมผล แต่ในช่วงที่กำลังค้นหาตัวเอง ผมคิดว่าความรับผิดชอบช่วยได้
วิธีคิดแบบนี้เข้าใจยากจริง ๆ รายได้พื้นฐานแบบเวทมนตร์จะกลายเป็นค่าแรงขั้นต่ำสำหรับมวลชนที่ไม่ทำงาน แล้วมันจะยั่งยืนหรือดีได้อย่างไร
ในทางทฤษฎี มีทางเลือกที่จะทำให้เสร็จอย่างถูกต้องได้ แต่ถ้าพยายามทำแบบนั้น องค์กรคงล้มละลาย ดังนั้นมันจึงเป็นทางเลือกในเชิงทฤษฎีเท่านั้น ดูจากสภาพซอฟต์แวร์ที่ผมใช้ในงานและจำใจต้องใช้เป็นการส่วนตัวด้วยแล้ว เหมือนทุกคนรอบตัวก็ใช้ชีวิตแบบนี้กันทั้งนั้น โชคดีที่ผู้ใช้ไม่มีทางเลือก จึงต้องซื้อของห่วย ๆ หรือไม่ซื้ออะไรเลย เราปลอดภัยแม้จะขายของห่วย ๆ
บริษัทจำนวนมากที่ผมเคยทำงานด้วยดำเนินงานแบบนี้ วิศวกรสร้างฟีเจอร์ใหม่แวววาว ปล่อยออกมา แล้วทุกคนก็มีความสุข ผ่านไปไม่กี่เดือน บั๊กกองพะเนิน
คนที่สร้างมันขึ้นมาตั้งแต่แรกย้ายไปทีมอื่นแล้ว เหตุผลที่อ้างคือ “ทลายไซโล” แต่ในความเป็นจริงใกล้เคียงกับ “ทำให้ทุกคนทดแทนกันได้” มากกว่า วิศวกรที่รับช่วงโปรเจกต์ต่อก็ต้องดูแลบำรุงรักษาและแก้บั๊กไปจนกว่าจะมีอีกทีมมารับช่วงต่อ แย่มาก
ยิ่งไปกว่านั้น “ใช้งานได้แบบขั้นต่ำ” ก็ห่างจาก “ใช้งานไม่ได้” แค่ก้าวเดียว ทุกโปรเจกต์กลายเป็นเหมือนอิคารัส ทดสอบว่าจะบินเข้าใกล้ดวงอาทิตย์ได้แค่ไหนก่อนที่ปีกจะละลาย
[1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
คนที่รับช่วงต่อไม่มีคุณสมบัติพอในการตัดสินใจ วิสัยทัศน์ใหญ่ของผมถูกปัดตก การเฝ้าดูความไร้ความสามารถในการจัดการฟีเจอร์นั้นเป็นเรื่องทนยาก และทุกวันนี้ผมยังหงุดหงิดทุกครั้งที่มีบั๊กโง่ ๆ โผล่มา โดยเฉพาะทั้งที่ผมเตือนแล้วตอนยังมีเวลาปรับแก้มากพอ ถึงอย่างนั้นผมก็ได้บทเรียนสำคัญ และบอกได้แน่นอนว่าคราวหน้าผมจะสู้โดยไม่ถอย แม้จะถูกมองว่าเป็น คนดื้อรั้น ก็ตาม
เหมาะกับนักพัฒนาอินดี้ และในระดับหนึ่งก็ใช้กับบริษัทใหญ่ได้ด้วย ปรัชญานี้ดีต่อการระบุฟีเจอร์หรือผลิตภัณฑ์ที่ควรค่าแก่การใช้เวลาอย่างมีความหมายด้วยซ้ำ สถานการณ์ที่คุณอธิบาย อาจมองได้ว่าเป็นผลโดยตรงจากการไม่ทำตามแนวทางที่ต้นฉบับเสนอ
ช่วงนี้กลับไปทำงานแบบ พัฒนาแนวเรโทร อยู่ กำลังสร้างซอฟต์แวร์สำหรับ 68K Macintosh ซึ่งเป็นเครื่องที่ได้เรียนเขียนโปรแกรมครั้งแรก
คุ้ยทั้งหนังสือเก่า ๆ โพสต์ใน comp.sys.mac.programmer และซอร์สโค้ดอย่าง Soft Dorothy กับ GliderPro ไปเยอะมาก การได้มองโค้ดเก่าด้วยสายตาใหม่เป็นประสบการณ์ที่แปลกดี ทำให้เห็นเหตุผลที่ Mac สมัยก่อนแครชบ่อยมาก นอกเหนือจากคำอธิบายง่าย ๆ ว่า “ไม่มีการป้องกันหน่วยความจำ” อย่างที่ผู้เขียนบอก ผมก็ชอบ ศิลปะ 1 บิต ด้วย เลยดูแลลิสต์บัญชี Twitter ที่โพสต์ศิลปะ 1 บิตอยู่ ถ้าขาดใครไปก็บอกได้: https://twitter.com/i/lists/1578111923324944397
ข้อดีของการเขียนโปรแกรมสำหรับระบบที่มีข้อจำกัดคือมันช่วยจำกัดตัวเลือกให้เรา เป็นการพักที่ดีจากประสบการณ์สมัยใหม่ที่แค่ดึงไลบรารีที่เหมาะสมมาก็ทำได้แทบทุกอย่าง บางครั้งก็จินตนาการถึงโลกที่พลังการคำนวณหยุดนิ่ง และซอฟต์แวร์สำหรับระบบที่เข้าใจกันดีแล้วค่อย ๆ ดีขึ้นเรื่อย ๆ เท่านั้น ระบบเก่าอย่าง Mac 68K นั้นความก้าวหน้าของฮาร์ดแวร์เร็วมากจนชวนเวียนหัว เมื่อโปรเซสเซอร์ใหม่อย่าง 68020 หรือ 80386 ออกมา เวลาที่จะสร้างอะไรสักอย่างที่ใช้ศักยภาพของมันได้จริง ๆ ก็มีอย่างมากแค่ไม่กี่ปี ถ้าช้าเกินไป ก็ต้องไปแข่งกับซอฟต์แวร์ใหม่สำหรับฮาร์ดแวร์รุ่นถัดไปแล้ว
อยากทำฟังก์ชัน wrapper สำหรับจัดการ Handle และอื่น ๆ ด้วย ถึงอย่างนั้น ตามที่พูดไว้ เมื่อเทียบกับระบบปฏิบัติการสมัยใหม่แล้ว Toolbox เรียบง่ายจนน่าทึ่งจริง ๆ การได้กลับมาทำพัฒนาแนวเรโทรอีกครั้งรู้สึกสนุกมาก
บล็อกทั้งบล็อกเจ๋งมาก มีเรื่องน่าสนใจให้ไล่อ่านเยอะ
การทิ้งบางอย่างไปก็ไม่เป็นไร และแม้แต่โปรเจกต์ที่ทิ้งไปแล้วก็ยังเรียนรู้อะไรได้ รวมถึงอาจนำบางส่วนกลับมาใช้ใหม่ได้ด้วย จุดเปลี่ยนสำหรับผมคือช่วงที่ตัดสินใจทำให้มันเล็กพอที่จะทำให้เสร็จได้ มันช่วยฝึก ทักษะการทำให้เสร็จ ซึ่งเป็นอีกทักษะหนึ่งแยกต่างหาก และเรียนรู้ยาก เพราะมันเกิดขึ้นก็ต่อเมื่ออยู่ปลายทางของกระบวนการที่ยาวและหนักมาก จึงแทบไม่มีใครไปถึงจุดนั้น เพื่อน ๆ ที่ทำวิดีโอเกมของผมทุกคนเริ่มจากการเขียนเอนจินของตัวเอง และพอถึงช่วงทำ level editor ก็หมดไฟ ได้เรียนรู้เรื่องการทำเครื่องมือเยอะก็จริง แต่ก็บังเอิญเป็นสิ่งคล้าย ๆ กับที่ทำเป็นอยู่แล้ว สุดท้ายก็ไม่ได้ทำเกมจริง ๆ เหมือนการเรียนงานก่อหินไปพร้อมกับสร้างมหาวิหาร ยังไงก็ไม่น่าจะเห็นปลายทาง ต้องเริ่มจากสิ่งที่เล็กจนแทบล้มเหลวไม่ได้ แล้วค่อย ๆ ไต่ไปยังโปรเจกต์ที่ใหญ่ขึ้น
ตอนนี้กำลังทำโปรเจกต์ Unity อยู่ แล้วก็ติดหล่มกับการคิดว่าจะทำระบบวางอาคารสไตล์ RTS อย่างไรให้ดีที่สุด แทนที่จะกระโจนเข้าไปเหมือนทุกที ผมตัดสินใจปรับคอนเซ็ปต์เกมใหม่ให้ผู้เล่นไม่จำเป็นต้องวางอาคารเลย พอลองแล้วกลับกลายเป็นประสบการณ์ผู้ใช้ที่ดีกว่าสำหรับสิ่งที่ผมตั้งใจจะทำเสียอีก ตอนแรกก็หาเหตุผลเข้าข้างตัวเองว่า “ค่อยเพิ่มระบบอาคารในรอบถัดไป” แต่ตอนนี้คิดว่าคงไม่ทำแล้ว
การตัดทอนออกแทบจะดีกว่าเสมอ การทำจุดเริ่มต้นเล็ก ๆ ให้เสร็จจริง ๆ เหมือนเป็นไนโตรมีเทนสำหรับรอบถัดไป ต้องไปถึง 100% ก่อน รอบต่อไปถึงจะดีขึ้นมาก ถ้าหยุดที่ 80% ก็เหลือแต่ความรู้สึกว่าต้องเข็นหินกลับขึ้นเนินอีกครั้ง
หลังจากมาทำงานด้านการเข้าถึงได้ ก็หยิบหลายชิ้นในนั้นกลับมาทำใหม่ให้เข้าถึงได้ บางชิ้นใช้ Bootstrap เวอร์ชันเก่ามาก เลยถือโอกาสอัปเกรดเป็น Bootstrap รุ่นล่าสุดไปด้วย แค่แก้ดีไซน์เก่าให้เข้าถึงได้ก็ได้เรียนรู้มากจริง ๆ รู้สึกว่าได้มุมมองที่ดีกว่ามากว่าควรมองอะไรเวลาประเมินไซต์และแอปพลิเคชัน และยังทำให้รู้ด้วยว่าสิ่งที่เคยทำไว้นั้นเข้าถึงไม่ได้มากแค่ไหน
เกมของ John เป็น แรงบันดาลใจ ให้ผมตอนเด็ก ๆ ที่เริ่มเรียนเขียนโปรแกรมบน Mac เล่น Glider เยอะมาก และเล่น Pararena เยอะยิ่งกว่า จนตอนนี้เสียง sample เปิดเกมที่ก้อง ๆ นั่นยังฝังอยู่ในหัว
คงใช้เวลาอีกมากกว่านั้นเสียด้วยซ้ำไปกับการคุ้ย resource fork ของเกมเหล่านั้นด้วย ResEdit ถึงจะทำไม่เสร็จหลายชิ้น แต่ก็ทำเกมแชร์แวร์เล็ก ๆ สำเร็จอยู่สองสามเกมแล้วอัปขึ้น AOL หลายเดือนต่อมา ตอนมีเช็คจากแคลิฟอร์เนียอันไกลโพ้นมาถึงตู้จดหมาย ก็ประหลาดใจมากจริง ๆ
ยุค Mac ช่วงต้นเป็นช่วงเวลาที่พิเศษมากจริง ๆ และมีความรู้สึกว่านักพัฒนาเดี่ยวคนหนึ่ง ขอแค่มีความคิดสร้างสรรค์กับเวลา ก็สามารถสร้างอะไรบางอย่างแล้วปล่อยมันออกสู่โลกได้ ขอบคุณที่เขียนบทความแบบนี้และพาให้ย้อนกลับไปในความทรงจำ หวังว่าจะมีความสุขกับชีวิตหลังเกษียณ
มันพิเศษเพราะสำหรับพวกเราที่เป็นผู้ใช้คอมพิวเตอร์ยุคแรกและนักพัฒนายุคแรก ทุกอย่างล้วนใหม่หมดหรือเปล่า? หรือในบรรยากาศตอนนั้นมีอะไรบางอย่างที่ต่างออกไปจริง ๆ กันแน่ ดีใจที่คุณชอบเกมเล็ก ๆ ที่ผมทำ และก็สงสัยเหมือนกันว่าเช็คจากแคลิฟอร์เนียใบนั้นอาจเป็นสิ่งที่ผลักให้คุณเข้าสู่เส้นทางอาชีพปัจจุบัน ไม่ว่ามันจะเป็นอะไรก็ตามหรือเปล่า
ถ้าเป้าหมายของบทความนี้คือการทำให้การทิ้งโปรเจกต์กลายเป็นเรื่องปกติ ผมก็ไม่แน่ใจว่าเป็นความคิดที่ดีไหม ต่อให้ตัดเรื่องอื่นทั้งหมดออกไป มันก็อาจเป็นการเสียเวลาอย่างมหาศาล และแค่คำว่า “อย่างน้อยก็ได้เรียนรู้อะไรบางอย่าง” ยังไม่พอจะใช้เป็นเหตุผลรองรับได้ เราไม่ควรต้องเรียนรู้แม้กระทั่งตอนจบมันด้วยหรือ
เพราะเป็นสิ่งที่ยังไม่มีใครเคยทำ พวกเขาจึงค่อย ๆ หาวิธีไปพร้อมกับการทำ และระหว่างทางก็พลาดไปไม่น้อย หนึ่งในประเด็นที่วิดีโอเน้นคือ เมื่อเกิดเรื่องแบบนี้ ทีมไม่ได้หยุดเฉย ๆ แล้วลองทำสิ่งเดิมอีกครั้ง แต่เดินหน้าต่อจนทำให้มันพังไปสุดทาง แล้วใช้เป็นโอกาสทดลองกับวัสดุอย่างเต็มที่
เขาพูดยาวถึงเรื่องนี้ว่ายอดเยี่ยมแค่ไหน เพราะเมื่อไม่ได้อยู่บนเส้นทางของการทำผลิตภัณฑ์ที่เสร็จสมบูรณ์และขัดเกลาแล้ว ก็สามารถลองสิ่งที่ปกติจะไม่กล้าลองได้อย่างอิสระ จึงเป็นโอกาสที่หาที่เปรียบไม่ได้ในการเรียนรู้พฤติกรรมของวัสดุที่กำลังจัดการอยู่ ในเมื่อของนั้นกลายเป็นขยะไปแล้ว การทำให้มันแย่ลงไปอีกก็ยาก จึงพูดได้ไม่เต็มปากด้วยซ้ำว่ายังเป็นการเสี่ยงอยู่
ผมคิดว่าข้อสังเกตที่ว่า แนวคิดที่ให้ความสำคัญกับการเรียนรู้และการทดลองมากกว่าความสำเร็จเพียงอย่างเดียว เป็นหนึ่งในวิธีที่ดีที่สุดในการเก่งจริง ๆ ในสิ่งที่ทำ นั้นถูกต้อง
ChatGPT สรุปว่า “สร้างให้เร็ว และอย่าเปิดตัวเด็ดขาด จนกว่าจะถึงเวลาที่จะเปิดตัว”
บางครั้งเราก็ยึดติดกับโปรเจกต์ที่ไม่ไปไหน โดยคิดว่าถ้าพยายามพอ มันคงไปถึงที่ไหนสักแห่ง แต่กลายเป็นว่าไม่สนุกและไม่ได้เรียนรู้อะไรใหม่ พอผลักดันตัวเองด้วยความคิดว่า “ต้องทำให้เสร็จ ต้องทำให้เสร็จ” แล้วลองถามว่า “ทำไม?” โดยมากก็มักเป็นเพราะ ความกลัวที่จะทำไม่สำเร็จ หรือไม่ก็กลัวว่าจะแยกไม่ออกระหว่างช่วงที่ยากกับช่วงที่เป็นโปรเจกต์ล้มเหลว ไม่ว่าจะอย่างไหน ผมเคยรู้สึกโล่งใจหลังล้มเหลวมาหลายครั้งมาก มันเป็นโอกาสให้เริ่มใหม่
พิกเซลอาร์ต บางภาพในสกรีนช็อตนั้นเจ๋งจริง ๆ
ส่วนตัวแล้ว ผมได้เรียนรู้และทำเงินได้มากกว่ามากจากการปล่อยของเล็ก ๆ ออกไป แล้วค่อยทำซ้ำหรือทิ้งมันไป
ผมชอบวิธีนี้และเห็นว่าน่าสนใจ แต่ใน ระดับองค์กร ดูจะซับซ้อนกว่า หลายสิ่งที่เราค้นพบเกี่ยวกับโปรเจกต์และเทคโนโลยีเกี่ยวข้องกับความเป็นไปได้เมื่อโปรเจกต์จริงทำงานในสเกลนั้น ๆ และการทดลองเล็ก ๆ อาจไม่ได้เผยให้เห็นเสมอไป
บางครั้งปัญหาไม่ใช่เรื่องเทคโนโลยี แต่เป็นปัญหาแบบ “เราจะทำให้นักพัฒนาส่วนใหญ่ที่นี่เข้าใจการทำงานด้วยวิธีนี้ได้ไหม” นั่นไม่ได้หมายความว่าเราไม่ควรลองทำแบบนี้ให้มากขึ้น การลองโปรเจกต์เล็ก ๆ มีสิ่งที่เรียนรู้ได้อยู่ เพียงแต่ไม่ได้รับประกันว่ามันจะใช้ได้ในสเกลใหญ่ด้วย
ปัญหาของผมก็แค่ เวลา พอกลับจากงานมาถึงบ้าน สิ่งที่ไม่อยากทำที่สุดคือการนั่งหน้าคอมพิวเตอร์
วันหยุดสองวันต่อสัปดาห์ก็ต้องถูกเติมด้วยงานบ้านอยู่ดี ผมเลยยังไม่อยากนั่งหน้าจอคอมพิวเตอร์
ผมอิจฉาคนที่ทำแบบคุณได้ ตอนนี้อุตสาหกรรมนี้ให้ความรู้สึกเหมือน ลัทธิ ที่มองหาแต่คนที่ทำให้เทคโนโลยีและการเขียนโปรแกรมเป็นทั้งชีวิตของตัวเอง ไม่ใช่ว่าผมเกลียดข้อกำหนดพวกนั้นเอง และผมก็มีจรรยาบรรณในการทำงานและอยากทำให้ดี แต่ความคาดหวังดูสูงกว่าที่เคยเป็นมา
ผมหวังว่าจะมีความมั่นคงในงานมากพอที่จะมีงานอดิเรกที่ไม่ต้องจ้องหน้าจอได้ ในเร็ว ๆ นี้อยากลองงานโลหะดู