Phát triển trò chơi điện tử không cần game engine (2025)

 (noelberry.ca)
33 điểm bởi GN⁺ 2025-05-21 | 5 bình luận | Chia sẻ qua WhatsApp
  • Có thể phát triển game đủ dễ và thú vị ngay cả khi không dùng game engine thương mại
  • Không cần đến phần lớn tính năng của các engine lớn; tự viết công cụ sẽ tăng tính linh hoạt và hiệu quả phát triển
  • Tận dụng C# hiện đại và các thư viện mã nguồn mở có thể mang lại môi trường phát triển đầy đủ bất kể quy mô nhóm
  • Có thể xây dựng pipeline phù hợp nhu cầu bằng cách kết hợp các thư viện như FMOD, SDL3, Dear ImGui với công cụ tự làm
  • Xét về phát triển đa nền tảng, bảo trì và tính khả chuyển, một framework gọn nhẹ tự xây dựng có nhiều lợi thế rõ rệt

Lời mở đầu: suy ngẫm của một nhà phát triển game 20 năm kinh nghiệm

  • Đến năm 2025, tác giả vẫn đang phát triển trò chơi điện tử mà không dùng game engine thương mại
  • Nhiều người xung quanh thường ngạc nhiên khi thấy tác giả không dùng engine thương mại
  • Các tính năng mặc định của những engine lớn như Unity hay Unreal không thỏa mãn bằng việc tự triển khai, và cuối cùng vẫn phải làm lại nhiều phần
  • Khi dùng engine thương mại, dễ bị ảnh hưởng bởi các thay đổi chính sách kinh doanh hoặc vấn đề phát sinh từ các bản cập nhật
  • Tự làm những công cụ nhỏ vừa khít với từng dự án sẽ hiệu quả hơn và cũng dễ bảo trì hơn về lâu dài

Chọn ngôn ngữ lập trình cần thiết cho phát triển game

  • Tác giả đã dùng C# làm ngôn ngữ chủ lực trong thời gian dài
  • C# hiện đại đã được cải thiện rất nhiều về hiệu năng, cú pháp và trải nghiệm phát triển so với trước đây
  • Có tính năng hot reload như dotnet watch, rất tiện cho việc sửa mã và kiểm thử theo thời gian thực
  • Ngay cả người không phải lập trình viên cũng dễ tiếp cận, giúp phân chia vai trò và cộng tác trong nhóm hiệu quả hơn
  • Tính năng reflection tích hợp sẵn là một lợi thế lớn khi làm editor hoặc công cụ

Thư viện đa nền tảng và cách triển khai render·input

  • Dùng SDL3 để triển khai mọi chức năng cơ bản như cửa sổ, render, controller và hỗ trợ đa nền tảng
  • Nhờ lớp trừu tượng GPU của SDL3, việc hỗ trợ nhiều môi trường như DirectX, Vulkan, Metal trở nên dễ dàng hơn
  • Trên nền SDL, tác giả dùng một lớp C# tự viết (ví dụ: Foster) làm tiện ích dùng chung
  • FMOD là công cụ âm thanh thương mại cuối cùng còn được sử dụng; ngoài ra pipeline được xây dựng dựa trên mã nguồn mở
  • Trước đây tác giả cũng từng tự triển khai trực tiếp OpenGL/DirectX, nhưng độ ổn định của SDL là một lợi thế rất lớn

Cách xử lý asset

  • Khi không dùng engine có sẵn, chỉ cần nạp đơn giản những tệp thật sự cần cho trò chơi
  • Với asset quy mô nhỏ như trong game pixel art, có thể nạp toàn bộ tệp một lần ngay lúc khởi tạo
  • Với dự án lớn, chỉ nạp asset khi có yêu cầu và giải phóng bộ nhớ khi chuyển cảnh
  • Nếu cần chuyển đổi định dạng, chỉ cần viết script tự động xử lý lúc biên dịch là đủ

Level editor và công cụ UI

  • Dễ liên kết dữ liệu với các level editor mã nguồn mở như LDtk, Tiled, Trenchbroom
  • Phần lớn trường hợp, tác giả tự triển khai editor tùy biến cho từng dự án
  • Không tự viết toàn bộ UI mà tận dụng mạnh Dear ImGui với GUI chế độ tức thời
  • Kết hợp reflection của C# với ImGui giúp trực quan hóa trạng thái đối tượng trong game theo thời gian thực
  • Khi cần, có thể trộn lẫn công cụ ngoài phù hợp mục đích với công cụ tự làm

Đa nền tảng và khả năng port sang console

  • Trước đây việc port sang console khiến C++ gần như là lựa chọn bắt buộc, nhưng điều này đã được giải quyết với C# Native-AOT
  • Các framework mã nguồn mở như FNA cũng đang tích cực mở rộng hỗ trợ console
  • Nếu tận dụng lớp trừu tượng phổ dụng do SDL3 cung cấp, có thể vận hành cùng một codebase trên hầu hết hệ thống

Môi trường phát triển: hệ sinh thái mở lấy Linux làm trung tâm

  • Tác giả đã chuyển nền tảng phát triển chính sang Linux, rất hợp với toolchain mã nguồn mở
  • Dù vẫn còn gắn với một số phần mềm thương mại nhất định (ví dụ: vscode, github), nhưng khi hệ sinh thái mã nguồn mở mở rộng thì mức hỗ trợ cũng tăng theo
  • Cá nhân tác giả cũng đang thiết lập cùng một môi trường làm việc trên nhiều nền tảng Linux như Steam Deck

Hỏi đáp thêm và các ví dụ

  • Về việc dùng Godot: nếu có nhu cầu phát triển xoay quanh engine mã nguồn mở thì khuyến nghị Godot; ngoài ra tác giả thiên về công cụ tùy biến hơn
  • Làm 3D: engine lớn có lợi thế, nhưng với các dự án nhỏ và chuyên biệt thì framework tùy biến là đủ
  • Nhu cầu công nghệ hiệu năng cao: tùy mức yêu cầu, dùng các engine lớn như Unreal cũng hoàn toàn ổn
  • Thay đổi engine ở cấp độ nhóm: phù hợp với phát triển solo/nhóm nhỏ; ngay cả các studio vừa và lớn cũng ngày càng có thêm trường hợp chuyển sang engine tùy biến để tránh rủi ro dài hạn
  • Quy trình asset: có thể tự động chuyển đổi tệp Aseprite thành animation bằng cách tận dụng tag và timing tích hợp sẵn

Kết luận

  • Việc làm game mà không cần game engine thương mại là một lựa chọn phụ thuộc vào gu cá nhân và cách làm việc
  • Chỉ cần ưu tiên nhu cầu và niềm vui, rồi chọn phương pháp phù hợp nhất với bản thân

Bài viết liên quan

5 bình luận

 
assembler 2025-05-29

Đây là một hoạt động hay.
Tôi là nhà phát triển game thuộc thế hệ đầu tiên.
Trước khi Unreal xuất hiện, các công ty phát triển đương nhiên
tự phát triển engine,
và đó cũng chính là năng lực cạnh tranh của họ.
Việc phát triển engine khi ấy chủ yếu là phát triển công cụ
dựa trên core, kernel, rendering và các thành phần vào/ra khác.
Hồi đó tôi phụ trách các công cụ particle, sound, layer và object,
ban đầu nhóm có 7 người nhưng nếu gom lại thì chắc cũng dễ dàng vượt quá khoảng 20 công cụ.

Từ một ngày nào đó, khi Unreal xuất hiện và các game sản xuất hàng loạt
tràn ra thị trường, người ta không còn đầu tư vào phát triển engine nữa.
Có lẽ lúc đó rất nhiều người đã ra riêng và lập công ty.
Vậy mà đã là câu chuyện của 27 năm trước rồi.

Giờ đây tôi cũng đã có tuổi và đang làm một công việc khác, không còn là game nữa.

Tôi lại nhớ về những ngày xa xưa khi làm phần core
theo từng chế độ DirectX, OpenGL tùy theo card đồ họa.

Cố lên nhé...
 
chanapple 2025-05-21

Gần đây tôi định làm một game chiến thuật nên đã tìm engine suốt thời gian dài, đến mức nghĩ rằng thôi thì tự làm một cái còn hơn, nhưng khi thấy một trường hợp đã thực sự làm và thành công thì cảm giác như được tiếp thêm rất nhiều dũng khí.
 
GN⁺ 2025-05-21
Ý kiến Hacker News

  • Sau 5 năm một mình phát triển engine game 2D và làm công việc trả phí liên quan, tôi muốn nói về một điểm quan trọng mà nhiều người không biết
    Engine là phần dễ
    Điều thực sự quan trọng là tooling xung quanh engine, nội dung và asset pipeline
    Import texture, audio, file model (gltf, fbx, animation, v.v.) từ nhiều nguồn dữ liệu và định dạng khác nhau
    Các tính năng chỉnh sửa cơ bản trong ứng dụng editor như cắt, sao chép, dán, hoàn tác, làm lại, lưu, xóa
    Khả năng hiển thị trực quan và các tính năng để developer có thể tạo và thao tác dữ liệu thực trong editor (entity, animation, scene, audio graph, hỗ trợ scripting, v.v.)
    Đóng gói và tiền xử lý dữ liệu như baking static geometry, biên dịch shader, resample và đóng gói texture·audio, tạo asset pack cho nội dung game
    Khi xong tất cả những thứ đó, phần runtime thực tế (tức main loop của game và các subsystem bên dưới) chỉ là một phần nhỏ của toàn bộ hệ thống
    Vì vậy trong game studio, số người phụ trách engine rất ít, còn đa số là programmer làm tool
    engine detonator: https://github.com/ensisoft/detonator

    • Điều quan trọng là tập trung vào việc tạo engine phù hợp với game của mình thay vì tính đa dụng
      UI, nén dữ liệu, v.v. có thể giải quyết bằng library và framework
      Việc OP dùng các library nhỏ như imGUI là một ví dụ hay
      Vì không phải làm engine cho mọi game, nên có rất nhiều việc thực ra không cần làm

    • Engine giống như một phần runtime nhỏ gắn vào asset pipeline
      Ngày nay ngay cả shader compiler cũng đang ngày càng quan trọng hơn 3D API
      Phần thú vị tập trung ở shader compiler, còn 3D API chỉ làm nhiệm vụ thực thi shader và truyền dữ liệu

    • Khi nói đến engine, mọi người thường có xu hướng tính luôn cả asset pipeline và editor
      Engine ngày nay không chỉ là main loop + các hàm 3D API
      Ngay cả khi dùng engine như Unity, số developer chỉ viết code rendering là cực kỳ ít
      Dĩ nhiên dùng Unity/Unreal cũng không có nghĩa là hoàn toàn không phải dùng tool asset riêng

    • Gần đây tôi đã làm lại engine cho phần tiếp theo và cực kỳ đồng ý với điểm này
      Như tôi viết trong postmortem, khi nói đến engine thì đa số nghĩ đến đoạn code nằm trong file thực thi của game, nhưng trên thực tế tôi thấy phần code không được phát hành cùng game như level editor, content pipeline, debugging/profiling, workflow phát triển mới chiếm tỷ trọng lớn hơn
      Phát triển tool là công việc chán và dễ kiệt sức hơn phát triển engine
      Đó là lý do nhiều dự án game dùng custom engine bị dừng giữa chừng
      postmortem: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

    • Tự làm editor từ đầu là một khối lượng công việc rất lớn
      Nếu có thể thì nên tận dụng editor sẵn có
      Ví dụ như kết hợp TrenchBroom (editor cho Quake) + func_godot, còn 2D thì có Tiled
      Để quản lý dữ liệu game từng có CastleDB, nhưng giờ đã được tích hợp với Hide (một editor 3D đầy đủ)
      Sau khi làm xong tool, việc thiết kế game và tạo nội dung lại là một giai đoạn lớn khác

  • Vài năm trước tôi tạo một lớp "sprite" đơn giản bằng SDL2 và một ít C++, rồi thêm các tính năng cơ bản như collision
    Nếu phải gọi thứ tôi làm là engine thì nó chỉ giống như một dạng trợ lực xe đạp điện
    Điểm là "engine" rất hay dẫn dắt toàn bộ project/game
    Rất thường xảy ra chuyện game phải uốn theo engine, nên tôi luôn tránh dùng các engine lớn như Unity
    Cuối cùng những engine đó thường chỉ tạo ra cùng một kiểu cấu trúc game, chỉ khác asset
    Cá nhân tôi thấy thay vì lãng phí thời gian học engine, có thể bắt đầu với SDL có đường cong học tập ngắn hơn, và SDL còn dùng được cho các project đa nền tảng ngoài game
    Game của tôi: https://store.steampowered.com/app/2318420/Glypha_Vintage/

  • Dù tự làm engine mất nhiều thời gian, tôi muốn hỏi rằng để thực sự thành thạo Unreal hay Unity đến mức có thể biến ý tưởng thành game ngay lập tức thì cần bao nhiêu thời gian
    Rốt cuộc khi hoàn thành engine của riêng mình, tôi cũng sẽ có ngay mức độ chuyên môn đó, nên về dài hạn sẽ tiết kiệm thời gian
    Càng có nhiều kinh nghiệm kỹ sư thì tự làm càng có lợi về mặt thời gian
    Game càng độc đáo hoặc càng thuộc thị trường ngách thì việc tự làm càng hợp lý
    Việc lạc trong UI phức tạp của Unreal hàng tháng trời rồi nhận ra thứ mình muốn vốn gần như không thể làm bằng engine đa dụng là rất kém hiệu quả
    Ngược lại, nếu làm một open-world RPG siêu quy mô thì tự làm không phải lựa chọn tốt
    Những ràng buộc của custom engine đôi khi lại khơi dậy sáng tạo, và kể cả không đạt đỉnh cao kỹ thuật thì game vẫn có thể độc đáo hơn

    • Tôi đã từng tự làm engine
      Lúc đầu mất khoảng 1 năm với vô số thử-sai và ngõ cụt
      Tôi đã triển khai gần như mọi subsystem có trong game: 3D rendering, UI thích ứng, skeletal animation, save file, smart object, pathfinding, scripting, audio, physics, v.v.
      Đặc biệt là tự triển khai tính năng tua ngược (giống hệ thống của Braid)
      Những tính năng như vậy đòi hỏi mọi subsystem trong engine (script, physics, v.v.) đều phải hỗ trợ
      Vì tôi biết mọi phần trong engine mình làm ra nên có mức tự do cực lớn khi phát triển thêm tính năng
      Nhưng sau 1 năm phát triển, tôi dần burnout và mất động lực

    • Tôi không rõ Unreal, nhưng với Unity thì phát triển nhanh hơn ít nhất 10 lần so với tự code
      Thêm tính năng vật lý chỉ mất 1 phút, còn với engine tự làm thì chỉ riêng tích hợp thư viện ngoài cũng mất 1-2 ngày
      Các tính năng trực quan hóa nội bộ mà Noel cho thấy ở Unreal cũng có sẵn trong Unity
      Những thao tác chỉnh sửa như điều khiển bounding box cũng được tích hợp mặc định
      Nếu hành vi mặc định của engine chưa đủ, có thể dễ dàng mở rộng bằng ImGui hoặc CSS engine dựa trên Yoga
      Nó còn cung cấp vô số tính năng như particle editor nâng cao, shader đã được xử lý bớt độ phức tạp, streaming dữ liệu mô-đun
      Về lý thuyết ai cũng muốn tự làm hết, nhưng cuối cùng vấn đề vẫn là thời gian nên ưu tiên hoàn thành

    • Thời gian để học Unreal hay Unity đến mức triển khai được ngay ý tưởng game, và thời gian để tự làm engine là hai câu hỏi khác nhau
      Chỉ cần đưa một ít ý tưởng là tôi có thể làm một prototype chơi được trong vài giờ
      Với Unity, ban đầu chỉ cần biết lập trình, còn Unreal thì chỉ với Blueprint cũng có thể đi gần đến mức phát hành game
      Xem video làm prototype game kiểu Super Hexagon chỉ trong 10 phút: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
      Yếu tố đặc thù của Unity gần như chỉ là prefab, còn lại đều là khái niệm chung của phát triển game
      Từ góc nhìn của một developer Unreal, tôi cũng có thể làm prototype tương tự trong Unity dưới 1 giờ

    • Giả định “sau khi engine hoàn thành” bản thân nó có thể đã không thực tế
      Ngay cả một thao tác đơn giản như GameObject.Instantiate cũng cần lượng tài nguyên khổng lồ nếu phải tự triển khai trong engine
      Hãy tính đến độ phức tạp của vật lý 2D/3D, shader, hỗ trợ nền tảng, v.v.
      Nếu mục tiêu là engine thì hãy làm engine, còn nếu mục tiêu là game thì hãy làm chính game đó

    • Nếu bạn đã có đủ kiến thức phát triển game để tự làm game engine
      Thì chỉ cần một ngày là đủ để học Unreal hay Unity ở mức làm prototype
      Để thành thạo hoàn toàn thì mất lâu, nhưng thời gian tạo ra prototype cho game mình muốn là không thể so sánh

  • Làm game mà không cần engine lớn “làm tất cả mọi thứ” thường dễ hơn, vui hơn, và đôi khi còn hiệu quả hơn
    Tuy vậy, khi đào sâu vào những tính năng cụ thể của engine (ví dụ inverse kinematics, animation blending của Unreal), đôi lúc sẽ nghĩ “may mà mình không phải tự vật lộn 2-3 tuần để làm cái này”
    Chủ nghĩa tối giản hay chống phình to cũng quan trọng, nhưng những engine đó nổi tiếng vì chúng gánh phần việc nặng thay bạn

    • Trước đây tôi cũng theo cách này
      Khi làm game 3D đầu tiên, tôi tự triển khai input, quản lý object, culling, model loading, thư viện toán, graphics, normal map, SSAA, v.v., và kết quả là tỷ lệ hoàn thành game đúng 0%
      Dù vậy, với các project 2D làm vì sở thích, tôi vẫn phát triển không phụ thuộc gì ngoài browser canvas
      Về cơ bản browser đóng vai trò như engine

    • Về ý kiến “may mà không phải tự làm”
      Nếu nghĩ dài hạn cho sự nghiệp indie developer, thì dù mất vài tuần, việc hiểu sâu chủ đề + sở hữu 100% source code và giá trị tái sử dụng vẫn lớn hơn

    • Luận văn tốt nghiệp của tôi là port particle engine dựa trên NeXTSTEP/Objective-C sang Windows 95/Visual C++ (dựa trên OpenGL, có cả mẫu marching cubes)
      Những chủ đề như vậy giờ chỉ còn là một phần của một tính năng một dòng trong các engine ngày nay

    • Dùng engine giúp project tiến nhanh hơn rất nhiều, và không phải tiêu tốn thời gian vào việc xây hạ tầng
      Việc phát minh lại bánh xe không phải là niềm vui lớn với đa số mọi người

    • Những tính năng như inverse kinematics hay animation blending
      Nếu là cốt lõi của game thì đáng để tự triển khai, còn nếu không thì chỉ là cái bẫy kỹ thuật không cần thiết

  • Tôi làm game theo cách của mình với Lua & Love2D
    Chính việc tự đặt ra ràng buộc là cốt lõi của niềm vui
    Nếu việc phát triển không còn vui nữa thì đó là dấu hiệu có gì đó sai, và nên tìm cách tốt hơn
    Game YOYOZO của tôi chỉ nặng 39KB nhưng đã xuất hiện cùng các bom tấn trong danh sách game hay nhất năm 2023 của Ars Technica
    https://news.ycombinator.com/item?id=38372936

    • Tôi nhớ game đó
      Sau nhiều năm mua Playdate, tôi mới bắt đầu nghịch SDK và cũng đang học Lua lần đầu
      Tôi vẫn thích strong typing và độ an toàn của ngôn ngữ, nhưng Lua là đủ dùng cho hoàn cảnh này
      Tôi chỉ mới làm một tech demo nhỏ trong đó văn bản xoay trong không gian 3D giả theo tay quay
      https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
      Làm project này khiến tôi nhận ra mình đã quên gần hết lượng giác sau nhiều năm làm CRUD/webapp
      Điểm tuyệt nhất của phát triển trên Playdate là sự giải phóng khi có canvas cố định, chỉ cần đặt đúng vị trí pixel là nó chạy y nguyên trên mọi thiết bị
      Sau cả chặng đường trước đây chỉ làm responsive UI, trải nghiệm này thật sự rất mới

  • Mỗi lần thử làm gì đó bằng game engine (Godot, Unity, Unreal, v.v.), tôi đều phải vật lộn với chính engine
    Cuối cùng nó giống như đang đặt asset lên một khuôn game đã định sẵn, khiến tôi khó làm ra game mình thực sự muốn
    Nếu ví với web development thì nó giống một sản phẩm hoàn thiện kiểu WordPress
    Khi cấu hình mặc định không khớp với ý đồ, bạn phải hack và lách đi rất nhiều

  • Tác giả (Noel) là người làm ra game Celeste và đã bán hơn 3 triệu bản
    https://en.wikipedia.org/wiki/Celeste_(video_game)

  • Tôi cũng đồng ý ở mức khá lớn và đang làm một game framework C# thuần code (người kế thừa tinh thần của XNA/Monogame, dùng Sokol thay vì SDL)
    https://zinc.graphics/
    Điểm mạnh của C# hiện đại: đa nền tảng, biên dịch NativeAOT, native hot reloading, reflection, v.v.
    Cá nhân tôi còn thêm cả source generator
    Dù hình ảnh tiêu cực trong quá khứ vẫn còn, nhưng sự phát triển của CoreCLR và ngôn ngữ trong 5 năm gần đây thật đáng kinh ngạc
    Điều duy nhất tôi mong là Union Types, hiện đã có đề xuất và hy vọng sẽ được thêm vào năm sau
    https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

    • Không biết có tài liệu nào để bắt đầu học C# cho kiểu project như thế này không
      Tôi mới chỉ dùng C# trong Win32 hoặc Unity, có kiến thức engine cấp thấp bên C/C++, nhưng từng nghĩ C# là không thể cho đa nền tảng như game console
      Giờ tôi mới nhận ra là mình đã sai

  • Với bất kỳ phần mềm nào, tôi thích bắt đầu từ con số 0
    Với người đã có kinh nghiệm project lớn thì có thể thấy chậm, nhưng ở giai đoạn startup lại thường nhanh hơn
    Chỉ triển khai mức tối thiểu, rồi khi có abstraction, tốc độ thêm tính năng mới sẽ tăng lên
    Năng suất giữa phần mềm doanh nghiệp cỡ lớn và mini engine do chính tôi viết là hoàn toàn khác nhau
    Code do tự mình viết thì có thể cắt bỏ và refactor ngay, nên nhanh hơn rất nhiều
    Đó là lý do tôi thích microservice và team nhỏ
    Tự làm mọi thứ thì chắc chắn phải đi qua thử-sai và bãi mìn dễ hỏng vỡ, và cũng mất nhiều năm để hiểu đặc tính thật sự của ngôn ngữ hay nền tảng
    Nhưng chính quá trình đó cuối cùng lại tích lũy thành nội lực của developer
 
kissdesty 2025-06-10

Không dùng engine, mà chỉ dùng một framework ở mức như MonoGame thì sao nhỉ, mình khá tò mò~
 
lazyhack 2025-05-23

"Bản thân quá trình đó cuối cùng sẽ trở thành nội lực của chính nhà phát triển" — hoàn toàn đồng ý.