Autor Wątek: Jak zorganizować kod engine'u - konkretne potrzeby.  (Przeczytany 5569 razy)

Offline dikamilo

  • Użytkownik
    • blog

# Luty 24, 2012, 14:19:08
Pozwolę sobie wtrącić 3 grosze od siebie. Co do TDD, testowania itp. sisio ma tutaj sporo racji, ja na początku też nie miałem jakoś przekonania do tej techniki pisania i projektowania kodu, wydawała mi się całkowicie zbędna itp. Po przeglądnięciu kilku artów, tutoriali na ten temat, wypowiedzi innych osób trochę się przekonałem. Ale bez praktyki to nie jest to, wiec warto zacząć samemu, ale czasami nie wie się jak się za to zabrać, dlatego ja polecam zapoznać się z tym: http://www.youtube.com/playlist?list=PL0CCC6BD6AFF097B1&feature=plcp Wszystko jest pisane w Javie ale myślę ze nie ma to większego znaczenia, można się sporo dowiedzieć odnośnie TDD, jak pisać, co testować, co to potem daje itp. Najważniejsze jest to że to nie jest jakiś wymyślony, typowo ćwiczeniowy problem tylko tworzenie aplikacji od zera w TDD.

A za "String calculator kata" dziękuję :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline zxc

  • Użytkownik

# Luty 24, 2012, 16:29:54
Silnik ma rozwiązywać problemy, które pojawiają się przy produkcji gry. Jeśli nie nie zrobiłeś dotąd gry ponad Ponga, to nie znasz tych problemów. Zrób kilka gier, poznaj problemy, wypracuj swoje rozwiązania, a z czasem te rozwiązania przekujesz w coś, co można nazwać silnikiem. W przeciwnym wypadku rozwiązujesz wyobrażone problemy, które nijak się mają do Twojej sytuacji, umiejętności i możliwości.

Zrób grę i rozwiązuj faktyczne problemy.

Jak chcesz, żeby potwory zachowywały się wiarygodnie, to zamiast pisać AImanagera ze skryptowym API, możesz zrobić z nich zombie, które idą w drodze prostej do gracza. Problem rozwiązany.

Jak chcesz wyświetlić postać gracza na ekranie, to zamiast opracowywać system, który wyświetla animowane modele 3d, i szukać ludzi, którzy opracują kontent pod ten system, możesz zrobić gracza prostopadłościanem, który ma symbolicznie narysowane ubrania i twarz, a animować go przez podskoki przy ruchu. Problem rozwiązany.

Jak chcesz mieć grę z podziałem na poziomy, to możesz tworzyć własny edytor, albo parsować bitmapy narysowane w gimpie, gdzie szary to ściana, czerwony przeciwnik, żółty to punkt startowy. Albo napisać eksporter do blendera, albo parsować xmle, które możesz edytować na żywo w grze, albo użyć gotowego edytora. Problem rozwiązany.

To wszystko są rozwiązania, które działają równie sprawnie jak elastyczny silnik, który proponujesz. Umożliwiają bardzo szybkie i efektywne sprawdzenie swoich pomysłów w działaniu. Jednocześnie nie ma potrzeby dbania, aby były elastyczne i sprawdzały się w przyszłości. Nie trzeba ich planować i pisać zawczasu. Takie podejście zmusza Cię do spojrzenia co teraz możesz zrobić i co jest teraz potrzebne. A nie co będziesz mógł zrobić w przyszłości z ekipą 10 grafików.

Jeśli więc nie chcesz pisać na Unity, to pisz od zera w XNA, ale pisz skutecznie - skup się na grze, a nie na pisaniu własnego Unity. Popróbuj dużej ilości brudnych sztuczek w tym stylu. Dużo hardcoduj. Zrób kilka kompletnych gier w dzień, w tydzień, w miesiąc. Wtedy będziesz dokładnie wiedział czego potrzebujesz od silnika i wtedy go napiszesz (lub przesiądziesz się na gotowy). Będziesz też znał swoje możliwości produkcyjne. Jeśli takich małych gier nie będziesz mógł wypełnić zawartością, to na nic Ci silnik, który umożliwi zrobienie gier "dowolnie bardziej skomplikowanych".

Z architektury kodu, to na początek potrzebujesz tylko systemu zarządzającego stanami gry, żeby móc pisać oddzielny kod dla menu i oddzielny kod dla gry. Resztę pakuj sobie w obiekty wedle potrzeb, a jak zaczną się powtarzać pewne schematy, to je odnotuj i upraszczaj.

Generalnie powodzenia. Bierz nawias wszystkie porady, które usłyszysz w internecie. Nie wierz mi na słowo. Sprawdź sam. Dlatego też polecam metodę, która opiera się na wymiernych rezultatach - jeśli nastawiasz się na zrobienie gry, a gry nie zrobiłeś, to porażka; jeśli zrobiłeś - to sukces. W pisaniu "silnika" nie ma takich kryteriów.


tl;dr: jak nie zrobiłeś kilku gier, to nie wiesz czego potrzebujesz w silniku. Zrób najpierw kilka gier.

Offline azmodan

  • Użytkownik

# Luty 24, 2012, 19:55:10
@Siso
Dzięki, będę pamiętał. Jak na razie ogarniam na spokojnie podstawy. Jak już dojdę do jakiś pytań, na które google nie ma jasnych odpowiedzi, to na pewno się odezwę :)

@dikamilo
Jop, niemniej dzisiaj cały dzień staram się trzymać tej techniki, idzie jak idzie, ale już zaczynam czuć, że to może być całkiem potężna sprawa. Największy problem to przestawić swój tryb myślenia. Klasycznie, musiałem szukać błędów, gdy już się pojawiły, teraz muszę je przewidywać zanim zostaną popełnione. To dość fundamentalna zmiana muszę przyznać.

Zajebiaszcza seria, z pewnością się temu dokładnie przyjrzę, bo jest właśnie tak jak mówisz. Ogromna większość materiałów to przykłady tak przykładowe, że niby już wiem "jak to się robi" z technicznego punktu widzenia, wiem co gdzie wpisać i w ogóle o co kaman, ale nadal nie mam jasnego wyobrażenia jak się zabrać za konkretny nieprzykładowy problem. Thx!

@zxc
Zacznę od kwestii unity, bo węszę w tym: "równie dobrze mógłbyś robić w unity". Owszem, mógłbym, ale nie wiem jaka "architektoniczna" idea przyświecała twórcom unity, nie znam ich api itd. Dowiadywanie się tego wszystkiego i ogólnie nauka unity zajęłaby mi porównywalną ilość czasu, co nauka pisania własnego engine'u. W pierwszym przypadku nie zyskuję nic poza uzależnianiem się od ich (było nie było) płatnego produktu. Natomiast w drugim, nawet jeśli jakościowe efekty gier w ten sposób zrobionych będę gorsze, uczę się znacznie więcej i znacznie bardziej uniwersalnych aspektów ich tworzenia.

Jeśli chodzi o resztę, to nie twierdzę, że nie masz racji, ale nie twierdzę też, że - przynajmniej w odniesieniu do mojego "celu" - masz ją w stu procentach. Bo właśnie hard code'owania chciałbym się oduczyć. Dokładniej, nauczyć właśnie pisać bardziej uniwersalny kod. Zasadniczo, od zawsze interesowałem się gamedevem. To nie jest tak, że od tygodnia i teraz engine'y mi się śnią po nocach. Mam generalne wyobrażenie na temat tego czego będę potrzebował w engine'ie. Prawda, prawda, że to nie to samo co konkretne doświadczenie, ale będzie musiało wystarczyć na początek. Znacznie gorzej rzecz się ma z wyobrażeniem jak mają funkcjonować bebechy, by były w miarę elastyczne i uniwersalne. I to właśnie tego w szczególności chcę się nauczyć. Stąd taka, a nie inna decyzja.

Ale nie odrzucam Twoich rad, zamierzam rozwijać silnik małymi kroczkami i co sensowną ilość takich kroczków dla próby i testu robić jakąś małą mini-grę/test/techdemo. Tak, żebym miał feedback, czy przypadkiem nie wymyśliłem czegoś w sposób, który tylko w kodzie zdaje się być sensowny, a nijak ma się do korzystania z edytora i engine'u przy tworzeniu samych gier. To chyba w pewnej mierze to o co Tobie właśnie chodziło, jeśli dobrze zrozumiałem? Tyle tylko, że upchnięte tak, żebym nie musiał rezygnować z pisania silnika :)



Offline zxc

  • Użytkownik

# Luty 24, 2012, 22:24:18
Jeśli chcesz się nauczyć uniwersalnych aspektów tworzenia gier, to twórz gry, a nie pisz silnik. Nie nauczysz się tworzenia gier nie tworząc gier. Chcesz nauczyć się robić gry od strony bebechów, to zrób grę, a nie pisz bebechy.

Twoje wyobrażenia na temat tego, czego potrzebuje gra są błędne. Jak zrobisz grę to się przekonasz które i dlaczego. Jak będziesz pisał silnik, to się nie przekonasz.

Generalnie można długo przekonywać, ale ja się w takie ranty za bardzo angażuję. Powodzenia. Chętnie dowiem się za pół roku jak poszło.

Offline azmodan

  • Użytkownik

# Luty 26, 2012, 01:00:20
@zxc
Cytuj
Generalnie można długo przekonywać,
To prawda, można. Też uważam to bez sensu, powiem więc tylko tyle, że postaram się nikogo nie zawieść. Siebie samego w szczególności :)
---

@Siso
Zrobiłem kalkulatorek kata, jak żeś kazał :D Mówiłem, że  zrobię. Dzisiaj, głupotami jakimiś się zajmowali w szkole, więc pomyślałem, że sam zajmę się czymś bardziej pożytecznym. No i ostatecznie muszę przyznać, że ćwiczenie okazało się znacznie bardziej przyjemne niż się spodziewałem. Dodatkowo, ku swemu zdziwieniu stwierdziłem, że wykonanie całości zajęło mi około godziny, może półtorej. Trudno powiedzieć, bo często musiałem przerywałem na moment, czy dwa, wiadomo. Tak czy owak, bez TDD zajęłoby mi to co najmniej kilkakrotnie więcej czasu. Do czego zmierzam, z początku była jakaś niechęć do takiego "zadania", ale tak - już po wykonaniu - jestem w pełni skłonny przyznać rację, że ćwiczenie to pozwala spojrzeć na programowanie z innej strony. Zwłaszcza jak nie miało się wcześniej do czynienia z TDD.
---

No i by the way, trochę grzebię sobie w przykładach, trochę czytam, trochę oglądam serię poleconą przez dikamilo, a trochę grzebię przy owym własny endżinie i jego zalążkach. Podstawową funkcjonalność menedżera grafu sceny, pisząc tak według własnego pomysłu, oprogramowałem starając się możliwie pryncypialnie przykładać do zasad TDD i cóż, mogę rzec... Wszystko działało w momencie gdy (de facto) skończyłem pisać. Być może są jakieś bardziej utajone bugi, które wyjdą dopiero później, ale generalnie wszystko działała. :)

Pozdrawiam.

Offline siso

  • Użytkownik

# Luty 26, 2012, 01:21:30
Zrobiłem kalkulatorek kata, jak żeś kazał :D
Eeee tam kazał... Ja żem tylko zasugerował ;)

Cytuj
Wszystko działało w momencie gdy (de facto) skończyłem pisać. Być może są jakieś bardziej utajone bugi, które wyjdą dopiero później, ale generalnie wszystko działała. :)

I tak właśnie powinno być. Jeśli pokażą się jakie bugi później, to może to być spowodowane niekompletnym pokryciem w chili obecnej. Ale z czasem dodasz jeszcze więcej testów i bugów nie będzie :)

Powodzenia!

Offline siso

  • Użytkownik

# Luty 26, 2012, 02:45:53
Znalazłem przypadkiem całkiem przyjemny framework do UT w C++: http://igloo-testing.org/

Obadajcie, jak ziom TTD-uje Game of Life w Vimie :)