Điểm kỳ dị: Hợp lý hóa quá trình phát triển trò chơi với Khung phụ trợ phổ quát

Xin chào! Tôi là Andrey Makhorin, Nhà phát triển máy chủ tại Pixonic (MY.GAMES). Trong bài viết này, tôi sẽ chia sẻ cách tôi và nhóm của mình tạo ra một giải pháp phổ quát để phát triển phụ trợ. Bạn sẽ tìm hiểu về khái niệm này, kết quả của nó và cách hệ thống của chúng tôi, được gọi là Singularity, hoạt động trong các dự án trong thế giới thực. Tôi cũng sẽ đi sâu vào những thách thức mà chúng tôi phải đối mặt.

Lý lịch

Khi một studio trò chơi bắt đầu hoạt động, điều quan trọng là phải nhanh chóng hình thành và triển khai một ý tưởng hấp dẫn: hàng chục giả thuyết được thử nghiệm và trò chơi trải qua những thay đổi liên tục; các tính năng mới được thêm vào và các giải pháp không thành công được sửa đổi hoặc loại bỏ. Tuy nhiên, quá trình lặp lại nhanh chóng này, cùng với thời hạn chặt chẽ và thời gian lập kế hoạch ngắn, có thể dẫn đến sự tích tụ nợ kỹ thuật.

Với nợ kỹ thuật hiện có, việc sử dụng lại các giải pháp cũ có thể phức tạp vì nhiều vấn đề cần được giải quyết với chúng. Điều này rõ ràng là không tối ưu. Nhưng có một cách khác: một “khuôn khổ chung”. Bằng cách thiết kế các thành phần chung, có thể tái sử dụng (chẳng hạn như các thành phần bố cục, cửa sổ và thư viện triển khai tương tác mạng), các studio có thể giảm đáng kể thời gian và công sức cần thiết để phát triển các tính năng mới. Cách tiếp cận này không chỉ làm giảm số lượng mã mà nhà phát triển cần viết mà còn đảm bảo mã đã được kiểm tra, dẫn đến mất ít thời gian hơn cho việc bảo trì.

Chúng ta đã thảo luận về việc phát triển tính năng trong bối cảnh của một trò chơi, nhưng bây giờ chúng ta hãy xem xét tình huống từ một góc độ khác: đối với bất kỳ studio trò chơi nào, việc sử dụng lại các đoạn mã nhỏ trong một dự án có thể là một chiến lược hiệu quả để hợp lý hóa quá trình sản xuất, nhưng cuối cùng, chúng sẽ cần phải tạo một trò chơi đình đám mới. Về mặt lý thuyết, việc tái sử dụng các giải pháp từ một dự án hiện có có thể đẩy nhanh quá trình này, nhưng sẽ nảy sinh hai trở ngại đáng kể. Trước hết, các vấn đề nợ kỹ thuật tương tự cũng được áp dụng ở đây và thứ hai, mọi giải pháp cũ đều có thể được điều chỉnh cho phù hợp với yêu cầu cụ thể của trò chơi trước, khiến chúng không phù hợp với dự án mới.

Những vấn đề này càng phức tạp hơn: thiết kế cơ sở dữ liệu có thể không đáp ứng được yêu cầu của dự án mới, công nghệ có thể lỗi thời và nhóm mới có thể thiếu chuyên môn cần thiết.

Hơn nữa, hệ thống cốt lõi thường được thiết kế dành cho một thể loại hoặc trò chơi cụ thể, gây khó khăn cho việc thích ứng với một dự án mới.

Một lần nữa, đây là lúc một khuôn khổ phổ quát phát huy tác dụng và trong khi việc tạo ra các trò chơi hoàn toàn khác biệt với nhau có vẻ như là một thách thức không thể vượt qua, vẫn có những ví dụ về các nền tảng đã giải quyết thành công vấn đề này: PlayFab, Photon Engine và các nền tảng tương tự đã chứng minh khả năng giảm đáng kể thời gian phát triển, cho phép các nhà phát triển tập trung vào việc xây dựng trò chơi hơn là cơ sở hạ tầng.

Bây giờ, hãy nhảy vào câu chuyện của chúng tôi.

Sự cần thiết của tính đơn nhất

Đối với các trò chơi nhiều người chơi, một chương trình phụ trợ mạnh mẽ là điều cần thiết. Điển hình là trò chơi hàng đầu của chúng tôi, War Robots. Đây là một game bắn súng PvP trên thiết bị di động, đã tồn tại hơn 10 năm và tích hợp nhiều tính năng cần hỗ trợ phụ trợ. Và mặc dù mã máy chủ của chúng tôi được điều chỉnh cho phù hợp với đặc điểm cụ thể của dự án nhưng nó lại sử dụng các công nghệ đã lỗi thời.

Khi đến thời điểm phát triển một trò chơi mới, chúng tôi nhận ra rằng việc cố gắng sử dụng lại các thành phần máy chủ của War Robots sẽ gặp vấn đề. Mã này quá dành riêng cho dự án và đòi hỏi chuyên môn về công nghệ mà nhóm mới còn thiếu.

Chúng tôi cũng nhận ra rằng sự thành công của dự án mới không được đảm bảo và ngay cả khi nó thành công thì cuối cùng chúng tôi cũng cần phải tạo ra một trò chơi mới khác và chúng tôi sẽ phải đối mặt với cùng một vấn đề "trống trống". Để tránh điều này và thực hiện một số biện pháp kiểm chứng trong tương lai, chúng tôi quyết định xác định các thành phần thiết yếu cần thiết để phát triển trò chơi và sau đó tạo ra một khuôn khổ chung có thể được sử dụng cho tất cả các dự án trong tương lai.

Mục tiêu của chúng tôi là cung cấp cho các nhà phát triển một công cụ giúp họ không cần phải thiết kế nhiều lần kiến trúc phụ trợ, lược đồ cơ sở dữ liệu, giao thức tương tác và các công nghệ cụ thể. Chúng tôi muốn giải phóng mọi người khỏi gánh nặng triển khai ủy quyền, xử lý thanh toán và lưu trữ thông tin người dùng, cho phép họ tập trung vào các khía cạnh cốt lõi của trò chơi: lối chơi, thiết kế, logic kinh doanh, v.v.

Ngoài ra, chúng tôi không chỉ muốn tăng tốc độ phát triển với khung công tác mới mà còn cho phép các lập trình viên khách hàng viết logic phía máy chủ mà không cần có kiến thức sâu về mạng, DBMS hoặc cơ sở hạ tầng.

Ngoài ra, bằng cách tiêu chuẩn hóa một bộ dịch vụ, nhóm DevOps của chúng tôi sẽ có thể xử lý tất cả các dự án trò chơi theo cách tương tự, chỉ thay đổi địa chỉ IP. Điều này sẽ cho phép chúng tôi tạo các mẫu tập lệnh triển khai có thể sử dụng lại và bảng thông tin giám sát.

Trong suốt quá trình, chúng tôi đã đưa ra các quyết định về mặt kiến trúc có tính đến khả năng sử dụng lại phần phụ trợ trong các trò chơi trong tương lai. Cách tiếp cận này đảm bảo rằng khuôn khổ của chúng tôi sẽ linh hoạt, có thể mở rộng và thích ứng với các yêu cầu đa dạng của dự án.

(Cũng cần lưu ý rằng quá trình phát triển khung này không phải là một hòn đảo – nó được tạo ra song song với một dự án khác.)

Tạo nền tảng

Chúng tôi quyết định cung cấp cho Singularity một tập hợp các chức năng bất kể thể loại, bối cảnh hoặc lối chơi cốt lõi của trò chơi, bao gồm:

• Xác thực
• Lưu trữ dữ liệu người dùng
• Cài đặt trò chơi và phân tích số dư
• Xử lý thanh toán
• Phân phối thử nghiệm AB
• Tích hợp dịch vụ phân tích
• Bảng quản trị máy chủ

Các chức năng này là nền tảng cho bất kỳ dự án di động nhiều người dùng nào (ít nhất, chúng có liên quan đến các dự án được phát triển trong Pixonic).

Ngoài các chức năng cốt lõi này, Singularity được thiết kế để đáp ứng nhiều tính năng dành riêng cho dự án hơn gần với logic kinh doanh hơn. Những khả năng này được xây dựng bằng cách sử dụng tính trừu tượng, giúp chúng có thể tái sử dụng và mở rộng trên các dự án khác nhau.

Một số ví dụ bao gồm:

• Nhiệm vụ
• Ưu đãi
• Danh sách bạn bè
• Mai mối
• Bảng xếp hạng
• Trạng thái trực tuyến của người chơi
• Thông báo trong trò chơi

Về mặt kỹ thuật, nền tảng Singularity bao gồm bốn thành phần:

• SDK máy chủ: Đây là một bộ thư viện dựa trên đó các nhà lập trình trò chơi có thể phát triển máy chủ của họ.
• SDK khách hàng: Cũng là một bộ thư viện, nhưng để phát triển ứng dụng di động.
• Một tập hợp các vi dịch vụ được tạo sẵn: Đây là những máy chủ được tạo sẵn không cần sửa đổi. Trong số đó có máy chủ xác thực, máy chủ cân bằng và các máy chủ khác.
• Thư viện tiện ích mở rộng: Các thư viện này đã triển khai nhiều tính năng khác nhau, chẳng hạn như ưu đãi, nhiệm vụ, v.v. Người lập trình trò chơi có thể kích hoạt các tiện ích mở rộng này nếu trò chơi của họ yêu cầu.

Tiếp theo, chúng ta hãy kiểm tra từng thành phần này.

SDK máy chủ

Một số dịch vụ, như dịch vụ hồ sơ và mai mối, yêu cầu logic kinh doanh dành riêng cho trò chơi. Để đáp ứng điều này, chúng tôi đã thiết kế các dịch vụ này để phân phối dưới dạng thư viện. Sau đó, bằng cách xây dựng dựa trên các thư viện này, các nhà phát triển có thể tạo các ứng dụng kết hợp trình xử lý lệnh, logic mai mối và các thành phần dành riêng cho dự án khác.

Cách tiếp cận này tương tự như xây dựng một ứng dụng ASP.NET, trong đó khung cung cấp chức năng giao thức HTTP cấp thấp, trong khi đó, nhà phát triển có thể tập trung vào việc tạo bộ điều khiển và mô hình chứa logic nghiệp vụ.

Ví dụ: giả sử chúng tôi muốn thêm khả năng thay đổi tên người dùng trong trò chơi. Để làm điều này, các lập trình viên cần phải viết một lớp lệnh bao gồm tên người dùng mới và trình xử lý cho lệnh này.

Đây là một ví dụ về ChangeNameCommand:

 public class ChangeNameCommand : ICommand { public string Name { get; set; } }

Một ví dụ về trình xử lý lệnh này:

 class ChangeNameCommandHandler : ICommandHandler<ChangeNameCommand> { private IProfile Profile { get; } public ChangeNameCommandHandler(IProfile profile) { Profile = profile; } public void Handle(ICommandContext context, ChangeNameCommand command) { Profile.Name = command.Name; } }

Trong ví dụ này, trình xử lý phải được khởi tạo bằng cách triển khai IProfile, được xử lý tự động thông qua việc chèn phụ thuộc. Một số mô hình, chẳng hạn như IProfile, IWallet và IInventory, có sẵn để triển khai mà không cần thực hiện các bước bổ sung. Tuy nhiên, những mô hình này có thể không thuận tiện khi làm việc do tính chất trừu tượng của chúng, cung cấp dữ liệu và chấp nhận các đối số không phù hợp với nhu cầu cụ thể của dự án.

Để làm cho mọi việc dễ dàng hơn, các dự án có thể xác định các mô hình miền riêng của chúng, đăng ký chúng tương tự như các trình xử lý và đưa chúng vào các hàm tạo nếu cần. Cách tiếp cận này cho phép trải nghiệm phù hợp và thuận tiện hơn khi làm việc với dữ liệu.

Đây là một ví dụ về mô hình miền:

 public class WRProfile { public readonly IProfile Raw; public WRProfile(IProfile profile) { Raw = profile; } public int Level { get => Raw.Attributes["level"].AsInt(); set => Raw.Attributes["level"] = value; } }

Theo mặc định, hồ sơ người chơi không chứa thuộc tính Cấp độ. Tuy nhiên, bằng cách tạo một mô hình dành riêng cho dự án, loại thuộc tính này có thể được thêm vào và người ta có thể dễ dàng đọc hoặc thay đổi thông tin cấp độ người chơi trong trình xử lý lệnh.

Một ví dụ về trình xử lý lệnh sử dụng mô hình miền:

 class LevelUpCommandHandler : ICommandHandler<LevelUpCommand> { private WRProfile Profile { get; } public LevelUpCommandHandler(WRProfile profile) { Profile = profile; } public void Handle(ICommandContext context, LevelUpCommand command) { Profile.Level += 1; } }

Mã đó chứng minh rõ ràng rằng logic nghiệp vụ của một trò chơi cụ thể được cách ly khỏi các lớp lưu trữ dữ liệu hoặc vận chuyển cơ bản. Sự trừu tượng hóa này cho phép các lập trình viên tập trung vào cơ chế trò chơi cốt lõi mà không phải lo lắng về tính giao dịch, điều kiện cuộc đua hoặc các vấn đề phụ trợ phổ biến khác.

Hơn nữa, Singularity mang đến sự linh hoạt sâu rộng để nâng cao tính logic của trò chơi. Hồ sơ của người chơi là tập hợp các cặp "giá trị được nhập bằng khóa", cho phép các nhà thiết kế trò chơi dễ dàng thêm bất kỳ thuộc tính nào, giống như họ hình dung.

Ngoài hồ sơ, thực thể người chơi trong Singularity còn được tạo thành từ một số thành phần thiết yếu được thiết kế để duy trì tính linh hoạt. Đáng chú ý, điều này bao gồm một ví theo dõi số lượng của từng loại tiền trong đó cũng như kho liệt kê các vật phẩm của người chơi.

Điều thú vị là các vật phẩm trong Singularity là những thực thể trừu tượng tương tự như hồ sơ; mỗi mục có một mã định danh duy nhất và một tập hợp các cặp giá trị được nhập khóa. Vì vậy, một vật phẩm không nhất thiết phải là vật hữu hình như vũ khí, quần áo hoặc tài nguyên trong thế giới trò chơi. Thay vào đó, nó có thể đại diện cho bất kỳ mô tả chung nào được cấp riêng cho người chơi, chẳng hạn như nhiệm vụ hoặc ưu đãi. Trong phần sau, tôi sẽ trình bày chi tiết cách triển khai các khái niệm này trong một dự án trò chơi cụ thể.

Một điểm khác biệt chính trong Singularity là các mục lưu trữ tham chiếu đến mô tả chung trong bảng cân đối kế toán. Mặc dù mô tả này vẫn cố định nhưng các thuộc tính của từng mặt hàng được phát hành có thể thay đổi. Ví dụ: người chơi có thể được cấp khả năng thay đổi giao diện vũ khí.

Ngoài ra, chúng tôi có các tùy chọn mạnh mẽ để di chuyển dữ liệu người chơi. Trong phát triển chương trình phụ trợ truyền thống, lược đồ cơ sở dữ liệu thường được kết hợp chặt chẽ với logic nghiệp vụ và các thay đổi đối với thuộc tính của thực thể thường yêu cầu sửa đổi lược đồ trực tiếp.

Tuy nhiên, cách tiếp cận truyền thống không phù hợp với Singularity vì khuôn khổ thiếu nhận thức về các thuộc tính kinh doanh liên quan đến thực thể người chơi và nhóm phát triển trò chơi thiếu quyền truy cập trực tiếp vào cơ sở dữ liệu. Thay vào đó, quá trình di chuyển được thiết kế và đăng ký dưới dạng trình xử lý lệnh hoạt động mà không có tương tác trực tiếp với kho lưu trữ. Khi người chơi kết nối với máy chủ, dữ liệu của họ sẽ được lấy từ cơ sở dữ liệu. Nếu bất kỳ di chuyển nào được đăng ký trên máy chủ chưa được áp dụng cho trình phát này, chúng sẽ được thực thi và trạng thái cập nhật sẽ được lưu trở lại cơ sở dữ liệu.

Danh sách các lần di chuyển được áp dụng cũng được lưu trữ dưới dạng thuộc tính người chơi và cách tiếp cận này có một lợi thế đáng kể khác: nó cho phép các quá trình di chuyển được sắp xếp so le theo thời gian. Điều này cho phép chúng tôi tránh thời gian ngừng hoạt động và các vấn đề về hiệu suất mà những thay đổi dữ liệu lớn có thể gây ra, chẳng hạn như khi thêm thuộc tính mới vào tất cả bản ghi người chơi và đặt thuộc tính đó thành giá trị mặc định.

SDK khách hàng

Singularity cung cấp một giao diện đơn giản để tương tác phụ trợ, cho phép các nhóm dự án tập trung vào phát triển trò chơi mà không phải lo lắng về các vấn đề về giao thức hoặc công nghệ truyền thông mạng. (Điều đó có nghĩa là SDK cung cấp tính linh hoạt để ghi đè các phương thức tuần tự hóa mặc định cho các lệnh dành riêng cho dự án nếu cần.)

SDK cho phép tương tác trực tiếp với API nhưng cũng bao gồm một trình bao bọc tự động hóa các tác vụ thông thường. Ví dụ: việc thực thi một lệnh trên dịch vụ hồ sơ sẽ tạo ra một tập hợp các sự kiện cho biết những thay đổi trong hồ sơ của người chơi. Trình bao bọc áp dụng các sự kiện này cho trạng thái cục bộ, đảm bảo máy khách duy trì phiên bản hiện tại của hồ sơ.

Đây là một ví dụ về lệnh gọi:

 var result = _sandbox.ExecSync(new LevelUpCommand())

Dịch vụ vi mô làm sẵn

Hầu hết các dịch vụ trong Singularity được thiết kế linh hoạt và không yêu cầu tùy chỉnh cho các dự án cụ thể. Các dịch vụ này được phân phối dưới dạng ứng dụng dựng sẵn và có thể được sử dụng trên nhiều trò chơi khác nhau.

Bộ dịch vụ làm sẵn bao gồm:

• Một cổng cho các yêu cầu của khách hàng
• Dịch vụ xác thực
• Dịch vụ phân tích và lưu trữ các cài đặt và bảng cân đối
• Dịch vụ trạng thái trực tuyến
• Dịch vụ bạn bè
• Dịch vụ bảng xếp hạng

Một số dịch vụ là nền tảng cho nền tảng và phải được triển khai, chẳng hạn như dịch vụ xác thực và cổng. Những thứ khác là tùy chọn, như dịch vụ bạn bè và bảng xếp hạng, đồng thời có thể bị loại khỏi môi trường trò chơi không yêu cầu chúng.

Tôi sẽ đề cập đến các vấn đề liên quan đến việc quản lý một số lượng lớn dịch vụ sau, nhưng hiện tại, điều cần thiết là phải nhấn mạnh rằng các dịch vụ tùy chọn vẫn là tùy chọn. Khi số lượng dịch vụ tăng lên, độ phức tạp và ngưỡng tiếp nhận cho các dự án mới cũng tăng lên.

Thư viện tiện ích mở rộng

Mặc dù khung cốt lõi của Singularity khá có khả năng nhưng các tính năng quan trọng có thể được các nhóm dự án triển khai một cách độc lập mà không cần sửa đổi lõi. Khi chức năng được xác định là có khả năng mang lại lợi ích cho nhiều dự án, nó có thể được nhóm khung phát triển và phát hành dưới dạng thư viện tiện ích mở rộng riêng biệt. Sau đó, những thư viện này có thể được tích hợp và sử dụng các trình xử lý lệnh trong trò chơi.

Một số tính năng mẫu có thể áp dụng ở đây là nhiệm vụ và ưu đãi. Từ quan điểm của khung cốt lõi, những thực thể này chỉ đơn giản là những vật phẩm được giao cho người chơi. Tuy nhiên, thư viện tiện ích mở rộng có thể đưa các mục này vào các thuộc tính và hành vi cụ thể, biến chúng thành nhiệm vụ hoặc ưu đãi. Khả năng này cho phép sửa đổi linh hoạt các thuộc tính của vật phẩm, cho phép theo dõi tiến trình nhiệm vụ hoặc ghi lại ngày cuối cùng mà ưu đãi được đưa ra cho người chơi.

Kết quả cho đến nay

Singularity đã được triển khai thành công ở một trong những trò chơi mới nhất hiện có trên toàn cầu của chúng tôi, Little Big Robots, và điều này đã mang lại cho các nhà phát triển ứng dụng khách khả năng tự xử lý logic máy chủ. Ngoài ra, chúng tôi có thể tạo nguyên mẫu sử dụng chức năng hiện có mà không cần hỗ trợ trực tiếp từ nhóm nền tảng.

Tuy nhiên, giải pháp phổ quát này không phải là không có thách thức. Khi số lượng tính năng ngày càng mở rộng, độ phức tạp của việc tương tác với nền tảng cũng tăng theo. Singularity đã phát triển từ một công cụ đơn giản thành một hệ thống tinh vi, phức tạp—theo một số cách tương tự như quá trình chuyển đổi từ một chiếc điện thoại nút bấm cơ bản sang một chiếc điện thoại thông minh có đầy đủ tính năng.

Mặc dù Singularity đã giảm bớt nhu cầu của các nhà phát triển trong việc đi sâu vào sự phức tạp của cơ sở dữ liệu và giao tiếp mạng, nhưng nó cũng đã giới thiệu lộ trình học tập của riêng mình. Các nhà phát triển hiện cần hiểu rõ các sắc thái của Singularity, đây có thể là một sự thay đổi đáng kể.

Những thách thức mà mọi người từ nhà phát triển đến quản trị viên cơ sở hạ tầng phải đối mặt. Những chuyên gia này thường có chuyên môn sâu trong việc triển khai và duy trì các giải pháp nổi tiếng như Postgres và Kafka. Tuy nhiên, Singularity là một sản phẩm nội bộ, đòi hỏi họ phải có các kỹ năng mới: họ cần tìm hiểu sự phức tạp của các cụm trong Singularity, phân biệt giữa các dịch vụ bắt buộc và tùy chọn, đồng thời hiểu những số liệu nào là quan trọng để theo dõi.

Mặc dù đúng là trong một công ty, các nhà phát triển luôn có thể liên hệ với những người tạo ra nền tảng để xin một số lời khuyên, nhưng quá trình này chắc chắn cần có thời gian. Mục tiêu của chúng tôi là giảm thiểu rào cản gia nhập càng nhiều càng tốt. Để đạt được điều này cần có tài liệu toàn diện cho từng tính năng mới, điều này có thể làm chậm quá trình phát triển nhưng vẫn được coi là một khoản đầu tư cho sự thành công lâu dài của nền tảng. Hơn nữa, phạm vi kiểm thử tích hợp và đơn vị mạnh mẽ là điều cần thiết để đảm bảo độ tin cậy của hệ thống.

Singularity chủ yếu dựa vào thử nghiệm tự động vì thử nghiệm thủ công sẽ yêu cầu phát triển các phiên bản trò chơi riêng biệt, điều này không thực tế. Kiểm tra tự động có thể phát hiện được phần lớn - tức là 99% - lỗi. Tuy nhiên, luôn có một tỷ lệ nhỏ vấn đề chỉ trở nên rõ ràng trong quá trình thử nghiệm trò chơi cụ thể. Điều này có thể ảnh hưởng đến tiến độ phát hành vì nhóm Singularity và nhóm dự án thường làm việc không đồng bộ. Lỗi chặn có thể được tìm thấy trong mã được viết từ lâu và nhóm phát triển nền tảng có thể đang bận rộn với một nhiệm vụ quan trọng khác. (Thử thách này không phải chỉ có ở Singularity và cũng có thể xảy ra trong quá trình phát triển chương trình phụ trợ tùy chỉnh.)

Một thách thức quan trọng khác là quản lý các bản cập nhật trên tất cả các dự án sử dụng Singularity. Thông thường, có một dự án hàng đầu thúc đẩy sự phát triển của khung với dòng yêu cầu và cải tiến tính năng liên tục. Sự tương tác với nhóm của dự án này rất chặt chẽ; chúng tôi hiểu nhu cầu của họ và cách họ có thể tận dụng nền tảng của chúng tôi để giải quyết vấn đề của họ.

Trong khi một số dự án hàng đầu có liên quan chặt chẽ với nhóm khung, các trò chơi khác trong giai đoạn phát triển ban đầu thường hoạt động độc lập, chỉ dựa vào chức năng và tài liệu hiện có. Điều này đôi khi có thể dẫn đến các giải pháp dư thừa hoặc không tối ưu vì các nhà phát triển có thể hiểu sai tài liệu hoặc sử dụng sai các tính năng có sẵn. Để giảm thiểu điều này, điều quan trọng là phải tạo điều kiện thuận lợi cho việc chia sẻ kiến thức thông qua thuyết trình, gặp gỡ và trao đổi nhóm, mặc dù những sáng kiến như vậy đòi hỏi sự đầu tư đáng kể về thời gian.

Tương lai

Singularity đã thể hiện giá trị của mình trong các trò chơi của chúng tôi và sẵn sàng phát triển hơn nữa. Mặc dù chúng tôi có kế hoạch giới thiệu các tính năng mới nhưng trọng tâm chính của chúng tôi hiện nay là đảm bảo rằng những cải tiến này không làm phức tạp khả năng sử dụng nền tảng cho các nhóm dự án.

Bên cạnh đó, cần hạ thấp rào cản gia nhập, đơn giản hóa việc triển khai, tăng thêm tính linh hoạt về mặt phân tích, cho phép các dự án kết nối các giải pháp của họ. Đây là một thách thức đối với nhóm, nhưng chúng tôi tin tưởng và thấy trên thực tế rằng những nỗ lực đầu tư vào giải pháp của chúng tôi chắc chắn sẽ được đền đáp xứng đáng!