- Lore ที่ Epic Games ดูแลรักษา เป็นระบบควบคุมเวอร์ชันโอเพนซอร์สรุ่นถัดไปที่มุ่งเป้าไปยังโปรเจ็กต์ซึ่งจัดการทั้งโค้ดและแอสเซ็ตไบนารีขนาดใหญ่ร่วมกัน
- เริ่มต้นใช้งานแบบโลคัลได้อย่างรวดเร็ว แล้วค่อยขยายตามความต้องการ พร้อมรองรับรีโพซิทอรีและทีมขนาดใหญ่ด้วย ข้อมูลที่แชร์และนำกลับมาใช้ซ้ำได้ และการดาวน์โหลดเมื่อจำเป็น
- ใช้ ที่เก็บข้อมูลแบบ content-addressed ที่มีศูนย์กลาง และแสดงสถานะของรีโพซิทอรีกับประวัติการเปลี่ยนแปลงด้วย Merkle tree และ immutable revision chain
- ไฟล์ขนาดใหญ่ถูกเก็บเป็น ชังก์ ที่นำกลับมาใช้ซ้ำได้ และด้วย sparse workspace กับ on-demand hydration จึงไม่จำเป็นต้องดาวน์โหลดข้อมูลทั้งหมดตั้งแต่แรก
- เปิดเผยภายใต้สัญญาอนุญาต MIT พร้อมมี CLI, API สำหรับ C/C++, C#, Rust, Go, Python, JavaScript และ รีโพซิทอรี SDK หลายรายการ
การจัดการเวอร์ชันสำหรับโค้ดและแอสเซ็ตขนาดใหญ่ร่วมกัน
- Lore เป็นระบบควบคุมเวอร์ชันโอเพนซอร์สรุ่นถัดไปที่ Epic Games ดูแลรักษา
- ออกแบบมาโดยมุ่งเน้นความสามารถในการขยายสูง ทั้งในด้านขนาดข้อมูล ขนาดทีม การกระจายตัวของทีม และขนาดรีโพซิทอรี
- เหมาะอย่างยิ่งกับโปรเจ็กต์ที่ใช้ทั้งโค้ดและแอสเซ็ตไบนารีขนาดใหญ่ร่วมกัน
- ยกตัวอย่างเป็นโปรเจ็กต์ในอุตสาหกรรมเกมและบันเทิง
- รองรับความต้องการในการทำงานร่วมกันของทั้งนักพัฒนาและศิลปิน
- สามารถเริ่มต้นในโหมดโลคัลได้ภายในไม่กี่นาที และค่อยขยายต่อได้ตามความจำเป็น
- เป็นพื้นฐานให้ทีมสร้างเวิร์กโฟลว์การทำงานร่วมกันที่รวดเร็ว เข้าใจง่าย และใช้งานได้จริง
โครงสร้างเพื่อการขยายตัวและการจัดการไฟล์ขนาดใหญ่
-
ข้อมูลที่แชร์และ API
- ความสามารถหลักถูกออกแบบมาให้เหมาะกับ การขยายตัว และการจัดการแอสเซ็ตขนาดใหญ่
- มุ่งให้ขยายได้โดยไม่ทำให้ความเร็วลดลง ด้วยข้อมูลที่แชร์และนำกลับมาใช้ซ้ำได้ และการดาวน์โหลดเมื่อจำเป็น
- สามารถสร้าง จัดการ และซิงก์บรันช์ได้อย่างรวดเร็ว
- เข้าถึงความสามารถทั้งหมดของ Lore ได้แบบหนึ่งต่อหนึ่งผ่าน CLI
- รองรับการขยาย การปรับแต่ง และการผสานรวมผ่าน API สำหรับ C/C++, C#, Rust, Go, Python และ JavaScript
-
ที่เก็บข้อมูลแบบ content-addressed
- โครงสร้างรีโพซิทอรีเป็นระบบควบคุมเวอร์ชันแบบ content-addressed ที่มีศูนย์กลาง
- ข้อมูลในรีโพซิทอรีถูกเก็บและอ้างอิงด้วยแฮชของคอนเทนต์ และแสดงด้วย Merkle tree
- รองรับการเปรียบเทียบที่รวดเร็ว การตรวจสอบความถูกต้องสมบูรณ์ และการใช้ข้อมูลซ้ำระหว่างประวัติและบรันช์
- ลายเซ็นแฮชของ revision ได้มาจากสถานะของ revision ซึ่งรวมแฮชของ parent revision และแฮชของข้อมูลที่รวมอยู่
- โครงสร้างนี้ก่อให้เกิดเชนแบบไม่เปลี่ยนแปลงที่มีความถูกต้องสมบูรณ์เชิงเข้ารหัส
-
การเก็บแบบชังก์และการดาวน์โหลดเมื่อจำเป็น
- การจัดการไฟล์ขนาดใหญ่และเวิร์กสเปซใช้ การเก็บแบบชังก์ และ on-demand hydration
- ไฟล์ถูกเก็บเป็นชังก์ที่นำกลับมาใช้ซ้ำได้ และใช้การค้นหาแบบอิงดัชนี
- ช่วยลดข้อมูลซ้ำซ้อน และเพิ่มประสิทธิภาพในการอัปเดตและส่งต่อแอสเซ็ตไบนารีขนาดใหญ่
- เวิร์กสเปซสามารถคงความเบาไว้ได้ด้วยการดึงมาเฉพาะข้อมูลไฟล์ที่จำเป็น
- ด้วย sparse workspace จึงไม่จำเป็นต้องดาวน์โหลดข้อมูลทั้งหมดตั้งแต่ต้น
-
เซิร์ฟเวอร์และโมเดลบรันช์
- โครงสร้างเซิร์ฟเวอร์เป็นสถาปัตยกรรมแบบบริการที่มีแคชรวมอยู่ด้วย
- การแคชที่อยู่หน้าชั้น durable storage ช่วยรองรับการขยาย throughput สำหรับทีมขนาดใหญ่และรีโพซิทอรีขนาดใหญ่
- บรันช์ทำงานเป็น mutable reference ที่มีน้ำหนักเบา ทำให้ต้นทุนในการสร้างและสลับต่ำ และไม่มีการทำสำเนาข้อมูลพื้นฐานซ้ำ
รีโพซิทอรีสาธารณะและเอกสาร
- Epic Games เปิดซอร์ส Lore อย่างสมบูรณ์ภายใต้ สัญญาอนุญาต MIT
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- เอกสารและเอกสารออกแบบระบบมีให้ที่ Lore docs และ system design doc
2 ความคิดเห็น
ความเห็นจาก Hacker News
เพื่อเพิ่มบริบทให้ผู้อ่าน HN ที่ไม่เคยทำเกมมาก่อน นี่ไม่ใช่เครื่องมือที่พยายามแข่งกับ Git ในงานพัฒนาซอฟต์แวร์ทั่วไป แต่เป็นเครื่องมือที่พยายามแข่งกับ Perforce ในการพัฒนาเกม
Git ใช้ได้ดีกับไฟล์แบบข้อความอย่างโค้ด แต่ค่อนข้างอ่อนมากเมื่อทำงานร่วมกันบนไฟล์ที่ไม่ใช่ข้อความ เช่น เท็กซ์เจอร์ โมเดล 3D หรือไฟล์เสียง ตัวอย่างเช่น ไม่มีวิธีที่สมเหตุสมผลในการรวมงานแก้ไขแบบอะซิงโครนัสจากศิลปินสองคนเข้าด้วยกัน จึงอาจต้องใช้ การล็อกแบบเอกสิทธิ์ กับแอสเซ็ตที่ศิลปินคนหนึ่งกำลังแก้อยู่
ผู้นำโดยพฤตินัยในพื้นที่นี้คือระบบปิดอย่าง Perforce(https://www.perforce.com/products/helix-core) เพื่อนนักพัฒนาเกมของผมบอกว่า Perforce ยอดเยี่ยมมากตอนที่มันทำงานได้ดี แต่ก็มีจุดติดขัดมากพอจนต้องมีวิศวกรเครื่องมือคอยดูแลและแก้ด้วยมือเป็นครั้งคราว Git LFS ก็เป็นอีกทางเลือก แต่สำหรับโปรเจกต์ทีมที่มีมากกว่า 3~4 คน ทุกคนดูจะชอบ Perforce มากกว่า
ใน P4 คุณจำกัดการเข้าถึงบางไดเรกทอรีให้เฉพาะคนที่เซ็น NDA ที่จำเป็นแล้วได้ แต่ใน Git มันเป็นแบบให้ทั้งหมดหรือไม่ก็ปิดทั้งหมด คุณอาจจัดอะไรบางอย่างด้วย submodule ได้ แต่ถ้าไม่ได้ออกแบบมาแบบนั้นตั้งแต่แรก ก็ต้องรื้อโครงสร้างรีโพครั้งใหญ่
git cloneหรือก็คือp4 syncอาจมีขนาดระดับ เทราไบต์Git ไม่เก่งในการจัดการแอสเซ็ตไบนารี เท็กซ์เจอร์ โมเดล และเสียงในขนาดระดับนี้
ถ้ามีแอสเซ็ตที่อัปเดตบ่อยในช่วงต้นการพัฒนา คุณก็ต้องแบกรับค่าเก็บข้อมูลนั้นไปตลอดอายุของรีโพ ซึ่งในการพัฒนาเกมเป็นเรื่องปกติมาก แอสเซ็ตส่วนใหญ่จะเปลี่ยนไปมาอยู่หลายรอบในช่วงแรก แล้วพอเสร็จแล้วก็แทบไม่ถูกแตะอีกเลย
ระหว่างที่ผม push การเปลี่ยนแปลงขึ้น Github วันนี้ก็คิดอีกครั้งว่า UI ของ Git ไม่เป็นมิตรกับผู้ใช้แค่ไหน
เอาต์พุตอย่าง
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltasอาจสื่ออะไรบางอย่างกับคนที่ใช้ Git แบบฮาร์ดคอร์ แต่สำหรับคนส่วนใหญ่มันคือคำพูดมั่วๆ ล้วนๆ “delta compression” คืออะไรกันแน่ ทำไมต้องรู้ว่ามันใช้กี่เธรด และ “object” หรือ local object กับ “pack-reused” หมายถึงอะไร ก็เข้าใจได้ยากจากเอกสาร Lore ดูเหมือนจะจัดการส่วนนี้ได้ดีกว่านิดหน่อย โดยแสดงประมาณ
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch main-vมากกว่า คงแค่ไม่มีใครไปแตะมัน และพวกเราก็เรียนรู้ที่จะมองข้ามมันมาตลอดหลายสิบปีobject ถูกอ้างถึงโดย tree และ tree ก็คือไดเรกทอรีนั่นเอง จากนั้น tree ก็ถูกอ้างถึงอีกทีโดย commit หรือ tag จนเกิดเป็น DAG และตัวชี้แบบมีชื่อที่ชี้ไปยังจุดต่างๆ เหล่านั้นก็คือ branch และ tag reference: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
การปล่อยให้มี loose object กองเต็มไปหมดไม่มีประสิทธิภาพมาก Git จึงรวม object เหล่านั้นเป็น pack เป็นระยะ เพื่อประหยัดพื้นที่ มันจะบีบอัดโดยเปรียบเทียบ object ภายใน pack เข้าหากัน ซึ่งก็คือ delta compression: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
เวลา push หรือ pull โปรโตคอลการส่งข้อมูลของ Git จะไล่ดูว่าทั้งสองฝั่งมี object อะไรอยู่บ้าง แล้วส่งเฉพาะส่วนต่าง นอกจากนี้ยังทำ delta compression กับ object ที่ยังไม่ได้ถูกรวมเป็น pack ทั้งสองฝั่งเพื่อประหยัดพื้นที่ด้วย: https://github.com/git/git/blob/master/Documentation/technic...
Git เป็นโปรเจกต์โอเพนซอร์สที่สร้างโดยพวกเนิร์ด เลยโชว์ข้อมูลพวกนี้ทั้งหมดออกมา คุณแค่ไม่ต้องสนใจก็ได้ แต่ถ้าอยากรู้จริงๆ มันมีเอกสารครบทั้งในหนังสือ Git และในไดเรกทอรีเอกสารที่ลิงก์ไว้ด้านบน
ตอนนี้เริ่มเก็ตมากขึ้นแล้ว ในแง่ UI มันดีขึ้นจาก Git มาก แต่ workflow แบบ branch ยังต้องใช้เวลาทำความคุ้นเคยอยู่บ้าง
ผมแนะนำอย่างยิ่งให้ลองเปิดดูไดเรกทอรี
.gitตรงๆ เลย แล้วความต้องการซัพพอร์ตเรื่อง Git สำหรับพนักงานใหม่จะลดลงจนแทบเป็นศูนย์การประกาศครั้งนี้ดูมีอนาคตมากโดยเฉพาะสำหรับ การพัฒนาเกมด้วย Unreal ถ้าเป็นการใช้งานแบบอื่นก็ไม่ได้ดึงดูดความสนใจขนาดนั้น
Perforce จำเป็นต้องมีคู่แข่งอย่างแน่นอน เหตุผลที่ Perforce ยังเป็นเจ้าตลาดเดิมไม่ใช่เพราะมันใช้งานหรือดูแลง่ายเป็นพิเศษ ตัวอย่างเช่น ถ้าดูแค่เรื่องการทำงานกับ branch แล้ว Git เองง่ายกว่ามากในทางปฏิบัติ
เหตุผลที่ P4 มักถูกเลือกในงานพัฒนาเกมก็คือเรื่องที่คอมเมนต์อื่น ๆ พูดไปแล้ว เช่น การรองรับโปรเจ็กต์ขนาดใหญ่ สิทธิ์การเข้าถึง และการล็อกไฟล์ อีกเหตุผลสำคัญคือ P4 ได้รับการรองรับใน Unreal Engine ดีมาก แม้จะไม่สมบูรณ์แบบ แต่เพราะเป็นเครื่องมือที่ Epic ใช้ภายใน จึงเป็นระบบควบคุมเวอร์ชันที่รองรับได้ดีที่สุด ส่วน Git plugin นั้น Epic ไม่ได้ใช้ภายใน ทำให้ยังไม่สมบูรณ์จนใช้งานได้อย่างน่าปวดหัว
เพราะแบบนั้นจึงคาดว่า Lore จะได้รับการรองรับระดับชั้นหนึ่ง ถ้า Unreal รองรับได้ดีกว่านี้ก็คงแนะนำ Git มากกว่านี้มาก ถ้าจะเล่าภูมิหลังไว้หน่อย ผมทำงานพัฒนาเกมมาเกือบ 20 ปี ผ่านทั้งบริษัทขนาด 2 คนไปจนถึง 200 คน และผ่านมาทั้งสารพัดเอนจินกับระบบควบคุมเวอร์ชัน ถ้าเป็นที่ที่ใช้ได้ก็จะชอบ Git มากกว่า แต่สำหรับ Unreal จะเหมาะแค่กับโปรเจ็กต์เล็กหรือทีมที่เชี่ยวชาญเทคโนโลยี เลือกเครื่องมือให้เหมาะกับงานและทีมก็พอ
https://github.com/EpicGames/UnrealEngine/pull/14630
ที่สตูดิโอเกมก่อนหน้านี้ต้องใช้ Perforce หรือให้ชัดเจนคือ Helix Core Cloud ซึ่งเป็นมาตรฐานโดยพฤตินัยของอุตสาหกรรมที่คนสายครีเอทีฟส่วนใหญ่คุ้นเคยกันอยู่แล้ว โปรแกรมเมอร์อาจไม่ชอบมัน แต่ในวงการเกมฝ่ายที่มีอำนาจตัดสินใจไม่ใช่โปรแกรมเมอร์ มันเป็นค่าเริ่มต้นที่ปลอดภัยและผ่านการพิสูจน์แล้วสำหรับการใช้ร่วมกับ Unreal Engine 5
แต่ก็ยังมีกลิ่นอายของความเก่าอยู่ เราเป็นทีมเล็กและไม่อยากโฮสต์เอง เลยใช้บริการคลาวด์ของ Perforce ตั้งแต่ช่วงต้น ๆ ซึ่งประสบการณ์ค่อนข้างสะดุด ถ้าจะเข้าถึงบริการต้องสมัครบัญชี Azure และถ้าจะเปลี่ยนอะไรอย่าง trigger ก็ต้องติดต่อฝ่ายซัพพอร์ต ถ้ามาจากโลกของ GitHub หรือผลิตภัณฑ์ SaaS อื่น ๆ จะรู้สึกได้ว่ามันเหมือนความพยายามเอาเปลือกใหม่มาครอบโมเดลเก่า
เส้นทาง Git LFS ก็มีการรองรับแบบไม่เป็นทางการอยู่บ้าง แต่ถ้างานพังขึ้นมาก็ต้องแก้กันเอง Epic ไม่ได้ช่วยมากนัก โดยเฉพาะถ้าตั้งเป้าจะให้มีการรองรับอย่างเป็นทางการเต็มรูปแบบในเอนจิน การมีคู่แข่งในพื้นที่นี้จึงเป็นเรื่องน่ายินดี
ผมเคยเขียนอธิบายไว้แล้วว่าทำไมในโลกพัฒนาเกมถึงไม่ค่อยมีการ merge ไฟล์ สำหรับคนที่มาจากสายพัฒนาแบบอิงข้อความ: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
ผมเพิ่งเข้ามารับทีมที่ใช้ Git อยู่ และแม้จะรู้ว่า Git เป็นระบบควบคุมเวอร์ชันที่ทุกคนชอบ แต่สำหรับเกมมันแทบจะเป็นหนึ่งในตัวเลือกที่แย่ที่สุด เวลาทำ art review ด้วย Git เราต้องวัดเป็นชั่วโมง แต่ถ้าเป็น Perforce วัดเป็นวินาที ไม่ได้พูดเล่น
เครื่องมือที่น่าสนใจที่ UE5 ใช้อย่าง Horde หรือ UBA ก็ต้องการ Perforce
แต่ Perforce เองก็ไม่ได้ทำอะไรทั้งที่มีสถานะครองตลาด ทั้งแพงมากและก็ไม่ได้มีบริการโฮสต์ให้ ต้องโฮสต์เอง ซึ่งในแง่ประสิทธิภาพก็ทำเองจะดีกว่า แต่หลังติดตั้งครั้งแรกแล้วการดูแลรักษานี่ทรมานจริง ๆ ดูเหมือนจะพยายามทำอะไรอยู่บ้างแต่ไม่มีทิศทางชัดเจน และแทบทุกอย่างที่ทำมาก็สวนทางกับสามัญสำนึกหรือฐานผู้ใช้ ผลิตภัณฑ์หลักก็เปลี่ยนแต่ชื่อโดยแทบไม่มีการปรับปรุงจริง
นี่เป็นบทเรียนว่าซอฟต์แวร์ปิดกลายเป็นคุกได้อย่างไร ผมอยากใช้เครื่องมือ code review ที่ดีกว่า Swarm อยากรวม SSO โดยไม่ต้องมี LUA hook ประหลาดที่ทำให้เครื่องผม segfault และอยากรัน distributed storage backend แทนการพึ่ง SSD ขนาดมหึมากับ journal backup ที่แย่ไปกว่านั้นคือไลเซนส์ยังผูกกับ IP address ของเซิร์ฟเวอร์หลักจนกู้คืนจากแบ็กอัปก็ไม่ได้ด้วยซ้ำ
มันคือเทคโนโลยีที่ถูกลืม และองค์กรที่บริหารบริษัทนี้ก็ดูเหมือนซอมบี้
ผมไม่แน่ใจว่าปัญหาเรื่องสิทธิ์การเข้าถึงถูกจัดการแล้วหรือยัง หรือโมเดลควบคุมเวอร์ชันแบบผสมกระจาย/รวมศูนย์ลักษณะนี้ ซึ่งมี file-level checkout มาปฏิสัมพันธ์กับการทำงานแบบ branch ดั้งเดิมนั้น ถูกจัดการเรียบร้อยแล้วหรือยัง
ถ้าดูใน FAQ จะพบว่าจริง ๆ แล้วมันไม่ใช่ผลิตภัณฑ์ใหม่ทั้งหมด แต่เป็นสิ่งที่เพิ่งถูกเปิดซอร์สในตอนนี้
มีคำอธิบายว่า “Lore ซึ่งก่อนหน้านี้ถูกเรียกว่า Unreal Revision Control เป็นระบบควบคุมเวอร์ชันที่ฝังอยู่ใน UEFN (Unreal Editor for Fortnite) และถูกใช้โดยครีเอเตอร์เพื่อจัดการเวอร์ชันของเกาะของตน ทีมภายในของ Epic เองก็เริ่มนำมาใช้เพิ่มขึ้นทีละน้อย และกำลังนำไปใช้เป็นที่เก็บข้อมูลแบ็กเอนด์ของ cook pipeline ใน UEFN เพื่อแทนที่ชั้นจัดเก็บข้อมูลชั่วคราวเดิม กำจัดการส่งไฟล์ซ้ำซ้อน และลดเวลาตั้งแต่เผยแพร่การเปลี่ยนแปลงจนสามารถเข้าไปเล่นได้ลงอย่างมาก”
น่าแปลกที่มันใช้ Rust ไม่ใช่ Epic C++ หรือ Verse อยากรู้เหตุผลเหมือนกัน
ส่วนที่ไม่ใช้ Verse น่าจะเป็นเพราะงานนี้ไม่เหมาะกับ Verse ซึ่งต่อให้ Simon ทำงานกับ Verse อยู่ก็อาจยังเป็นแบบนั้นอยู่ดี และที่ไม่ใช้ Haskell ก็น่าจะเพราะเรื่องประสิทธิภาพ DARCS เองก็มีข้อจำกัดด้านประสิทธิภาพจนไม่ได้แพร่หลายมากนัก
แถมยังจะเป็นการผูกตัวเองเข้ากับปัญหาและความช้าทั้งหลายของเอนจินอีกด้วย Epic เคยพลาดแบบนี้กับ Epic Games Launcher ซึ่งแทบจะเป็นการรันเอนจินอินสแตนซ์หนึ่งขึ้นมา และนั่นก็เป็นต้นตอใหญ่ของปัญหาหลายอย่าง
ถ้าเทียบ Verse กับ Rust นั้น Verse ใช้อยู่ภายในประสบการณ์ของ UEFN แต่ยังห่างไกลจากความพร้อมระดับ production และโดยธรรมชาติก็ผูกติดกับ UEFN ด้วย ไม่ใช่อะไรที่คุณจะดาวน์โหลดคอมไพเลอร์แบบรันเดี่ยวหรือ REPL มาใช้ได้
แน่นอนว่าถ้าเปิดออกมาเพราะตัดสินใจเลิกพัฒนาก็อีกเรื่อง แต่กรณีนี้ดูไม่เหมือนแบบนั้น
Full-surface API เป็นความสามารถที่ไม่มีใครพูดถึงที่นี่เลย สงสัยว่ามันเป็นการพาดพิงถึง Git ที่จงใจไม่ให้มีไลบรารีแบบลิงก์ใช้งานได้หรือเปล่า ก่อนหน้านี้เคยเห็นโพสต์นี้: https://news.ycombinator.com/item?id=48470604
porcelainสำหรับให้โปรแกรมโต้ตอบด้วย ถึงจะไม่ใช่ในรูปแบบที่ลิงก์เข้าไปใช้ได้โดยตรง แต่ก็ยังถือเป็น API อยู่ดีสมมติฐานก็คือ Git-LFS ไม่ค่อยดีพอ เลยต้องสร้าง ระบบควบคุมเวอร์ชันข้อมูล ใหม่จากศูนย์ด้วย Rust ซึ่งโดยรวมแล้วก็เห็นด้วยกับสมมติฐานนี้ แต่ในทางปฏิบัติก็มีระบบควบคุมเวอร์ชันข้อมูลที่มีอยู่ก่อนและค่อนข้าง成熟หลายตัวที่ใช้แนวคิดคล้ายกันอยู่แล้ว
Pachyderm(Go): https://github.com/pachyderm/pachyderm
XetHub(HuggingFace เข้าซื้อกิจการ): https://huggingface.co/blog/xethub-joins-hf
LakeFS(Go): https://github.com/treeverse/lakeFS
Oxen(Rust): https://github.com/Oxen-AI/Oxen
ทุกวันนี้เพราะ AI ก็เลยเหมือนเป็นยุคที่ใคร ๆ ก็สามารถไวบ์โค้ดระบบจัดเก็บแบบ content-addressed, การขจัดข้อมูลซ้ำระดับชังก์ และระบบควบคุมเวอร์ชันด้วย Rust ได้
พูดเล่นนอกเรื่องไปหน่อย แต่ Lore ดูเท่มาก สิ่งที่น่าสนใจคือแม้โดเมนและอุตสาหกรรมจะแตกต่างกัน แต่กลับมีปัญหาคล้ายกันโดยที่ดูเหมือนจะไม่ได้แลกเปลี่ยนไอเดียกันมากนัก ในกรณีนี้ทั้ง AI และเกมต่างก็ต้องการระบบจัดเก็บสำหรับ การจัดการเวอร์ชันไฟล์ไบนารีขนาดใหญ่ ดูเป็นพื้นที่ที่น่าจะมีโอกาสแชร์ไอเดียกันได้มาก และการที่ตอนนี้ยังแชร์กันน้อยก็อาจเป็นโอกาสในตัวเอง
แค่ความต่างข้อนี้ก็อาจทำให้ต้องใช้สถาปัตยกรรมสตอเรจคนละแบบแล้ว
คิดว่าส่วนหนึ่งของปัญหามาจากการประนีประนอมที่จำเป็นเมื่อยังต้องรักษาที่เก็บแบบไฮบริดร่วมกับ Git ดังนั้นจึงดีใจที่ระบบควบคุมเวอร์ชันนี้ไม่ได้ใช้ Git xethub เองก็เริ่มออกผลิตภัณฑ์เวอร์ชันที่ไม่ใช้ Git แล้ว แต่ยังไม่มีโอกาสได้ลอง
เคยลอง oxen ด้วย ตอนแรกก็ไม่เลว แต่ไม่นานก็เจอปัญหาแปลก ๆ เกี่ยวกับสถานะของรีโพซิทอรี และไม่ได้ลงลึกไปถึงขั้นดีบักจริงจัง หลังจากเจอกับระบบพวกนี้มาหมด ก็ชัดเจนว่าไม่มีตัวไหนน่าพอใจแบบ 100% และการสร้าง Git สำหรับข้อมูล ไม่ใช่ปัญหาง่าย ๆ เลย
สงสัยว่าจะมีบริษัทไหนนำระบบนี้ไป ใช้งานจริงภายใน 2 ปี หรือไม่
Helix และ Perforce ทำเรื่องนี้มาหลายสิบปี และเป็นส่วนหนึ่งของธุรกิจหลัก จึงเชื่อถือได้ คุณพอจะมั่นใจได้ว่าพวกเขาจะยังดูแลผลิตภัณฑ์ต่อไปอีกพักใหญ่
แต่ถ้า Epic เลิกโครงการนี้พรุ่งนี้ ธุรกิจก็คงไม่ได้รับผลกระทบอะไรเลย ตรงกันข้าม อาจช่วยให้เอาทรัพยากรฝั่งพัฒนากลับไปใช้กับธุรกิจหลักได้ด้วยซ้ำ
มันคล้ายกับคำถามว่าทำไมเราต้องเชื่อว่า Cloudflare จะลงทุนกับ EmDash ต่อในระยะยาว ในเมื่อ Cloudflare ไม่ได้สนใจ CMS ธุรกิจของพวกเขาไม่ใช่การมอบประสบการณ์ที่ดีที่สุดให้ผู้อ่าน ผู้เขียน หรือเจ้าของเว็บไซต์ มันแทบจะเป็นงานข้างที่ไม่เกี่ยวกับธุรกิจหลักด้วยซ้ำ
ในพื้นที่นี้มีคู่แข่งที่ค่อนข้างดีชื่อ PlasticSCM อยู่มานานแล้ว ตั้งแต่อดีตจนถึงปัจจุบัน ไม่กี่ปีก่อน Unity เข้าซื้อกิจการไป แต่ Unity ก็ไม่ได้เป็นผู้ดูแลที่ดีนัก
พวกเขาควรทำแบบที่ Epic ทำแล้วเปิดซอร์สออกมา แต่กลับเลือกแนวทางที่ให้ต้องรับผิดชอบด้านกำไรขาดทุนแทน สงสัยว่ามันมีส่วนช่วยตัวเลขการเงินของ Unity มากแค่ไหน
ความคิดเห็นบน Lobste.rs
บอกว่าออกแบบมาให้เหมาะกับโปรเจกต์เกม/เอนเตอร์เทนเมนต์ที่ต้องจัดการทั้งโค้ดและแอสเซ็ตไบนารีขนาดใหญ่ ในที่สุดก็ดูเหมือนมีใครสักคนเบื่อกับการ ผูกขาดของ Perforce ที่กินเวลามาหลายสิบปี แล้วเลยลงมือทำอะไรสักอย่าง
ตอนเห็นครั้งแรกเหมือนจะยังไม่มี เลยสงสัยว่าทำไมตอนนี้ถึงติดแท็ก vibecoding
ตัวอย่างเช่นคำอธิบายทำนองว่า “Mercurial กับ Sapling เน้นประวัติข้อความ ส่วน Lore ให้ความสำคัญกับไบนารีเป็นหลัก” นั้นไม่ถูกต้อง Mercurial เองก็เป็นโครงสร้างที่มีโมเดลอ็อบเจ็กต์ไบนารีอยู่ข้างล่าง แล้วค่อยมีความสามารถด้านข้อความวางทับอยู่ด้านบน
ในฐานะคนที่เคยมีส่วนร่วมกับการพัฒนา Mercurial/Sapling ผมเชื่อว่า LLM สามารถช่วยเพิ่มความเข้มงวดได้ด้วยการชี้ทางเลือกที่ทีมมองข้ามไป แต่เอกสารนี้ทำให้ผิดหวัง แม้ตัวการตัดสินใจเองจะมีข้อดีมาก แต่ก็อยากให้เป็น เอกสารที่เขียนอย่างเข้มงวดกว่านี้ มาก
2026-06-17 12:56 (Users)
Story: Epic Games announces Lore version control system
Action: changed tags from "release vcs" to "release vcs vibecoding"
Reason: Automatically changed from user suggestions
นี่อาจเป็น โปรเจกต์ Rust ตัวแรกที่ Epic Games ทำแบบเปิดเผยต่อสาธารณะหรือเปล่า?
พอเห็นข่าวนี้คู่กับข่าวระบบควบคุมเวอร์ชันตัวล่าสุดของ Cursor ก็รู้สึกว่าช่วงนี้ทุกคนเหมือนกำลังอยากทำ VCS กันหมด
มีแค่ผมไหมที่ความคิดแรกคือ “ของนี้ไม่ควร โฮสต์อยู่บน lore เองหรือ?”