Khi tạo mẫu, làm thế nào tôi có thể dễ dàng khám phá hành vi trò chơi hơn?

Tôi tự xây dựng các trò chơi độc lập, nhưng tôi thường hết năng lượng một khi tôi đã đưa một trò chơi mới được phát triển đến một mức độ có thể chơi với hành vi, vì vậy tôi giải quyết để sàng lọc thay vì khám phá. Với kết quả khủng khiếp.

^{(hình ảnh từ blog Liên lạc )}

Ví dụ, tôi thấy rằng các chu kỳ lặp để điều chỉnh hành vi (nghĩa là liên kết và khởi động lại ứng dụng C ++) quá dài đến nỗi chúng giết chết mọi sáng tạo. Tôi đang xây dựng một công cụ để đối phó với điều này.

Những cách khác tồn tại để nhanh chóng khám phá hành vi trò chơi? Tôi quan tâm đến các phương pháp được sử dụng bởi các nhà phát triển độc lập cũng như các công ty lớn hơn.

Như bạn đã lưu ý, khi bạn làm việc trên cơ chế trò chơi, tốc độ lặp là rất quan trọng. Thời gian giữa việc nghĩ đến một sửa đổi và có thể kiểm tra với sửa đổi đó càng lâu, bạn sẽ càng làm việc kém hiệu quả hơn và bạn sẽ càng mất tập trung hơn. Kết quả là, bạn chắc chắn muốn được quản lý thời gian lặp lại của mình.

Đối với tôi, tôi thấy rằng năng suất của tôi thực sự bắt đầu giảm khi thời gian kiểm tra một thay đổi đơn giản vượt quá khoảng năm giây. Vì vậy, khi bạn đang thử nghiệm để hoàn thiện cảm giác của trò chơi, một trong những mục tiêu của bạn phải tìm ra "làm thế nào tôi có thể thay đổi và sau đó chơi bằng cách sử dụng thay đổi đó trong vòng năm giây". Nó không thực sự quan trọng như thế nào bạn làm điều đó, miễn là bạn có thể giữ thời gian lặp đi lặp lại xuống mức đó.

Rất nhiều công cụ hiện đại lớn (Unity, Unreal, v.v.) có xu hướng làm điều này bằng cách đưa trình soạn thảo của họ vào trong công cụ trò chơi, để bạn có thể thực hiện hầu hết các sửa đổi trực tiếp mà không cần phải khởi động lại trò chơi. Động cơ / trò chơi nhỏ hơn thường tập trung làm việc theo hướng khác; làm cho trò chơi được biên dịch và khởi chạy nhanh đến mức không thành vấn đề nếu bạn phải khởi động lại trò chơi cho mỗi thay đổi; bạn vẫn sẽ tham gia và thử nghiệm trước khi giai đoạn năm giây kết thúc.

Trong dự án hiện tại của tôi, tôi mất khoảng mười giây để thực hiện một biên dịch lại nhỏ, liên kết, khởi chạy trò chơi và sau đó tiếp cận trò chơi (hầu hết điều đó tạo ra hình học thế giới có thể kết xuất khi tải một trò chơi đã lưu). Và điều đó quá dài. Vì vậy, tôi đã tạo các chế độ trò chơi "thử nghiệm" riêng biệt cho phép tôi thử nghiệm các phần khác nhau của trò chơi mà không cần tải tất cả tài sản trò chơi thực sự, để tôi có thể vào và ra nhanh hơn, nhanh hơn nhiều; thông thường trong khoảng hai đến ba giây. Nếu tôi muốn kiểm tra một số UI, tôi có thể làm điều đó mà không cần tải vào trò chơi thực sự. Nếu tôi muốn kiểm tra kết xuất, tôi có một chế độ khác nơi tôi có thể kiểm tra lại, mà không cần tải lên toàn bộ hệ thống trò chơi.

Tôi đã thấy những người khác đã tiếp cận vấn đề bằng cách đặt logic trò chơi vào một DLL và để cho trò chơi đã có trong bộ nhớ thực thi tải lại DLL trong khi trò chơi đang chạy, vì vậy bạn có thể xây dựng lại DLL và chỉ cần tải lại vào bên trong đã được tải sẵn, vì vậy bạn không cần tải lại / xây dựng lại tài sản nghệ thuật của trò chơi. Điều này có vẻ như điên rồ với tôi, nhưng tôi đã thấy nó được thực hiện.

Đơn giản hơn nhiều so với việc chỉ định các hành vi và / hoặc cấu hình trò chơi trong tập lệnh hoặc tệp dữ liệu và cung cấp cách để hệ thống của bạn tải lại các tệp đó, theo yêu cầu hoặc có thể chỉ cần xem chúng để sửa đổi mà không cần phải tắt Trò chơi xuống, liên kết lại, và sau đó khởi động lại.

Có rất nhiều cách tiếp cận. Chọn những gì làm việc tốt nhất cho bạn. Nhưng một trong những chìa khóa để hoàn thiện thành công cơ chế trò chơi là việc lặp lại cực kỳ nhanh chóng. Nếu bạn không có điều đó, hầu như bạn không làm gì khác.

Để nguyên mẫu tốt, giảm chi phí của ý tưởng thử nghiệm.

Quy trình làm việc của tôi được điều chỉnh cho các trò chơi nhỏ, nhưng tôi đã thấy những điều này hữu ích:

• Công nghệ thân thiện với nguyên mẫu  Tôi thấy hữu ích khi sử dụng ngôn ngữ và khung lập trình động, chẳng hạn như Lua ( LÖVE phù hợp với 2D), JavaScript hoặc Lisp / Scheme trong đó việc chương trình thực hiện điều gì đó yêu cầu tổ hợp phím tối thiểu, thậm chí với chi phí của mọi thứ khác. Khi bạn biết bạn muốn gì và muốn tinh chỉnh nó, hãy tối ưu hóa hoặc chuyển sang một số công cụ khác.
• Kiểm soát phiên bản  Giữ nguyên mẫu trong kho lưu trữ kiểm soát sửa đổi . Chi nhánh sớm, chi nhánh thường xuyên. Điều này giúp bạn thoải mái thử mọi thứ mà không lo bạn sẽ mất hoặc quên thứ gì đó. ( Git có mô hình phân nhánh rẻ nhất.)
• Xây dựng tự động hóa  Hãy chắc chắn rằng bạn cần làm ít nhất có thể để thực sự có được thứ để chạy. Theo tôi, thậm chí phải nhấn nút là quá nhiều: Tôi thường có Makefilemột make watchmục tiêu chạy inotifywaittrong một vòng lặp, phản ứng với các thay đổi tệp bằng cách tự động biên dịch / chạy trò chơi. Trong một ngôn ngữ được biên dịch hoặc biên dịch JIT , đây là ngay lập tức.

Là một nhà phát triển tập trung chủ yếu vào tạo mẫu, đây là một chút lời khuyên từ kinh nghiệm của tôi.

1. Sử dụng một công cụ cho phép bạn thay đổi NHANH CHÓNG. Điều này bao gồm những thứ như "Không chờ biên dịch", mà còn "thay đổi mọi thứ trong thời gian chạy", "dễ gỡ lỗi", "tính sẵn có của tài sản thử nghiệm", v.v. Cá nhân tôi yêu Unity3D, nhưng nó không phải là công cụ tốt nhất hiện có. Công cụ tốt nhất phụ thuộc vào trò chơi: ví dụ: Unreal Engine biên dịch mã chậm hơn Unity3D, nhưng nó có thể nhanh chóng khởi chạy nhiều máy khách được kết nối. Đối với một trò chơi nối mạng, điều này thường bù đắp chi phí biên dịch. Cân nhắc cũng quen. Nếu bạn là một người cuồng với C ++, thì ngay cả công cụ Javascript tốt nhất cũng sẽ không hoạt động tốt và ngược lại. Đừng dành thời gian vật lộn với công nghệ xa lạ (ý tôi là, học các ngôn ngữ / khung khác, nhưng không đồng thời tạo ra các nguyên mẫu quan trọng).
2. Tìm hiểu để loại bỏ các tính năng hiện có không thương tiếc. Bám vào những thứ mà bạn đã thực hiện là sự vô cảm để tạo mẫu thành công, nhưng buông bỏ công việc của bạn là khó khăn.
3. Nếu bạn không làm việc với một nhà thiết kế trò chơi, hãy đặt một ranh giới rõ ràng giữa "đội mũ lập trình viên" và "đội mũ của nhà thiết kế". Thêm một tính năng chơi trò chơi mới thú vị có vẻ rất hấp dẫn, nhưng đừng làm vậy khi bạn ở vị trí nhà thiết kế. Thay vì cố gắng tạo ra trò chơi thú vị (tốt nhất là nhiều biến thể) với những gì bạn có; lập một danh sách các tính năng sẽ giúp và sau đó thực hiện (một số) chúng.
4. Tạo mẫu nhanh liên quan đến sự cân bằng giữa hai mặt đối lập. Bạn muốn làm cho công cụ càng nhanh càng tốt, vì vậy bạn viết mã xấu. Nhưng bạn muốn thay đổi công cụ càng nhiều càng tốt, vì vậy bạn phải viết mã tốt! Học cách cân bằng hai điều này. Xin lỗi, tôi không thể nghĩ ra bất kỳ lời khuyên cụ thể nào về cách thực sự làm điều này, nhưng ít nhất là ý thức được vấn đề này (-8

Nhìn vào bao nhiêu thời gian tạo mẫu của bạn yêu cầu. Theo kinh nghiệm của tôi, bạn muốn có một phiên bản có thể chơi được của bất cứ thứ gì trong tối đa hai ngày - bắt đầu từ đầu; và bạn muốn thử nghiệm một hoặc hai tính năng mới mỗi ngày. Nếu bạn không đạt được các mục tiêu này, hãy tìm cách để nhanh hơn.

Người ta có thể phân chia phát triển trò chơi giữa bốn giai đoạn này:

• tạo mẫu
• sàng lọc trò chơi
• phát triển
• sàng lọc hiệu suất

Khám phá trò chơi tôi tin rằng xảy ra chủ yếu ở giai đoạn tạo mẫu và đây là một số lời khuyên tôi cố gắng làm theo:

• Bắt đầu thiết kế với một nguyên mẫu giấy. Sau khi bạn có một ý tưởng rõ ràng về trò chơi có thể là gì, hãy bắt đầu mã hóa nó để bạn thực sự có thể cảm nhận được các tương tác. Có thể điều này là vô ích đối với các trò chơi 3D nhưng cá nhân tôi đã giúp tôi rất nhiều trong quá khứ.

• Mã biết rằng bạn sẽ vứt bỏ mã của mình sau khi bạn hoàn thành. Điều này sẽ cho phép bạn tự do khi chọn công cụ trò chơi nào.

• Chu kỳ lặp nhanh là rất quan trọng (như những người khác đã chỉ ra trước đây). Chọn một công cụ trò chơi dựa trên khả năng của nó để nhanh chóng cho bạn thấy những gì bạn đã mã hóa. Bạn cũng không cần phải quan tâm đến hiệu suất hoặc độ trung thực đồ họa trong giai đoạn này.

• Giới hạn phạm vi của bạn. Nếu lối chơi thực tế là 2D (trò chơi chiến lược thông thường, JRPG), nguyên mẫu ở dạng 2D. Trong giai đoạn này, bạn chỉ quan tâm đến phản hồi về lối chơi .

• Đừng lãng phí thời gian đánh bóng hoặc tìm kiếm tài sản. Viết nguệch ngoạc một cái gì đó trên một tờ giấy, chụp ảnh nó, cắt nó trong Photoshop, có thể tô màu nó và sử dụng nó như một sprite. Bật micrô của bạn và nói "pew pew". Đặt hai hình khối và một hình cầu lại với nhau và bạn có một robot. Luôn ghi nhớ, khám phá khả năng chơi trò chơi là ưu tiên hàng đầu và duy nhất của bạn.

Sau khi quyết định một nguyên mẫu thú vị, hãy bắt đầu tinh chỉnh nó. Tôi không nghĩ có lý do để chuyển đổi công nghệ trừ khi có yếu tố chơi trò chơi cần nó.

Sau đó trong giai đoạn phát triển, bạn sẽ giữ nguyên mẫu tinh tế trong tay trong khi phát triển một trò chơi mới, đẹp hơn nhiều, âm thanh hay hơn, cảm giác tốt hơn nhiều. Ở đây bạn phải chọn công cụ trò chơi thực tế để sử dụng.

Cuối cùng, lấy những gì bạn có và điều chỉnh nó để sử dụng ít tài nguyên hơn.

Hầu hết những gì tôi mô tả ở trên nó là kiến ​​thức phổ biến nhưng đưa nó ra một danh sách, ngăn chặn toàn bộ quá trình phát triển, giúp tôi đặt từng bước trong quan điểm. Tôi hy vọng nó cũng giúp bạn.

Tôi đồng ý với câu trả lời của Trevor Powell rằng tốc độ lặp là rất quan trọng để bạn duy trì tâm trạng sáng tạo thay vì chỉ đánh bóng. Một nguồn cảm hứng lớn cho tôi là bài nói của Bret Victor, "Phát minh về nguyên tắc" . Thật không may, thật khó để tìm thấy các công cụ thực sự ở cấp độ đó. Tôi đã cố gắng tự xây dựng một bản phát triển Python cho phép tôi chạy mã Python của mình trong khi tôi đang gõ nó. Nó được gọi là Mã hóa trực tiếp trong Python .

Tôi đã xây dựng một công cụ tạo mẫu có tên là Trabant :

• là 3D và CHỈ cơ chế trò chơi (không có UI, không có văn bản, không có gì);
• yêu cầu rất ít mã và không có tài sản để xây dựng nguyên mẫu;
• Các mô hình 3D được tạo bằng mã bằng nghệ thuật ASCII ;
• cho phép lặp lại thứ hai phụ;
• có hỗ trợ mô phỏng cơ thể cứng nhắc;
• hoạt động trên Windows, Mac, Linux và iOS;
• sử dụng một ngôn ngữ có mục đích chung nổi tiếng, Python;
• có IDE cho Windows và iOS.

Tôi đã xây dựng 30 nguyên mẫu thử nghiệm trong đó để xác minh những điều trên.

Như Trevor Powell nhấn mạnh các lần lặp lại cần phải <5 giây và tôi thấy các lần lặp <1s gần gấp năm lần.:)

Anko đã đề cập rằng sử dụng ngôn ngữ động là một ý tưởng hay, tôi đã chọn Python vì đây là một trong những ngôn ngữ được sử dụng rộng rãi nhất . Về tự động hóa xây dựng, thử nghiệm trong Trabant cũng nhanh như nhấn F5 trong IDE (hoặc F6 để kiểm tra nó trên iPad của bạn) và vì không có bước xây dựng nào liên quan nên nó không nhận được nhiều hơn ngay lập tức.

Throwaway đang là một trong những Nevermind của takeaways . Tôi hoàn toàn đồng ý, và Trabant thi hành nó.

Ngoài tốc độ lặp lại của Trevor Powell, điều thực sự quan trọng, đây là một số cân nhắc hữu ích khác:

Nó giống như mã tốt ...

Rất nhiều IF trong đó.

Khái niệm càng vững chắc thì bạn càng cần ít đồ chơi xung quanh. Nếu bạn biết phần thịt của bạn đang cố gắng làm là gì, tạo mẫu trở thành - những gì cần đặt và cách sắp xếp mọi thứ liên quan đến trụ cột trung tâm (điều chính của bạn).

Nếu bạn đang bắt đầu như nhiều người khác - không hoàn toàn chắc chắn những gì bạn muốn làm, bạn đi theo một hướng và khám phá nhiều theo cách của hình ảnh bạn đã hiển thị.

Dù bằng cách nào, cam kết đối với một công nghệ là không liên quan nếu những gì bạn đang tìm kiếm có thể được mô phỏng mà không có nhiều chiều sâu - nguyên mẫu nó trên bất cứ điều gì bạn muốn / có thể.

Đừng lãng phí thêm một giây cho tài nguyên. Tải xuống mọi thứ từ internet. Độc quyền hay không. Bạn đang muốn cảm nhận khái niệm của bạn tại nơi làm việc - trừ khi đồ họa là tính năng chính của bạn, không ai sẽ kiện bạn để thử nghiệm âm thanh, kết cấu và mọi thứ của người khác, bạn chưa đặt nó lên kệ trong cửa hàng. Trừ khi bạn đã được tài trợ - thuyết phục mọi người, khái niệm này đáng giá là điều sẽ giúp bạn có tiền để có được tài nguyên bạn muốn. Tôi đã thấy những người chơi game studio trình bày các khái niệm trò chơi với các phiên bản mod của trò chơi độc quyền mà họ không có quyền.

Nó giống như bạn đang xây dựng một mô hình quy mô. Trong khi thật tuyệt vời khi có một bản sao cuộc sống thu nhỏ của những gì bạn muốn. Đôi khi nó đủ để cắt nó ra khỏi tạp chí, thủ công và dán các mảnh lại với nhau. Mọi người với một chút tưởng tượng sẽ không cho rằng bạn thực sự sẽ xây dựng tòa nhà chọc trời từ cùng một tấm bìa cứng mà bạn đã cho thấy mô hình quy mô. Và trong các ngành công nghiệp sáng tạo - loại hình thích hợp hơn để làm việc với những người có trí tưởng tượng. Nếu họ không thể xem qua một số vấn đề dự thảo để thấy tiềm năng đằng sau toàn bộ khái niệm, họ sẽ hiếm khi đánh giá cao một sản phẩm. Không đánh giá cao có nghĩa là họ ít sẵn sàng cam kết và đó là một vòng xoáy đi xuống. Đó là sự khác biệt giữa việc thiết lập thái độ của con bạn để chinh phục thế giới và thay vào đó là nói "Bạn thậm chí không thể buộc đôi giày của mình đúng cách.

Bất cứ điều gì bạn có thể làm luôn luôn nhớ thái độ một mình là quá đủ để làm hỏng bất cứ điều gì tuyệt đối bất kể tiềm năng công nghệ hoặc kinh tế của nó.

Tôi đã từng tạo ra một trò chơi bằng cách sử dụng hình ảnh gif độc quyền và cung cấp cho họ một chút gì đó để làm với javascript. Nó không chói mắt nhưng nó phục vụ mục đích thể hiện những gì tôi muốn thể hiện. Không thành vấn đề nếu sau này bạn phát triển nó cho Xbox.

Nếu ý tưởng của bạn phức tạp hơn một nguyên mẫu đơn giản, thì bạn sẽ phải đưa nghiên cứu vào công nghệ mà bạn sẽ sử dụng - vì nguyên mẫu sẽ là giàn giáo cho điều cuối cùng (đơn giản là vì đã đầu tư rất nhiều vào nó và nó không thể bị ném đi một cách nhẹ nhàng) - nếu bạn được chấp thuận rõ ràng.