Trình Soạn Thảo Trực Quan Trong Động Cơ Game
Khi nhắc đến động cơ game, đặc biệt là các động cơ thương mại phổ biến như Unreal hay Unity, ấn tượng đầu tiên thường là những trình soạn thảo trực quan mạnh mẽ của chúng. Tuy nhiên trong thực tế phát triển game, yếu tố ảnh hưởng lớn nhất đến quy trình làm việc lại chính là các API ở tầng động cơ và mô hình lập trình mà chúng mang lại.
Ngược lại với các động cơ thương mại, những game sử dụng động cơ nội bộ chuyên dụng thường ít có trình soạn thảo trực quan nổi bật. Lấy ví dụ điển hình là các game của Paradox Interactive nổi tiếng với cộng đồng mod sôi động. Dù các tựa game mới của họ đều sử dụng chung động cơ Clausewitz, nhưng lại không đi kèm với một trình soạn thảo chuyên dụng nào. Các modder chủ yếu làm việc trực tiếp với file văn bản và gỡ lỗi ngay trong game. Có thể nói chính bản thân game đã đóng vai trò như một trình soạn thảo - đôi khi chỉ khác biệt ở việc thêm vào một bảng điều khiển (console) nhỏ. Quy trình phát triển trên các động cơ này vẫn dựa chủ yếu vào dòng lệnh (command line).
Trong quá trình phát triển động cơ game, trình soạn thảo trực quan luôn là thành phần tốn nhiều công sức nhất. Dự án động cơ tự phát triển của chúng tôi đã kéo dài 5 năm, trong đó trình soạn thảo đã được xây dựng lại hoàn toàn hai lần và hiện đang ở phiên bản thứ ba do một thành viên duy trì. Trong suốt giai đoạn đó, tôi không ngừng tự hỏi: Một động cơ game thực sự cần trình soạn thảo như thế nào? Nó nên giải quyết những vấn đề gì?
Hơn 20 năm trước, khi tôi viết động cơ Feng Hun, ảnh hưởng lớn nhất đến tôi đến từ thư viện Allegro. Thời điểm đó, chỉ cần đóng gói các API để xử lý các thành phần底层 như đồ họa, âm thanh, bàn phím, chuột và cửa sổ hệ thống là đã giải quyết được phần khó nhất của việc phát triển game. Đến năm 2001, khi phát triển Đại Thoại Tây Du, tôi đã tự xây dựng một vài công cụ nhỏ để chỉnh sửa cảnh và hoạt ảnh 2D theo nhu cầu của game. Những công cụ này hoàn toàn được thiết kế riêng biệt cho dự án, cùng với các module chương trình tương ứng. Tôi cho rằng chúng không thực sự thuộc phạm vi của động cơ game.
Sau này, khi các công ty game lớn dần chuyển sang sử dụng động cơ thương mại, xu hướng tự phát triển động cơ (in-house engine) ngày càng ít phổ biến. Năm 2005, khi xây dựng động cơ 3D đầu tiên, tôi cũng bị ảnh hưởng bởi tư duy “phải có một trình soạn thảo toàn diện” từ các động cơ thương mại. Tôi từng nghĩ rằng thiếu đi trình soạn thảo, không ai sẽ muốn sử dụng động cơ đó. Đến cuối năm 2017 khi khởi động lại dự án động cơ, tôi vẫn giữ quan điểm này - rằng việc xây dựng trình soạn thảo là yếu tố then chốt để thu hút nhà phát triển.
Tuy nhiên, việc “người khác có gì thì mình cũng phải có” là một tư duy sai lầm. Sao chép các tính năng hời hợt không giải quyết được vấn đề cốt lõi. Trước tiên, chúng ta cần hiểu rõ vấn đề thực sự là gì. Một trình soạn thảo đầy đủ tính năng dường như được thiết kế để giảm thiểu việc viết code (low-code?), hạ thấp rào cản phát triển game, cho phép những người không chuyên lập trình vẫn có thể phát huy sáng tạo.
Nhưng điều này lại không phù hợp với nhu cầu của nhóm chúng tôi. Tất cả thành viên đều có kinh nghiệm lập trình dày dặn, việc viết code không phải là trở ngại. Ngược lại, việc tránh dùng code hay giảm thiểu code lại làm tăng độ phức tạp trong phát triển. Trong phát triển phần mềm, nguyên tắc “Dogfooding” (sử dụng sản phẩm của chính mình) luôn cực kỳ quan trọng. Một trong những bài học lớn nhất tôi rút ra sau nhiều năm làm phần mềm là: Nếu một tính năng bản thân bạn không sử dụng thường xuyên, hãy loại bỏ nó khỏi mã nguồn ngay lập tức - chỉ thêm lại khi thực sự cần thiết. Chính vì vậy, lần重构 đầu tiên của trình soạn thảo là khi chúng tôi từ bỏ ý tưởng sao chép một trình soạn thảo kiểu Unity. Chúng tôi nhận ra rằng không nên phát triển tính năng chỉ vì đối thủ có, và người dùng cũng sẽ không chọn động cơ chỉ vì nó có cùng tính năng với các động cơ khác. Nếu chính chúng tôi không sử dụng mô hình low-code để phát triển game, thì cũng không nên xây dựng một trình soạn thảo với mục tiêu giảm thiểu code.
Liệu điều này có nghĩa là động cơ của chúng tôi không cần một trình soạn thảo trực quan toàn diện? Chỉ cần thiết kế API tốt và xây dựng game bằng code là đủ?
Trong một giai đoạn, chúng tôi đã thử nghiệm theo hướng này: chỉ cần vài chục dòng code là có thể dựng lên một demo nhỏ để kiểm tra tính năng. Tuy nhiên cách tiếp cận này khiến động cơ chỉ dừng lại ở tầng rendering, còn rất xa so với việc tạo ra một game hoàn chỉnh. Tệ hại hơn, các file demo đầy rẫy “magic number” - góc quay camera, thông số ánh sáng, tên file cứng nhắc… Cần phải thừa nhận rằng: phần lớn nội dung trong game được biểu diễn dưới dạng dữ liệu chứ không phải code. Dữ liệu này cuối cùng sẽ quyết định hiệu ứng hình ảnh, và cần được điều chỉnh dựa trên cảm quan thị giác. Một chương trình khởi động nhanh sẽ cải thiện trải nghiệm điều chỉnh dữ liệu này; ngược lại, việc sửa giá trị bằng trình soạn thảo văn bản hoàn toàn không hiệu quả. Vì vậy, chúng tôi cần một trình soạn thảo trực quan.
Trình soạn thảo của động cơ game là công cụ trực quan để tạo ra dữ liệu game. Nếu có công cụ chuyên dụng hơn để tạo ra loại dữ liệu đó, không nhất thiết phải tích hợp vào trình soạn thảo. Ví dụ, chúng tôi không cần trình soạn thảo có khả năng dựng mô hình 3D, cũng không cần bút vẽ như Photoshop để tạo texture; việc tích hợp trình soạn thảo script cũng không mang lại nhiều ý nghĩa. Vai trò quan trọng nhất của trình soạn thảo là tách biệt logic code và dữ liệu. Một trình soạn thảo tốt sẽ tạo ra dữ liệu, sau đó code của động cơ chỉ cần đọc dữ liệu này để dựng lên các đối tượng trong game.
Đồng thời, API của động cơ nên được đơn giản hóa. Khi không có trình soạn thảo, tầng API thường cung cấp hàng loạt hàm để giúp code xây dựng các đối tượng game đúng cách. Các API này phản ánh cách dữ liệu kiểm soát từng chi tiết nhỏ. Nhưng khi đã có dữ liệu được tạo bởi trình soạn thảo, cấu trúc phức tạp đã được tổ chức sẵn trước khi code chạy, do đó động cơ chỉ cần một API duy nhất để tải dữ liệu. Có thể hiểu trình soạn thảo chính là công cụ để tạo các “prefab” - những cấu trúc dữ liệu được chuẩn bị sẵn cho thời gian chạy. Phần lớn dữ liệu trong game phục vụ biểu diễn hình ảnh, vì vậy cần có công cụ trực quan để chỉnh sửa và hiển thị.
Dữ liệu do trình