Czy dobrym pomysłem jest opracowanie nietrywialnej gry 2D w Pythonie? [Zamknięte]

Planuję opracować kosmiczną grę RPG 2D i stoję przed wyborem: w jakim języku najlepiej ją pisać? Moimi kandydatami są C ++, Java i Python. Oczywiście chcę pisać grę w Pythonie ze względu na jej ekspresję, szybkość rozwoju i prostotę dodawania obsługi skryptów. Ale martwię się:

• Czy Python nie będzie zbyt wolny? Gra nie będzie trywialna (jak na przykład Tetris), może być konieczne obliczenie zadań dla tysięcy statków we wszechświecie (chociaż ich sztuczna inteligencja może być znacznie uproszczona, jeśli te statki nie są widoczne dla gracza). Oczywiście mogę napisać niektóre krytyczne części w C, ale natychmiast komplikuje budowę i wdrożenie.
• Załóżmy, że ta gra stała się popularna, a ja zostałem gwiazdą. Użytkownicy systemu Windows rzadko mają w ogóle Pythona (na szczęście mamy py2exe). Python w Mac OS X może być przestarzały, a gra może ulec awarii z niejasnym wyjątkiem. Czy nie byłoby trudno wdrożyć grę w Pythonie?
• Z powodu braku bibliotek dla Python 3 będę musiał napisać grę w Python 2. Czy przejście na Python 3 za kilka lat nie będzie zbyt bolesne i czasochłonne?

Czy Python nie będzie zbyt wolny? Gra nie będzie trywialna (jak na przykład Tetris), może być konieczne obliczenie zadań dla tysięcy statków we wszechświecie (chociaż ich sztuczna inteligencja może być znacznie uproszczona, jeśli te statki nie są widoczne dla gracza). Oczywiście mogę napisać niektóre krytyczne części w C, ale natychmiast komplikuje budowę i wdrożenie.

Trudno powiedzieć, ale przeważnie czynnikiem ograniczającym wydajność jest zdolność / doświadczenie programisty, a nie język. Zauważ, że EVE używa Python bez stosu (patrz tutaj i tutaj, aby pobrać powiązaną prezentację). Nie pamiętam dokładnych szczegółów, ale najwyraźniej większość ich klastra serwerów działa w języku Python . Wyobrażam sobie zatem, że poradzi sobie z wymaganiami dotyczącymi skalowalności, choć na pewno prototypowanie będzie dobre.

Użytkownicy systemu Windows rzadko mają w ogóle Pythona (na szczęście mamy py2exe). Python w Mac OS X może być przestarzały, a gra może ulec awarii z niejasnym wyjątkiem. Czy nie byłoby trudno wdrożyć grę w Pythonie?

Większość użytkowników rzadko ma odpowiednie zależności binarne dla gier, niezależnie od technologii, w której te gry zostały napisane (nawet C wymaga dystrybucji komponentu wykonawczego). Wdrażanie za pomocą py2exe lub równoważnego, lub po prostu wdrażanie odpowiedniej zależności, jest faktem. Chociaż nigdy nie jest to najłatwiejsze (większość technologii instalacyjnych jest bolesne), jest wykonalne i nie powinno być powodem do unikania języka - jak powiedziałem, prawdopodobnie będziesz musiał poradzić sobie z czymś podobnym niezależnie.

Z powodu braku bibliotek dla Python 3 będę musiał napisać grę w Python 2. Czy przejście na Python 3 za kilka lat nie będzie zbyt bolesne i czasochłonne?

O tym niewiele wiem, nigdy tak naprawdę nie korzystałem z Pythona 3. Nie oczekuję jednak, że Python 2.X zniknie w najbliższym czasie, więc nawet nie podejrzewam, że czas życia twojej gry byłby taki, że ty 're potrzeba do przejścia ponad jeśli nie chcą, co czyni to dotyczyć czegoś nie problem.

Jak powiedzieli inni, zbytnio martwisz się aspektem wyboru języka w swoim projekcie. Python jest potężnym, użytecznym narzędziem do tworzenia gier, a jeśli go znasz i podoba ci się, powinieneś się nim rozwijać. Nie ma znaczenia, jak szybko działa Twoja gra, jeśli nigdy się nie skończy, ponieważ zbytnio martwisz się językiem.

Do pierwszego punktu wystarczy zbudować prototyp i przekonać się. Nawet jeśli powiesz nam wszystkie szczegóły, które tak naprawdę nie zmieniłyby rzeczy.

Jeśli chodzi o pozostałe dwa punkty, wydaje mi się, że stawiasz wózek przed koniem. Z twojego pytania wydaje się, że jesteś nowy w tworzeniu gier, w takim przypadku naprawdę musisz po prostu wybrać narzędzie i iść z nim. Rzucanie okiem na zalety i wady najczęściej równie użytecznych narzędzi odwraca uwagę od prawdziwego wyzwania: uczenia się tworzenia gier.

do nr 3, Python 2.x będzie obsługiwać dystrybutora przez co najmniej kolejne 5-10 lat. Jeśli używasz dość nowej wersji (2.7 lub ewentualnie 2.6), ścieżka migracji jest dość łatwa, jeśli napiszesz przyszłościowy kod (obiekt w nowym stylu, wszędzie Unicode itp.). Ból dotyczy głównie rzeczy, które polegały na starych, zepsutych zachowaniach.