Vấn đề
Bên cạnh xử lý đồ họa, xử lý tương tác với game cũng là một trong những vấn đề rất quan trọng trong lập trình game. Đã là game thì người dùng phải thao tác được trên nó. Một game có khả năng xử lý đồ họa tốt nhưng khả năng tương tác với game không uyển chuyển và không kịp thời sẽ gây ra sự khó chịu cho người chơi.
Cơ chế chúng em xây dựng hiện tại đã thực hiện tốt việc thể hiện game nhưng làm sao để xây dựng cơ chế cho phép người dùng tương tác với game một cách dễ dàng, thuận tiện cũng là một việc làm vô cùng cần thiết.
Giải pháp
Những tương tác từ người dùng với game như các sự kiện nhấn phím, click chuột xảy ra hoàn toàn ngẫu nhiên. Vì thế, ta phải luôn kiểm tra để xử lý các sự kiện này trong suốt quá trình chạy game. Tuy nhiên, nếu thêm một bước xử lý sự kiện vào ngay trong cơ chế xử lý hiện thời của game thì khả năng đáp ứng các sự kiện sẽ bị chậm đi do mỗi chu kỳ chỉ xử lý sự kiện một lần. Bên cạnh đó, nếu ta
thêm nhiều bước xử lý sự kiện vào trong cơ chế xử lý game hiện thời thì thêm bao nhiêu bước là đủ để có thể bảo đảm game luôn đáp ứng được các sự kiện bất kỳ lúc nào người dùng tương tác với game? Chính vì lý do đó, chúng em xử lý sự kiện trên một tiến trình khác với tiến trình xử lý cơ chế hiện tại của game. Điều này có nghĩa là game sẽ được cài đặt chạy trên 2 tiến trình cùng lúc:
1. Một tiến trình chính xử lý cơ chế cập nhật và hiển thị hình ảnh của game. 2. Tiến trình còn lại đảm nhận công việc tiếp nhận và xử lý các sự kiện
tương tác từ người dùng.
Tuy nhiên, những tương tác của người dùng hầu hết đều tạo nên sự thay đổi trên màn hình hay nói cách khác những tương tác đó thường làm thay đổi các giá trị sử dụng để thể hiện lên màn hình. Vì vậy, điều này làm nảy sinh vấn đề là các sự kiện khi xảy ra có thể dẫn đến trường hợp 2 tiến trình cùng truy xuất vào một giá trị biến chung nào đó của game. Do đó, cần phải quan tâm đến vấn đề xử lý đồng bộ
nếu muốn kiểm soát các hoạt động của game một cách chính xác, hợp lý và không phát sinh lỗi.
Do cơ chế đồng bộ các tiến trình trên .NET Compact Framework được hỗ trợ khá hạn chế nên chúng em sử dụng cờ để đồng bộ hóa 2 tiến trình. Mỗi tiến trình sẽ có một cờ để báo hiệu tiến trình đó đã thực hiện xong các thao tác sử dụng biến, tài nguyên hay chưa, … Và tiến trình khác chỉ được truy cập vào biến hay tài nguyên đó khi tiến trình kia đã giải phóng.
Kết luận
Nhờ cơ chế sử dụng nhiều tiến trình và đồng bộ hóa dữ liệu, khả năng đáp ứng các tương tác của người dùng được thực thi tương đối nhanh chóng. Tuy nhiên, việc sử dụng nhiều tiến trình cũng dẫn đến việc cài đặt phải cẩn thận hơn rất nhiều và rất khó dò tìm các lỗi phát sinh.
5.1.5. Xử lý giao diện trên Windows Mobile
Một game không thể được xây dựng mà không có giao diện. Chính vì vậy, chúng em cần xây dựng những giải pháp hỗ trợ xử lý giao diện trong game.
Giải pháp
Những ai từng lập trình trên Windows Form đều đã từng làm quen với các control được xây dựng sẵn cũng như khái niệm về User Control để cho phép ta tự tạo ra các control theo mục đích riêng. Tuy nhiên, lập trình cho User Control trên môi trường Windows Mobile lại khiến chương trình xử lý chậm chạp và thời gian để nạp các User Control đó thường khá lâu. Điều này làm cho giải pháp sử dụng User Control trên Windows Mobile cho lập trình game trở nên khó khăn và gần như không thể thực hiện được.
Chính vì lý do đó, chúng em đã nghiên cứu mô hình các control trong Windows Form và tự xây dựng lại hệ thống control đơn giản nhằm đơn giản hóa việc xử lý giao diện cho game. Hệ thống control chúng em xây dựng với tên gọi là ImageControl chứa đựng đầy đủ những tính năng cần thiết để xử lý cho những control đơn giản trong lập trình game như cửa sổ (ImageForm), nút nhấn (ImageButton) hay control chứa danh sách các hình ảnh (ImageContainer). Với cơ chế xử lý event cho các sự kiện trong game như sự kiện click chuột, sự kiện chọn một hình ảnh trên ImageContainer, chúng em đã phần nào đơn giản hóa được quá trình xử lý giao diện cho game. Với những người lập trình quen thuộc với Windows Form, đây thật sự là một giải pháp giúp mã nguồn dễ hiểu và phân tách được các xử lý ra nhiều phần rõ ràng hơn.
Kết luận
Bằng cách xây dựng và sử dụng các control theo giống với mô hình các control trong Windows Form, chúng em đã làm đơn giản hóa việc cài đặt giao diện cho game. Tách biệt xử lý giao diện và xử lý logic của game rõ ràng hơn. Đặc biệt, điều này còn làm cho việc cài đặt giao diện trong game dễ hiểu, đơn giản hơn với những người quen thuộc với lập trình giao diện trên Windows Form.
5.1.6. Các đối tượng xử lý giao diện
Một trong những vấn đề khó khăn trong việc xây dựng các giao diện cho game như thiết lập các menu, nút nhấn,... gặp khó khăn chính là vì ta phải trực tiếp gắn các ảnh đại diện lên một vị trí nào đó trên màn hình và sau đó kiểm tra sự kiện click chuột sau mỗi lần click. Tuy đây là công việc bắt buộc nhưng nó lại khiến việc lập trình game trở nên rối rắm, khó phân biệt giữa phần xử lý giao diện và phần xử lý cho logic của game. Chính vì vậy, sử dụng các user control với các cơ chế event delegate và đóng gói các phần xử lý giao diện đó ra riêng sẽ giúp mã nguồn dễ hiểu hơn và dễ phân tách giữa phần xử lý giao diện và xử lý logic cho game.
Giải pháp
Các nhà phát triển các ứng dụng Windows Form hẳn sẽ cảm thấy quen thuộc với mô hình xử lý giao diện của Windows Form. Đây cũng là một trong những mô hình xử lý giao diện đơn giản và dễ dàng phát triển nhất. Vì vậy, chúng em tìm hiểu và xây dựng các lớp xử lý giao diện ImageControl dựa trên mô hình xử lý của Windows Form.
Hệ thống các ImageControl được xây dựng gồm 2 nhóm chính là các control không chứa control con (ImageButton, ImageLabel) và các control có chứa control con (ImageForm, ImageContainer).
5.1.6.1. ImageControl
Lớp ImageControl là lớp thuần ảo chứa các thuộc tính và chức năng cần thiết để xây dựng các control đơn giản. Ngoài ra, lớp này còn xử lý sự kiện Click, nhờ đó khi người dùng nhấn vào một control, sự kiện Click cho control đó sẽ được phát sinh.
Các lớp xử lý này còn có thể được ẩn đi hoặc hiện lại bằng các hàm Hide() và Show(). Nếu một control đang trong trạng thái ẩn thì nó sẽ không nhận được sự kiện cũng như hiển thị trên màn hình.
Hình 5-34-Lớp ImageControl 5.1.6.2. Nút nhấn và nhãn chuỗi
ImageButton và ImageLabel sử dụng để tạo các nút nhấn và nhãn chuỗi trên màn hình. Sự khác biệt giữa việc sử dụng chuỗi, hình ảnh thông thường và đối tượng ImageLabel, ImageButton nằm ở sự quản lý các sự kiện. Ta có thể dễ dàng
xử lý các sự kiện khi nút nhấn hay nhãn nào đó được nhấn khi sử dụng 2 lớp này mà không cần phải xử lý riêng bên ngoài.
5.1.6.3. Đóng gói nhiều control con
Hình 5-36-Lớp ImageForm
ImageForm cung cấp cho ta giải pháp để tạo các control chứa bên trong nó là các control khác.
Vị trí các control con sẽ được xác định tương đối so với control cha. Nhờ đó, ta có thể xác định vị trí của các control dựa trên control chứa nó mà không cần quan tâm vị trí của control cha.
Khi một sự kiện nhấn chuột được phát sinh, control cha sẽ xử lý sự kiện click chuột cho riêng nó sau đó chuyển giao sự kiện đến các control con của nó. Bên trong mỗi control sẽ tự động kiểm tra dựa trên tọa độ nhấn chuột và xác định control nào đã được nhấn. Nếu control được nhấn, sự kiện Click của nó sẽ được phát sinh và chuyển đến các hàm xử lý sự kiện Click.
5.1.6.4. Thể hiện danh sách các hình ảnh
Lớp ImageContainer kế thừa từ ImageForm nên nó cũng có khả năng chứa các control con bên trong. Tuy nhiên, mục đích chính của lớp này là nhằm thể hiện danh sách các hình ảnh. Ngoài ra, phải kiểm tra được khi nào các hình ảnh này được nhấn. Chính vì vậy, lớp này chỉ chứa các đối tượng ImageButton. ImageContainer nạp danh sách các hình ảnh thông qua danh sách các IImageChild. Lớp này sử dụng để thể hiện danh sách các công trình, quân lính, công nghệ,...
Chính vì vậy, nhằm tạo sự thuận tiện trong quá trình nạp danh sách các hình ảnh, chúng em sử dụng interface IImageChild. Các đối tượng nào muốn thể hiện danh sách hình ảnh trong ImageContainer cần kế thừa interface IImageChild. Hàm LoadListGameObject() dùng để nạp danh sách các hình ảnh. Hàm LoadListGameObject() :
void LoadListGameObject(IImageChild[] objs, IGraphics g)
Hình 5-37-Lớp ImageContainer và interface IImageChild
Kết luận
Với hệ thống control chúng em xây dựng, việc xây dựng giao diện cho game trở nên đơn giản hơn. Dễ dàng tách biệt xử lý logic và xử lý giao diện.
5.1.7. Cơ chế xử lý luồng sự kiện
Vấn đề
Thế mạnh của các lớp xử lý giao diện là đóng gói lại các xử lý giao diện và tách biệt xử lý giao diện với xử lý logic. Qua đó, giúp người lập trình chỉ tập trung vào xử lý logic của game mà không cần quan tâm quá nhiều đến lập trình xử lý giao diện. Nhằm tách biệt mã nguồn xử lý các sự kiện cho giao diện với xử lý logic cho game một cách rõ ràng, các lớp thể hiện giao diện cần có cơ chế xử lý sự kiện phù hợp.
Các sự kiện trong game thu được nhờ bắt sự kiện trên đối tượng Form của Windows Form. Sau khi bắt được các sự kiện, lớp Form sẽ truyền sự kiện xuống phần quản lý game Game Panel. Phần quản lý game lại bắt đầu chuyển xử lý xuống cho các đối tượng xử lý giao diện. Nếu một đối xử lý giao diện có chứa các đối tượng giao diện con thì nó sẽ chuyển các sự kiện này xuống cho đối tượng con.
Sự kiện được xử lý chính trong game là sự kiện Click.
Hình 5-38-Qui trình xử lý luồng sự kiện
Kết luận
Với giải pháp xử lý sự kiện của các lớp thể hiện giao diện, công việc xử lý giao diện và xử lý logic cho game được tách ra, góp phần làm đơn giản hóa cũng như rõ ràng hơn trong lập trình game.
Hình 5-39-Kiến trúc của giải thuật A* áp dụng cho game
5.1.8. 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ì