Giới hạn nghiêm trọng nhất của Unity là gì? [đóng cửa]

Đã đọc câu hỏi nóng hổi này về Unity so với UDK so với ID gì đó, tôi tò mò muốn biết: giới hạn bị đánh nhiều lần, bị tê liệt nhất của Unity là gì?

Để giữ câu hỏi này không chủ quan, một lần nữa, tôi đang nói về (những) người phạm tội lặp đi lặp lại hàng đầu của Unity. Đây là điều mà, với tư cách là người dùng Unity, bạn thực sự mong muốn ai đó đã nói với bạn trước khi bạn bắt đầu sử dụng nó.

Tôi đã nghe từ ai đó rằng Unity không xử lý tốt việc kiểm soát phiên bản, vì nó tạo ra rất nhiều tệp nhị phân (không thể phân biệt được). Điều này, với tôi, không thực sự làm tê liệt khi tôi làm việc một mình.

Suy nghĩ?

Hãy để tôi nói trước rằng các anh chàng Unity đã khá giỏi khi nghe những điều quan trọng mà cộng đồng của họ phải đối mặt và cuối cùng là xung quanh để hứa hẹn cải thiện mọi thứ. Ngoài ra còn có rất nhiều vấn đề chỉ xuất hiện trên một số nền tảng nhất định hoặc là vấn đề sở thích cá nhân hoặc các vấn đề cụ thể của trò chơi mà bạn đang làm việc.

Điều đó đang được nói:

1) Tích hợp kiểm soát nguồn kém và các công cụ nhóm lớn. Như bạn đã đề cập, rất nhiều tệp nhị phân không thể khuếch tán. Trình chỉnh sửa bỏ qua cờ chỉ đọc cho các tệp cảnh. Các tập tin thực tế bạn phải kiểm tra không rõ ràng ngay lập tức. Một số điều này đang được khắc phục trong 3.5 với tích hợp SVN và P4. Ngoài ra còn có lời hứa về các định dạng cảnh dựa trên văn bản. CẬP NHẬT: Định dạng cảnh dựa trên văn bản hiện có sẵn trong phiên bản Pro của Unity. Xem tại đây .

2) Công cụ UI trung tâm chậm, lập trình viên. Mỗi tiện ích là một cuộc gọi rút thăm riêng, có rất nhiều chi phí trên nền tảng di động. Không có khái niệm về những thứ như bảng với hình động và tất cả những thứ lạ mắt khác làm cho UI cảm thấy tốt mà không cần tự lăn. Có một lời hứa về một hệ thống UI mới trên lộ trình (3.6?). Có một số công cụ của bên thứ ba nhưng chúng không tuyệt vời.

3) Thực sự chỉnh sửa hạt thô sơ. Mặc dù vậy, họ đang hứa hẹn một hệ thống dựa trên đường cong mới trong 3.5. CẬP NHẬT: Hệ thống dựa trên đường cong này, được gọi là Shuriken, hiện đã có sẵn. Xem tại đây .

4) Bạn không thể lồng prefabs. Một vấn đề nhỏ nhưng khi bạn đã quen làm việc với hệ thống prefab và tất cả sức mạnh mà nó cung cấp cho bạn, nó có thể gây nản lòng. Điều này đã được hứa nhưng không có ngày cụ thể. CẬP NHẬT: Bây giờ bạn có thể lồng prefabs.

5) Bên cạnh không thể có được một trò chơi iOS dưới giới hạn không khí. Chỉ riêng nhị phân giống như 8 megs trong trường hợp tốt nhất. Đây không phải là một cái gì đó dễ dàng sửa chữa.

6) Các nền tảng ngoại lệ tham chiếu Null không cho phép mã được biên dịch JIT. Trên các phiên bản độc lập hoặc web, NRE bị bắt. Đây vẫn là một ngoại lệ chưa được phát hiện, nhưng ít nhất ứng dụng sẽ cố gắng tiếp tục chạy. Trên iOS, nó bị sập thiết bị. Bạn có thể đặt nó trong chế độ gỡ lỗi và bắt một số loại ngoại lệ, nhưng hiệu suất bị ảnh hưởng.

7) Khi làm việc trên một trò chơi đa nền tảng, bất cứ khi nào bạn chuyển đổi mục tiêu xây dựng, bạn phải nhập lại mọi thứ và điều đó sẽ mất nhiều thời gian. Tôi đã giải quyết vấn đề này bằng cách thực sự có nhiều bản sao của dự án trên đĩa. Rõ ràng có một máy chủ tài sản nhập khẩu trong 3,5.

Khi tôi và một người bạn evalutad Unity cho một dự án lớn hơn, chúng tôi thấy rằng một trong những vấn đề lớn hơn là hiệu năng với phần mềm của họ. Nếu tôi nhớ chính xác, chúng tôi đã có một cái gì đó giống như 10 vật thể hoạt hình với khoảng 1000 câu mỗi cái và tôi có 20 khung hình / giây trong khi sử dụng máy tính giữa ... Không tốt lắm ...

Vấn đề số một của tôi là kiểm soát phiên bản lại. Giải pháp? Chỉ cần sử dụng DropBox cho các dự án Unity. Miễn là bạn thiết lập chính xác (nghĩa là trả tiền cho dịch vụ "PackRat" của họ), nó sẽ duy trì lịch sử sửa đổi. Cách này cũng dễ dàng hơn nhiều để cộng tác với các nhà thiết kế, theo cách này, những người không muốn biết về kiểm soát phiên bản truyền thống, DropBox cung cấp cho họ một giải pháp minh bạch. Nhược điểm là phân nhánh / hợp nhất không thực sự được hỗ trợ theo cách họ đang ở ví dụ. git, SVN.

Dành cho những ai nghi ngờ ...

Trong khi Dropbox hoạt động như một dịch vụ lưu trữ, trọng tâm của nó là đồng bộ hóa và chia sẻ. Nó hỗ trợ lịch sử sửa đổi, do đó các tệp bị xóa khỏi thư mục Dropbox có thể được phục hồi từ bất kỳ máy tính được đồng bộ hóa nào. [33] [34] Kiểm soát phiên bản của Dropbox cũng giúp người dùng biết lịch sử của một tệp mà họ hiện đang làm việc, cho phép nhiều người chỉnh sửa và đăng lại các tệp mà không gặp phải các biến chứng mất mẫu trước đó. [35] Lịch sử phiên bản giới hạn trong 30 ngày. Một tùy chọn trả phí cho lịch sử phiên bản không giới hạn gọi là "Gói chuột" có sẵn.

Xem ở đây để tham khảo vững chắc từ các diễn đàn Unity.

Ngoài ra, điều duy nhất tôi thấy khó chịu về Unity là nó không có điểm vào ứng dụng theo cách mà C làm (main ()) hoặc AS3 (lớp tài liệu). Nhưng bạn chỉ cần đặt init ứng dụng của mình trên một GameObject trống, không phải là vấn đề lớn. Luồng mã có một chút khác biệt xung quanh cấu trúc vốn có này, nhưng một lần nữa, không có gì quá khó để nắm bắt.

Đối với giấy phép, hầu hết mọi người không nhận ra (và tôi đặc biệt đề cập đến các hoạt động độc lập nhỏ và những người có sở thích không có tiền để trả cho một giấy phép chuyên nghiệp và addon quản lý tài sản) mà bạn có thể làm mọi thứ bạn có thể bao giờ muốn với phiên bản cơ bản / miễn phí. Thực sự, đó không phải là một rào cản lớn, nhóm Unity đã rất hào phóng.

Tôi đã nghĩ đến một hạn chế lớn khác gây phiền nhiễu cho tôi hàng ngày vì vậy tôi sẽ đăng bài này một cách riêng biệt.

Unity3D muốn bạn chỉnh sửa tập lệnh của mình trong MonoDevelop, cụ thể là phiên bản cũ của MonoDevelop mà họ phân phối. Chức năng "Tìm trong tệp" của phiên bản này bị hỏng, trong đó việc sử dụng nó thường khiến IDE bị treo, khiến nó trở nên vô dụng.

Đây sẽ là một sự khó chịu lớn với bất kỳ động cơ nào, nhưng nó là một sự khó chịu lớn với Unity vì nó khuyến khích một hệ thống phi tập trung rất riêng của các thành phần riêng biệt hoạt động trên các đối tượng trò chơi khác nhau. Nhưng làm thế nào bạn có thể tìm ra thành phần nào truy cập thuộc tính nào nếu bạn thậm chí không thể tìm kiếm trên các thành phần khác nhau?

EDIT: Câu trả lời này đã được đăng vào năm 2011: lỗi Find In Files đã được sửa cách đây một thời gian, rất may. Và như các nhà bình luận nói, bạn có thể chỉnh sửa mã của mình trong các trình soạn thảo khác (mặc dù lựa chọn của bạn bị giới hạn nếu bạn muốn có thể chạy trong trình gỡ lỗi).

Đối với tôi, hạn chế nghiêm trọng nhất là trong EULA:

"Hạn chế đánh bạc Bạn không được phân phối hoặc xuất bản bất kỳ Nội dung được cấp phép nào liên quan đến bất kỳ Hoạt động đánh bạc nào mà không có giấy phép riêng từ Unity."

Điều này có nghĩa là kể từ phiên bản 4.0, bạn không thể sử dụng Unity cho các trò chơi liên quan đến tiền mặt / cơ hội, trừ khi bạn hoặc khách hàng của bạn sẵn sàng trả một khoản phí giấy phép bổ sung được thỏa thuận trong từng trường hợp. Tức là họ thấy bạn đáng giá bao nhiêu và đánh thuế bạn theo đó, với 6 con số được trích dẫn.

Đáng lo ngại hơn là ai biết họ sẽ thêm gì vào v5 EULA. Có lẽ tất cả các trò chơi xã hội? Có lẽ tất cả các trò chơi nhiều người chơi?

Bất kỳ nhà phát triển nào sử dụng Unity đều có nguy cơ bị buộc phải chuộc trong phiên bản tương lai.

Câu hỏi hay. Đối với tôi, vấn đề lớn nhất là GUI. Tôi không bận tâm nó là trung tâm của lập trình viên, nhưng tôi nhớ cách thức khủng khiếp trong đó các đối tượng GUI là các chức năng chứ không phải là một đối tượng và việc xử lý GUI đó được nhồi vào một lệnh gọi được sử dụng để kết xuất và xử lý sự kiện, và rằng không có tích hợp với hệ thống đầu vào (có nghĩa là các nhấp chuột trên các thành phần GUI có thể được hiểu là các nhấp chuột trên thế giới), v.v.

Một vấn đề thứ yếu là thiếu hỗ trợ kiểm soát phiên bản đầy đủ (phần lớn là do hệ thống sử dụng bố cục thư mục làm bố cục dự án, điều này làm cho VCS bối rối khi bạn di chuyển hoặc đổi tên mọi thứ), nhưng điều này có thể được giải quyết và không phải là vấn đề đối với mọi người