Khi nào bạn nên cuộn công cụ trò chơi của riêng bạn? [đóng cửa]

Tôi đã là một nhà phát triển phần mềm được 5 năm rồi và tôi muốn tham gia phát triển trò chơi iOS. Tôi đã chơi xung quanh với SDK iOS trong khoảng 2 năm, tham dự các cuộc họp về cocoahead và tôi cảm thấy mình đã nắm bắt tốt về mục tiêu - c, ca cao và thậm chí cả c và c ++.

Tôi có một ý tưởng trò chơi và biết rằng tôi sẽ sử dụng Box2D, nhưng tôi tự hỏi liệu tôi có nên sử dụng cocos2D hay không. Những lý do chính là:

1. Tôi có thể muốn làm mọi thứ, đồ họa khôn ngoan, không có sẵn trong cocos2d.
2. Nếu tôi cuộn công cụ trò chơi của riêng mình, tôi sẽ có nhiều quyền kiểm soát hơn.

Tất nhiên, lý do chính để sử dụng một công cụ trò chơi đã có sẵn là thời gian tiết kiệm và nó làm cho công cụ cứng dễ dàng hơn; Nhưng đối với một người có các kỹ thuật để tự lăn, liệu nó có ý nghĩa?

Hầu hết các bài đăng khác sẽ là "làm cho trò chơi không phải là một công cụ", nhưng tôi sẽ giả định rằng bạn có một trò chơi cụ thể mà bạn muốn thực hiện và muốn biết khi nào nên bắt đầu với mã của người khác cơ sở hoặc bắt đầu từ đầu.

Bạn không nên cuộn công nghệ của riêng bạn trừ khi bạn biết bạn cần phải tự lăn . Điều đó nghe có vẻ thiếu sót nhưng đó thực sự là câu trả lời đúng duy nhất. Như với hầu hết các quyết định, có sự đánh đổi. Chỉ bạn mới có thể xác định cho tình huống cụ thể của mình phân tích chi phí / lợi ích.

Bạn nên có một sự hiểu biết về những điều sau đây (danh sách này hầu như không bao gồm tất cả).

• Phần mềm trung gian nào đã có sẵn mà bạn có thể sử dụng ("engine" hoặc cách khác)
• Những gì mà phần mềm trung gian mang đến cho bảng, tính năng khôn ngoan.
• Phần mềm trung gian đã được chứng minh / trưởng thành như thế nào, đặc biệt nếu bạn quan tâm đến hỗ trợ đa nền tảng
• Loại công cụ trung gian nào cung cấp hoặc không cung cấp để giúp tăng tốc độ phát triển (không giảm giá các công cụ với công nghệ của riêng bạn)
• Những hạn chế mà phần mềm trung gian có (như một ví dụ đơn giản, Unity 3.x đã không thực hiện bóng thời gian thực từ đèn động trên iOS)
• Những tính năng cụ thể mà trò chơi cụ thể của bạn phải có .
• Thời hạn của bạn là bao nhiêu và bạn sẽ phải dành bao nhiêu thời gian để đi đến điểm mà phần mềm trung gian sẽ đưa bạn đến so với chi phí phần mềm trung gian là bao nhiêu.
• Phần mềm trung gian có thể mở rộng như thế nào (ví dụ: bạn có thể khắc phục sự cố bóng trên iOS trong Unity bằng cách sử dụng bóng blob. Hoặc có thể là bóng chiếu.)

(Lưu ý rằng tôi đặc biệt không đặt "nhiều quyền kiểm soát" hơn ở đó. Đó là cụm từ được tải có thể từ "Tôi không thích mã tôi không viết" đến "Tôi cần có thể nhìn, hiểu và điều chỉnh tất cả các biến trong công cụ vật lý để đạt được hiệu ứng đặc biệt này. "Cái đầu tiên không thực sự là một sự cân nhắc hợp lệ, nhưng cái thứ hai là.)

Cá nhân, tôi thấy rằng việc tung ra công nghệ của riêng bạn cho một trò chơi có ngân sách thấp hầu như không đáng để bỏ công sức. Số lượng điện năng bạn có được các động cơ giá rẻ những ngày này là vô lý. Bạn không ở thời điểm mà bạn quyết định cấp giấy phép động cơ ba triệu đô la hay không. Bạn sẽ không thể đánh bại những gì, nói, Unity cung cấp cho bạn với giá 3k. Hoặc Cocos2d cho bất cứ giá nào (không phải là miễn phí?).

Bây giờ, nếu trò chơi của bạn chủ yếu tập trung vào một số loại công nghệ mà các động cơ khác không thể cung cấp hoặc không thể cung cấp ở tốc độ khung hình hợp lý, thì có thể đáng để nghiên cứu những gì bạn có thể làm. Điều đó không có nghĩa là bạn hoàn toàn loại bỏ các phần mềm trung gian khác. Chỉ vì bạn cần trình kết xuất của riêng bạn, không có nghĩa là bạn không thể sử dụng một số phần mềm trung gian khác cho vật lý hoặc âm thanh hoặc giao diện người dùng hoặc những gì có bạn.

Đừng cuộn động cơ của riêng bạn. Cuộn trò chơi của riêng bạn. Nếu bạn tình cờ viết một công cụ cùng một lúc thì tốt cho bạn, nếu không bạn luôn có thể cấu trúc lại bất kỳ phần nào bạn có thể muốn sử dụng lại để làm cho nó trở thành "công cụ" hơn.

Mọi người thường ước tính quá mức những gì cần thiết để viết phần "động cơ" của trò chơi. Nếu bạn chỉ làm những gì bạn cần thì sẽ không mất nhiều thời gian như vậy. Điều khó khăn là không bị kẹt khi viết cơ sở hạ tầng và chỉ viết những gì bạn hoàn toàn phải giải quyết vấn đề của mình.

Tôi sẽ sử dụng một công cụ hiện có khi:

• Tôi có một thời hạn chặt chẽ
• Tôi có một bộ tính năng cố định đã biết để tôi có thể chọn một công cụ cho việc đó

Tôi nghĩ bạn chỉ nên viết trò chơi của mình và có lẽ bạn sẽ kết thúc với một công cụ sau này . Viết công cụ đồ họa (có vẻ như bạn đang nói đến) từ đầu không sử dụng gì nhưng OpenGL có thể sẽ chỉ lãng phí thời gian của bạn. Đây là một vấn đề tương đối được giải quyết tốt, do đó, nói chung, bạn chỉ thay đổi hình dạng của API mà không cần thêm nhiều tính năng mới quan trọng so với bất kỳ giải pháp bên thứ ba nào khác hiện có.

Nếu Cocos2D hoặc một số lớp đồ họa khác đáp ứng yêu cầu của bạn bây giờ, thì hãy sử dụng nó. Nếu các yêu cầu của bạn thay đổi trong quá trình phát triển, bạn có thể trao đổi kết thúc kết xuất tương đối dễ dàng - nếu bạn thực sự tin rằng bạn có kinh nghiệm và tự mình tạo ra một công cụ, bạn chắc chắn nên có những gì cần thiết để cấu trúc trò chơi của mình sao cho hoán đổi kết thúc kết xuất là một hoạt động tương đối tầm thường.

Xây dựng trò chơi của bạn, cho phép các nhu cầu cụ thể của nó điều khiển bộ tính năng của mã bạn viết và viết mã với khả năng sử dụng lại và kiến ​​trúc tốt trong tâm trí. Bạn sẽ tự nhiên kết thúc với một "công cụ" sau khi bạn hoàn thành một vài dự án như thế này và bạn sẽ hoàn thành các dự án đó nhanh hơn vì bạn không cho phép mình bị sa lầy vào tính năng leo thang ở cấp độ khung.

Nó rất đơn giản. Mục tiêu chính của bạn là gì: học tập hay thời gian để tiếp thị?

Tránh sử dụng thư viện nếu mục tiêu chính của bạn là học hỏi kinh nghiệm triển khai các khái niệm được thư viện giải quyết. Bất cứ khi nào tôi phát triển một trò chơi (bán thời gian), mục tiêu của tôi hoàn toàn là học tập. Tôi không quan tâm mất bao lâu, đó là lý do tại sao tôi làm tất cả từ đầu! Bây giờ, bạn quyết định.

Bạn nên cuộn công cụ trò chơi của riêng bạn khi bạn biết có một nhu cầu cho nó.

Vì vậy, ví dụ, giả sử bạn không có tiền để chi tiêu cho Unity. Hoặc, bạn muốn sử dụng nó cho phần cứng mới thay thế. Hoặc, có vấn đề về hiệu suất với các công cụ miễn phí có sẵn cho bạn hoặc bạn cần kiểm soát nhiều hơn ở mức thấp.

Nếu bạn thích viết phần mềm vì mục đích viết phần mềm, thì bạn sẽ thích viết một công cụ trò chơi. Một cái bẫy phổ biến của các lập trình viên trò chơi bắt đầu là bị bắt gặp viết một công cụ như một dự án vĩnh viễn. Tôi thành thật tin rằng đó là cách mà tất cả các công cụ trò chơi nguồn mở này xuất hiện - các lập trình viên trò chơi thực sự không làm

Sau đó, trong trường hợp đó, viết động cơ của riêng bạn.