Steamworks SDK 1.65: Indie dev cần đổi gì cho Steam Hardware, Proton, Workshop và server browser?

Steamworks SDK 1.65 không phải một bản cập nhật buộc mọi studio phải nâng ngay, nhưng đây là loại release đáng để indie developer đọc kỹ trước khi bước vào giai đoạn tối ưu PC, Steam Deck/Linux, Steam Input, Workshop hoặc multiplayer server browser. Valve phát hành SDK 1.65 ngày 23/07/2026, sau đó phát hành lại binary Win32 ngày 27/07 và sửa một lỗi liên quan ISteamApps::GetBetaInfo ngày 31/07. Điểm quan trọng nhất không nằm ở một API đơn lẻ, mà ở hướng thiết kế mới: code tích hợp Steam nên bớt phụ thuộc vào một thiết bị cụ thể và chuyển sang nhận diện năng lực phần cứng, môi trường Proton, cấu hình mặc định và dữ liệu vận hành theo cách tổng quát hơn.

Với một game indie chỉ dùng achievement và overlay, bản cập nhật này có thể chưa tạo ra khác biệt trực tiếp. Nhưng nếu project có launcher riêng, graphics preset, Steam Deck support, Linux/Proton QA, controller glyph, Workshop phụ thuộc lẫn nhau hoặc dedicated server, 1.65 chạm đúng các điểm dễ tạo technical debt khi game sống lâu hơn dự kiến.

Steamworks SDK 1.65 thực sự thay đổi điều gì?

Theo thông báo chính thức của Steamworks Development, việc cập nhật sang SDK 1.65 được khuyến nghị nhưng không bắt buộc; các phiên bản SDK cũ vẫn tiếp tục hoạt động. Đây là dữ kiện quan trọng vì nó cho phép team chọn thời điểm migration dựa trên vòng đời project thay vì nâng cấp chỉ vì số version mới.

Valve đồng thời ghi rõ hai lần re-release sau bản đầu: ngày 27/07 rebuild lại Win32 steam_api binaries, và ngày 31/07 sửa ISteamApps::GetBetaInfo để điền đúng tham số output punTimestampUpdated. Nếu team đã tải SDK 1.65 ngay trong ngày đầu, nên kiểm tra lại package hiện có thay vì mặc định rằng binary đang dùng chính là revision mới nhất của 1.65.

Từ “Steam Deck” sang “Steam Hardware”: thay đổi nhỏ nhưng ảnh hưởng kiến trúc

Một thay đổi đáng chú ý là Valve loại bỏ ISteamUtils::IsRunningOnSteamDeck(). Thay vào đó, SDK có ISteamUtils::IsRunningOnSteamHardware(), trả về ESteamHardwareType. Valve mô tả API này phù hợp cho analytics, support và diagnostic; còn khi cần quyết định chức năng trong runtime, developer nên dùng các API chuyên biệt theo tính năng.

Về mặt kiến trúc, đây là tín hiệu khá rõ: đừng viết toàn bộ logic theo kiểu if Steam Deck thì A, còn desktop thì B. Một game sống vài năm có thể gặp nhiều form factor Steam khác nhau, và logic gắn cứng vào tên thiết bị sẽ nhanh chóng trở thành nợ kỹ thuật. Cách an toàn hơn là chia hệ thống thành các capability: input, display, performance profile, VR, Big Picture, compatibility layer và hardware family.

Valve còn thêm GetSteamHardwareDefaultConfig(), cho phép game lấy cấu hình mặc định dành cho một loại Steam hardware mà developer đã tune trước đó. Điểm đáng chú ý là Valve nói cấu hình mặc định cho phần cứng Steam trong tương lai có thể được thay đổi mà không cần game phải recompile. Với indie team, đây là cơ hội tách “preset khởi đầu” khỏi code build.

Một cách tổ chức hợp lý cho project

Thay vì đặt hàng chục nhánh kiểm tra thiết bị trong menu graphics, nên có một lớp PlatformProfile hoặc tương đương. Lớp này nhận thông tin từ Steamworks, engine và hệ điều hành, sau đó xuất ra preset khởi đầu. Người chơi vẫn phải có quyền thay đổi setting, vì hardware detection không thay thế benchmark thật hoặc sở thích cá nhân.

Đây là nhận định biên tập dựa trên hướng API mới, không phải yêu cầu bắt buộc của Valve. Nhưng nó giúp project tránh trường hợp mỗi thiết bị mới lại kéo theo một chuỗi if/else khó kiểm thử.

IsRunningUnderProton: Linux QA không còn phải đoán

SDK 1.65 thêm ISteamUtils::IsRunningUnderProton() để game biết nó đang chạy dưới lớp tương thích Proton trên Linux. Với team chỉ phát hành Windows build nhưng vẫn muốn hỗ trợ Steam Deck/Linux thông qua Proton, API này hữu ích cho diagnostic và support.

Điều quan trọng là không nên dùng Proton detection làm lý do để vô hiệu hóa hàng loạt tính năng một cách mặc định. Nếu game chạy tốt, người dùng không cần bị đẩy sang trải nghiệm thấp hơn chỉ vì compatibility layer được phát hiện. Giá trị thực tế nằm ở logging, crash report segmentation, workaround có phạm vi hẹp và QA.

Ví dụ hợp lý là khi một middleware hoặc video codec có lỗi đã biết dưới Proton, team có thể ghi nhận môi trường chính xác trong telemetry và áp dụng workaround đúng module. Ví dụ không hợp lý là tự động giảm chất lượng đồ họa chỉ vì IsRunningUnderProton() trả về true.

Game có thể báo performance setting và render resolution cho Steam

Trong ISteamApps, Valve bổ sung SetGamePerformanceSetting() và SetGameRenderResolution(). Theo release notes, game có thể báo cho Steam server mức performance setting tương đối và độ phân giải render đang được dùng. Dữ liệu này có thể được kết hợp với framerate ẩn danh nếu người dùng đã opt-in chia sẻ.

Đây không phải API “tự tối ưu FPS” và cũng không có nghĩa Steam sẽ tự chỉnh settings cho game. Giá trị của nó nằm ở việc hệ sinh thái có thêm dữ liệu để hiểu một title đang chạy ở cấu hình nào. Indie developer không nên quảng bá tính năng này như một hệ thống benchmark tự động nếu chưa xây thêm logic riêng.

Nếu project đã có preset Low/Medium/High/Ultra, việc map chúng sang performance setting tương đối sẽ đơn giản hơn so với game có hàng chục slider độc lập. Team nên xác định một quy ước nội bộ rõ ràng, tránh báo “High” trong khi người chơi đang dùng render scale thấp hoặc một preset tùy chỉnh cực nặng.

Workshop và UGC: có thêm cách nhìn vào dependency graph

SDK 1.65 bổ sung lựa chọn query mới cho ISteamUGC. Một query có thể xếp item theo số lượng parent item phụ thuộc vào nó, và một query khác theo số collection chứa item đó. Với game có Workshop phức tạp, đây là dữ liệu hữu ích hơn một danh sách mod phẳng.

Trong thực tế, Workshop lớn thường phát triển thành một dependency graph: framework mod, shared library, collection, map pack và asset pack có quan hệ phụ thuộc. Khi một item nền tảng bị hỏng hoặc bị xóa, ảnh hưởng có thể lan sang rất nhiều nội dung khác. Khả năng truy vấn theo số parent hoặc collection giúp team nhận diện item có vai trò hạ tầng mạnh hơn.

Điều này không tự giải quyết dependency management. Developer vẫn cần versioning, validation, fallback và UI thông báo rõ khi dependency thiếu. Nhưng với game mod-heavy, nó có thể giúp xây dashboard nội bộ hoặc công cụ moderation thông minh hơn.

Steam Input mở rộng action origin cho phần cứng mới

Release notes của 1.65 bổ sung action origin enum cho Switch 2, Steam Controller và Steam Frame Controller. Nếu game dùng Steam Input để hiển thị glyph theo controller thực tế, đây là phần cần kiểm tra sớm.

Một lỗi UX phổ biến ở game indie là input vẫn hoạt động nhưng prompt hiển thị sai: người chơi bấm một nút, UI lại hiện glyph của Xbox hoặc keyboard. Về mặt QA, controller support không nên dừng ở “nhân vật có di chuyển được không”; cần test cả navigation focus, remapping, glyph swapping, hot-plug và chuyển input giữa chuột/bàn phím với controller.

Nếu project có một lớp abstraction cho input icon thì migration thường nhẹ. Nếu glyph được hard-code trực tiếp trong từng widget, hỗ trợ thêm hardware origin có thể làm lộ ra technical debt đã tồn tại từ trước.

Server browser có thêm tín hiệu từ bạn bè

Trong ISteamMatchmakingServers, SDK thêm ServerFriends() để lấy danh sách bạn bè đã chơi gần đây trên một server cụ thể, cùng filter popularamongfriends để truy xuất server thường được bạn bè của người dùng chơi.

Với multiplayer indie, đây là thay đổi đáng chú ý vì server discovery không chỉ là vấn đề ping và số người online. Một server có bạn bè đang chơi hoặc từng chơi có thể tạo động lực tham gia mạnh hơn một server đứng đầu danh sách nhưng hoàn toàn xa lạ.

Tuy nhiên, team nên xem đây là một tín hiệu ranking bổ sung, không phải tiêu chí duy nhất. Ping, region, anti-cheat policy, ruleset, capacity và phiên bản server vẫn cần được ưu tiên tùy thiết kế game.

Indie team có cần nâng ngay lên SDK 1.65 không?

Nếu game chỉ sử dụng achievement, overlay và cloud save ổn định, không có lý do kỹ thuật bắt buộc phải đổi build ngay lập tức. Valve đã nói rõ SDK cũ vẫn hoạt động. Với project đang sát release candidate, thay SDK chỉ để “đang dùng bản mới nhất” có thể tạo rủi ro QA không cần thiết.

Ngược lại, nên lên kế hoạch migration sớm nếu project thuộc một trong các nhóm sau: đang viết logic riêng cho Steam Deck; cần phân biệt Proton trong crash/support pipeline; đang mở rộng controller glyph; có Workshop dependency phức tạp; có multiplayer server browser; hoặc muốn tune default settings theo Steam hardware theo hướng ít hard-code hơn.

Đối với project giữa production, lựa chọn tốt thường là tạo một branch migration riêng, cập nhật SDK, chạy smoke test toàn bộ Steam integration rồi mới merge. Đừng chỉ mở game thấy overlay hiện lên và kết luận rằng migration đã xong.

Checklist migration thực tế

1. Xác minh đúng revision của 1.65

Nếu SDK được tải trước ngày 31/07/2026, kiểm tra lại package vì bản 1.65 đã được Valve phát hành lại hai lần. Đặc biệt chú ý Win32 steam_api binaries và code dùng GetBetaInfo.

2. Tìm toàn bộ tham chiếu IsRunningOnSteamDeck

Không thay máy móc một lời gọi bằng lời gọi khác. Hãy phân loại từng nhánh: nhánh nào dùng cho analytics, nhánh nào dùng để chọn graphics preset, nhánh nào dùng cho input, nhánh nào chỉ phục vụ logging. Sau đó thay bằng API đúng mục đích.

3. Tách hardware identity khỏi capability

Hardware type có thể hữu ích cho hỗ trợ và cấu hình mặc định, nhưng quyết định chức năng nên dựa trên capability cụ thể. Cách này giảm nguy cơ game hiểu sai phần cứng Steam mới trong tương lai.

4. Test Proton như một môi trường QA riêng

Chạy ít nhất boot, save/load, cutscene/video, online, controller, fullscreen/window mode, suspend/resume nếu liên quan và crash reporting. Ghi rõ build number, distro/SteamOS version nếu hệ thống support của team cần phân tích lỗi.

5. Kiểm tra lại controller glyph

Nếu UI dùng Steam Input action origin, thêm test case cho origin mới. Đặc biệt kiểm tra menu trước khi vào gameplay, bởi nhiều project chỉ cập nhật glyph sau khi player controller được spawn.

6. Với Workshop, lập danh sách item nền tảng

Nếu game có mod framework hoặc shared dependency, thử tận dụng query mới để xác định item ảnh hưởng lớn. Đây cũng là dịp kiểm tra hành vi khi dependency bị unpublish, đổi version hoặc không còn tương thích.

7. Với multiplayer, test ranking có social signal

Server có bạn bè nên được đánh dấu rõ thay vì âm thầm đẩy lên trên mà người chơi không hiểu lý do. Một icon hoặc nhãn “friends played here” có thể giúp UI minh bạch hơn.

Ba lỗi thiết kế nên tránh

Thứ nhất, coi Steam Hardware API như detector duy nhất. Valve đã nhấn mạnh hardware type phù hợp cho analytics/support/diagnostic, còn functional decisions nên dùng API chuyên biệt. Nếu code đảo ngược nguyên tắc này, hệ thống sẽ khó mở rộng.

Thứ hai, gắn Proton với trải nghiệm “thấp hơn”. Proton detection là context, không phải đánh giá chất lượng máy. Chỉ áp workaround khi có bug cụ thể và có thể kiểm chứng.

Thứ ba, cập nhật SDK nhưng không cập nhật QA matrix. API mới không có giá trị nếu team vẫn test một controller, một desktop Windows và một tài khoản Steam duy nhất.

Steamworks 1.65 nói gì về hướng phát triển Steam?

Đây là phần nhận định, không phải tuyên bố chính thức từ Valve: 1.65 cho thấy Steam integration đang dịch chuyển từ logic gắn với một thiết bị nổi bật sang lớp abstraction rộng hơn cho Steam hardware, compatibility, performance context và social discovery. Đối với studio nhỏ, điều này có lợi nếu tận dụng để giảm hard-code ngay từ bây giờ.

Cũng cần tránh suy diễn quá mức. Release notes không nói rằng mọi game phải hỗ trợ phần cứng Steam tương lai, không đảm bảo API performance sẽ tự động tối ưu trò chơi, và không biến Workshop dependency thành hệ quản lý package hoàn chỉnh. Đây là các building block, còn chất lượng implementation vẫn phụ thuộc game.

Kết luận

Steamworks SDK 1.65 là một bản cập nhật có giá trị rõ nhất với game đã đi xa hơn lớp tích hợp Steam cơ bản. Nếu project có Steam Deck/Linux, controller abstraction, Workshop hoặc multiplayer, đây là thời điểm tốt để rà lại kiến trúc thay vì chỉ đổi file SDK. Mục tiêu không phải chạy theo version number, mà là giảm các nhánh hard-code trước khi chúng trở thành chi phí support dài hạn.

Nguồn kỹ thuật chính: Steamworks Development — SDK 1.65 release notes. Steamworks xác nhận việc cập nhật được khuyến nghị nhưng không bắt buộc, đồng thời ghi rõ hai lần re-release ngày 27/07 và 31/07 cùng danh sách API mới được phân tích trong bài.