Khám Phá Ngôn Ngữ Kịch Bản Của Paradox

Trong quá trình duy trì bản mod dịch tiếng Việt cho trò chơi Stellaris, tôi đã dành nhiều thời gian nghiên cứu hệ thống ngôn ngữ kịch bản độc đáo của Paradox. Đây là một hệ thống vừa tinh tế vừa phức tạp, kết hợp giữa cấu trúc dữ liệu thuần túy với khả năng điều khiển logic trò chơi.

Tôi nhận thấy mô hình này có nhiều điểm tương đồng với cách tiếp cận của ngôn ngữ LISP, khi sử dụng cấu trúc dữ liệu để mô tả logic trò chơi. Các game của Paradox đều có kho kiến thức khổng lồ trên wiki cộng đồng, cung cấp tài nguyên phong phú cho các modder. Khả năng học hỏi hệ thống này rất cao nhờ cơ chế trực quan và nhất quán trong thiết kế.

Thông qua việc nghiên cứu toàn diện hệ thống tài liệu wiki liên quan đến modding, tôi đã hiểu rõ hơn về bản chất của ngôn ngữ này. Dù mục đích chính là mô tả dữ liệu cấu hình, nhưng nó còn sở hữu hàng loạt công cụ kiểm soát logic rất đáng khai thác. Dưới góc nhìn của một lập trình viên trò chơi, tôi muốn chia sẻ những điểm thú vị trong thiết kế này - lưu ý là tôi chưa từng xây dựng mod hoàn chỉnh nên có thể có hiểu sai.

Hệ thống này xây dựng trên hai khái niệm trọng yếu trong kiểm soát logic trò chơi (gọi là “Dynamic modding”): Hiệu ứng (Effect) và Điều kiện (Condition). Cả hai đều được biểu diễn dưới dạng danh sách dữ liệu trong kịch bản. Từ góc nhìn cú pháp, chúng không khác gì các dữ liệu cấu hình thông thường, nhưng trong ngữ cảnh trò chơi, chúng hoạt động như các khối lệnh trong ngôn ngữ lập trình truyền thống.

Hiệu ứng (Effect) là các khối lệnh thực thi tuần tự, mỗi lệnh đều tạo ra sự thay đổi trạng thái trò chơi. Chúng ta có thể đóng gói các hiệu ứng này thành các đơn vị có tên gọi là hiệu ứng kịch bản (scripted effect), tương tự như cách định nghĩa hàm (có side-effect) trong các ngôn ngữ lập trình thông thường. Đặc biệt, các hiệu ứng kịch bản này còn hỗ trợ tham số đầu vào dù không có giá trị trả về.

Về phía Điều kiện (Condition), chúng là tập hợp các biểu thức luận lý với giá trị trả về chỉ có thể là đúng hoặc sai, mà không làm thay đổi trạng thái trò chơi. Các đơn vị cơ bản tạo nên điều kiện được gọi là trigger, có thể được định nghĩa độc lập thành các trigger kịch bản (scripted trigger), hoạt động như các hàm luận lý không có side-effect.

Sự phân tách giữa hiệu ứng (có side-effect) và điều kiện (không có side-effect) giúp giảm đáng kể sự phức tạp của các khối logic if-else rối rắm. Hơn nữa, engine có thể tối ưu hiệu suất bằng cách cache kết quả của các điều kiện trong cùng một game tick - một lợi thế lớn cho các trò chơi chiến lược phức tạp như Stellaris với hàng ngàn đối tượng cần xử lý.

Lấy ví dụ cụ thể từ cấu trúc sự kiện (event) trong trò chơi:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

country_event = {
  id = action.8
  hide_window = yes
  is_triggered_only = yes
  trigger = {
    is_country_type = default
    from = { is_country_type = default }
    NOT = { has_communications = from }
    is_hostile = from
  }
  immediate = {
    establish_communications = from
    fromfrom = {
      conquer = root
      set_controller = root
    }
  }
}

Trong ví dụ trên, sự kiện action.8 sẽ kích hoạt hiệu ứng immediate khi điều kiện trigger được thỏa mãn. Tuy nhiên, để hiểu sâu hơn về cách hoạt động, cần nắm rõ khái niệm “scope” - một yếu tố then chốt trong hệ thống này.

Trong Stellaris, mọi đối tượng đều tồn tại trong các phạm vi (scope) cụ thể như country, sector, system, planet, pop, fleet, ship, leader… Mỗi scope không chỉ chứa đối tượng cùng tên mà còn chứa các scope liên kết. Ví dụ, scope sector chứa các hệ thống (system scope), trong khi mỗi system lại có tham chiếu ngược về sector. Điều này tạo thành các cấu trúc phân cấp dạng cây, nơi một đối tượng có thể tồn tại đồng thời trong nhiều cây phân cấp khác nhau.

Chẳng hạn, một pop có thể được truy cập qua các đường dẫn scope khác nhau như: country → sector → system → planet → pop, hoặc country → faction → pop. Mỗi hiệu ứng hay trigger đều yêu cầu scope nhất định để hoạt động - ví dụ trigger habitability (độ dễ chịu) chỉ có thể được gọi từ scope hành tinh (planet):

1

habitability = { who =  value = 0.6 }

Dòng lệnh này kiểm tra xem độ dễ chịu của pop chỉ định có bằng 0.6 trên scope hành tinh hiện tại không. Dù cú pháp có vẻ như là phép gán giá trị, đây thực chất là toán tử so sánh. Nó tương đương với đoạn mã Lua:

1

_ENV:habitability(who, function(value) return value == 0.6 end)

Một điểm độc đáo là thay vì viết a:foo(args), ngôn ngữ này yêu cầu ta phải “nhập scope” trước rồi mới gọi hàm, như viết a = { foo = args }. Ưu điểm là ta có thể thực hiện nhiều thao tác liên quan đến scope hiện tại mà không cần nhắc lại đối tượng, tương tự việc lược bỏ this trong C++.

Ví dụ phức tạp hơn:

1

pop = { planet = { habitability = { who = prev value > 0.6 } } }

Đoạn này kiểm tra xem độ dễ chịu của pop trên hành tinh của nó có lớn hơn 0.6 không. Việc sử dụng prev giúp tham chiếu đến scope cấp trên (pop), trong khi this tham chiếu đến scope hiện tại (planet). Hệ thống scope còn hỗ trợ root để tham chiếu đến scope gốc và from để truy cập scope từ ngăn xếp gọi hàm.

Khái niệm scope mang lại nhiều cảm hứng thiết kế. Trong lập trình hướng đối tượng truyền thống, ta chỉ có this/self để tham chiếu đối tượng hiện tại. Nhưng với trò chơi chiến lược, ta thường xuyên làm việc với nhiều đối tượng cùng lúc: quân địch trong trận đánh, cấp trên/dưới trong hệ thống quản lý, v.v.

Các trigger và effect đều có thể tận dụng hệ thống scope để đơn giản hóa logic phức tạp. Chẳng hạn, trong scope country:

1

any_planet_within_border = { is_planet_class = pc_gaia }

Lệnh này kiểm tra xem quốc gia có chứa ít nhất một hành tinh kiểu Gaia không. Trigger bắt đầu bằng any_ sẽ lặp qua tất cả hành tinh trong scope và kiểm tra điều kiện is_planet_class = pc_gaia với từng hành tinh.

Một ví dụ nâng cao hơn:

1

every_owned_planet = { limit = { is_planet_type = pc_continental } … }

Trong đây, mệnh đề limit lọc ra các hành