Це гарна ідея розробити нетривіальну 2d гру в python? [зачинено]

Я планую розробити 2D космічну RPG, і я стою перед вибором: на якій найкращій мові це написати? Мої кандидати - C ++, Java та Python. Очевидно, я хочу писати гру в Python через її виразність, швидкість розвитку та простоту додавання сценаріїв підтримки. Але я хвилююся:

• Чи не буде Python занадто повільним? Гра не буде тривіальною (як, наприклад, Tetris), можливо, знадобиться обчислити завдання для тисяч кораблів у Всесвіті (хоча їх AI можна значно спростити, якщо ці кораблі не будуть помічені гравцю). Звичайно, я можу написати деякі критичні частини на C, але це миттєво ускладнить створення та розгортання.
• Припустимо, що гра стала популярною, і я став суперзіркою. Користувачі Windows рідко взагалі мають Python (на щастя, у нас py2exe). Python на Mac OS X може бути застарілим, і гра може вийти з ладу за незрозумілим винятком. Не буде важко розгорнути гру в Python?
• Через брак бібліотек для Python 3 мені доведеться писати гру на Python 2. Чи не перехід на Python 3 через пару років буде занадто болючим і трудомістким?

Чи не буде Python занадто повільним? Гра не буде тривіальною (як, наприклад, Tetris), можливо, знадобиться обчислити завдання для тисяч кораблів у Всесвіті (хоча їх AI можна значно спростити, якщо ці кораблі не будуть помічені гравцю). Звичайно, я можу написати деякі критичні частини на C, але це миттєво ускладнить створення та розгортання.

Важко сказати, але більшу частину часу обмежуючим фактором продуктивності є здатність / досвід людини як розробника, а не мова. Зауважте, що EVE використовує Stackless Python (див. Тут і тут для завантаження відповідної презентації). Я не пам'ятаю точних деталей, але, мабуть, більшість їх кластерних серверів працює під управлінням Python . Таким чином, я б уявив, що він може відповідати вашим вимогам до масштабованості, хоча прототипування, напевне, було б добре.

Користувачі Windows рідко взагалі мають Python (на щастя, у нас py2exe). Python на Mac OS X може бути застарілим, і гра може вийти з ладу за незрозумілим винятком. Не буде важко розгорнути гру в Python?

Більшість користувачів рідко мають відповідні бінарні залежності для ігор, незалежно від того, в якій технології були написані ці ігри (навіть для C потрібен розподільний компонент для виконання). Розгортання через py2exe або еквівалент, або просто розгортання відповідної залежності, є чимось життєвим фактом. Хоча це ніколи не найпростіша річ (більшість інсталяторських технологій болісна), це доцільно і не повинно бути приводом ухилятися від мови - як я вже сказав, вам, швидше за все, доведеться обробляти щось подібне незалежно.

Через брак бібліотек для Python 3 мені доведеться писати гру на Python 2. Чи не перехід на Python 3 через пару років буде занадто болючим і трудомістким?

Про це я мало знаю, ніколи не використовував Python 3. Я не очікую, що Python 2.X скоро зникне, однак я навіть не підозрюю, що тривалість вашої гри буде такою, що ви Вам потрібно було б перейти, якщо ви цього не хотіли, що робить це неприємним питанням.

Як говорили інші, ви занадто переживаєте про аспект вибору мови вашого проекту. Python - це потужний, корисний інструмент для розробки ігор, і якщо ви це знаєте і вам подобається, вам слід розвивати його. Не має значення, наскільки швидко працює ваша гра, якщо вона ніколи не закінчиться, оскільки ви занадто сильно переживаєте за мову.

До першого моменту вам просто потрібно буде скласти прототип і подивитися. Навіть якби ви сказали нам усі деталі, які насправді не змінили б речі.

Що стосується двох інших пунктів, мені якось здається, що ти поставиш візок перед конем. З вашого запитання здається, що ви новачок у розробці ігор, і в цьому випадку вам справді просто потрібно вибрати інструмент і піти з ним. Проблематика плюсів і мінусів переважно не менш корисних інструментів - це відволікання від вашої реальної проблеми: навчання ігровим розробкам.

re # 3, Python 2.x буде бачити підтримку дистриб'юторів щонайменше ще 5-10 років. Якщо ви використовуєте досить недавню версію (2.7 або, можливо, 2.6), шлях міграції є досить простим, якщо ви пишете захищений майбутнім код (новий стиль, об'єкт unicode скрізь, і т. Д. Тощо). Біль здебільшого стосується речей, які спиралися на стару, порушену поведінку.