Phát triển trò chơi khác với phát triển phần mềm khác như thế nào? [đóng cửa]

Đối với một nhà phát triển phần mềm có mục đích chung, sự khác biệt cụ thể về phát triển trò chơi, về cơ bản hay chỉ là sự khác biệt về mức độ?

Tôi đã thực hiện các trò chơi đồ chơi như Tic-tac-toe, Tetris và người giải sudoku mạnh mẽ (có UI) và bây giờ tôi đang bắt tay vào một dự án cỡ trung bình (cỡ trung bình để trở thành một nhà phát triển duy nhất và không có đã thực hiện nhiều trò chơi) và một điều tôi đã tìm thấy với dự án cụ thể này là việc phân tách các mối quan tâm khó khăn hơn rất nhiều vì mọi thứ đều ảnh hưởng đến trạng thái và mọi đối tượng có thể tương tác với mọi đối tượng khác theo vô số cách.

Cho đến nay tôi đã quản lý để giữ mã sạch một cách hợp lý cho sự hài lòng của mình nhưng tôi thấy rằng việc giữ mã sạch trong các trò chơi không tầm thường khó hơn rất nhiều so với công việc hàng ngày của tôi.

Trò chơi tôi đang làm là theo lượt và đồ họa sẽ khá đơn giản (dựa trên web, chủ yếu thông qua thao tác DOM) nên thời gian thực và công việc 3d không thực sự phù hợp với tôi, nhưng tôi vẫn quan tâm đến câu trả lời liên quan đến những câu hỏi nếu chúng thú vị. Chủ yếu là quan tâm đến logic trò chơi nói chung mặc dù.

PS Hãy thoải mái thử lại cái này, tôi không thực sự chắc chắn những thẻ nào được áp dụng.

Có một sự khác biệt lớn. Theo tôi, đó là sự khác biệt duy nhất thực sự quan trọng.

Chúng ta có thể xem qua các chi tiết kỹ thuật về lý do tại sao nó khác biệt, chắc chắn. Động cơ 3D, vật lý hạt, rất nhiều thứ khác nhau ra đời.

Nhưng rất nhiều dạng phần mềm khác nhau có chuỗi đính kèm. Phần mềm mô hình hóa phải làm rất nhiều thứ giống nhau. Mỗi phần mềm quan trọng có một số thư viện chuyên dụng mà nó phải sử dụng.

Vậy điều gì làm cho GAME khác biệt?

Đây là: Phần mềm được thiết kế để đáp ứng nhu cầu kinh doanh. Bạn muốn có một hệ thống hàng tồn kho? Bạn có thể xác định loại mặt hàng nào bạn muốn xử lý. Bạn có thể xác định những gì bạn muốn cho lập kế hoạch sản xuất của bạn. Bạn có thể làm tất cả điều đó. Hoặc nếu bạn muốn phần mềm ngân hàng, bạn có thể xác định những gì bạn muốn làm với nó.

Với các trò chơi, nhu cầu kinh doanh của bạn là "vui vẻ". Hãy thử viết một đặc tả kỹ thuật cho "vui vẻ".

Điều đó, theo ý kiến ​​khiêm tốn của tôi với tư cách là một nhà phát triển, là điều làm cho các trò chơi khác với phần mềm thông thường. Bạn chỉ đơn giản là không thể nói "Tuyệt vời! Phần mềm này hiện đã hoàn thành tính năng theo yêu cầu của khách hàng!" bởi vì tất cả những gì họ muốn làm là vui chơi

Điều đó đang được nói, bạn không cần đồ họa 3d và vật lý xa hoa cho một cái gì đó để được vui vẻ. Tại sao mọi người vẫn chơi Tetris? Vật lý của nó bao gồm "di chuyển chặn xuống" "không để khối vượt ra khỏi giới hạn" và "dừng chặn khi nó chạm phải thứ gì đó", và trong nhiều năm qua, có rất nhiều phiên bản, một số phiên bản có đồ họa lạ hơn các phiên bản khác, nhưng điểm mấu chốt là - thật vui !!

Vì vậy, nếu bạn muốn trở thành một nhà phát triển trò chơi tuyệt vời, đừng bỏ qua những gì bạn đã học như một nhà phát triển phần mềm thông thường. Nó vẫn là những thứ rất hữu ích. Và @Sion đúng về việc tách các thành phần của bạn, giống như bạn làm trong một phần mềm thông thường. Nhưng tính năng quan trọng nhất bạn có thể thêm vào trò chơi của mình là thú vị. Vui vui vui vui vui. Đó là lý do tại sao phát triển trò chơi tồn tại, đó là những gì bạn cần để làm cho trò chơi của bạn thành công. Và hãy tin tôi đi, tuy nhiên điều này rất thú vị khi chơi, nó ít nhất gấp 10 lần để tạo ra niềm vui !!

Chúc may mắn với trò chơi của bạn !! : D

Tôi chủ yếu là một nhà phát triển trò chơi và không phải là một nhà phát triển phần mềm truyền thống, nhưng tôi nghĩ có một số khác biệt chính.

Đây rõ ràng là một số khái quát và không toàn diện:
Các đội lớn hơn. Nhiều nền tảng khác nhau (nghệ sĩ, lập trình viên, nhà sản xuất, với mỗi người thậm chí còn có nhiều biến thể hơn). Chu kỳ phát triển dài hơn. Tiêu chuẩn cao hơn về hiệu suất. Quy mô lớn hơn của các dự án. Nguy cơ thất bại lớn hơn và tốn kém hơn. Môi trường căng thẳng hơn.

Đối với các tương tác đối tượng và bố trí kiến ​​trúc của bạn, bạn vẫn có thể tách rời các hệ thống đúng cách. Đối tượng và hành vi chơi trò chơi của bạn, rõ ràng sẽ có sự phụ thuộc lẫn nhau và trên các hệ thống này. Đó là bản chất của trò chơi mặc dù (ý định chơi chữ), nó kết hợp tất cả các hệ thống này thành một đơn vị gắn kết duy nhất và không có gì sai với điều đó. Có vẻ như vậy bởi vì quy mô của tất cả đều lớn hơn bạn đã quen.

Một số hệ thống dễ dàng xác định và tách biệt?

• Phát hiện va chạm
• Phản ứng va chạm
• Vật lý
• Hoạt hình
• Đồ họa (2D và 3D)
• Trí tuệ nhân tạo
• Đầu vào của người dùng
• Nhập / xuất tệp
• Mạng

Tôi không nghĩ rằng lập trình trò chơi là bất kỳ khác biệt so với các lĩnh vực ứng dụng khác từ quan điểm của nó là khó khăn hơn để chọn đúng mối quan tâm. Bất cứ khi nào bạn đưa các kỹ năng của mình đến một loại miền ứng dụng khác, bạn sẽ thấy rằng quá trình chuyển đổi không suôn sẻ như bạn có thể hy vọng vì luôn có sự khác biệt. Những gì hoạt động trong ứng dụng cơ sở dữ liệu của bạn có nhiều mẫu / thành ngữ không hoạt động tốt trong ứng dụng nhúng của bạn, có nhiều mẫu / thành ngữ không hoạt động tốt trong hệ thống thời gian thực đó cũng có nhiều mẫu / thành ngữ đó không làm việc trong lập trình trò chơi. Tuy nhiên, các lập trình viên trò chơi có cùng một vấn đề khi họ rời khỏi miền lập trình trò chơi của họ. Tất cả chỉ là vấn đề của những gì bạn đã quen.

Như đã nói, tôi nghĩ lập trình trò chơi có vẻ khó hơn đối với nhiều người vì nó đòi hỏi bạn phải làm việc với các bộ phận của máy tính mà hầu hết các lập trình viên không bao giờ phải làm việc với công việc thực sự của họ (đồ họa và âm thanh cấp thấp) và toán học ứng dụng nhiều hơn mọi người cảm thấy thoải mái và không phải vì sự quan tâm Mặc dù luôn có những khó khăn trong việc xác định lựa chọn đúng đắn để phân tách các mối quan tâm, tôi nghĩ rằng khó khăn trong việc phân tách các mối quan tâm mà bạn đang gặp phải chỉ đơn giản là chuyển sang một miền vấn đề mới. Khi bạn xây dựng một vài ứng dụng thì nó sẽ giống như mọi thứ khác, bạn sẽ học những gì bạn thích và không sử dụng những gì bạn không.

và một điều tôi đã tìm thấy với dự án cụ thể này là việc phân tách các mối quan tâm khó khăn hơn rất nhiều vì mọi thứ đều ảnh hưởng đến trạng thái và mọi đối tượng có thể tương tác với mọi đối tượng khác theo vô số cách.

Tôi nghĩ rằng bạn có một câu trả lời ở đó, có rất nhiều tương tác. Tôi đã tạo một vài trò chơi với XNA (C #), bây giờ tôi đang làm một trò chơi cỡ trung bình như bạn nói, một trò chơi mô phỏng chiến lược, đã làm việc với nó gần 2 tháng nay và tôi làm một mình mà không có sự giúp đỡ, vì vậy tôi phải giữ mã của tôi đơn giản. Một sự khác biệt lớn tôi nghĩ, là để hiểu và thiết kế một số lớp cho chức năng, và khác để vẽ, điều này giúp và làm cho chương trình của bạn sạch hơn. Tất nhiên, nếu bạn đang làm một trò chơi, bạn cần có nhiều tài nguyên hơn, như hình ảnh (2d hoặc 3d) và âm nhạc (hoặc âm thanh). Vì vậy, có những khác biệt, tôi nghĩ nó khó hơn, nhưng nó rất buồn cười.

Tôi nghĩ Lập trình trò chơi thú vị hơn. Bạn có thể liên tục kiểm tra trò chơi của mình, bạn thực hiện các vật lý khác nhau, dẫn đến hành vi khác nhau.

Từ kinh nghiệm của tôi, lập trình trò chơi thực sự thú vị hơn rất nhiều so với phát triển phần mềm. Trong phát triển phần mềm, bạn có những quy tắc kinh doanh nhất định phải tuân theo, nó sẽ hơi nhàm chán. Bạn đang tạo ra một phần mềm, nó không vui chút nào. Sử dụng phần mềm là rất tốt, hữu ích, hữu ích, nhưng không vui vẻ.

Trò chơi rất vui. Có thể đó chỉ là tôi, nhưng tôi thấy việc phát triển trò chơi hấp dẫn và thú vị hơn nhiều so với phát triển phần mềm truyền thống, bất kể sử dụng các công cụ nào.

PS: Tôi sử dụng các công cụ mới nhất để phát triển phần mềm, HTML5, Asp.Net, C #, v.v. Tôi vẫn thấy DirectX, UDK, XNA, Unity thú vị hơn để viết mã.