Sự khác biệt giữa người dùng và nhà phát triển không phải lúc nào cũng rõ ràng trong phát triển trò chơi. Các kỹ thuật lập trình tiêu chuẩn như "thất bại nhanh" không phải lúc nào cũng thuận lợi, đặc biệt là khi quy mô nhóm phát triển.
Ví dụ: có lẽ nghệ sĩ kỹ thuật của bạn đã làm hỏng trình tạo bóng cho phác thảo nhắm mục tiêu - đã phá vỡ dự phòng, giả sử, vì vậy nó chỉ tải trên các hệ thống SM4 và anh ta đã không chú ý vì anh ta có một hệ thống hàng đầu. Điều này dẫn đến một số hình ảnh động không tải. Những hình ảnh động được tham chiếu bởi một câu thần chú cụ thể mà nhà thiết kế chiến đấu của bạn đã viết. Cuối cùng, nhà thiết kế cấp độ của bạn đang cố gắng tạo ra các sinh sản và tất cả những sinh sản đó đều có thể sử dụng câu thần chú đó - nhưng giờ cô ấy không thể đặt bất kỳ ai trong số họ lên thế giới vì phép thuật của họ không hợp lệ vì các hiệu ứng phát sinh Không hợp lệ vì các shader sẽ không tải vì các nhà thiết kế luôn có những máy tính tệ nhất.
Vì vậy, bản demo của bạn chưa sẵn sàng trước 2 giờ chiều và các nhà đầu tư của bạn tự hỏi tại sao bạn thậm chí không thể có được một kẻ thù trong trò chơi và dự án của bạn bị tắt.
Hoặc bạn chọn tùy chọn nơi bạn ghi lại thất bại nhưng tiếp tục thử và trò chơi vẫn hoạt động tốt ngoại trừ một số hiệu ứng chính tả của kẻ thù không xuất hiện - nhưng các nhà đầu tư không biết những gì được cho là trông như thế nào, vì vậy họ không để ý.
Vì lý do đó, tôi hầu như luôn luôn ủng hộ lựa chọn đầu tiên - sinh ra càng nhiều thực thể càng tốt. Có những trường hợp không nhanh - như nếu dữ liệu không bao giờ được chỉnh sửa trừ những người có khả năng thực hiện các bản dựng (tức là lập trình viên và nhà sản xuất kỹ thuật) và luôn được kiểm tra 100% khi tải hoặc nếu bạn chắc chắn là người chịu trách nhiệm vấn đề là người sử dụng trình soạn thảo - nhưng đó không phải là những trường hợp thông thường và đòi hỏi nhiều cơ sở hạ tầng kỹ thuật, mà bạn có thể chưa sẵn sàng đầu tư.