Grand Killer UPDATE klon GTA 2

Question

Hej, od ostatniej wersji mojej gry minęły prawie 3 miesiące. Chciałbym wam pokazać co się w niej zmieniło oraz jak teraz wygląda. Grand Killer v2.0

Oferta dalej aktualna:
Jest przy tym strasznie dużo pracy i samemu już tego nie chce robić. Nie mam tu na myśli programistów (choć jeśli jesteś zainteresowany możesz napisać), ale ludzi, którzy dadzą coś od siebie, a szczególnie grafików. Jest masa pomysłów, które chciałbym zrealizować. Oczywiście nie przewiduję żadnego wynagrodzenia dla tych osób, choć to też zależy jaka to będzie gra.
Mogę tylko dodać, że ten projekt traktuje bardzo poważnie i raczej chciałbym go ukończyć lub przynajmniej doprowadzić go do stanu grywalności.

Sterowanie - polecam zajrzeć
Screenshoty - na zachętę ;)

Proszę o opinie, rady, wskazówki.
Pozdrawiam.
 

Comments

Rozumiem że mój Phenomek II X2 545 ledwo zipie, ale przy klonie GTA 2 podczas ładowania gra się wiesza a obciążenie procesora przez aplikację wynosi od 40 do 70%.

Więc do poprawy, wg mnie OPTYMALIZACJA.

---

Mogę jeszcze wiedzieć jakie masz GPU ?

40-70% to nie jakoś dużo. SFML renderuje grafikę poprzez kartę graficzną, więc jest ona konieczna do uruchomienia GK, jak do większości gier komputerowych.

---

@10kw10, wygląda to obiecująco. Dobrze że masz rozpiskę co zrobiłeś, co robisz i co planujesz.

Moim zdaniem, zrób kilkuminutowy filmik z rozgrywki i udostępnij go - nie każdemu chce się instalować grę, ale jeśli ludzie zobaczą jak wygląda to w ruchu, to może ktoś chętniej dołączy do projektu.

---

Dzięki za fajną opinię ;) Pomyślę nad tym.

Answer 1

Trochę wstyd: 

... ludzi, którzy dadzą coś od siebie, a szczególnie grafików. Jest masa pomysłów, które chciałbym zrealizować. Oczywiście nie przewiduję żadnego wynagrodzenia dla tych osób,

a jednak planujesz potem :

 raczej chciałbym go ukończyć lub przynajmniej doprowadzić go do stanu grywalności. 

Czyli generalnie; wykorzystasz czyjąś prace, wkład ... tak po prostu a potem może w przyszłości np okaże się, że to dobry produkt i idzie go sprzedać/ będzie zysk ... no to jest hipokryzja- nie oczekuj tego, że ktoś poswięci się, swój czas, umiejętności zaangażowanie - tak po prostu dla funu, gdzie mógłby robić w tym czasie coś rozwijającego dla siebie  

Comments

Zdanie wyjete z kontekstu. Nie oferuje zadnych pieniądzy od siebie, jednak gdy projekt zacznie zarabiac oczywiście dzielimy sie sprawiedliwie.

---

Nie wyjęte z kontekstu, tylko cytuje twoją wypowiedź :)

---

Zapomniałeś o tym zdaniu:

choć to też zależy jaka to będzie gra.

Tłumacząc: zależy czy uda się na niej zarobić.

---

Na tej zasadzie mogę napisać

 

Szukam ludzi do projektu, potrzebuje grafika.... "coś tam..." jeśli" grafika będzie w przyszłości dobra/przyjmie się zapłacę, jak nie to nie zapłacę. Kto chętny? 

---

Gra jest pisana bardziej w celu nabierania doświadczenia, ciekawego spędzenia wolnego czasu, samorozwoju, choć nie ukrywam, że fajnie by było coś na niej zarobić. To też ciekawy projekt do pokazania przyszłym pracodawcom, nie tylko przeze mnie jako programisty, ale też jako portfolio dla grafików lub innych ludzi zaangażowanych w projekt. Jestem młody i nie mam zamiaru inwestować w to, jeśli nie mam pewności, że mi się to zwróci. Oferta wygląda trochę tak jak napisałeś, ale niestety w tej chwili jestem tylko tyle wstanie dać od siebie ;)

Answer 2

Pierwszym wyznacznikiem jakości projektu od strony implementacyjnej jest dla mnie zawsze wykorzystanie abstrakcji i postrzeganie obiektowości:

1. W folderze Engine (sama nazwa sugeruje że powinien zawierać uniwersalne komponenty; rendering itp) jest samochód 
2. Nie wykorzystałeś dziedziczenia. Lepiej zrobić enuma Type i napisać w konstruktorze switcha ma 190 linijek. 
3. Wczytywanie tekstur samochodu w jego konstruktorze to najlepszy dowód, że niezbyt dobrze zrozumiałeś zależność tekstura - sprite.
4. Ogólnie podział logiczny zrobiłeś bardzo marny. Klasy które pozornie powinny stanowić samodzielną funkcjonalność są sztywno zależne od innych. Button - window ? 
5. Zupełnie nie wiem po co klasa Keyboard i enum Key. Wszystko masz w SFMLu.

Podsumowując bo nie chcę więcej pisać  skup się na dobrym kursie obiektowości realizującym duuużo przykładów. 

Comments

3 mógłbyś rozwinac?

5 dzięki temu moge latwo dostac sprita danego klawisza, który mi jest potrzebny.

2 nie widzialem sensu w tym zeby kazdy rodzaj samochodu byl osobna klasa.

---

Jedną teksturę powinieneś załadować tylko i wyłącznie raz. Potem rozdajesz tylko jej referencje dla poszczególnych spritów.

---

Hmm ma to sens, ale jest textureManager ktory sprawdza czy juz zostala wczytana.

Potem zrobie jakis ekran ladowania plikow gdzie bede wczytywal wszystkie textury.

---

Zupełnie niepotrzebnie. Stwórz sobie 200 samochodów. Zobacz ile porównań musisz wykonać.

---

@Ehlert, 

1. Kto powiedział że Samochód to nie jest uniwersalny komponent? W silniku do gry wyścigowej na pewno znajdą się podobne klasy, które można wykorzystać do tworzenia wielu innych rodzai samochodów. Zresztą Engine według mnie wcale nie sugeruje, że tam muszą się znaleźć same uniwersalne zasoby. Często przy grach projektuje się silnik do konkretnej gry i wszyscy mają w nosie czy ktoś tego silniku będzie jeszcze do czegoś używać. Tak w ogóle to tylko czepianie się mało znaczącej nazwy :p

2. Dziedziczenia w tym przypadku to byłby błąd bo dziedziczenie służy do rozszerzenia zachowań, a nie do do ustawiania własności. Tutaj najlepszym rozwiązaniem byłoby zapisać ustawienia samochodów do jakiegoś XMLa/JSONa i samochody produkować w fabryce, ale takie produkcje w konstruktorze w przypadku małych projektów też są okey.

3. Zastosowanie pyłka ma sens tylko wtedy gdy wydajność jest na nieakceptowalnym poziomie. Czy wczytanie tekstury kilka razy ma kluczowy wpływ na wydajność? Tego nie jestem pewien. Jestem za to pewien, że zastosowanie pyłka tylko dla hecy to łamanie zasady KISS.

4. Według mnie button zależny od window jest jak najbardziej w porządku. Przecież nie wynikają z tego żadne powtórzenia kodu, ani tym bardziej łamanie KISSa.

---

3. co masz na myśli pisząc "pyłek" ?

---

Pyłek to taki obiekt, który jest współdzielony przez inne obiekty właśnie w celu poprawy wydajności. Na wikipedi masz wszystko napisane.

---

1. Pisanie silnika z klasą samochód wewnątrz tylko dlatego że jest to grsa wyścigowa to zamykanie sobie drzwi do prawidłowego rozwoju. Pozostaje przy swoim zdaniu. Albo piszesz silnik gry, albo zmień sobie nazwę folderu na Game i rób tam co chcesz. 
2. OK, bez dziedziczenia można. Mimo to ten konstruktor to dla mnie absurd. 
3. Z Twojego toku rozumowania wynika że skoro jest zasada KISS to po co korzystać z merge i quick sorta jak można wykonywać n² porównań za każdym razem.
4. Button powinien odnosić się do Window tylko w takim stopniu jak robi to metoda draw z Drawable. Nie wiem po co tam wskaźnik. 

Podsumowując projekt jest prosty, mały więc piszemy na odwal, bo po co przemyślane podejście architektoniczne i wzorce projektowe. Działa to działa. 

---

Podsumowując bo nie chcę więcej pisać

Mógłbyś mi wytknąć kolejne błędy? ;d Te nie są jakieś rażące, przynajmniej tak mi się wydaje, a ja dalej uważam, że mój kod nie jest jakiś tragiczny.

---

No cóż moim zdaniem kicha bo napisałem o błędach implementacji, logicznych. Pozostaje czystość kodu. 

Nie we wszystkich miejscach spójnie używasz kamer przy ifach. Nazwy klas rozpoczynamy wielką literą.

Przydałoby się użycie scen, czego obecnie nie ma. 

Ogólnie z całym szacunkiem do tego co zrobiłeś polecam usiąść do tego projektu od strony kartki i ołówka 

---

Scen?

Wydaje mi się, że trochę dużo już napisałem, żeby sobie ot tak pozmieniać klasy, ale oczywiście pomyślę nad jakoś refaktoryzacją.

---

Moim zdaniem to wcale nie jest jeszcze dużo. Warto się cofnąć i odrobić dług technologiczny.