Potraktujcie ten wpis (pytanie) jako luźny artykuł, w którym ponarzekam sobie (znowu) na środowisko Borland CPP Builder 6. Chciałbym też zauważyć, że jest to głównie moja opinia (więc nie oczekujcie obiektywnego podejścia), a postanowiłem udostępnić szerzej naszej społeczności, bo coś mi się już robi jak widzę kolejne pytania dotyczące BugBuildera.
To, że osobiście zalecam go omijać szerokim łukiem wspominałem już nie raz, choćby w [CR Obiektowy C++ #7] i wciąż nie doczekałem się odpowiedzi na postawione tam przeze mnie pytanie: "Jakie Builder ma zalety nie licząc prostoty, której bliżej jest do prymitywności?" Ale mniejsza o to, jeżeli ktoś czuje potrzebę użycia tak prostego narzędzia, to w porządku; ale mam prośbę: nie róbcie w nim projektów, których zrobienie zajmuje więcej niż kilka godzin, bo się rozczarujecie i niepotrzebnie sfrustrujecie.
Nie piszę tego wpisu aby w jakiś sposób sabotować pracę pana Mirosława, po prostu chcę Was przestrzec przed używaniem narzędzia, które nie jest wspierane od ładnych paru lat, dokumentacja to jakaś kpina (nie trzyma obecnych standardów), a główne źródło wiedzy to jedna [książka] (2link od góry), oraz stackoverflow. Podkreślę to jeszcze raz: jeżeli nie chcecie zrobić czegoś więcej niż prymitywna aplikacja (żadnych gier!) to builder ma sens, w przeciwnym wypadku szkoda waszego czasu.
Builder, a Gamedev
Skoro już wiemy, że Builder nie nadaje się do tworzenia bardziej skomplikowanych programów, to łatwo się domyślić że o tworzeniu gier nie ma mowy (mówiąc szczerze MZ pokazał niemal jego wszystkie możliwości: na serio tego jest tak mało).
Nawiasem mówiąc, to do pisania gier nie użyłbym żadnego narzędzia RAPID, bo samo GUI Windowsowe jest przystosowane po prostu do czego innego (choćby mamy różnicę w renderowaniu aplikację składających się stricte z systemowych kontrolek i okien w których renderowane są gry). Gra stworzona w ten sposób na pewno będzie gorzej wyglądała (bez szans na poprawę), nie będzie dało się jej fajnie rozwinąć, prawdopodobnie będzie nawet gorzej działała, a samo udostępniane API nie będzie spełniało waszych wymagań, albo rozwiązania pewnych problemów będą istniały, ale ich wykonanie ostatecznie okaże się trudniejsze (np animacje na buttonach, albo customowy wygląd samych buttonów).
Także: Czy pisanie gier przy użyciu Buildera ma sens: Nie.
Czego użyć do napisania gry?
Wybór jest spory, jeżeli chcesz po prostu napisać grę bez wchodzenia w większe szczegóły (które de facto są przydatne w zrozumieniu pewnych mechanizmów) to [Unity] jest fajną opcją (ważna sprawa: zacznij od gier 2D).
Jeżeli nie boisz się zejść niżej, tzn jesteś człowiekiem, który chce faktycznie się uczyć, czy to samego programowania, czy to pisania gier to istnieją inne rozwiązania, np: [SFML] (dygresja: pisząc w tej bibliotece nauczyłem się obiektówki), [SDL], czy jeżeli jesteście masochistami to możecie pouczyć się openGL (tutaj jest wybitnie dużo matmy).
Czego użyć do napisania programu?
To że nie Builder, to już oczywiste. Osobiście polecam [Qt], który jest dość prosty w użyciu, ma dużo większe możliwości niż Builder, przyjaźniejszą licencję, jest aktywnie rozwijany (Builder w normalnej wersji też jest rozwijany, ale społeczność tego forum skupiła się na wersji 6) i co ważne: jego znajomość coś znaczy na rynku pracy bo się go po prostu używa.
Wszelki feedback mile widziany