Tại sao một nhà phát triển trò chơi sẽ viết công cụ riêng của họ thay vì sử dụng công cụ hiện có?

Tôi đã quan sát thấy rằng nhiều nhà phát triển trò chơi lớn và nổi tiếng thường phát triển các công cụ riêng của họ. Ví dụ bao gồm Valve, Crytek, Ubisoft, Epic Games và Square-Enix.

Có thể đơn giản là vì họ có thể, hoặc có khả năng là các động cơ hiện tại không đáp ứng đủ yêu cầu, vì vậy chúng tôi sẽ tự phát triển? Tôi khó có thể tưởng tượng một trò chơi đòi hỏi một công cụ cụ thể. Những thứ như Unity hay Unreal chỉ đơn giản là đủ để tạo ra bất kỳ loại trò chơi nào; ngay cả khi không, họ có mã nguồn, có thể được sửa đổi để đáp ứng ngay cả một số nhu cầu đặc biệt.

Tại sao một nhà phát triển trò chơi sẽ viết công cụ riêng của họ thay vì sử dụng công cụ hiện có?

Có một số lý do mà một studio có thể chọn "xây dựng" thay vì "mua" công nghệ của họ:

• Công nghệ kế thừa; một studio có thể đã bắt đầu xây dựng chuỗi công cụ của riêng họ trước khi có phần mềm trung gian khả thi cho nó.
• Yêu cầu cụ thể; một studio có thể có một bộ yêu cầu cụ thể không phù hợp với phần mềm trung gian hiện có hoặc
• Lo ngại về ngân sách; một studio có thể không đủ khả năng chi trả các chi phí hoặc nghĩa vụ theo hợp đồng của phần mềm trung gian hiện có.
• "Không được xây dựng ở đây hội chứng;" lãnh đạo kỹ thuật của hãng phim có thể cảnh giác (một cách hợp lý hoặc không hợp lý) công nghệ mà họ không xây dựng và do đó không hiểu đầy đủ.

Nói chung, việc sở hữu và kiểm soát những điều quan trọng đối với sự thành công của doanh nghiệp của bạn và thuê ngoài những điều không hợp lý là điều hợp lý.

Đối với một số hãng phim, khía cạnh thiết kế hoặc kể chuyện trong các trò chơi của họ có thể là tài nguyên quan trọng mà họ mong đợi để tận dụng thành công. Đối với các hãng phim, thật đơn giản khi mua công nghệ cho phép các nhà thiết kế của họ nhận ra tầm nhìn phù hợp.

Đối với những người khác, công nghệ có thể là nền tảng để thành công. Các hãng xây dựng MMO, chẳng hạn, nói chung sẽ cần phải tự xây dựng cơ sở hạ tầng đó vì nó rất quan trọng đối với thành công của họ (và phần mềm trung gian hiện tại thường không phù hợp, ít nhất là cho các tựa game "AAA" lớn hơn).

Lưu ý rằng một số studio mà bạn liệt kê (đặc biệt là Crytek và Epic) đã ngừng cố gắng thống trị trực tiếp các lực lượng trong thị trường trò chơi và gần như chắc chắn kiếm được nhiều nhà cung cấp phần mềm trung gian hơn so với các nhà phát triển trò chơi.

như Josh Petrie đã nói :

" Không được xây dựng ở đây hội chứng ;"

Tôi cũng đang viết công cụ của riêng mình và tôi cho rằng lý do sẽ khác nhau đối với mọi nhà phát triển ngoài kia, nhưng thực tế - tôi thường không thích làm việc trong mã người khác. Tôi bị ép buộc theo nghĩa là nếu tôi cảm thấy tôi có thể tự xây dựng nó, thì không có gì phải giải quyết cho bất cứ điều gì khác .

Tôi đã thử nghiệm nhiều loại công cụ trò chơi, API kết xuất và như vậy, đáng chú ý là Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre, v.v. nhiều hơn nữa ... Tôi muốn bắt đầu viết trò chơi - Tôi đã tải xuống rất nhiều và tài liệu nhập cảnh điểm ...

Tuy nhiên, vấn đề của tôi là vào thời điểm đó tôi không biết chuyện gì đang xảy ra bên dưới động cơ. Tôi muốn kiểm soát tốt, và tôi muốn một khuôn khổ mà tôi biết như mu bàn tay của tôi. Tôi đã nảy ra ý tưởng "HEY! Tôi nghĩ cách duy nhất tôi sẽ học được cách thức hoạt động của nó và hiểu nó là thử xây dựng công cụ của riêng tôi hoàn toàn và hoàn toàn từ đầu. Hầu hết lịch sử lập trình của tôi là với các giải pháp xử lý web và xử lý - đây là một trò chơi bóng hoàn toàn mới đối với tôi.

Đó là những gì tôi đã làm.

Vì vậy, tôi đã chọn thiết lập XNA vì tôi đã biết C # và bắt đầu suy nghĩ về việc tôi nên bắt đầu như thế nào hoặc ở đâu. Tôi cần một ý tưởng.

Tôi quyết định rằng, không có vấn đề gì, tôi sẽ đi thẳng vào 3D .

Làm cho các vấn đề cơ bản trở nên tuyệt vời - công cụ hàng loạt sprite, nhưng khi tôi tiến bộ, cuối cùng tôi đã phát hiện ra những rào cản và trở ngại mới - cái thực sự đầu tiên của tôi là giới hạn lô . Mục tiêu của tôi là xây dựng một trò chơi có thể kết xuất ít nhất 10000 thực thể trong chế độ xem bất cứ lúc nào.

Tôi bắt đầu một hành trình mới để thực hiện Shader Dựa Instance (và học được HLSL khi tôi ở đó), tôi đã bỏ các đối tượng Model và Effect được xây dựng của XNA để viết thay thế cho riêng mình. Tôi đã gặp khó khăn khi hiểu các luồng VBO lúc đầu; Tôi đã phá vỡ mọi thứ - Tôi đã lên mạng đặt câu hỏi về những thứ linh hoạt và giữ nó cho đến khi cuối cùng tôi hiểu GPU đang làm gì. Nó trả hết; bây giờ tôi đã có hơn hai mươi nghìn thực thể thử nghiệm phóng to xung quanh trong chế độ xem của tôi sau vài ngày gỡ lỗi VBO của tôi với PIX (dxsdk).

Bây giờ tôi đã có "một số" ý tưởng về cách hoạt động của các đường ống hoạt động, nhưng vẫn chưa được thực hiện - cuối cùng tôi đã tạo ra trạng thái trò chơi, máy ảnh, hiệu ứng bài đăng và các đối tượng thực thể của riêng mình, di chuyển khỏi Đường ống nội dung XNA bằng cách xây dựng đường ống của riêng tôi các trình tải (không thích cá nhân đối với điều XNB), đã tạo ra một chuỗi hình học phân tách trạng thái pha trộn và phân tách độ sâu phức tạp và cũng có các họa tiết và văn bản được thể hiện trong bối cảnh trò chơi.

Tôi liên tục bổ sung, sửa chữa, thay đổi và thử nghiệm điều này liên tục trong gần một năm. Cuối cùng, nó đi ra khá tốt. Bây giờ tôi đã hiểu được những gì đang diễn ra dưới mui xe, bởi vì tôi đã tạo ra nó - con tôi.

Bây giờ động cơ của tôi chủ yếu là ổn định và sắp hoàn thành. Nó không hoàn hảo: kịch bản rất tuyệt vời và GUI không tuyệt vời chút nào. Nhưng tôi vẫn yêu nó. Hàng ngàn dòng mã, tài sản và phương tiện - ẩn chứa trong kho lưu trữ git 2GB riêng tư và tất cả những vấn đề đau đầu mà tôi phải trải qua khi cố gắng thực hiện một loại phát triển mà tôi chưa từng làm trước đây. Mỗi trở ngại tôi vượt qua là một bài học kinh nghiệm - và một sự giải thoát.

Tôi rút ra gần như mọi thứ tôi muốn trong đó.

Nhưng cuối cùng - tôi quyết định đã đến lúc đặt cô ấy xuống. Tôi cảm thấy hài lòng khi tự mình viết một công cụ khổng lồ như vậy, với lời khuyên từ mạng và những người bạn chơi game khác, tôi quyết định rằng tôi sẽ làm lại từ đầu - và làm tốt hơn - bởi vì bây giờ tôi hầu như biết những gì tôi đang làm

Dự án đó vẫn nằm gọn trong repo GIT của tôi.

Lần thứ hai của tôi khi viết một công cụ mới (lần này là trên MonoGame), đang tiến triển tốt. Khi một cái gì đó bị phá vỡ, nó dễ dàng hơn để sửa chữa. Ít lộn xộn. Tôi hy vọng sẽ công khai khoe trò chơi của mình trong năm nay, bởi vì tôi có xu hướng hơi "quá" với mã của mình.

Cuối cùng, viết động cơ của riêng tôi là cách tôi học 'cách' để làm điều đó, trong khi có thể nói rằng tôi biết và hiểu chính xác mọi thành phần làm gì, và cách chúng hoạt động. Tôi thực sự ghét đọc mã của người khác, đặc biệt là đối với các dự án lớn không có giấy tờ. Tôi muốn mọi thứ tôi sử dụng được xây dựng bởi tôi.

Đây chỉ là tôi mặc dù. Tôi nghi ngờ tôi sẽ không bao giờ sử dụng một công cụ được tạo sẵn, có lẽ bởi vì tôi nghĩ việc viết các khung của riêng tôi sẽ vui hơn là ngồi và xử lý mã của người khác - toàn quyền kiểm soát.

Lý do chính tuyệt đối để viết công cụ của riêng bạn (và điều đó làm tôi ngạc nhiên rằng chưa có ai gọi nó ra) là để gỡ lỗi .

Nếu bạn đã viết một trò chơi lớn, phức tạp và có một lỗi sự cố trong đó và bạn có mã nguồn (và rất quen thuộc với mã nguồn đó nhờ vào việc đã viết nó), thì bạn có thể chỉ cần đính kèm một trình gỡ lỗi vào quá trình và tìm thấy những gì gây ra vụ tai nạn. Làm xong.

Nếu bạn đang sử dụng công cụ có sẵn trên thị trường của người khác và bạn không có mã nguồn cho công cụ đó (thông thường bạn không), thì việc gỡ lỗi bất kỳ vấn đề nào xảy ra - ngay cả trong mã của riêng bạn - sẽ xảy ra trở nên khó khăn hơn Và nếu bạn gặp phải một lỗi bên trong động cơ, bạn sẽ không thể tự giải quyết chúng. Làm thế nào bạn muốn có một tuần kể từ ngày phát hành của bạn và có ai đó phát hiện ra lỗi sự cố trong công cụ bạn đang sử dụng - một lỗi sự cố mà bạn không thể khắc phục vì nó nằm trong một công cụ độc quyền mà bạn không có mã nguồn không? Tôi đã thấy điều này xảy ra - bạn không có lựa chọn nào khác ngoài việc thực hiện một cuộc gọi hỗ trợ khẩn cấp với nhà cung cấp và hy vọng rằng họ có thể (và quan tâm đến) khắc phục sự cố cho bạn, trong khi bạn loay hoay xung quanh,

Phát triển trò chơi là khó, nhưng gỡ lỗi là thứ tự cường độ khó hơn. Trong cuốn sách của tôi, bất cứ điều gì làm cho việc phát triển trò chơi trở nên khó khăn hơn nhưng việc gỡ lỗi dễ dàng hơn là một chiến thắng ròng lớn .

Có những câu trả lời rất hay ở đây nhưng họ đang thiếu một điểm bổ sung quan trọng.

Nhiều động cơ có thể cấp phép ngày nay bắt đầu như các động cơ chuyên dụng .

Hãy lấy Unreal làm ví dụ vì nó rất phổ biến.

Ngày nay khi bạn nghĩ về Unreal, bạn có xu hướng nghĩ về một công cụ mà bạn cấp phép và có thể sử dụng thay vì phải tự chế tạo, nhưng điều đó không phải luôn luôn như vậy, và đã có lúc động cơ Unreal thậm chí không tồn tại như một thực thể riêng biệt.

Ngày xửa ngày xưa có một trò chơi tên là Unreal . Các nhà phát triển của nó đã quyết định xây dựng công cụ riêng của họ thay vì cấp phép cho một công cụ hiện có . Chuyển tiếp nhanh qua nhiều lần lặp và động cơ đó trở thành công cụ Unreal mà chúng ta biết ngày nay.

Vấn đề là đây là một vấn đề gà và trứng. Mỗi bit phần mềm trung gian bạn có thể cấp phép bắt đầu ở đâu đó và nó thường không bắt đầu như phần mềm trung gian (đôi khi nó thậm chí không được viết với ý định trở thành phần mềm trung gian và tình trạng hiện tại thực sự là một tai nạn ). Mọi người viết công cụ riêng của họ bởi vì cuối cùng ai đó phải viết công cụ này và công cụ chuyên dụng ngày nay có thể trở thành phần mềm trung gian có thể cấp phép.

Có nhiều lý do khác mà một studio có thể chọn "xây dựng" thay vì "mua" công nghệ của họ:

• Nền tảng mới: HĐH di động mới, bảng điều khiển hoặc bộ điều khiển. Hãy suy nghĩ về bước nhảy vọt, kính google, v.v ... Việc hỗ trợ đa dạng rất khó
• Cơ chế trò chơi mới và / hoặc trình chỉnh sửa trong trò chơi : Hãy nghĩ về FEZ, một số năm trước (2D so với 3D)
• Thiếu các trình soạn thảo trò chơi mã nguồn mở miễn phí tốt . Thiếu tài liệu tốt về nguồn trò chơi cũ hiện có
• Sự phát triển của các công cụ trong studio toolchain (hoặc thêm những công cụ mới)
• Giá động cơ và cuộc chiến giấy phép

Tôi cũng đồng ý với các yêu cầu / nhu cầu cụ thể và giá cả động cơ và cuộc chiến giấy phép buộc một số hãng phim tung ra một số động cơ.

Động cơ tốt để "mua" hoặc "sử dụng" các động cơ khác là:

• Tái sử dụng mã : một công cụ đã được sử dụng trong các trò chơi khác được thử nghiệm nhiều hơn, ổn định hơn và có thể có hầu hết các tính năng cần thiết, bắt đầu từ ngày đầu tiên.
• Mở rộng : bạn có thể mở rộng một số công cụ nguồn mở.
• Miễn phí : hoặc gần như miễn phí, vì ngay cả các công cụ nguồn mở miễn phí, cũng cần một số thời gian để nhà phát triển tìm hiểu.

Lý do lịch sử (chủ yếu).
Mà có liên quan đến giá cả.

Mỗi trò chơi bạn thấy chạy Unreal hoặc CryEngine trong những năm qua phải trả một số tiền rất lớn. Đặc biệt nếu bạn muốn lấy mã nguồn (ví dụ: bạn muốn UE, không chỉ UDK.)

Nhưng điều này đã thay đổi. Bây giờ tất cả mọi người có thể mua động cơ thậm chí lớn hơn, khi cuộc đua giá bắt đầu.
Điều đó có nghĩa...

• Bạn sẽ thấy nhiều trò chơi hơn sử dụng cả UE4 và CryEngine.
  Mặc dù vậy, chúng sẽ không phải là trò chơi AAA như chúng đã từng.
• Yêu cầu và nhu cầu tùy chỉnh cho từng dự án sẽ không biến mất.
  Xem công cụ Warhammer40k / COH tại Relic hoặc công cụ mà các Tướng sử dụng tại EA.
  Vì vậy, ngay cả khi bất cứ ai có thể mua các động cơ lớn hơn, họ không nhất thiết phải cung cấp một sự lựa chọn tốt hơn.
• Có những cái khác trên thị trường. Giống như Thống nhất.
  Mọi người thích nó vì nó dễ sử dụng, hiệu suất nhanh và kho tài sản khổng lồ.
  Tất nhiên, Unity có thể triển khai đến hầu hết mọi nền tảng.

Vì vậy, vâng. Nhu cầu, giá cả trong quá khứ và như vậy.

Còn tổ chức đội thì sao?

Đằng sau các công cụ gỡ lỗi là tài liệu & hỗ trợ, không có mã, vì cuối cùng tôi không muốn rằng nhóm xây dựng của tôi sẽ chạm vào mã của công cụ của riêng tôi. Đó có thể là một mớ hỗn độn.

Vì vậy, tôi cần một nhóm hỗ trợ để làm điều đó. Nhưng điều đó làm tăng chi phí: nhiều người hơn, nhiều địa điểm hơn, nhiều điện thoại hơn, nhiều quản trị hơn ...

Một giải pháp cho vấn đề này có thể là thuê ngoài ... cho một công ty phần mềm trung gian, giải phóng tài nguyên cho doanh nghiệp sản xuất trò chơi của tôi, tức là cho nhóm sáng tạo và nhà văn.

Đối với một công ty mới thành lập, đó không phải là một lựa chọn tồi để sử dụng và không xây dựng. Và, sau khi nhận được một khối thu nhập quan trọng, có thể, chỉ là có thể, bạn sẽ muốn xây dựng công cụ của riêng mình ...

tốt. cho hầu hết các trò chơi sử dụng công cụ riêng do các nhà phát triển của họ tạo ra. thường xuyên họ không thể làm mọi thứ với động cơ của bên thứ 3. vì vậy họ tự làm để phát triển trò chơi của riêng mình dễ dàng hơn. hoặc ít nhất có thể

và nhiều trò chơi sử dụng công cụ riêng của họ nói chung. làm việc tốt hơn bởi vì họ tùy chỉnh hơn và 100% phù hợp với nhiệm vụ của họ. và bản thân trò chơi cảm thấy khác biệt. nó thực sự dễ dàng để chơi một trò chơi và nói rằng đó là do. động cơ không thực hoặc bất cứ điều gì. công cụ tùy chỉnh nhiều hơn nói chung và sẽ dẫn đến một trò chơi cảm thấy độc đáo. trông độc đáo và hoạt động độc đáo và nó sẽ hoạt động tốt hơn một trò chơi được tạo ra trên một công cụ được tạo sẵn.

Câu trả lời của tôi khác với những câu hỏi hiện có, vì vậy tôi thêm nó vào mặc dù đã muộn:

Nếu bạn lấy ví dụ về Valve từ câu hỏi hoặc loạt Witcher, quy trình là:

• Cấp phép cho một động cơ
• Sửa đổi / điều chỉnh động cơ theo mục đích của bạn
• Phát hành trò chơi và tạo ra tiền
• Tạo công cụ riêng cho trò chơi tiếp theo

Cách tiếp cận tương tự được thực hiện bởi hầu hết tất cả các nhà phát triển hợp lý về tài chính, những người phát triển động cơ của riêng họ. Bằng cách sửa đổi một công cụ, họ xây dựng kiến ​​thức về cách một công cụ hoạt động và gặp phải các hạn chế thiết kế do động cơ được cấp phép. Cuối cùng, họ có kiến ​​thức nội bộ cần thiết để tạo ra một động cơ, tiền mặt để tài trợ cho việc tạo ra một động cơ và một dự án sẽ được hưởng lợi từ một động cơ chuyên dụng. Tại thời điểm đó, lý do để chế tạo một động cơ là: Bởi vì đó là điều thông minh để làm.

giáo viên lập trình của tôi nói với chúng tôi, chỉ sử dụng API / phương thức / lớp / hàm mà bạn biết cách xây dựng

bởi vì nếu bạn không biết cách xây dựng nó và đang sử dụng cơ hội làm việc của người khác thì bạn không biết nó hoạt động như thế nào và khi bạn không biết cách thức hoạt động của một cái gì đó thì bạn sẽ dễ bị lỗi và gặp rắc rối hơn

học những điều đơn giản có thể khi kết hợp với các vấn đề lạ, huống chi là một thứ phức tạp như công cụ trò chơi, đặc biệt là khi bạn phải sử dụng công cụ trò chơi đó để chạy trò chơi của mình, điều này có thể dẫn đến nhiều kết quả và sự cố không mong muốn

và công cụ trò chơi không tuân theo mã logic hoặc bất kỳ logic nào khác khi chúng được xây dựng, chắc chắn có một số điều có thể xảy ra nhưng thực tế mọi thứ sẽ được xây dựng dựa trên sự hiểu biết và kiến ​​thức về ngôn ngữ lập trình nào đó hoặc cách một số hệ thống hoạt động

ví dụ nếu tôi chọn viết phương trình toán học, tôi có thể viết nó theo nhiều cách tôi có thể biểu diễn nó bằng đa thức, hoặc phép tính vi phân hoặc hình học cơ bản hoặc đại số hoặc bất cứ điều gì phù hợp với tôi nhưng đôi khi tôi sẽ viết theo một hình thức / định dạng nhất định vì tôi muốn để có thể điều khiển những gì dễ dàng có sẵn, chẳng hạn như nếu tôi dự định thực hiện nhiều thao tác đỉnh, tôi có thể viết mô hình toán học này bằng hình học cơ bản, tuy nhiên nếu tôi muốn thay đổi đường cong bằng cách sử dụng độ dốc, tôi có thể tập trung vào phép tính vi phân để có thể để dễ dàng thao tác với độ dốc, v.v. và tôi cũng có thể truy cập dễ dàng hơn

và đôi khi công cụ trò chơi hiện tại có thể không cho tôi sự linh hoạt của những gì tôi dự định làm hoặc thậm chí có thể nó cung cấp cho bạn tùy chọn đó nhưng rất khó để thực hiện vì công cụ trò chơi tập trung vào lực vật lý là nguồn chuyển động và thao tác chính của nó đồ vật trong game

dù sao tôi hy vọng tôi đã làm rõ những gì tôi đang cố gắng chỉ ra