Open Source Story: Agar.IO Clone

Những gì sắp kể ra ở đây là về hành trình của mình đến với thế giới open source, đây là một dự án làm cho vui nhưng rốt cuộc lại đóng vai trò khá quan trọng đối với con đường làm kĩ thuật của mình, nhất là khi nó cũng mở ra khá nhiều cơ hội lúc mình đặt chân đến Mỹ (khi có dịp mình sẽ nói về cái này sau). Từ đó đến giờ cũng khá lâu rồi, nên mình không thể nhớ hoàn toàn mọi chi tiết cũng như rất nhiều tư liệu trong quá trình viết game này đã bị mất, hôm nay quyết định viết ra chứ để lâu nữa có khi lại quên sạch luôn.

Vào khoảng nửa đầu năm 2015, thì trò chơi Agar.IO bắt đầu trở nên nổi tiếng và tình trạng chơi Agar trong giờ làm việc dần trở nên phổ biến, team mình lúc đó cũng không ngoại lệ

Thú thực thì công ty outsource, ở thời điểm mới thành lập, dự án cũng không có nhiều và gắt nên anh em cũng khá rảnh rỗi. Rảnh đến mức mình cài luôn Diablo III vào máy để chơi cơ mà.

Nhưng chơi game cả ngày thì cũng chán, thế là mình chuyển qua làm game ở trên công ty luôn (thời điểm đó mình vẫn còn hoạt động trong mảng game dev, đối với mình, làm game là đam mê, còn chuyện đi làm outsource cũng chỉ là vì cơm áo gạo tiền, quyết không bán mình đi làm game vì tiền, một phần khác thì vì cty outsource này trả lương cũng khá là cao).

Làm game gì bây giờ nhỉ? Lúc đó mình đang chơi 2 game là Diablo và Agar, làm Diablo thì đương nhiên là không làm nổi rồi, trình đếu đâu, thôi thì làm game Agar vậy.

Bản prototype đầu tiên

Tính từ lúc start đến lúc hoàn thành bản prototype chơi được đầu tiên là khoảng 1 buổi sáng, chắc tầm 3 tiếng, bản prototype khá đơn giản, hoàn toàn không có chế độ chơi online, nhưng các thành phần cơ bản của gameplay thì đều có đầy đủ:

• Cơ chế dịch chuyển/điều khiển, collision detection (nói cho sang, chứ chỉ là kiểm tra một điểm có nằm trong một đường tròn không thôi), food spawning, cơ chế ăn food, cơ chế growth khi ăn.
• Game được render trên một thẻ <canvas>, xóa toàn bộ màn hình sau mỗi lần di chuyển
• Toàn bộ diện tích game là diện tích của màn hình hiện tại, chưa có scrolling và viewport

Thực ra ban đầu mình không có ý định làm bản online, mà dự định sẽ viết thêm bot và chơi offline. Nhưng mấy anh bạn trong team sau khi thấy mình làm ra được thế thì muốn mình share ra để chơi chung, nên đành phải viết thêm chức năng online.

Bản prototype tiếp theo: Multiplayer

Việc add thêm chức năng multiplayer cho một bản prototype game đang chạy offline cũng có nhiều cái thú vị cần nói tới, vì ngay từ bước này mình mắc phải nhiều sai lầm nghiêm trọng nhưng bản thân mình lúc đó chưa hề hay biết.

Về cơ bản thì logic của game vẫn được xử lý hoàn toàn trên phía client (!!!), server gần như chỉ làm nhiệm vụ nhận và broadcast các sự kiện được truyền lên từ các client.

Ví dụ có 2 player cùng kết nối vào game, khi player A di chuyển đến một vị trí (x, y) thì nó sẽ gửi một tín hiệu đến server, bảo là "Ê, tao chạy đến (x, y) nè", server sẽ nhận tín hiệu đó và thông báo cho tất cả những player khác rằng "Chúng mài ơi, thằng A nó chạy đến (x, y) nhá".

Hoặc khi player B ăn được một miếng food, thì nó sẽ thông báo lên server là "Này, tao vừa ăn được một cục, kích thước của tao giờ +1 rồi nhé", với bản chất là một cái loa phóng thanh, server cũng sẽ hét lên rằng "Bớ làng nước ơi thằng B nó tăng thêm một đơn vị rồi kìa".

cho nên đến lúc trước khi đụng phải vấn đề này, mình cũng chỉ biết mang máng là cách làm của mình nó sai lè ra đấy, nhưng không hình dung được phải làm sao cho nó đúng. Rất may, nhờ việc khoe cái ngu của mình lên mạng, nên mình đã chữa được cái ngu đấy của bản thân.

Một lần khác, project lại nhận thêm một issue nữa để bàn về vấn đề tại sao không sử dụng một cấu trúc dữ liệu khác tốt hơn thay cho việc dùng mảng để quản lý player.

Nói về vấn đề này, có thể hiểu nôm na rằng, ban đầu, tất cả các player được lưu vô một mảng ở trên server, và khi có sự tương tác xảy ra giữa các user, server sẽ phải kiểm tra bằng cách duyệt hết toàn bộ mảng đó:

// khởi tạo mảng chứa các player
const players = []; // khi có player join vào game thì đưa vô mảng
server.on('playerJoined', (player) => players.push(player)); // kiểm tra va chạm giữa các players khác và player A
for (let player of players) { if (hitTest(playerA, player)) { // ... do something ... }
}

Tất nhiên làm như vậy thì rất ngu, vì server phải tốn công xử lý cho cả những user mà trên thực tế đang ở cách nhau rất xa (đầu screen và cuối screen chẳng hạn).

.

nên số lượng star cho dự án lại càng tăng lên từng ngày, từng ngày một.

Bên cạnh vai trò làm kẻ thay thế đại diện cho chính nghĩa trước thủ đoạn "xảo trá con buôn" của nhà phát hành game bản gốc, project của mình còn đóng vai trò là một nguồn tư liệu tham khảo cho nhiều developer khác khi họ có ý định bắt tay vào làm một game giống như Agar.IO - hẳn là bạn đang thắc mắc học hỏi được cái gì? mình cũng thắc mắc y thế khi thấy các repo khác mentioned tên mình và tên project của mình, chắc họ nhìn vào mình như là một case điển hình của code thối và kiến trúc tồi .

Về sau thì mình mới biết lý do project của mình còn sót lại là vì "người ta" không coi mình là đối thủ https://news.ycombinator.com/item?id=9976643. Thêm một bài học nữa, ở hiền thì gặp lành, chỉ cần mình đừng làm hại đến người ta, thì dù có tiền, người ta cũng sẽ để yên cho mình.

Vấn đề kiểm soát dự án

Tất nhiên không phải bài học miễn phí nào cũng dễ chịu, bên cạnh những người bạn vô danh sẵng lòng đem kiến thức của họ ra mở mang tầm mắt cho mình một cách nhiệt tình và nhã nhặn, có không ít những cá nhân thoải mái mạt sát, chửi đổng khi gặp những điều họ không vừa ý về project, hoặc lên các diễn đàn, website khác để nói xấu, cũng có vô số người tạo issue xong lặn đâu mất, 2, 3 năm sau mới vô comment lại

Tuy khó chịu thật, đôi lúc đọc issue xong chán chả buồn comment, nhưng nghĩ lại thì qua mỗi một trường hợp như thế, mình đều học được thêm về cách deal với từng loại người khác nhau trên internet, và quan trọng hơn nữa, đây là công sức và cống hiến của mình cho cộng đồng, ở đâu đó, dự án của mình đã ít nhiều tạo được một chút impact tốt đẹp (ví dụ như trường hợp anh thầy giáo Brazil ở trên), mình lấy đó làm động lực để tiếp tục fix bug

Nếu mà nói về một bài học đắt giá nhất, thì có lẽ đó là bài học về cách để kiểm soát dự án một cách hiệu quả.

Hồi đầu khi project vừa được ra mắt, mình rất là ba phải, ai tạo issue gì hay suggest cái gì mình cũng đều accept, gần như là merge hết không chừa một cái PR nào (thằng bé lần đầu được nhiều người tặng star và contribue cho dự án, nên gặp ai cho cái gì cũng hốt).

Và hậu quả thì chỉ sau vài tháng, toàn bộ codebase đã trở nên hoàn toàn lạ lẫm đối với mình , đến mức chính bản thân mình còn không hiểu được code nữa, còn thời gian dành cho việc fix bug do user report còn nhiều hơn cả thời gian làm việc ở công ty. Mặc dù đến lúc đó đã có thêm 2 bạn contributor khác cũng join vào để maintain dự án. Danh sách issue thì ngày một dài lên.

Nếu ở thời điểm đó mình biết cách nói không với các feature request, hay giữ thái độ cứng rắn hơn khi nhận được các pull request, biết cách sắp xếp và quản lý được roadmap cho dự án hiệu quả hơn thì có lẽ mình sẽ không bị quá tải và dẫn đến việc chán nản mà bỏ luôn dự án.

Tại sao lại bỏ?

Vì sao mình không làm tiếp dự án này?

Mặc dù những ai biết mình thì đều biết rằng mình nổi tiếng với việc làm giữa chừng là bỏ, nhưng nói thật là trong dự án này mình có lý do hẳn hoi đấy nhé.

Đầu tiên, phải nói đến đó là vision và motivation khi bắt đầu dự án. Mình hoàn toàn không có một định hướng gì rõ ràng cho dự án này, và mình bắt đầu làm nó chỉ vì rảnh quá không biết dùng thời gian để làm gì.

Và mình chỉ trở nên nghiêm túc với nó sau khi nhận được một vài sự chú ý nhất định.

Cho nên khi số lượng issue và feature request tăng lên, các vấn đề khó hơn xuất hiện càng nhiều, không còn quá quen thuộc với chính dự án do mình khởi xướng lên từ đầu, nên thời gian để fix bug cũng tăng lên, mức độ interest của mình đối với dự án càng lúc càng đi xuống.

Một lý do khác nữa, là mình không thực sự cảm thấy tự hào về dự án này, nhiều star để làm gì? ).

Dù sao thì đây cũng là một project thú vị, và hành trình đưa nó đến với cộng đồng cũng đã đem lại cho mình rất nhiều kinh nghiệm và bài học quý giá. Và tất nhiên đây không phải là trải nghiệm duy nhất của mình, còn rất nhiều những dự án khác nữa mà mình sẽ kể trong các bài viết tới, mong các bạn đón đọc.