Xây dựng AI cho game

Vấn đề

AI cho game đóng vai trò quan trọng trong quá trình phát triển game. Hầu như game nào cũng đều hỗ trợ chức năng cho người chơi với máy nên việc xây dựng AI là điều vô cùng cần thiết. Ngoài ra, việc xây dựng nhiều AI cho game sẽ

tăng khả năng chơi lại của game.

Các AI trong game của nhóm chúng em được xây dựng dưới dạng các plugin. Nhờ đó, chương trình có thể đọc cái AI từ các thư viện DLL mà không cần phải cài đặt trực tiếp trong chương trình.

Cơ chế plugin hỗ trợ hiệu quả cho việc nạp động các AI cho game mà không cần phải cài đặt trực tiếp vào mã nguồn chính của game. Người dùng muốn cài đặt AI cho game chỉ cần cài đặt interface IAIPlugins. Cấu trúc IAIPlugins :

public interface IAIPlugins {

string Name { get; } int Level { get; }

List<int> NextAIBattle(ref UnitOnBM unit, byte[] matrix, int numCellOnRow);

List<int> NextAIWorld(List<TeamOnWM> listTeam, int idParty, byte[] matrix, int numCellRow);

}

 Name : Tên của AI  Level : Cấp độ của AI

 NextAIBattle : hàm xử lý AI cho trận chiến.

 NextAIWorld : hàm xử lý AI khi di chuyển ngoài bản đồ thế giới của game.

Kết luận

Với cơ chế xây dựng AI bằng plugin, nhóm chúng em có thể cài đặt AI của game từ bên ngoài, hỗ trợ cài đặt thêm AI sau này, không cần cài đặt lại mã nguồn của game, không phải biên dịch lại game.

5.2. Giải pháp lưu trữ

5.2.1. Quản lý thông tin của game

Vấn đề

Game của chúng được xây dựng hướng đến việc hỗ trợ thay đổi logic của game mà không cần cài đặt lại. Vì vậy, thông tin logic của game cần phải độc lập với phần xử lý chính của game.

Giải pháp

Để hỗ trợ thay đổi logic game mà không cần cài đặt lại game, nhóm chúng em xây dựng mã nguồn trên các lớp cho các đối tượng game tổng quát. Đồng thời, thông tin logic được lưu trong tập tin XML và sẽ được nạp lúc chương trình thực thi.

Thông tin logic của game được lưu trong tập tin XML bao gồm các thông tin về công trình, công nghệ, thị trấn, phép thuật, quân lính, tài nguyên, thuộc tính nguyên tố. Chi tiết đặc tả nội dung XML của tập tin của nhóm sẽ được trình bày trong phụ lục A.

Bên cạnh các thông tin logic, game còn bao gồm nhiều vòng chơi, mỗi vòng có bản đồ, số lượng người chơi,... Để có thể xây dựng nhiều vòng chơi thuật tiện, nhóm chúng em cũng xây dựng tập tin XML để mô tả danh sách các vòng chơi có trong game. Cấu trúc chi tiết tập tin XML mô tả vòng chơi sẽ được nhóm chúng em trình bày trong phụ lục A.

Kết luận

Nhờ quản lý thông tin của game trên các tập tin XML, nhóm chúng em có thể thay đổi logic của game mà không cần cài đặt lại game. Nhờ đó, chúng em có thể xây dựng game với thông tin khác nhau dựa trên chương trình phát sinh mã nguồn cho game một cách dễ dàng.

5.2.2. Cơ chế quản lý hình ảnh

Vấn đề

Hệ thống các tài nguyên trong game tương đối lớn, không thể nạp cùng lúc tất cả vào hệ thống. Cũng không thể đọc lên từ tập tin mỗi khi cần sử dụng các tài nguyên hình ảnh vì sẽ làm chậm tốc độ xử lý. Chính vì vậy, một cơ chế quản lý hình ảnh cần phải được xây dựng để dung hòa giữa tốc độ xử lý và quản lý bộ nhớ của game.

Giải pháp

Chúng em xây dựng lớp ImageManager để quản lý các tài nguyên hình ảnh của game. Lớp này làm nhiệm vụ trả về các hình ảnh tương ứng khi có yêu cầu lấy hình ảnh từ các lớp xử lý game. Quá trình xử lý một yêu cầu lấy hình ảnh có thể xảy ra 2 trường hợp :

1. Hình ảnh được yêu cầu không được lưu sẵn trong lớp ImageManager. Khi đó, ImageManager sẽ đọc tập tin hình ảnh, trả về đồng thời nạp vào trong danh sách các hình ảnh chờ cho các yêu cầu tiếp theo. Tuy nhiên sau một khoảng thời gian hoặc khi có yêu cầu, các hình ảnh này sẽ bị xóa khỏi danh sách.

2. Hình ảnh được yêu cầu có trong danh sách các hình ảnh. Khi đó, ImageManager sẽ lấy hình ảnh trong danh sách được yêu cầu và trả về.

Kết luận

Với cơ chế quản lý tài nguyên hình ảnh, chúng em có thể tiết kiệm được bộ nhớ đồng thời không làm giảm tốc độ xử lý quá nhiều. Các hình ảnh được tạo ra, lưu trữ khi vào màn hình nào đó của game. Khi thoát ra khỏi màn hình đó, các hình ảnh sẽ được xóa khỏi hệ thống.

5.2.3. Cơ chế quản lý và sử dụng tài nguyên

Vấn đề

Một trong những đặc điểm của game nói chung cũng như game mobile mà chúng em thực hiện chính là xử lý chuyển động animation trên nền đồ họa 2 chiều. Do đó, mỗi đối tượng thể hiện sẽ cần phải có một dãy các ảnh để tạo thành chuyển động animation. Tuy nhiên, số lượng ảnh quá nhiều sẽ dẫn đến việc sử dụng quá nhiều bộ nhớ. Hơn nữa, chi phí cũng như thời gian xử lý cũng sẽ tăng lên đáng kể vì phải nạp nhiều hình vào bộ nhớ hiển thị ra màn hình. Chính vì vậy, làm sao để quản lý và sử dụng tài nguyên một cách hợp lý và hiệu quả là một trong những nguyên tắc lập trình quan trọng cho các ứng dụng mobile nói chung cũng như ứng dụng game nói riêng.

Giải pháp

Một trong những cách tiếp cận để quản lý tài nguyên xây dựng chuyển động animation là sử dụng nhiều ảnh, mỗi ảnh đại diện cho một khung hình của chuyển động. Tuy nhiên, cách quản lý này cũng chứa đựng 2 điểm yếu lớn chính là tốc độ xử lý chậm và tốn nhiều bộ nhớ. Mỗi ảnh bao gồm 2 phần chính là phần header và phần data. Phần header không lớn nhưng nếu ta phải nạp nhiều lần thì nó cũng sẽ tiêu tốn một phần bộ nhớ đáng kể. Hơn nữa, chi phí đọc nhiều tập tin hình ảnh vào bộ nhớ cũng là lý do khiến tốc độ xử lý bị hạn chế. Chính vì thế, giải pháp sử dụng nhiều tập tin hình ảnh để giải quyết vấn đề quản lý tài nguyên cho chuyển động animation là không thể, đặc biệt trên môi trường mobile.

Để khắc phục 2 nhược điểm chính của cách làm trên, chúng em quản lý các hình ảnh chuyển động animation của một đối tượng trong duy nhất một tập tin hình ảnh. Việc làm này đầu tiên sẽ giúp chúng ta hạn chế bớt phần bộ nhớ dư thừa cho phần header của các ảnh khác nhau. Đồng thời, cách làm này cũng giảm chi phí đọc nhiều tập tin hình ảnh cho một chuyển động, chính việc chỉ phải đọc một tập tin hình ảnh duy nhất cho một chuyển động sẽ giảm chi phí đáng kể cho hệ thống.

Tuy nhiên, điều này cũng dẫn dến một câu hỏi là tại sao ta không đưa các hình ảnh của tất cả các chuyển động vào duy nhất một tập tin hình ảnh? Câu trả lời chính là nhược điểm bộ nhớ ít ỏi của các thiết bị mobile. Bộ nhớ hạn chế của các thiết bị mobile không cho phép nạp tất cả các tài nguyên hình ảnh này vào bộ nhớ cùng một lúc. Do đó, cơ chế sử dụng tài nguyên sao cho hợp lý là một vấn đề quan trọng sẽ được trình bày ở phần sau.

Bên cạnh cơ chế quản lý các tài nguyên, việc sử dụng tài nguyên như thế nào cũng sẽ góp phần làm giảm bộ nhớ cần thiết cho hệ thống và vấn đề này càng đặc biệt quan trọng hơn với các hệ thống có bộ nhớ hạn chế như thiết bị mobile. Giải pháp ban đầu cũng như đơn giản nhất mà chúng em sử dụng là nạp sẵn các ảnh cần thiết vào lúc khởi động màn chơi. Tuy nhiên, cách làm đó vẫn làm quá tải bộ nhớ trên thiết bị mobile mặc dù kích thước các ảnh đã được thu nhỏ. Chính vì vậy, chúng em sử dụng giải pháp chỉ nạp những hình ảnh cần thiết tại những thời điểm cần thiết phải thể hiện nó lên màn hình và giải phóng chúng ngay khi không dùng đến nữa. Tuy cách làm này sẽ làm chậm tốc độ xử lý một phần nào đó nhưng đây là giải pháp bắt buộc để sử dụng tài nguyên trên một hệ thống có quá ít bộ nhớ như thiết bị mobile.

Kết luận

Bằng cách sử dụng cơ chế quản lý một tập tin hình ảnh đại diện cho một chuyển động animation của các đối tượng kết hợp với việc cấp phát và thu hồi bộ nhớ cho các tài nguyên một cách hợp lý ngay khi cần sử dụng chúng đã khiến cho game vận hành ổn định, tránh được các lỗi quá tải bộ nhớ thường gặp trên thiết bị mobile.

Chương 6 Kiến trúc game

 Nội dung của chương này sẽ trình bày kiến trúc của game chúng em xây dựng.

6.1. Kiến trúc xử lý chính của game

6.1.1. Sơ đồ kiến trúc

Hình 6-40-Kiến trúc tổng thể của hệ thống

6.1.2. Ý nghĩa các thành phần

STT Tên thành phần Ý nghĩa

1 Graphics Các lớp xử lý đồ họa cho game.

2 GameLibrary Các lớp xử lý game chính.

3 SpriteLib Các lớp xử lý Sprite cho game như lơp Sprite và lớp SpriteManager.

6.2. Kiến trúc xử lý đồ họa

6.2.1. Sơ đồ lớp

Sơ đồ lớp của các lớp xử lý đồ họa

Hình 6-41-Sơ đồ lớp xử lý đồ họa của game

Ý nghĩa các thành phần trong thư viện đồ họa

STT Tên thành phần Ý nghĩa

1 IGraphics Interface mô tả các chức năng chính của đối tượng đồ họa

2 IBitmap Interface mô tả các chức năng chính của lớp xử lý ảnh Bitmap

3 IFont Interface mô tả các chức năng chính của lớp xử lý Font

4 IImage Interface của Imaging API mô tả các chức năng để nạp các ảnh thuộc các loại định dạng khác Bitmap

Bảng 6-13-Ý nghĩa các interface trong thư viện đồ họa

STT Tên thành

1 GdiGraphics Lớp xử lý đồ họa cài đặt dựa trên GDI+

2 GdiBitmap Lớp xử lý ảnh Bitmap cài đặt interface IBitmap

3 GdiFont Lớp xử lý Font cài đặt interface IFont

4 Animation Lớp xử lý nạp các ảnh animation

Bảng 6-14-Ý nghĩa các lớp trong thư viện đồ họa

6.2.2. Cách hoạt động

Mô tả cách hoạt động của thư viện đồ họa trong thư viện đồ họa đã được đề cập trong phần 4.1

6.3. Kiến trúc quản lý ảnh

6.3.1. Sơ đồ lớp

Sơ đồ các lớp quản lý ảnh

Hình 6-42-Sơ đồ lớp quản lý lưu trữ

6.3.2. Ý nghĩa các thành phần

STT Tên thành

phần Ý nghĩa

1 ImageManager Lớp quản lý truy xuất các ảnh sử dụng trong game

2 Sprite Lớp quản lý ảnh animation

3 SpriteManager Lớp quản lý các Sprite

Bảng 6-15-Ý nghĩa các lớp quản lý hình ảnh

6.4. Kiến trúc xử lý logic

6.4.1. Sơ đồ kiến trúc

Hình 6-43-Kiến trúc xử lý logic

Ý nghĩa các thành phần

ST

T Tên thành phần Ý nghĩa

1 GamePanel Lớp quản lý xử lý chung của game. Làm nhiệm vụ chuyển đổi giữa các loại màn hình trong game và quản lý framework chính của game.

2 GameLogic Nhóm các lớp quản lý các thông tin về logic của game như quan hệ giữa các công trình, quân lính, phép thuật,... trong game.

3 GameQuest Lớp quản lý các vòng chơi trong game. Đọc nội dung từ tập tin XML.

4 GameAI Lớp xử lý AI trong game.

5 GameManager Các lớp xử lý cho các loại màn hình chính của game.

6.4.2. Cách hoạt động

6.4.2.1. Cơ chế hoạt động của framework game

Game hoạt động theo cơ chế gồm 4 bước : Update, Render, Draw, Sleep1. Toàn bộ cơ chế này của game được quản lý bởi lớp GamePanel. Lớp GamePanel sẽ nhận sự kiện phát sinh và truyền các sự kiện đó đến những lớp xử lý game tương ứng. Đồng thời, lớp GamePanel cũng sẽ chuyển đổi giữa các lớp xử lý 3 loại màn hình trong game.

Hình 6-44-Cơ chế hoạt động xử lý các loại vòng chơi chính của game

Cơ chế hoạt động của framework game bao gồm các bước sau:

- Bước 1: Khi game khởi tạo, lớp GamePanel sẽ đọc các thư viện AI của game vào chương trình dưới dạng các plugin.

- Bước 2: Sau khi nạp các plugin AI, lớp GamePanel sẽ lưu lại thành một danh sách các interface IAIPlugins. Các AI này sẽ cung cấp các chức năng xử lý thông tin.

- Bước 3: Lớp GamePanel cũng khởi tạo các lớp quản lý 3 loại màn hình của game là WorldManager, BattleManager và TownManager. Ba lớp xử lý này sẽ cung cấp các giá trị cho lớp GamePanel biết khi nào cần chuyển qua các màn hình khác. - Bước 4: Trong quá trình thực thi, các lớp quản lý game sẽ sử dụng các AI của game để xử lý lối chơi cho máy.

6.4.2.2. Cơ chế hoạt động các lớp quản lý logic game

Các lớp xử lý logic của game bao gồm 3 phần chính : GameType, GameInfo và GameInstance

 GameType : đây là các lớp quản lý các thông tin logic của game như các loại đối tượng chính trong game (công trình, phép thuật, công nghệ,...) Các lớp này được lưu trữ trong lớp GameLogic và được tạo ra dựa trên nội dung file xml mô tả logic của game.

 GameInfo : đây là các lớp mô tả thông tin của các đối tượng trong game. Các lớp này có thể là các đối tượng thông tin có trong logic của game. Các lớp này được tạo ra từ lớp GameType tương ứng. Ngoài ra còn có một nhóm các lớp quản lý các thông tin không có trong GameType như lớp quản lý các người chơi, nhóm quân lính.

 GameInstance : đây là các lớp xử lý các đối tượng thể hiện được lên màn hình của game như các quân lính chuyển động trên bản đồ, thị trấn hay trong các trận chiến, các công trình,...

Hình 6-45-Cơ chế xử lý thông tin trong game

Cơ chế xử lý thông tin trong game bao gồm các bước sau :

- Bước 1: Lớp GameLogic đọc thông tin logic của game từ tập tin Logic.xml.

- Bước 2: Lớp GameLogic tạo ra các lớp GameType tương ứng ứng với từng loại đối tượng thông tin cụ thể.

- Bước 3: Trong quá trình game thực thi, các lớp GameInfo (chức thông tin của các đối tượng hiện tại trong game như thông tin các quân lính hiện tại, anh hùng hiện tại... ) sẽ tạo nên các đối tượng thông tin trong game từ các lớp GameType. Ví dụ khi thuê một loại quân lính nào đó, lớp UnitInfo sẽ sử dụng lớp UnitType để khởi tạo các giá trị.

- Bước 4: Khi cần thể hiện ra màn hình các đối tượng thông tin của game, các lớp GameInstance sẽ được tạo ra từ các lớp GameInfo. Ví dụ khi chiến đấu, các lớp GameInfo được lưu trong thông tin của nhóm quân đó sẽ được tạo thành các đối tượng Unit để thể hiện quân lính chuyển động trên màn hình. Trong quá trình thực thi game, các lớp GameInstance sẽ cập nhật thông tin của game vào các lớp GameInfo tương ứng của nó.

6.4.2.3. Cơ chế xử lý vòng chơi trong game

Các vòng chơi trong game sẽ được xử lý dựa trên lớp GameQuest. Lớp này làm nhiệm vụ đọc cái vòng chơi từ tập tin Quests.xml.

Hình 6-46-Cơ chế xử lý các vòng chơi trong game

Cơ chế xử lý vòng chơi:

- Bước 1: Lớp GameQuest đọc thông tin các vòng chơi từ tập tin Quests.xml.

- Bước 5: Lớp GameQuest tạo ra các đối tượng QuestType từ nội dung của tập tin Quests.xml.

- Bước 6: Lớp GameLogic sử dụng lớp GameQuest để khởi tạo vòng chơi cần thiết.

6.4.3. Vấn đề về kỹ thuật lập trình

Vấn đề

Tối ưu hóa những giải thuật cho lập trình game trên mobile là điều tối quan trọng nhưng điều đó vẫn chưa đủ và vẫn chưa giúp game đạt được hiệu suất cao

nhất có thể. Điều này xuất phát từ kỹ thuật lập trình, cách sử dụng các phép toán, các câu lệnh,...

Trong lập trình, có những thao tác rất đơn giản và tốc độ của nó không quá