Czy ktoś pisze gry w Delphi? [Zamknięte]


12

Jestem bardzo doświadczonym programistą Delphi (ponad 12 lat doświadczenia nie licząc mojego doświadczenia z Turbo Pascal) i zastanawiałem się, czy ktoś pisze gry w Delphi? Widziałem opakowania API DirectX w Delphi, które pozwalają programować przeciwko DirectX (nawet napisałem prostą grę w pasjansa z przyjacielem), ale nie widziałem niczego, co pokazuje, że powinienem nadążać za Delphi. Nienawidzę odejść od tak dużej wiedzy i języka Object Pascal, ale nie widzę powodu, dla którego warto kontynuować Delphi.

Obecnie programuję w C # i myślę o XNA, ale wydaje mi się, że dominującą opinią jest przejście na C / C ++ z DirectX.

Czy inni programiści Delphi też mają z tym problem?

Dzięki, MDV


sama w sobie nie jest grą, ale popularnym programem związanym z grą, uczniem został Delphi. Myślę, że głównym powodem, dla którego nikt go nie podjął po tym, jak się porzucił, był język.
lathomas64

Dwa lata później muszę powiedzieć: spójrz na MonoGame. To jest zajebiste. Byłoby lepiej, gdyby nie zaakceptowali żądania ściągnięcia, które
popsuło

+1 za przypomnienie Delphi :) Miałem trochę zabawy z DelphiX, ale nigdy nie zrobiłem w nim prawdziwej gry. Delphi wciąż jest dla mnie przyjemnym środowiskiem do szybkiej pracy .
Markus von Broady,

Odpowiedzi:


12

Okej, nie chcę tego mówić, ale Delphi faktycznie nie żyje. Wiem, wiem - to przygnębiające. Nie obawiają się jednak: nawet lepsze języki ewoluowały, które mają 99% korzyści z Delphi, ale jest ciężko oddychać jeszcze (naprawdę) wspierany i korzystających powszechne przyjęcie branży. Trzymając się Delphi, nie sprzyjasz swojej karierze. Pracowałem z Delphi przez około sześć wspaniałych lat, zanim podążyłem za Anderem w ciemną stronę.

Jeśli już grasz w C #, bez wątpienia zauważyłeś niesamowite podobieństwa między nim a Delphi. Twoje doświadczenie Delphi bardzo pomoże, biorąc pod uwagę podobne modele obiektów, obsługę wyjątków itp.

Jedyną zaletą Delphi nad C # jest to, że jest kompilowany do kodu natywnego. Jedyną inną grą w mieście w tych dniach wydaje się być C i C ++.

Mam fantastyczny sukces z C # i XNA. Wydajność kodu zarządzanego jest obecnie bardzo bliska wydajności kodu natywnego. Jeśli chcesz kodować dla wielu platform (Windows, Xbox, PS3 itp.), Musisz trzymać się c ++, ponieważ jest to jedyna rzecz, która zbuduje się na wszystko.

Jeśli trzymasz się Windowsa i Xboxa, XNA to świetne narzędzie.


David, niestety muszę zgodzić się ze względów praktycznych. Delphi nie żyje. I tak, C # jest bardzo „podobny” do Delphi - po prostu bardzo podoba mi się szybka, responsywna aplikacja Delphi WinApp w stosunku do C #. Jest zauważalna różnica. Chyba muszę to zassać i pozwolić Delphi odejść.
MDV2000,

Ponadto planuję pozostać przy tworzeniu gier dla systemu Windows ... nie jestem pewien, czy zależy mi na tym, aby w tej chwili stworzyć grę na konsolę Xbox i nie obchodzi mnie Linux / Mac.
MDV2000,

2
Tak, jest różnica, ale maleje. Jeśli znajdziesz się w sytuacji, w której różnica wydajności jest zbyt duża, możesz połączyć się w bibliotekach C ++, aby wykonać ciężkie podnoszenie. Jednak nie musiałem się do tego uciekać.
3Dave

W rzeczywistości, korzystając z Mono, możesz również bezproblemowo pracować na Macu / Linuksie, a MonoTouch / MonoDroid pozwala na pracę na iDevices i Androidzie. Więc to naprawdę nie jest tak ograniczające. ;)
Ipsquiggle

2
@ Ipsquiggle na pewno - mono to dobra opcja. Jeśli ignoruje Linuxa i Maca (i obaj, którzy kupili Maca do gier, mogą mnie pocałować w dupę), .NET / XNA to świetna opcja.
3Dave

4

Myślę, że Soldat jest napisany całkowicie w języku Delphi.


4
Powinienem również wspomnieć, że niekoniecznie jest to dowód na to, że jest to dobry pomysł. Wiem, że użycie określonego smaku Delphi uniemożliwiło przeniesienie gry poza Windows pomimo ogromnego zapotrzebowania konsumentów.
coderanger

3

Nie unikając głównego tytułu pytania, ale mogę zaoferować porady dotyczące innego aspektu (gdzie należy przejść dalej, ponieważ wydaje się, że już zdecydowałeś). C # i XNA są po prostu warstwą abstrakcji powyżej DirectX. Używanie C # i XNA pomoże ci skrócić czas wprowadzania na rynek i może zmniejszyć niektóre koszty rozwoju; jednak dzieje się to kosztem pewnej wydajności i kontroli.

C / C ++ i surowy Direct X jest popularny, ponieważ zyskujesz maksymalną wydajność i kontrolę. To naprawdę zależy od twoich celów. Osobiście używam C # i XNA, ponieważ jego początkowe koszty są w zasadzie zerowe (szczególnie jeśli już znasz C #) i kosztuje tylko 99 USD rocznie, aby zostać członkiem Creators Club, co jest wymagane tylko, jeśli chcesz wdrożyć swoją grę na Xbox i Windows Phone 7. Robienie C # i XNA tylko dla Windows jest całkowicie darmowe i może dawać niesamowite rezultaty. Przynajmniej polecam sprawdzić to przed skokiem do C ++ i surowego Direct X.


3

Zespół, w którym pracowałem, opracował w przeszłości całkiem sporo gier, wykorzystując opakowanie Delphi i DirectX o nazwie Asphyre. Były to wszystkie gry 2D opracowane z myślą o automatach do wypłat. Połączyliśmy nawet Delphi i Flash przez ActiveX, co okazało się bardzo satysfakcjonujące.

Asphyre to jedno z najlepszych (jeśli nie jedyne) opakowanie DirectX dla Delphi. Użyliśmy tam wielu cząstek i innych rzeczy, więc były to raczej przyjemne dla oka gry. Asphyre posiada również technologie 3D, ale nigdy nie wykroczyliśmy poza 2D, ponieważ nie musieliśmy.

Moim zdaniem jednak Delphi jest po prostu o wiele za stare i wydaje się, że C # stanowi dla niego najlepszą alternatywę.


1
Nie jestem pewien, czy ta nazwa powinna brzmieć jak „aspirować”, ale bardziej przypomina „tyłek ognia”. Po prostu mówię'.
3Dave

2

To cud, ale na Węgrzech jest mała gra, z dużą ilością fanów, napisaną w języku delphi, i wciąż pojawiają się nowe aktualizacje. Nazywa się Stickman Warfare i jest trójwymiarowym MMOFPS.


0

SvEngine . Jest to zaawansowany silnik do gier 2D na PC z systemem Windows® i wykorzystuje Direct3D® do sprzętowego renderowania przyspieszonego. Jest solidny, w pełni obiektowy, zaprojektowany z myślą o łatwej obsłudze i odpowiedni do tworzenia wszelkiego rodzaju gier 2D i innych symulacji graficznych. Obsługiwane są powierzchnie, tekstury, duszki, audio, strumienie, archiwa, pliki konfiguracyjne, cele renderowania, łańcuchy wymiany, bazy danych i wiele innych.

UWAGA: To nasze własne oprogramowanie pośrednie dla silnika gier 2D, które opracowujemy i obsługujemy. Będziemy go używać do tworzenia wszystkich naszych nadchodzących projektów.


3
Używasz go, ale także piszesz i sprzedajesz. Podczas udzielania odpowiedzi na pytania zawierające linki do produktów należy ujawnić interesy handlowe.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.