Tramway SDK – Sự kết hợp báng bổ giữa engine Half-Life và Morrowind

• Tramway SDK là một gói đồ họa/framework/game engine được phát triển trong 3 năm qua, hướng tới một engine nhẹ, đi ngược lại yêu cầu cấu hình cao và luồng làm việc với trình biên tập nguyên khối của các engine phổ biến
• Cho rằng các engine phổ biến như Unity và Godot đòi hỏi phần cứng quá mức ngay cả với game low-poly đơn giản, dự án nhắm tới khả năng chạy trên phần cứng trong vòng 15 năm gần đây và cả raster hóa bằng phần mềm
• Cách tạo nội dung không phải là chuyển qua lại giữa GUI node và code, mà là viết code bằng cách kế thừa lớp Entity, rồi chỉ chọn dùng những trình biên tập cần thiết
• Việc tạo màn chơi dựa trên workflow brush kiểu Quake, sử dụng bộ chuyển đổi .map, lightmap, Gouraud shading và hệ thống input/output kiểu Source
• Dự án nhắm tới streaming open-world và một framework RPG gần với 3D RPG Maker, nhưng hiện vẫn ở giai đoạn phát triển ban đầu, nên cần lưu ý API chưa ổn định và nhiều phần chưa được triển khai

---

Vấn đề mà Tramway SDK nhắm tới

• Tramway SDK là một gói đồ họa, framework và game engine, đồng thời cũng dùng cách viết kiểu heavy metal là “T̈ra̦m̊ẅa̦ÿ SD̈K”
• Phê phán đối với các engine phổ biến tập trung vào Turbobloat
  • Unity bị cho là đòi hỏi phần cứng rất mạnh và tiêu thụ nhiều điện năng
  • Godot được xem là đỡ hơn Unity một chút, nhưng vẫn cần phần cứng tương đối có hiệu năng
  • Quan điểm của dự án là những game như low-poly horror roguelite deckbuilder simulator phải có thể chạy tốt cả trên phần cứng 15 năm tuổi
• Tramway SDK tuyên bố có thể chạy trên gần như mọi phần cứng trong vòng 15 năm gần đây vì không có Turbobloat
  • Có thể chuyển sang raster hóa bằng phần mềm để hoạt động ngay cả khi không có card đồ họa
  • Thậm chí nêu ví dụ hiển thị đồ họa trên các thiết bị như máy nướng bánh mì hoặc tủ lạnh
• Trước phản biện “cứ mua máy tính tốt hơn là được”, dự án đáp lại bằng ba lý do
  • Vấn đề khả năng chi trả, vì nhiều người không đủ điều kiện mua phần cứng mạnh
  • Vấn đề rác thải điện tử, vì sản xuất chip máy tính gây hại cho môi trường, và nếu phần mềm không phình to thì chỉ cần mua phần cứng mới khi phần cứng cũ hỏng và không thể sửa được
  • Quan điểm rằng khi một chiếc máy tính vẫn đang hoạt động tốt, không có lý do gì phải mua máy mới chỉ vì Turbobloat của người khác

Cách tạo nội dung và tính năng

• Cách tạo nội dung dựa trên node bị phê phán vì phải xử lý “nhiều thứ trông như một thứ” và phải chuyển qua lại giữa GUI node và code
• Với Tramway SDK, chỉ cần viết code bằng cách kế thừa lớp Entity, rồi tạo màn chơi bằng trình biên tập màn chơi
  • Cấu trúc xoay quanh entity, không dùng node
  • Tránh luồng làm việc phải chuyển qua lại giữa code và GUI node
• Trình biên tập nguyên khối của các engine phổ biến cũng bị xem là vấn đề
  • Dự án cho rằng người dùng phải chờ toàn bộ trình biên tập được tải, kể cả những tính năng không dùng tới
  • Tất cả các trình biên tập của Tramway SDK đều là tùy chọn
  • Nếu chỉ muốn dùng như framework, có thể chỉ dùng C++ runtime
  • Nếu chỉ cần tạo màn chơi, có thể chỉ dùng trình biên tập màn chơi
  • Các file dữ liệu có định dạng giá trị phân tách bằng khoảng trắng, nên cũng có thể chỉnh sửa thủ công mà không cần trình biên tập
• Về mặt đồ họa, chỉ với lightmap và Gouraud shading cũng có thể tạo ra các hình ảnh ví dụ
  • Ví dụ đó có thể được render cả trên fixed-function pipeline của card đồ họa cấp Direct3D 7
• Việc tạo màn chơi hỗ trợ workflow dựa trên brush thuộc họ Quake
  • Tramway SDK cung cấp bộ chuyển đổi file .map, chuyển brush thành mesh tam giác
  • Dự án minh họa luồng tạo màn chơi trong Trenchbroom rồi cấu hình trong trình biên tập màn chơi của Tramway SDK
  • Engine render màn chơi đã được áp dụng lightmap
  • Có thể thiết lập tương tác giữa các entity trong màn chơi bằng hệ thống input/output tương tự Source
  • Trong tương lai, dự án dự định triển khai toàn bộ Source logic entity để có thể thực hiện visual scripting ngay trong trình biên tập màn chơi
• Ở mảng RPG, dự án xem các công cụ như RPG Maker và việc có thể tạo nhiều thứ bằng cách thay đổi dữ liệu trong mod/total conversion dựa trên Morrowind là những ví dụ thú vị
  • Tramway SDK có phần mở rộng framework RPG gần giống RPG Maker cho 3D
  • Engine được thiết kế ngay từ đầu để hỗ trợ streaming màn chơi, qua đó được cho là có thể giúp việc tạo game kiểu open-world RPG trở nên nhanh và dễ hơn
• Tóm lại, Tramway SDK là một game engine dựa trên entity theo phong cách Quake/Source, cung cấp các phần mở rộng tùy chọn như streaming open-world và framework RPG
• Trạng thái phát triển hiện vẫn ở giai đoạn rất sớm
  • API chưa ổn định
  • Tính năng có thể bị hỏng hoặc không hoạt động
  • Còn nhiều phần chưa được triển khai
  • Dự án cho biết đang được cải thiện nhanh chóng
• Kho GitHub: racenis/tram-sdk

[GN⁺]

Ý kiến trên Hacker News

• Có thể sẽ có người nói “cứ mua máy tính tốt hơn đi”, nhưng chính vì vậy tôi hoàn toàn đồng ý rằng việc phải mua máy tính tốt hơn là điều tệ. Nhiều người, đặc biệt là người ở các nước đang phát triển, không đủ khả năng mua phần cứng để chạy Turbobloat, và việc sản xuất chip gây tác động xấu đến môi trường.
  Nếu phần mềm hiện đại không phình to đến vậy, người ta chỉ mua máy mới khi phần cứng hiện có hỏng và không thể sửa được. Khi vẫn có một chiếc máy tính hoạt động tốt thì chẳng có lý do gì phải mua máy mới chỉ vì phần mềm cồng kềnh của người khác; số tiền đó còn có thể mua 1000 lon Dr. Pepper. Đây là một dự án thật sự hay, nên tôi mong họ tiếp tục cập nhật tiến độ.

  • Dù có nói “độ phân giải màn hình từ 320x200 đến 800x600”, độ phân giải cao hơn không phải được phát minh chỉ vì Turbobloat
  • Nói vậy nhưng có vẻ engine lại yêu cầu GPU OpenGL 4, trong khi đồ họa trông như mức chạy được trên cả card Voodoo
  • Tôi không rõ Turbobloat là gì. Theo ngữ cảnh thì nghe như “công nghệ đồ họa mà tôi không thích”, nhưng không chắc ranh giới nào thì được xem là Turbobloat
  • Việc chế tạo và vận chuyển máy tính mới về lâu dài cũng có thể đáng giá. Vì những cải thiện về hiệu năng và hiệu suất điện năng theo thời gian có thể bù đắp tác động môi trường.
    Tất nhiên nếu chỉ để giải trí thì khó đánh giá hơn; một chiếc Game Boy cũ có khi còn vui hơn một PC gaming hiện đại 1000W

• Câu “Một thứ phải là một thứ. Nó không được là nhiều thứ giả vờ là một thứ. Khi dùng node, bạn phải giả vờ rằng nhiều tập hợp là một thứ” thật sự rất giống Terry Pratchett và rất hay.
  Tôi thích vì nó như câu mà Sam Vimes có thể nghĩ ra khi đang xử lý một vụ điều tra phức tạp, và mong dự án tiếp tục phát triển. Tôi chưa tự dùng thử, nhưng có vài ý tưởng để áp dụng vào dự án AI của mình

  • Nếu chỉ tách riêng câu đó ra thì tôi lại thấy nó có vẻ rõ ràng là sai. Chúng ta lúc nào cũng xem một tập hợp nhiều thứ như một thứ.
    Con người là một tập hợp các bộ phận cơ thể, bộ phận cơ thể là tập hợp các chất hóa học, chất hóa học là tập hợp các phân tử, phân tử là tập hợp các nguyên tử, nhưng ở mỗi cấp chúng ta vẫn xem là một thứ. Cấm làm vậy thì vô lý. Dù sao dự án trông vẫn rất ngầu
  • Tôi hình dung Sam Vimes sau khi nói câu đó sẽ phải trải qua một quá trình trưởng thành đau đớn vì Sybil, rồi miễn cưỡng thừa nhận rằng “đôi khi một thứ có lẽ phải là nhiều hơn một thứ”.
    Và entity component system của Vetinari tuy trông phức tạp nhưng hoạt động đúng cách, khiến cái thành phố chết tiệt đó vận hành được
  • Cụm này có vẻ nhắm đến những người đã thử và ghét các giải pháp khác, nhưng với tư cách người chưa từng dùng game engine, tôi muốn có một giải thích dễ hiểu về việc node liên quan thế nào đến chuyện “một tập hợp nhiều thứ giả vờ là một thứ”.
    Có phải ý là trải nghiệm người dùng của trình chỉnh sửa node khuyến khích gán thuộc tính và quan hệ cho những thứ như Vector của các Finger, nhưng rốt cuộc Vector chỉ là “một tập hợp các thứ”, không phải một “loại” có hành vi riêng, nên khó gắn code vào đó?
    Tôi thắc mắc câu “mọi thứ đều là Entity, cứ viết code đi” có nghĩa là thay vì Vector, nên tạo một lớp Hand chứa các Fingers và có trạng thái cũng như hành vi riêng. Hoặc cũng có thể là thay vì tạo các instance node đóng gói sẵn một số giá trị tĩnh và thành viên quan hệ cụ thể, thì nên kế thừa tiếp từ lớp con Entity để cụ thể hóa hơn
  • Đoạn ngay sau đó rất thú vị: “Khi tạo thứ gì đó bằng node, bạn phải liên tục qua lại giữa GUI node và code”.
    Cấu trúc Node/GDScript của Godot có thể được xem như một kiểu phản hồi cho lập luận này. Nó là nỗ lực khiến việc “qua lại” đó trơn tru và tích hợp nhất có thể bằng những thứ như toán tử $ và tự động hoàn thành. Dù vậy, cuối cùng thì vẫn phải phát hành game, nên tôi nghĩ lối tư duy “một thứ là một thứ” cuối cùng sẽ thắng
  • Đáng tiếc là mọi thứ đều là tập hợp của nhiều thứ giả vờ là một thứ, ngay cả những thứ đơn nhất cũng vậy. Điều tốt nhất chúng ta có thể làm là giả vờ như thế, hoặc né tránh sao cho không bị phát hiện

• Theo thời gian, có cảm giác như tồn tại một lực bên ngoài kéo giảm chất lượng game engine. Những thứ lan rộng trong giới công nghệ thường là những thứ dễ xây dựng giáo trình
  Các trình biên tập dựa trên node như Unity có cấu trúc rất vừa vặn để giải thích qua nhiều buổi học. Ngược lại, một engine như raylib có thể hiểu được chỉ trong một buổi chiều, nên khó có thể hình thành một lớp học raylib ở bậc đại học. Vì vậy xuất hiện một vòng lặp: các trường kiểu bootcamp đào tạo ra lập trình viên nghiệp dư chỉ biết Unity/Unreal, công ty tuyển nhân sự Unity/Unreal, rồi đại học lại dạy những thứ đó. Hiện tượng này cũng giống phần nào với sự phổ biến của Java.
  Thêm nữa, vì mỗi công ty lại có yêu cầu khác nhau đối với dự án Unity, Unity, với tư cách là một công ty vì lợi nhuận phục vụ khách hàng chứ không phải một lập trình viên hay phàn nàn, phải liên tục điều chỉnh engine, và cuối cùng trở thành Turbobloat. Engine của Half-Life và Morrowind là kết quả của một hoàn cảnh đặc biệt, nơi các lập trình viên đầy đam mê được trả tiền để phát triển những gì họ cho là tuyệt vời, nên đã tạo ra công nghệ xuất sắc và những engine tối giản phù hợp với nhà phát triển game chuyên nghiệp.
  Dự án này có vẻ nằm đâu đó giữa raylib và Unity. Tôi lo rằng nó chưa đủ hấp dẫn với lập trình viên nghiệp dư, nhưng lại làm quá nhiều thứ đối với các lập trình viên muốn một engine nhỏ gọn. Hy vọng tôi sai; hiệu năng và mức độ hoàn thiện trông có vẻ tốt. Chắc chắn có những nhà phát triển đã mệt mỏi với Unity, và khi chu kỳ hoài niệm chuyển sang thập niên 2000, nhu cầu chơi và làm những game không phức tạp về đồ họa hơn Half-Life 2 là có thật. Thiết kế web và giọng văn tài liệu cũng tốt

  • Một điểm quan trọng nữa là khi game và engine được làm cùng nhau, chúng có thể được điều chỉnh cho phù hợp với nhau. Doom không thể đặt một sàn khác lên trên một sàn, đó là giới hạn của engine xuất phát từ ràng buộc CPU, và các level designer đã tạo ra những thủ thuật để khiến nó trông như vậy
    Nếu thiết kế cả hai cùng lúc, bạn có thể tận dụng tích cực các tính năng đã thêm vào, đồng thời tránh những tính năng không làm tốt, hoặc thậm chí điều chỉnh art style cho phù hợp với engine. Những mob góc cạnh, dạng pixel của Minecraft rất hợp với engine, nhưng nếu bắt đầu làm chúng tinh xảo hơn, bạn sẽ rơi vào thung lũng khó chịu nơi chúng trông còn cũ kỹ và gượng gạo hơn Minecraft, cho đến khi có đủ polygon để render ổn
  • Tôi nhớ một người từng làm ở Bioshock, có lẽ là lead designer, đã nói trong một cuộc phỏng vấn rằng: “Muốn thử nghiệm một ý tưởng mới ở công ty thì phải lập đội và tốn ít nhất một tháng mới có thứ để chạm vào. Trong khi ở nhà, chỉ trong một buổi tối tôi có thể làm cả một chiến dịch Doom”
  • Tôi thích phát triển game dựa trên thư viện như raylib hay libgdx, nhưng việc một game như Slay the Spire ở phần tiếp theo đã đi từ Unity sang Godot là có lý do
    Tôi không nghĩ người ta dùng Unity vì bị các giáo sư mê sự phức tạp dạy sai
  • Game ngày xưa thật sự rất sắc nét, còn game ngày nay thì chạy tệ, crash, cần tải 150GB và mất 150 năm để khởi động. Nếu chúng ta chơi game vì đồ họa, một trong những MMO phổ biến nhất đã không thể dựa trên một game trình duyệt năm 2002, và ngay từ đầu chúng ta đã chơi thực tại chứ không phải game
    Cứ nhìn việc Epic Games đã làm với Fortnite là thấy. Họ đã giết chết một game xoay quanh đấu trường cạnh tranh vốn chạy mượt chỉ vì đồ họa Turbobloat và skin
  • Hiện tượng “các lập trình viên chỉ biết Unity/Unreal ra đời, công ty tuyển nhân sự Unity/Unreal, rồi đại học lại dạy lại” cũng xuất hiện tương tự trong ArcGIS

• Tôi hoàn toàn đồng ý với vấn đề phình to kiểu turbo. Máy móc ngày nay mạnh hơn nhiều, vậy mà phần lớn chương trình lại có cảm giác chậm hơn trước
  Dự án này cũng rất tuyệt, và thiết kế website xứng đáng điểm A+

  • Câu “phần lớn chương trình chậm hơn trước” có lẽ chỉ đúng với những người từng may mắn dùng phần cứng hơi dư hiệu năng vào một thời điểm nào đó
    Từ góc nhìn của người dùng phần cứng bình thường thời Windows 98/2000/XP, chạy Windows 10/11/KDE/Gnome trên một laptop hiện đại giá rẻ có SSD vẫn phản hồi tốt hơn nhiều, ngay cả khi chạy các web app bị xem là cồng kềnh như vscode hay Slack
  • Tôi không hiểu thuật ngữ Turbobloat. Tôi từng làm game nhưng chưa bao giờ nghe nói, tác giả cũng không định nghĩa, tìm trên Kagi thì chỉ ra bài được gửi này, còn Google không có kết quả liên quan
    Không biết nó chỉ có nghĩa là “rất cồng kềnh” hay không. Đọc thêm trên site thì thấy có cả những cụm như “mô phỏng vật lý siêu thực”, nên rốt cuộc có vẻ nó mang nghĩa “rất phình to”

• Quan điểm rằng “đa số game Unity trông rất tệ dù có dùng shader hào nhoáng, normal mapping và các kỹ thuật khác” dường như ngày càng phổ biến hơn trong một thế hệ nhất định.
  Chắc chắn là một dạng công nghệ texture mapping nào đó đã biến mất. Phần nền của Ikaruga đẹp quá mức cần thiết, đặc biệt là hiệu ứng khu rừng đơn giản ở đoạn đầu. Một vài game mô phỏng tàu hỏa thời PS2 cũng làm được điều này.
  Tuy nhiên, nếu một nguồn sáng định hướng mạnh như mặt trời chiếu lên vật thể bóng và người chơi di chuyển, cách làm này sẽ sụp đổ. Nếu môi trường u ám và hoàn toàn không có vật thể động, có thể né được khá nhiều mánh khóe hiện đại.

  • Đúng vậy. Vấn đề là một số game hiện đại u ám và cũng không có ánh sáng động nhưng vẫn cố dùng Lumen. Bản remake Silent Hill là như thế; chạy rất chậm, trông còn tệ hơn trên PS5 Pro, và cỏ cũng kém hơn các game cũ.
    Bối cảnh của Silent Hill ban đầu được tạo ra để biện minh cho các mánh tối ưu hóa. Để dễ quản lý các đối tượng trên màn hình, họ đặt ra một không gian sương mù thường trực gọi là “không gian sương mù”, còn bản remake thì lãng phí lượng xử lý khổng lồ để tạo ra sương mù thực tế thay vì thứ sương mù trông siêu nhiên.
  • Những game đẹp làm bằng Unity không trông “như game Unity”, nên người ta không nghĩ tới chúng như ví dụ về “game Unity trông như thế nào”. Vì vậy hình mẫu điển hình của game Unity vẫn mãi là “khá thô”.
    Kỹ năng mỹ thuật để làm cho game trông đẹp hoàn toàn không biến mất, chỉ là phân bố rất không đồng đều. Một đội có modeler, texture artist, animator giỏi và năng lực visual programming tốt thì dùng Unreal, Unity hay engine tự làm cũng đều có thể tạo ra hình ảnh đẹp.
  • Có một sự cố chấp rằng chỉ riêng vật liệu là có thể khắc phục texture và normal mapping thiếu tốt. Điều đó không đúng, và là hệ quả của việc các câu chữ marketing của những thứ như Unreal Engine bị hiểu sai hoặc bóp méo.
    Trong Super Mario Sunshine, những cái bóng “sắc nét” mà GameCube không thể render thực ra dùng mesh phẳng. Ở Delfino Plaza, bóng dưới mái che gần Shine Gate không phải texture mà là mesh. Ngược lại, lý do quảng trường lát gạch nơi đặt bóng mesh đó trông đẹp không phải vì một texture khổng lồ, mà vì hàng chục texture 128x128px được UV mapping đúng cách.
    Nếu là game hiện đại, có lẽ họ sẽ dùng hai texture gạch và một mẫu noise để trộn chúng, cả ba đều 2048x2048px, còn bóng thì dùng ray tracing để tạo cạnh sắc. Trớ trêu là dù VRAM và tốc độ bus đã tăng, chúng ta lại chọn texture lớn hơn thay vì nhiều texture hơn. Normal mapping cũng vậy: thay vì dùng cùng với mô hình được chia nhỏ chi tiết hơn, người ta nhầm tưởng rằng normal map đã lỗi thời và mô hình hóa thật mọi chi tiết mới là con đường tiên tiến về kỹ thuật. Một quả cầu ít góc cạnh hơn thì ổn, nhưng mô hình hóa thật mọi vết nứt và vết xước trên quả cầu là ngớ ngẩn và lãng phí tính toán.
  • Với những thứ như Unity, có thể tạo ra thứ gì đó chạy được khá nhanh, nhưng để nó trông thật đẹp thì cần kỹ năng riêng và công đoạn trau chuốt.
    Ngay cả game “2D” như Factorio cũng có khác biệt về độ polish rất lớn giữa bản phát hành đầu tiên, bản 1.0 và phiên bản hiện tại. Sự khác biệt này cũng thấy rõ trong game có mod: tài sản từ mod thường “dùng được”, nhưng trông không được trau chuốt như nội dung gốc.

• Gần đây tôi chơi lại Half-Life 2, và ngạc nhiên vì ngay cả không có gói texture độ phân giải cao, đến giờ nó vẫn đẹp đến vậy.

  • Tôi cho rằng đó là vì game đã chọn art style cực kỳ thông minh. Có nhiều bề mặt phản xạ khuếch tán, rất hợp với cách bake ánh sáng trước, và bầu trời âm u cho phép ánh sáng môi trường tỏa rộng thay vì ánh sáng định hướng buộc phải có shading phụ thuộc góc nhìn và viền bóng sắc, tương phản cao.
    Các bề mặt bóng cũng phần lớn không quá bóng, điều này cũng giúp ích. Những lựa chọn này rất phù hợp với một thế giới dystopia cực đoan, cũ kỹ và bị chiếm đóng, nên trông đáng tin; các texture có tông màu trầm thì gắn kết toàn bộ lại.
  • Vì vậy tôi nghĩ art direction thật sự tốt luôn thắng sức mạnh đồ họa thuần túy. Source vào thời đó cũng đã ấn tượng, nhưng phần trụ lại lâu dài là môi trường và model được thiết kế tỉ mỉ đến mức nào.
    Valve tập trung tài nguyên vào việc đưa chi tiết vào trong các giới hạn kỹ thuật và vắt kiệt chúng, và 20 năm sau nó vẫn giữ được vẻ nhất quán, được thiết kế tốt.
  • Half-Life 2 đã nhận nhiều bản cập nhật về shading và mức độ chi tiết sau khi phát hành, nên trông có phần tốt hơn so với lúc ra mắt. Dù vậy, ngay tại thời điểm phát hành nó đã là một game ấn tượng về mặt hình ảnh.
  • Tôi chơi lại Half-Life 2 chưa đầy một tuần trước, và nghĩ rằng “dù các màn chơi không đầy ắp chi tiết như game hiện đại, định hướng nghệ thuật của đồ họa và thiết kế màn chơi vẫn tốt hơn nhiều nhà thiết kế hiện đại có ngân sách lớn hơn”.
  • Black Mesa, bản remake HL1 trên engine HL2, cũng rất đáng chơi. Tôi đã chơi trong thời dịch và không hối tiếc.

• Từ góc nhìn của một người làm trong một nhóm nhỏ tạo game low-poly bằng Godot, thứ này thật tuyệt.
  Những câu như “khi tạo thứ gì đó bằng node, bạn phải liên tục qua lại giữa GUI node và code”, “các engine chủ lưu có một trình biên tập game khổng lồ duy nhất, và dù dùng tính năng nào bạn cũng phải chờ 10 phút cho mọi thứ tải xong” rất chạm đúng trải nghiệm của tôi. Ngay cả trong Godot, dù hầu như không dùng các tính năng hào nhoáng, vòng lặp debug vẫn cảm thấy chậm hơn nhiều so với khi tôi lập trình trong các môi trường khác.
  Ý tưởng nhiều trình biên tập cùng hoạt động quanh một đặc tả file dữ liệu duy nhất cũng hay. IDE tích hợp khiến nhiều lập trình viên dễ tạo merge conflict, nên các trình biên tập có mục đích cụ thể hơn cũng có thể giúp lập trình viên theo từng vai trò giới hạn phạm vi và tính chất thay đổi. Rất mong xem engine này sẽ phát triển như thế nào.

  • Tháng trước ở một hackathon, tôi khá tự hào vì đã tìm ra cách phát triển module C# theo hướng test-driven mà không cần mở Unity.
    Ngay cả với một chiếc netbook hiệu năng thấp, tôi vẫn có thể đóng góp phần của mình. Tôi chưa từng viết một dòng C# nào, nhưng không định từ bỏ TDD trên dòng lệnh. Tôi biết là có thể, và cuối cùng đã làm cho nó chạy được. Mọi người đều nghĩ tôi điên, còn các nhân viên quan hệ nhà phát triển của nhà tài trợ thì chẳng giúp được gì.
    Ma sát lớn nhất cuối tuần đó vẫn là việc chiếc máy tính tốt nhất phải tốn cả một thời gian dài chết tiệt chỉ để bật và bật lại Unity IDE. Thật đáng kinh ngạc khi người ta chịu đựng những xiềng xích như vậy.

• Tác giả dùng các từ “Turbobloat” và nói engine “cồng kềnh”; ở mức nào đó thì đúng. Tuy nhiên, đáng lẽ nên giải thích điều đó có nghĩa gì với chính tác giả, những tính năng nào được xem là sự cồng kềnh, và dự án Tramway đã loại bỏ những gì.
  Ví dụ, với một số người, việc bao gồm cả RPG framework cũng có thể bị xem là cồng kềnh, mà Tramway lại có phần đó.

  • Vì vậy tôi đưa nó vào dưới dạng tính năng mở rộng tùy chọn. Nó là một phần của dự án engine lớn hơn, nhưng hoàn toàn tùy chọn.
    Tôi thích nguyên tắc “chỉ trả chi phí cho những gì bạn dùng” của C++.

• Có ghi là “cách dùng framework dành cho người mới bắt đầu thấy C++ đáng sợ hoặc đơn giản là không làm được”, và tôi thuộc nhóm sau nên rất biết ơn trang Getting Started
  Ấm trà đã xuất hiện, và tôi đã hiểu những thứ mà tôi tưởng mình sẽ không hiểu. Giờ tôi chỉ có 30 phút nghỉ trưa nên không đủ thời gian hoàn thành tutorial, nhưng việc tôi muốn tiếp tục đã cho thấy tài liệu này thú vị và dễ tiếp cận đến mức nào

• Có ai tìm thấy trang Design Patterns chưa? Đây là bảng điểm mục tiêu 100%, tôi thích nó quá

  • Nó được liên kết ở trang chủ: “Đã dùng 82% các design pattern. Khi dùng hết mọi pattern, dự án sẽ bị xóa và viết lại bằng Rust. Không hướng đối tượng”
  • Tôi đã tìm khá lâu mà vẫn chưa thấy