Kompletnie nie umiem pisać większych programów i gier

Cześć wam, mam sprawę. Mimo roku nauki C++, prawie skończonej symfonii i kilkudziesięciu godzin w SFML'u nadal nie potrafię napisać prostej gry. MOŻE udałby mi się najwyżej arkanoid. Podam przykład: jakieś 2 miechy temu chciałem napisać grę rpg, kafelkowa, 2d. Porzuciłem projekt po kilkunastu dniach, wylanych łzach i kilku stówach zostawionych u psychologa przy leczeniu nerwicy (no dobra, może to ostatnie to nieprawda). Po prostu pisze powiedzmy funkcje odpowiedzialną za chodzenie. Po kilku godzinach okazuje się, że moja funkcja jakoś koliduje z inną / trzeba to zrobić inaczej i DUPA. Kilka godzin w plecy a przede mną kolejne godzinki poprawek. I tak jest ze wszystkim. To odbiera całą przyjemność z pisania. Szczególnie, kiedy widzi się jakie programy/gry piszą inni.
Nie wiem jak się zabrać za grę. Jak to powinno działać. Pisze coś a z perspektywy czasu okazuje się, że trzeba to przebudować. Kiedy to przebuduje - trzeba zmienić coś innego. Kiedy wszystko jest zrobione, to dochodzą nowe funkcje i znów trzeba zmieniać!

Nie wiem, czy po prostu jestem głupi, ale zobaczcie na tego gościa:

Po roku. Wiem, nie wszystko w internecie to prawda, ale czemu miałby kłamać? Poza tym wydaje mi się, że ja nie zrobiłbym takich rzeczy i po 5 latach!
albo to:

Co jest ze mną nie tak... Cokolwiek bym nie napisał, jest źle.

PS. nie chciałbym stracić tej pasji do programowania. Już zbyt wiele hobby położyłem przez to, że stresowałem się "tego nie umiem, jestem beznadziejny. Skoro tego nie umiem to może to nie jest moja dziedzina".

Problem poniekąd tkwi w tym, że uważasz, że kilkadziesiąt godzin to dużo. Otóż to mało. Nie jestem jakimś guru, ale nawet nie wyobrażasz sobie ile ja miałem takich projektów jak Twoja gra. Wymyśliłem coś super, porwałem się z motyką na słonce i nic z tego nie wyszło. Za chwilę to samo, i tak w kółko. No i w sumie o to chodzi - żeby pisać jak najwięcej. Dalej biorę się za projekty, które mnie przerastają, ale przy każdym uczę się nowych rzeczy.

Morał jaki chce przekazać jest taki, że nie jesteś jedyny, któremu pierwsza gra nie wyszła. Uwierz mi, że jak tylko będziesz pisał, będzie coraz lepiej (:
Nie będę pisał tu złotych środków, bo ich nie ma. Po prostu pisz.

Dzięki. Tylko właśnie szkoda, że nie ma jakiejś recepty na grę. Każda jest inna i wymaga innego podejścia. Niestety :/

Hmm... szalony kaczor. Ciekawe tu są nazwy użytkowników bez konta :D. Sorka, myślałem, że zapamiętało hasło i jestem zalogowany

Poświęciłeś chwilę czasu na analizę i zaplanowanie sobie tego co będziesz kodował, czy od razu rzucałeś się do kodowania?

Nazwa_użytkownika napisał(a):

Po kilku godzinach okazuje się, że moja funkcja jakoś koliduje z inną / trzeba to zrobić inaczej i DUPA. Kilka godzin w plecy a przede mną kolejne godzinki poprawek. I tak jest ze wszystkim. To odbiera całą przyjemność z pisania. Szczególnie, kiedy widzi się jakie programy/gry piszą inni.

Właśnie tutaj tkwi problem - w nastawieniu. Te godziny nie są "w plecy" tylko są kolejną lekcją. Po tych wszystkich książkach które nauczyły cię składni danego języka przychodzi nauka programowania - i tak właśnie ona wygląda. Po każdym takim "nieudanym" sprincie, odetchnij chwilę, pomyśl w jaki sposób to dałoby się zrobić inaczej, zastanów się jak rozwiążesz podobny problem w przyszłości. Jeżeli chce ci się to poprawiać w tym momencie, to popraw - ale wiedz o tym, że za chwile znów pomyślisz o tym, że wypadałoby to napisać jeszcze inaczej.
Lepszym rozwiązaniem jest próba dokończenia projektu mimo wszystko. Gdy skończysz, możesz wtedy zabrać się za refaktoryzację, lub przejść do kolejnego projektu bogatszy w doświadczenia oraz szerszą perspektywę.

Na początku przygody z programowaniem nie polecam robić bardzo rozbudowanych projektów, bo przyjemność "grzebania" się w takim kodzie jest raczej wątpliwa. Dodatkowo "szybkie" nastawianie się do swojego kodu negatywnie jest raczej oznaką równie szybkiego zdobywania doświadczenia. Uwierz mi, że w przyszłości twój kod będzie ci się podobał odrobinę dłużej ;)

Dodatkowo, możesz poczytać o wzorcach projektowych. Jednak na tym etapie, niech one nie będą dla ciebie głównym wyznacznikiem architektury kodu twojej aplikacji. Lepszym sposobem jest zerknięcie na problemy jakie one rozwiązują.
Przykładowo: http://gameprogrammingpatterns.com/contents.html

Hmm... No zbyt długo nie zastanawiam się nad projektem, tylko od razu koduje. Problem w tym, że nie wszystko da sie zaplanować, szczególnie gdy mamy ruch, kolizje, ekwipunek, walke, rozmowy itd.
Załóżmy, że chce otworzyć ekwipunek. W tym momencie nie powinienem się ruszać. Trzeba więc dodać zmienną bool isEqOpen
Teraz trzeba wrócić do miejsca w kodzie odpowiadającego za poruszanie się i wprowadzić warunek:
if(isEqOpen == false)
postac.ruch

Może się użalam, ale gdy posiedze nad takim projektem długi czas i nie mam pomysłu, albo okazuje się, że (znów) coś nie działa to dostaje białej gorączki i ostatnie o czym myśle to powrót do projektu. Gdybym o czymś sobie przypomniał to napiszę :)

kilkadziesiąt? Ja jak zaczałęm programować w 2 technikum to przez technikum robiłem tak mniej więcej tysiąc godzin rocznie, aktualnie to jest koło 3tys godzin rocznie :D

Ja kiedyś ćwiczyłem pisanie gier w BlitzBasic - http://www.blitzbasic.com/

Najważniejsze to nie poddawać się. Z nauką programowania jest jak z nauką języka obcego. Po roku coś już tam umiesz powiedzieć, zrozumieć, ale czy napiszesz książkę w tym języku? Wątpię.
Jest pewna zasada w nauce (języka, ale też czegokolwiek), która mówi, że najlepiej i najszybciej uczy się, gdy ma się z tym czymś częsty kontakt. Jeśli to jest nauka języka, to najlepiej wyjechać za granicę. Matematyka, fizyka - częste rozwiązywanie zadań.
Mózg lubi powtórzenia, dlatego dobrze że piszesz, ale staraj się raczej nie przerywać projektów, tylko je kończ. Rozwiązywanie problemów bardzo rozwija.
Skoro nie możesz ukończyć większości projektów, to może powinieneś jakieś prostsze pisać, albo znaleźć sobie kogoś do grupy.
I rada na koniec: nie myśl o zmarnowanych godzinach na pisaniu kodu, tylko traktuj to jako zdobywanie doświadczenia.

@Nazwa_użytkownika: wydaje mi się ze twój problem leży w złym projektowaniu rozwiązania. Spróbuj moze coś napisać metodą top-down a nie bottom-up tak jak robisz teraz. Czyli zacznij od ramowego "szablonu" dla twojego programu, bez implementowania szczegółów i potem schodź coraz niżej. W takim wypadku co prawda coś zacznie działac dopiero na sam koniec, ale jednocześnie jest mała szansa że nagle coś zacznie ze sobą kolidować.
Zacznij pisać od main() i twórz sobie potrzebne klasy/metody bez ich implementowania na początku.

Ja polecam poszukać pracy jako programista. Też mi średnio wychodziło zakończenie każdego projektu, ale w firmie tłukąc dzień w dzień programowanie i będąc wspierany przez innych już tak nie mam.

Podam przykład: jakieś 2 miechy temu chciałem napisać grę rpg, kafelkowa, 2d. Porzuciłem projekt po kilkunastu dniach

Rozumiem po kilku miesiącach, ale po kilkunastu dniach? Wytrwałość jest konieczna, jak chce się coś osiągnąć.

Załóżmy, że chce otworzyć ekwipunek. W tym momencie nie powinienem się ruszać. Trzeba więc dodać zmienną bool isEqOpen
Teraz trzeba wrócić do miejsca w kodzie odpowiadającego za poruszanie się i wprowadzić warunek:
if(isEqOpen == false)
postac.ruch

Tutaj może być problem. Z tego co napisałeś wnioskuję, że traktujesz grę jako monolit z logiką umieszczoną po całej grze, gdzie dodanie jednej rzeczy (ekwipunek) wymaga ruszania kodu w iluś miejscach i ciągłego sprawdzania konkretnych warunków.

A można inaczej. Zamiast sprawdzać konkretny warunek "czy jest otwarty ekwipunek" w konkretnej funkcji "ruszania", można iść trochę wyżej w abstrakcji i dodać coś takiego jak "pauza" i sprawdzać warunek pauzy:

if(isPause == false)

w ten sposób jak dodasz inny powód, dla którego postać miałaby się nie ruszać, nie musiałbyś dodawać nowego warunku i sprawdzać isInMainMenu tylko ustawiałbyś pauzę i miałbyś spokój.

Być może więc podchodzisz ze złego poziomu abstrakcji, szukasz rozwiązania pojedynczych problemów, zamiast myśleć całościowo i wybiegać w przód o parę kroków.

Po prostu pisze powiedzmy funkcje odpowiedzialną za chodzenie. Po kilku godzinach okazuje się, że moja funkcja jakoś koliduje z inną / trzeba to zrobić inaczej i DUPA

hasła do wygooglowania: decoupling, Single Responsibility Principle, separation of concerns :)

np. czemu w ogóle funkcja odpowiedzialna za chodzenie ma sprawdzać ekwipunek (albo czemu ma sprawdzać warunek pauzy)?

To tak jakby bohaterowie filmu sprawdzali, czy masz wciśnięty przycisk pauzy w odtwarzaczu.

Takie rzeczy lepiej sprawdzać na wyższym poziomie kontroli, np. w głównej pętli gry. Wszystko powinno mieć swoje miejsce. Dobrym pomysłem może być rozrysowanie sobie na kartce pewnych rzeczy, co się z czym wiąże (tylko i tak nie zaprojektujesz wszystkiego za pierwszym razem, na to nie licz nawet. Raczej chodzi o to, że kartka i długopis może być stymulacją dla wyobraźni i myślenia bardziej koncepcyjnego o kodzie, z lotu ptaka, a nie na poziomie funkcji i ifów).

trzeba to zrobić inaczej i DUPA.

Czy korzystasz z Git? Jeśli nie to powinieneś zacząć. Wtedy łatwo możesz cofać zmiany i masz ładny podgląd wszystkiego co po kolei robiłeś (pod warunkiem regularnego commitowania).

Nie wiem jak się zabrać za grę. Jak to powinno działać. Pisze coś a z perspektywy czasu okazuje się, że trzeba to przebudować.
Kiedy to przebuduje - trzeba zmienić coś innego. Kiedy wszystko jest zrobione, to dochodzą nowe funkcje i znów trzeba zmieniać!

Z czasem nauczysz się tworzyć skalowalne rozwiązania... :) Czasem kwestią jest też stosowanie odpowiednich wzorców projektowych.

Przy projektowaniu gier przydają się komunikaty/komendy. Polega to na tym, że obiekty w grze ("gracz", "żołnierz", "apteczka", "czołg") mogą nawzajem wysyłać do siebie komunikaty. Np. "gracz" może wysłać komunikat "bierz" do obiektu "apteczka", a obiekt "czołg" może wysłać komunikat "strzelaj" do obiektu "żołnierz" itp.

http://gameprogrammingpatterns.com/command.html

To wiele upraszcza w sytuacji, kiedy gra się rozrasta (bo masz gotowy protokół komunikacji między obiektami i system reagowania na zdarzenia. Więc jeśli dodajesz nowy rodzaj obiektu np. "robot", który ma strzelać to tylko wpinasz go w cały system, i pozwalasz żeby wysyłał komunikat "strzelaj", na który już będzie reszta obiektów sama reagować).

OOP jest też przydatne, szczególnie polimorfizm. W ten sposób możesz przypisać metodę AI do każdego obiektu inną. I robot będzie miał inną sztuczną inteligencję niż żołnierz, a z perspektywy głównej pętli gry będzie to tak samo się obsługiwało. Mniej ifów, więcej abstrakcji.

Kiedyś natknąłem się na pierwszy filmik, który wrzuciłeś. Nie sugeruj się tym. Możliwe, że nigdy nie będziesz umiał czegoś takiego napisać. Ten twórca ma skończone jakieś wyższe studia nieinformatyczne. Ma solidną wiedzę matematyczną i fizyczną, ale gdy spojrzysz na kod, to wirtuozem w tej dziedzinie nie jest.
Co do Twoich problemów, to chyba dobrym pomysłem jest znalezienie jakiegoś kursu typu "piszemy grę od zera" i chociaż zobaczenie jak ktoś z trochę większym doświadczeniem podstawową logikę tworzy. Dobry projekt = łatwiejsze naprawianie kolidujących części kodu.

Ja bym proponował nie zaczynać od gier w ogóle, w sensie większe projekty które da rade skończyć ale nie gry. Osobiście nigdy nie napisałem gry i jakoś żyje z programowania już 4 lata :D Znajdź jaką apke którą chciałbyś napisać np program do generowania i rozwiązywania testów, aplikacja szyfrująca i deszyfrująca tekst rożnymi algorytmami, prosty edytor tekstowy, to są apki takie na w zależności od tego jak bardzo złożone założenia sobie przyjmiesz od jednego wieczora do 1-2tygodni pracy.

Co do Twoich problemów, to chyba dobrym pomysłem jest znalezienie jakiegoś kursu typu "piszemy grę od zera"
i chociaż zobaczenie jak ktoś z trochę większym doświadczeniem podstawową logikę tworzy.

Ogólnie się zgadzam, że należy brać przykład z bardziej doświadczonych, ale nie zgadzam się z tym, żeby szukać kursu "piszemy grę od zera".

Kursy typu "piszemy grę od zera" pokazują jak zacząć od zera do "czegoś", ale rzadko który pokazuje jak zrobić większą, skalowalną aplikację (a właśnie z tym OP ma problem z tego co pisze, z rozwojem zaczętej już gry, a nie z samym zaczęciem). Tutoriale są dobre na początek, ale na dłuższą metę to z tutoriali można się raczej nabyć złych nawyków pisania "byle jak, byleby działało", a nie dowiedzieć, jak napisać coś większego. Dużo tutoriali propaguje dość słabe praktyki kodowania, bo uwaga skupiona jest na technikaliach (jak coś wyświetlić na ekranie i jak to poruszyć) a nie na tym, żeby zrobić coś, co będzie się dało potem rozszerzać.

Moim zdaniem więc lepiej na tym etapie poczytać artykuły bardziej teoretyczne o tym w jaki sposób można rozwiązać pewne problemy w grach (wspomniane już http://gameprogrammingpatterns.com/contents.html , poza tym na https://gamedev.net czy innych podobnych stronach można znaleźć też ciekawe artykuły. Jeszcze jest bardzo fajna seria książek Perełki Programowania Gier. Tam są opisane rzeczy bardziej od strony koncepcyjnej (a nie tylko od strony "zaklepania kodu") przez ludzi z dużym doświadczeniem.

Recepta: nie przejmować się i przeć dalej do skutku. Piszę w C# apki na desktop w mvvm. Siedzę w tym już dość długo, bo jakieś cztery lata. Dopiero niedawno tak naprawdę nauczyłem się separować właściwie warstwy logiki w kodzie. Zawsze coś było nie tak. Czasami miałem wrażenie, że to w ogóle nie ma sensu i rzucałem te projekty w kąt na tygodnie. Później jednak wracałem i dopracowywałem i wreszcie coś zaczęło wychodzić. Tak to juz jest w tym zawodzie... jeden nauczy się szybciej, a drugi wolniej. Sam mam świadomość tego, że poziomu niektórych osób raczej nie osiagnę ale nie przejmuję się tym. Nie przejmuje się, bo w życiu jest masa ciekawszych rzeczy niż programowanie. I uwierz mi, że przejmować się tym nie warto.

Sam jestem humanistą, który programuje i jakoś to ciagnę mimo, że rzeczy z tym związane pojmuję czasami znacznie wolniej niż umysły ścisłe. Widzę to po moich kolegach z pracy ;)

A czy powinienem być programistą czy też nie? Choć jako osoba pracująca w zawodzie wiele razy mam wątpliwości to jednak jestem zdania, że życie zweryfikuje to najlepiej.

Jeżeli to lubisz to rób to. A czy to gry czy nie gry... mnie też wiele razy mówiono, że desktop umiera ;)

A programowanie? Sam mam je czasami ochotę rzucić w cholerę i zająć się uprawą kartofli. Ot przychodzą do mnie ludzie i mówią żebym coś zakodował, a ja nie rozumiem ani słowa z tego co powiedzieli. A ziemniaki? To chociaż wiadomo, że wzrosną albo nie. ;) Może to trochę abstrakcyjnie brzmi ale tak mam wiele razy ;) Nie łamać się autorze wątku! Nigdy!

Eh szczerze to ci nawet zazdroszczę, ja to wolałbym sobie gry pisać, a nie robię nic.

Ojjj też znam ten problem, znam coś tam C++ i akurat ostatnio pisałem prostą grę w SFML, grę zrobiłem, zajęło mi to sporo czasu żeby działała tak jak ja chcę ale nie poddawałem się. Kod jest słaby jak pomyślę że miałbym wprowadzić tam jakieś zmiany to "szkoda gadać" zauważyłem że miałem problem żeby podzielić to sensownie na klasy itp, muszę nad tym popracować, jak będę miał więcej czasu to zabiorę się za jakiś większy projekt tylko nie mam za wiele pomysłów