1. Biết đối tượng sử dụng GDD

• Các đối tượng quan tâm đến GDD:
• Game designer, tất nhiên rồi
• Programmer, cần để biết game mình sẽ code
• Artist, biết thế giới game, story và art style
• Producer, để lên kế hoạch và dự trù chi phí
• QA, để xây dựng test plan
• Các đối tượng khác, ví dụ nhà đầu tư cho dự án
• Trong cái đối tượng quan tâm đến GDD thì programmer được coi là đối tượng quan trọng nhất vì:
• Cần biết để chọn engine phù hợp
• Theo sát các design trong GDD, giảm lãng phí thời gian hỏi han, bàn bạc
• Idea thường là do GD khởi sướng, nên programmer cần phải nắm bắt được bằng GDD
• Một số programmer không chơi và không có thời gian tham khảo nhiều game

Bởi vậy, khi game design viết GDD, hãy hỏi xem programmer muốn gì và cần gì. Nếu họ nói cần bỏ 1 chức năng nào đó thì hãy cứ bỏ đi (nếu không quá quan trọng :D )

2. Ngắn Gọn

Thật ra rất khó để viết một GDD ngắn, ngắn ở đây nghĩa là:

• Dễ viết
• Dễ đọc
• Dễ cập nhập
• Dễ sử dụng
• Ít mâu thuẫn
• Đơn giản
• Không phình to lên
• Không để trống
• Không copy & paste (từ các document khác vào)
• Loại bỏ text thừa, lặp lại

Một trong những việc nên làm để đảm bảo GDD ngắn gọn đó là chia các phần thiết kế chuyên sâu thành một document khác, ví dụ UI, hệ thống chỉ số nhân vận, hệ thống chỉ số skill, hệ thống hội thoại... Lúc đó trong GDD, để nhắc đến phần đó bạn chỉ cần viết:

HUD cần phải sáng, là một pop-up giữa màn hình

Nên tránh những câu dài lê thê trong GDD, ví dụ: Anh là nhân vật chính đẹp trai, có sở trường cưỡi ngựa (bạc mã) bắn cung, văn võ song toàn, sống trong tòa lâu đài nguy nga tráng lệ màu hồng... Thì bạn có thể ghi ngắn gọn: Anh là nhân vật tài sắc vẹn toàn, lại còn giàu nữanhà đẹp,

Ngoài ra các bạn nên lưu ý là programmer luôn thích document dạng một loạt gạch đầu dòng, để họ tiện kiểm tra xem đã hoàn thành tính năng nào.

3. Prioritize (Đặt Thứ Tự Ưu Tiên)

Hãy đặt thứ tự ưu tiên cho các tính năng trong game của bạn và chia chúng thành các phase (giai đoạn). Đây cũng chính là thứ tự thực hiện của dự án. Ví dụ

Phase 1 (prototype):

1 character

• Vũ khí mặc định
• Không có túi đồ
• Không có skill
• Phase 2:
• Có thể thay đổi giữa 2 vũ kỹ
• Có 2 skill
• Di chuyển và xài skill được

Phase 3:

• 2 character
• 4 vũ khí
• Có túi đồ
• Cho phép dùng tiền mua bình máu

Bạn cũng nên lưu ý là mình sẽ đặt thứ tự ưu tiên xuyên suốt dự án, chứ không phải chỉ cho 1 tính năng.

4. Minh Họa

Một tấm hình đáng giá hơn 1000 lời nói. Các thành viên khác trong team sẽ thở phào nhẹ nhõm hơn rất nhiều nếu GDD có những hình minh họa và tham khảo như:

• Screenshot của các game khác có chức năng tương tự
• Biểu đồ, flow
• Các text mẫu

Lưu ý: Các hình minh họa nên đơn giản, rõ ràng và truyền đạt đúng mục đích. Bạn không cần phải vẽ nguyên một layout chỉ để minh họa. Hãy dùng wireframe làm điều đó và để việc thết kết UI cho UI designer. Đừng chỉ người khác biết họ phải làm công việc của họ như thế nào.

5. Thảo Luận và Tôn Trọng

Theo quan điểm của tôi, ai cũng có thể đề xuất ý tưởng, tính năng, thậm chí là thiết kế màn chơi. Tuy nhiên các ý kiến không nên mâu thuẫn lẫn nhau. Khi có bất đồng ý kiến cho một tính năng nào đó, các thành viên nên ngồi lại bàn bạc trên nguyên tác: Nhìn nhận dưới góc độ end user, là người chơi.

Sau khi bàn bạc thì sẽ thống nhất lại ý kiến cuối cùng, thời gian bàn bạc thống nhất không nên quá dài sẽ lãng phí thời gian và chậm tiến độ dự án.

6. Đầu Tư Vào Định Dạng Document

Nên sử dụng template của team

• Thay đổi font chữ cho phù hợp
• Ngắt bằng các đường kẻ ngang
• Sử dụng bullet list (như dòng tôi đang viết)
• Nhưng đừng lạm dụng format quá

7. Sử Dụng Thuật Ngữ Rõ Ràng Và Dễ Hiểu

• Đừng nghĩ rằng người đọc chắn chắn sẽ hiểu các thuật ngữ mà bạn dùng. Ví dụ: DPS, MMMORPG...
• Tránh dùng các thuật ngữ riêng của công ty bạn vì bạn có thể đưa GDD này cho người khác xem.
• Thuật ngữ mới thì phải được xử dụng nhất quán
• Có thể dùng chú thích

8. Rõ Ràng, Không Dư Thừa Và Phải Đúng Ngữ Pháp/Chính Tả

Như đã nói ở phần 2, bạn cần phải cẩn thận khi viết GDD để đảm bảo không bị trùng lắp thông tin, từ ngữ dễ hiểu và đúng ngữ pháp, chính tả. Các game designer của tôi vẫn rất thích xài tiếng Anh, dù công ty toàn người Việt Nam, để viết GĐ, một phần để không bị mai một tiếng Anh, phần nữa là nhiều từ ngữ rất khó dịch sang tiếng Việt.

Sử dụng các từ nhấn mạnh và tránh các từ như: có lẽ, có thể, hình như, chắc là... (ở tiếng Anh là các từ như may, maybe, could, might...)

Xem thêm: https://vncode.org/lap-trinh-game.html

Đăng bởi Kiều Tiên Tags: Cách Viết Một Game Design Document, Cách Viết Một Game Design Document Tốt, Game, Game Design Document, Game Design Document là gì, Game Design Document tốt, lập trình, lập trình game