Bắt đầu phát triển trò chơi: XNA có phải là một lựa chọn tốt không? [đóng cửa]

Người đọc lâu năm; người hỏi lần đầu:

Tôi đã muốn tham gia một phần của ngành công nghiệp trò chơi một thời gian, nhưng sơ yếu lý lịch của tôi là 100% tất cả công việc phụ trợ.

Tôi là một nhà phát triển C ++ / C # mạnh mẽ, không có kinh nghiệm phát triển trò chơi thực tế. Trải nghiệm phụ trợ của tôi khiến tôi trở thành ứng cử viên sáng giá cho công việc phụ trợ (vì nhiều trò chơi ngày nay có các khía cạnh dựa trên dịch vụ đối với họ), nhưng đó là một lĩnh vực cạnh tranh siêu hạng và tôi đang tìm cách để nổi bật.

Vì không ai sẽ chỉ đến gần tôi và cho tôi một công việc trong ngành công nghiệp trò chơi, tôi quyết định thử chiếc mũ của mình bằng cách viết các trò chơi của riêng tôi.

Tôi hiểu tại sao C và C ++ là ngôn ngữ defacto trong phát triển trò chơi, nhưng tôi thực sự thích triết lý đằng sau XNA. Như tôi đã nói trước đó, tôi thành thạo cả C # và C ++, nhưng nếu tôi nhớ chính xác, XNA chỉ hoạt động với các ngôn ngữ tuân thủ CLR (có lẽ chỉ là C #).

Việc tập trung vào phát triển trò chơi bằng XNA và C # thay vì C ++, có làm tổn thương cơ hội của tôi trong công việc trong ngành công nghiệp trò chơi không? VB có tiếng là không công bằng khi không phải là một ngôn ngữ lập trình thực sự, và các lập trình viên VB bị cuốn vào sự kỳ thị đó. Đây có phải là trường hợp sử dụng C # trong một cộng đồng bao gồm chủ yếu là các nhà phát triển C ++ không?

Hay các nguyên tắc cơ bản của phát triển trò chơi có thể học được từ việc viết trò chơi, vượt qua ngôn ngữ và công nghệ?

Tôi không nghĩ rằng nó sẽ làm hại cơ hội của bạn. C # đang trở nên phổ biến hơn, đặc biệt là với XNA và SlimDX. Tôi đã sử dụng cả C # và C ++ và tôi phải nói rằng tôi thích XNA hơn đáng kể. Nó chỉ đơn giản hơn để làm việc với, nhưng không đến nỗi bạn cảm thấy như mình không làm gì cả.

Về phần sự nghiệp, bạn sẽ muốn đề cập rằng bạn đã quen với XNA, mặc dù tôi không nghĩ rằng điều đó sẽ làm hại cơ hội của bạn. Trong thực tế, vì cách dễ sử dụng hơn, các danh mục đầu tư của bạn có thể tốt hơn.

Và các khái niệm vẫn giữ nguyên, chỉ cần cú pháp trở nên khác nhau. Trừ khi bạn đang làm một công việc đồ họa cấp thấp, bố cục của những gì bạn phải làm sẽ gần giống nhau (không viết mã tải shader hoặc bộ đệm lưới, thay vào đó chỉ tải nó).

Theo kinh nghiệm của tôi, các khái niệm tương tự được sử dụng trong XNA chuyển qua lại giữa các thư viện và ngôn ngữ khác nhau. Tôi đã có thể chuyển đổi qua lại một cách hiệu quả giữa các công nghệ trò chơi khác nhau và tôi bắt đầu với XNA.

Làm việc với C # và XNA đã giúp tôi tập trung vào một mục tiêu học tập cụ thể ("Điều gì tạo nên một trò chơi tích tắc?") Trái ngược với các mục tiêu pha trộn ("Làm cách nào để tôi học X và tạo trò chơi cùng một lúc?"). Tôi thấy rằng bất cứ khi nào tôi kết hợp các mục tiêu, tôi đã kết thúc với kết quả khá tuyệt vời. Tuy nhiên, bắt đầu trong vùng thoải mái của tôi và dựa vào XNA đã giúp mọi thứ tiến triển.

Nếu bạn có thể tạo ra một trò chơi thú vị, và bạn thực sự là một kỹ sư tài năng, bạn không có gì phải lo lắng. Không ai sẽ ding bạn cho cách bạn thực hiện trò chơi của bạn.

Các trò chơi không được duy trì theo cách rất nhiều sản phẩm phần mềm khác. Mã vứt đi ít hơn được tạo ra so với trong ngành công nghiệp hiệu ứng đặc biệt, nhưng chúng ta vẫn có thể thoát khỏi rất nhiều hack cho kinh nghiệm.

Chỉ cần hoàn thành công việc. Vào cuối ngày, đó là những gì phát triển trò chơi.

Tôi đã được nói rằng:

1. Nội dung quan trọng hơn đáng kể so với các công cụ được sử dụng với một số ngoại lệ.

2. Mặc dù nền tảng của hầu hết các trò chơi lớn hơn là C ++, nhưng đó là do các công cụ được phát triển trong C ++. Nếu bạn không mã hóa các công cụ, có thể bạn sẽ không lập trình trong C ++.

Chỉnh sửa: Ngoài ra, có một dự án demo hoàn thành trong bất cứ điều gì (C #, v.v.) tốt hơn đáng kể so với việc có một cái gì đó không hoàn chỉnh trong một ngôn ngữ khó hơn (C ++, v.v.).