Poprawny proces tworzenia projektu

Ciężko rozważać optymalną wieloletnią architekturę obiektową, jak w OOP mamy podstawowe problemy (obiekt w/s klasa)
Nie wyobrażam sobie uczenia dobrych praktyk takich projektów, bez absolutnie płynnego poruszania się w programowaniu obiektowym.

generalnie tzw praktykom, co szyli kod spagetti szczególnie trudno się przestawić, to prawda. Chyba łatwiej jest nauczyć kogoś zielonego, ale u dobrego mistrza.

PS. nie znam wzorców w branży gier, nie mój konik.

@cplusplus94: Producenci gier używają silników, których po prostu używają. Sposoby dodawania nowych assetów są w nich z góry ustalone. Studia są ograniczone przez zestaw funkcji dostarczanych przez silnik. Z czasem rozwijanie gry staje się coraz bardziej utrudnione/niemożliwe więc nowe wersje gier są tworzone na nowym silniku, więc nie jest tak, że można płynnie rozwijać produkt bez rewolucji. Nie przewidzisz wszystkich ficzerów, które chciałbyś mieć w przyszłości, zresztą tracenie czasu na implementację możliwości dodania wszystkiego to też nie jest dobry pomysł. W skali aplikacji w rozszerzeniu pomaga architektura warstwowa(onion, clean), w skali systemu mikroserwisy.

Na podstawie postu o kolizjach (https://4programmers.net/Forum/Algorytmy/347326-kolizja_prostokatow_w_platformowce?p=1732294#id1732294) zgadzam się z AnyKtokolwiek, że jak dla ciebie to trochę więcej praktyki ukierunkowanej na programowanie obiektowe i single responsibiity principle (z SOLID).

Co do architektury to słyszałem pobieżnie o entity component system (https://en.wikipedia.org/wiki/Entity_component_system) w A-Frame, ale może to zależeć od frameworka którego się używa. Owszem warto się interesować "jak to robią profesjonaliści", jakie są architektury czy przeczytać książkę w stylu programowanie gier w 24h czy programowanie gier w trzech tomach :).

Natomiast twoje pytanie w odniesieniu do napisanego przez ciebie kodu to poszukiwanie odpowiedzi na to jakie mamy obiekty i abstrakcje i jakieś powtarzalne elementy.

        local cLeft = character:getPositionX()
        local cRight =  character:getPositionX() + character:getBoundingRectWidth() 
        local cTop =  character:getPositionY() 
        local cBottom =  character:getPositionY() + character:getBoundingRectHeight() 

        local tLeft = tile:getPositionX()
        local tRight =  tile:getPositionX() + tile:getBoundingRectWidth()
        local tTop =  tile:getPositionY()
        local tBottom =  tile:getPositionY() + tile:getBoundingRectHeight() 

Profesjonalnie to się nazywa duplikatem kodu.
Prostokąt mógłby być klasą tworzoną na podstawie czegoś co jest "character" i "tile". np

Prostokąc c = new Prostokąt(character) 
albo 
Prostokąc c = character.getProstokąt()

wtedy nie masz czterech linii dla każdego elementu.
To też w pewien sposób pozwala na sprawdzanie kolizji prostokątów co powoduje że można sprawdzić czy kolizja wystąpiła między ludzikami tym samym kodem. Z twojego kodu wygląda że kolizji może nie być albo być z jednej z czterech stron. No to jest do przemyślenia, ale chodzi o to, że twój kod razem z wykryciem kolizji opisuje zachowanie elementów - co jest złamaniem tego "single responsibility principle" - kod wykrywający kolizję powinien ją wykryć (no i ewentualnie podać jakieś dodatkowe informacja jak ta strona wystąpienia) ale nie powinien wpływać na zachowanie tego co się zderzyło.

Wykrycie kolizji na podstawie dwóch prostokątów powinno mieć testy jednostkowe i może pomogą z poprawnością algorytmu (ale nie naciskam).

Łatwiej się krytykuje istniejący kod niż planuje jego napisanie. Także lepiej go przepisać i się nie przejmować bardzo, że troche spageti wyszło za pierwszym razem. Z czasem przychodzi to łatwiej, żeby już przed napisaniem kodu wykryć części wspólne, podobne zachowania. Ale żeby pisać obiektowo czy funkcyjnie to trzeba się zapoznać z tym. Poczytać jakieś podstawy (wiki czy jakieś krótkie artykuły).

No tak, słuszna uwaga, niby fakt że programiści nie tworzą kodu twk żeby można było WSZYSTKO potem zaimplementować to oczywistość ale nie myślałem o tym w ten sposób, zawsze mnie coś gryzło że to chyba ja coś źle robię a przecież zawsze są jakieś limity. Co do projektowania obiektowego i ECS to noe sugerujcie sie moimi poprzednimi postami, to były różne testy dodawania skryptów LUA do programu itd, to nie obrazuje w jaki sposób tworzę program. Wszystko robie obiektowo. Natomiast mam czasami problem jak stworzyc te wszystkie obiekty które sie sprawnie będą ze sobą komunikowały itd. Jestem już na coraz lepszej drodze natomiast tu też jeszcze raz powtórzę pytanie jak to rozrysować? Programiści czy to działający w pojedynkę czy w grupie musza jakoś na początku sobie projekt rozpisać. Czyli mam zarys głównych ficzerow, mechanik i teraz chodzi mi o etap ktory pomijam, projekt. W szkole wieleat temu wiem że robiliśmy przez kilka miesięcy schematy blokowe zanim przeszliśmy do klepania kodu, ja wtedy na ten temat strzeliłem focha i przeszedłem od razu do pisania kodu.

@cplusplus94: Nie wiem jakie masz doświadczenie w programowaniu więc najbardziej podstawowy przykład, masz "ficzery" w grze które przewidziałeś, że będą Ci potrzebne jak quest, postać... Pierwszy krok to zrobić klasę abstrakcyjną Quest, do której możesz potem "wsadzić" wszystkie konkretne questy. Czego w kodzie unikać to wywołań w kodzie na konkretnych instancjach:

Quest q1 = new ConcreteQuest1();
Quest q2 = new ConcreteQuest2();
q1.doSomething();
...
q2.doSomething();

A zamiast tego dokonywać operacji na kolekcjach a jedynym punktem gdzie zmieniasz w kodzie jest dodanie nowego typu questa do kolekcji:

Collection c;
c.add(new ConcreteQuest1());
c.add(new ConcreteQuest2());
for(Quest q : c){
q.doSomething();
}

Więc trzeba kod napisać tak aby metoda mogła przyjąć i obsłużyć całą kolekcję wszystkich instancji a nie była pisana pod konkretną instancję w kolekcji.

Bonanzaa napisał(a):

@cplusplus94: Nie wiem jakie masz doświadczenie w programowaniu więc najbardziej podstawowy przykład, masz "ficzery" w grze które przewidziałeś, że będą Ci potrzebne jak quest, postać... Pierwszy krok to zrobić klasę abstrakcyjną Quest, do której możesz potem "wsadzić" wszystkie konkretne questy. Czego w kodzie unikać to wywołań w kodzie na konkretnych instancjach:

Kopiuj

Quest q1 = new ConcreteQuest1();
Quest q2 = new ConcreteQuest2();
q1.doSomething();
...
q2.doSomething();

A zamiast tego dokonywać operacji na kolekcjach a jedynym punktem gdzie zmieniasz w kodzie jest dodanie nowego typu questa do kolekcji:

Kopiuj

Collection c;
c.add(new ConcreteQuest1());
c.add(new ConcreteQuest2());
for(Quest q : c){
q.doSomething();
}

Więc trzeba kod napisać tak aby metoda mogła przyjąć i obsłużyć całą kolekcję wszystkich instancji a nie była pisana pod konkretną instancję w kolekcji.

A w takim przypadku jak będzie 100 różnych typów questów to będę musial stworzyć 100klas abstrakcyjnych. Ja bym tu bardziej stworzył jedną klasę quest i questy dodawal z poziomu pliku JSON albo jakoś przez skryptowanie. Natomiast nie o to mi dokładnie chodziło w moim pytaniu. Chodzi mi o to ze mam liste rzeczy ktore chce mieć w grze powiedzmy questy, kolizje, archivmenty, czary, pistacie, atrybuty, jak sobie to rozpisać przed rozpoczęciem pracy z kodem żeby nie było problemów z tworzeniem komunikacji między tymi klasami. Komponent atrybuty który ma zmienna mana musi sie komunikować z czarem ktory sprawdzi czy postać ma na tyle many, czy ma ten czar, itd itd czy te relacje sie jakoś rozrysowuwuje na kartce albo jakimś programie przed tworzeniem projektu? Jeśli tak to jak?

@cplusplus94: dla 100 questów tworzysz jedną klasę abstrakcyjną Quest. Natomiast dodanie 100 konkretnych questów możesz zrobić z json jeśli różnią się tylko polami, ale pewnie będą musiały mieć w sobie jakieś konkretne implementacje metod z klasy abstrakcyjnej, których nie oskryptujesz. Komunikacja to wywołanie metod, wg mojego przykładu właśnie nie ma wywołań konkretnych implementacji ale całych kolekcji obiektów typu klasy abstrakcyjnej, co upraszcza taki rysunek bo takie wywołanie metody Quest.doSomething() dla każdego elementu kolekcji c z poziomu Postac.doQuest() łatwo zapisać Postac -> Quest. Jak chcesz żeby Postać używała tylko wybranych questów to możesz dodać filtry, tą pętle możesz zrefaktoryzować łatwo do IoC, dodać callbacki tam gdzie potrzebujesz operować na konkretnych questach i wszystko skonfigurować w jednym miejscu aplikacji.

Naucz się wydzielać kod.
Masz moduł(albo klasę, funkcję itp.), który robi zbyt dużo i ma zbyt dużo zależności - możesz ją podzielić na kilka mniejszych.

przed rozpoczęciem tworzenia kodu, bo ja na chwilę obecną robie wszystko w locie i myślę że to też duży błąd ,bo już na samym starcie to powoduje nieład.

To nie musi być błąd. Jak prototypujesz, to fajnie jest pisać wszystko w locie, żeby jak najszybciej zweryfikować, czy dany pomysł w ogóle da się zrobić i jak go zrobić (technicznie). Jak masz np. jakiś algorytm do implementacji albo jakąś technikę, której nie znasz, albo po prostu coś większego od tego, co zwykle robiłeś, to ciężko, żebyś umiał to rozrysować od razu wszystko.

Więc pisanie w locie jest okej. Tylko potem musisz się liczyć z tym, że po etapie prototypowania przychodzi czas na zrobienie porządku i wtedy może się okazać, że musisz od początku wszystko przepisać "na czysto" (i to też jest okej!) - wtedy już sobie możesz to bardziej zaprojektować. Warto się też nauczyć refaktoringu - wtedy będziesz w stanie brzydki kod zamienić w ładny po prostu wydzielając pewne rzeczy, łącząc inne, zmieniając jedne linijki kodu, kasując inne, dodając inne...

Tylko czasem trudno zadecydować "czy lepiej jest przepisać od zera, czy wystarczy zrefaktorować". A może np. przepisać od zera, ale tylko jeden moduł? I tutaj warto się nauczyć pisać moduły, które są niezależne od siebie o tyle, że jesteś w stanie przepisać jakiś moduł niezależnie od reszty aplikacji.

robiliśmy przez kilka miesięcy schematy blokowe zanim przeszliśmy do klepania kodu,

lepiej jest przeplatać - zaklepać naiwną implementację, potem jak natrafisz na problem, to usiąść i trochę pomyśleć (również: przejrzeć internet w poszukiwaniu odpowiedzi), a potem znowu trochę kodzić (żeby zweryfikować założenia projektowe), a potem znowu praca koncepcyjna, gdzie sobie projektujesz głębiej, a potem znowu kodzenie itp.
Czyli proces bardziej iteracyjny.

. Chciałbym się dowiedzieć jak to robią profesjonaliści że w locie są w stanie dodać jakieś nowe rzeczy o których nie wiedzieli jeszcze w trakcie tworzenia kodu na początku pozostawiając cały kod w dobrym stanie.

Już sobie odpowiedziałeś - są profesjonalistami ;]

A tak na poważnie, po prostu trzeba łączyć doświadczenie praktyczne + wiedzę teoretyczną z zakresu architektury, wzorców. Takimi konceptami w aplikacjach biznesowych są np. Clean Architecture, SOLID, Event Driven Architecture, itp.