Các bước thực hiện để có thể build game cho QA thông qua hệ thống Tool Game

Bước 1: Switch git branch
Sử dụng branch feature/build_qa để có thể build game

Bước 2: Merger code
Merger code của nhánh đang dev game vào nhánh feature/build_qa sau đó commit lên.

Bước 3: Setup thêm game vào tool manager
Setup như hướng dẫn tại đây

Bước 4: Commit lên branch feature/build_qa

Bước 5: Build bằng CI/CD
Sử dụng CI/CD để hoàn thành build

5.1 Yêu cầu thêm vào nhóm telegram CI_Monkey Stories để nhận thông báo build:

5.2 Đăng nhập link được ghim trên nhóm để vào giao diện CI/CD build android hoặc ios

5.3 Chọn vào thư mục Monkey_Stories_2 để ra khu vực build cho MS 2.0

5.4 Chọn Build

5.5 Chọn Build with parammeters

5.6 Lựa chọn thông số

• PLATFORM : build cho android / ios
• FLUTTER_BRANCH : tên branch của vỏ app (hỏi dev app để biết đúng nhánh)
• UNITY_BRANCH : điền feature/build_qa

5.7 Bấm Build

Bước 6: Theo dõi thông báo và trạng thái build từ nhóm telegram CI_Monkey Stories

Mục tiêu

Thống nhất về cùng kiểu endgame
Tiết kiệm thời gian phát triển endgame trong quá trình dev game

Tổ chức

updating...

Cách dùng

Kéo prefabs endgame trong Base lên Hierarchy như hình

Set Active false trên Hierarchy

Reference vào đối tượng cần dùng

Chú ý sử dụng tính abstraction

Call các method tương ứng

Chú ý bỏ âm thanh yeah kết thúc của game nếu có (Sẽ có yêu cầu từ GD)

Các phương thức hỗ trợ

• Scale: Thay đổi kích thước của hướng dẫn.
• SetActive: Ẩn hiện endgame.
• SetPosition: Vị trí của end game nhưng thường sử dụng (0,0).
• SetParent: Ít khi sử dụng.
• PlayAnimation: Phát Anim, chú ý đến các action end game .

Xin hãy đọc thêm ở summary của từng method

Lý do

Hiện tại trên branch develop tên thư mục được đặt tên là 4. Game, đây là sai so với quy chuẩn, cần đặt lại tên 4.Game

Quy trình

B1. Xác định game đang không ở trên branch develop

Kiểm tra các game trên branch của mình ở thư mục 4. Game

B2. Di chuyển game

Các game được xác định ở trên sẽ được kéo ra thư mục Assets

B3. Commit code lên branch hiện tại

B4. Merger branch develop về branch hiện tại

B5. Kéo lại code vào thư mục 4.Game đã được sửa lại

Mục tiêu

Lợi ích của Pool chúng ta xem tại đây

Cách sử dụng

Bài toán

Trong game đang có một object không biết số lượng cụ thể cần bao nhiêu và object đó có thể sử dụng đi sử dụng lại được.

Ví dụ

Game "xây cầu", mỗi lần click vào đáp án đúng thì có "hiệu ứng pháo hoa", nếu người dùng click spam thì pháo hoa sẽ nhảy liên tục nên số lượng pháo hoa không biết trước được và sau khi pháo hoa phát xong thì có thể để lại để lần sau phát

Cách triển khai trong code

Bước 1

• Pool được thiết kế dạng Generics (Pool<T>) nên cần khởi tạo loại cần Pool
• Cần prefab của loại T để init ở bước 2

Bước 2

Init Pool với các tham số prefab loại T,

Bước 3

Lấy object loại T trong Pool để sử dụng

Bước 4

Trả object T về lại cho pool khi không còn sử dụng

1. Phương án giao tiếp

Về cơ bản sự giao tiếp chỉ là app và unity send data cho nhau thông qua hệ thống giao tiếp.

2. Phương án kỹ thuật

Updating...

3. Model data giao tiếp

3.1 Model chung

{
  "id": "string",
  "type": "string",
  "response": "boolean",
  "payload": {
  }
}

3.2 Ví dụ các trường hợp cụ thể

3.3.1 App request Unity mở một scene cụ thể và không cần trả về kết quả

{
  "id": "123",
  "type": "open_unity",
  "response": false,
  "payload": {
    "action":"open",
    "destination": "map_lesson"
  }
}

destination: "map_lesson" : là scene / layout muốn hiển thị. Giá trị này cần được thống nhất giữa app và unity

3.3.2 App request Unity lấy dữ liệu của coin và cần trả về kết quả

Request từ App sang Unity

{
  "id": "4444",
  "type": "coin",
  "response": true,
  "payload": {
    "action": "get"
  }
}

Response từ Unity trả về cho App, về bản chất là Unity gửi cho App bộ data có id và type cùng loại với Request ở trên

{
  "id": "4444",
  "type": "coin",
  "response": false,
  "payload": {
    "success": true,
    "message": "Get coin success",
    "current_balance": 1000
  }
}

4. Model giao tiếp trong MS 2.0

Phần payload là phần động giữa các lần giao tiếp, cần phải thống nhất giữa App và Unity
Updating...

Mục tiêu

Thống nhất về cách sử dụng Debug
Dễ dàng quản lý debug cũng như tối ưu performance của ứng dụng

Tổ chức

Class DebugMonkey

Giải thích tăng hiệu năng

1. Vấn Đề Hiệu Năng Khi Debug

Trong Unity, việc sử dụng Debug.Log, Debug.LogWarning, và Debug.LogError có thể gây ảnh hưởng đến hiệu suất của game, đặc biệt là trên mobile hoặc build final. Nguyên nhân chính:

• Chuỗi string được tạo dù log có hiển thị hay không

Ví dụ khi debug theo cách truyền thống:
Debug.Log("Player position: " + player.transform.position.ToString());
Dù bạn có tắt debug khi build, nhưng chuỗi "Player position: ..." vẫn được tạo, gây tốn bộ nhớ và CPU không cần thiết.

2. Giải Pháp DebugMonkey

Class DebugMonkey sử dụng biểu thức lambda (Func<string>) và điều kiện Conditional để tối ưu hiệu năng debug, ví dụ việc sử dụng DebugMonkey
DebugMonkey.Log(() => "Player position: " + player.transform.position);
Nếu điều kiện hiển thị Debug bị tắt , hàm Log() bị loại bỏ hoàn toàn khỏi build (tương đương với việc code không tồn tại)

Cách dùng

Sử dụng DebugMonkey với các phương thức tương tự Debug của Unity, lưu ý là sử dụng lamda cho nội dung debug như ảnh trên.

Mục tiêu

Thống nhất về cùng kiểu guilding
Tiết kiệm thời gian phát triển guiding trong quá trình dev game

Tổ chức

updating...

Cách dùng

Kéo prefabs guiding trong Base lên Hierarchy như hình

Reference vào đối tượng cần dùng

Call các method tương ứng

Các phương thức hỗ trợ

• Scale: Thay đổi kích thước của hướng dẫn.
• Tap: Mô phỏng thao tác chạm vào một vị trí.
• HideTap: Ẩn hiệu ứng chạm.
• Drag: Mô phỏng thao tác kéo từ một vị trí đến vị trí khác trong một khoảng thời gian.

Xin hãy đọc thêm ở summary của từng method

Mục tiêu

Tránh việc coupling giữa game và hệ thống âm thanh bên ngoài
Thuận lợi cho việc implement SoundManager ở các project khác nhau

Tổ chức

updating...

Cách dùng

SoundListenner

Mỗi 1 game cần có 1 object chứa class SoundListenner trên Hierarchy, đối tượng này đã thiết kế sẵn method và phương thức lắng nghe các sự kiện phát âm thanh.

Sử dụng Observer qua kênh SoundChannel để phát âm thanh mong muốn

Cách gán SoundListenner lên Hierarchy

Class SoundListenner đã có sẵn trong project.
Kéo class SoundListenner vào 1 object tồn tại trên Hierarch như hình dưới đây

SoundManager

Mỗi 1 game cần có 1 object chứa class SoundManager Fake trên Hierarchy để thực thi các method phát âm thanh

SoundManager Fake có ý nghĩa là sau này trong game sẽ không thực sự có vì sau này SoundManager sẽ dùng chung của cả project

Cách get prefabs SoundManager

SoundManager đã được tổ chức thành prefabs, chỉ cần kéo lên Hierarchy của game để sử dụng như hình dưới đây

Mục đích

Nhằm tránh tình trạng không thống nhất và phân mảnh các tài nguyên dùng chung, sẽ có một số tài nguyên được quy định dùng chung tại tài liệu này

Đặc điểm

Thông thường các tài nguyên dùng chung sẽ nằm trong các mục được phân quyền cao, khi có vấn đề về việc thay đổi, bổ sung tài nguyên dùng chung sẽ phải làm theo quy trình tại đây (Xem mục Phân quyền và Quy trình đề xuất sửa đổi khi không được phân quyền )

Danh sách tài nguyên

1. Core

Sẽ bổ sung bài viết về hệ thống này sau

2. Base

1. Font
Hiện tại sử dụng 2 font là Nunito-Bold và Nunito-SemiBold, các game sử dụng chung font này, không tự tạo font mới

3.ThirdPatty

1. Demigiant
Sử dụng cho Tween Tài liệu tại đây
2. Spine
Sử dụng cho animation Tài liệu tại đây
3. TextMesh Pro
Sử dụng TextMesh Pro Tài liệu tại đây

Cập nhật ngày 13/3/2025

Mã nguồn

1. Source
https://github.com/eduhub123/monkey_story_2
2. Flow
Xem tại đây

Tổ chức chung

1. Core
Bộ phận chung của các project khác nhau (MS, MJ...)

2. Base
Phần base của từng project, mỗi project khác nhau

3. ThridPatty
Các library bên thứ ba

4. Game MS
Nơi chứa các game của project

Phân quyền

1. Core, 2. Base, 3. ThridPatty
Chỉ Leader hoặc thành viên được leader ủy quyền mới được thay đổi nội dung của các thư mục này

4. Game MS
Tất cả các thành viên code game sẽ được đặt code ở đây theo git flow tại đây

Quy trình đề xuất sửa đổi khi không được phân quyền

Bước 1. Thành viên trao đổi vấn đề với leader hoặc thành viên được leader ủy quyền để được thay đổi khu vực không có quyền thay đổi

Bước 2. Leader hoặc thành viên được ủy quyền review và thay đổi nếu có theo git flow tại đây

Bước 3. Thông báo đến thành viên yêu cầu thay đổi hoặc thông báo vào nhóm khi đã có kết quả (chấp nhận hay không chấp nhận đều thông báo)