Autor Wątek: Wybór silnika  (Przeczytany 15607 razy)

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 12, 2007, 21:08:37
Cytuj
Ale jesli dobrze przemyslimy sprawe i od razu zaimplementujemy dobre optymalne rozwiazanie to moze nie trzeba go bedzie wcale zmieniac i sie przez nie przekopywac w pozniejszej fazie
I przykładowo (trochę skrajny przykład, ale ma taka sytuacja miejsce) wystarczy, że ktoś w tym czasie opracuje nową technologię, która niestety wymaga trochę innego podejścia. I co wtedy? Ryzykujemy, że nasz projekt będzie już na wejściu przestarzały? Czy wprowadzamy zmiany (które zajmują nam krótki czas, bo mamy czytelny kod) i jesteśmy konkurencyjni?

Offline Mr. Spam

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

Offline mINA87

  • Użytkownik

# Sierpień 12, 2007, 21:12:12
Przy naprawdę dużych projektach to nie ma żadnego code Feng-Shui - jest kasa, są terminy, jest produkcja - ma być kod i koniec. Nikogo nie interesuje czy klasa będzie dodatkowo parzyła kawę bo może się to komuś przydać - ma być napisana tak by działała teraz i by nikt niemusiał do tego kodu wracać, bo wracanie do kodu to zawsze koszty czasowe i finansowe. Dlatego produkuje się małe porcje kodu, który spełnia oczekiwania i który jest na tyle prosty i działa na tyle dobrze że jutro go nie trzeba będzie poprawiać. Przy dużych projektach zaczyna się manufaktura a kończy sztuka.
A odnośnie technologii - nikt się nimi nie przejmuje - gry się robi na kilka lat w przód, albo się ich nie kończy wcale :]

Offline yarpen

  • Użytkownik

# Sierpień 13, 2007, 10:42:55
Cytuj
Tyle, ze te metodologie dotycza zazwyczaj systemow innych niz gry, takich, gdzie odbiorca/klient ma duzo do powiedzenia i moze sobie po prostu zazyczyc jakiegos feature'a.
Innych niż gry... polskie. Na zachodzie wiele z tych metodologii jest już z powodzeniem stosowana/wdrażana w gamedevie. Moje zdanie jest takie, że Polska w tym względzie jest jakieś 20 lat z tyłu :( Prawda jest taka, że klientem jest wydawca - nierzadko ma miejsce sytuacja, że czegoś chce, bo tak mu się podoba. I nic się z tym nie zrobi. W poważniejszych przedsięwzięciach dokumentacja jest jeszcze bardziej skomplikowana niż design doc, co wcale nie przeszkadza w implementacji takiego postępowania.
Nie wiem skad czerpiesz ta wiedze, pracowalem w gamedevie na zachodzie, pracuje w Polsce, duzej roznicy nie widze.

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 13, 2007, 11:12:47
Cytuj
Nie wiem skad czerpiesz ta wiedze, pracowalem w gamedevie na zachodzie, pracuje w Polsce, duzej roznicy nie widze.
Ponoć jednak zmiany zachodzą ;) Polskie doświadczenia zasiały u mnie jedynie zwątpienie w sens pracy w gamedevie, więc liczę, że na zachodzie jest choć trochę lepiej. Metodologie te są na tyle młode (XP i całe Agile przecieć tak na prawdę od ok. 4-5 lat zaczyna zdobywać popularność), że mogłeś jeszcze tego nie doświadczyć :) A nawet jeśli by tak nie było, to jest to tym większy błąd gamedevu. Czasami patrząc na sposób organizacji projektów i sposób ich prowadzenia (zarówno od strony kierownicznej, jak i programistycznej) to aż się człowiekowi chce płakać. Są popełniane tak elementarne błędy, że aż wstyd. I to także w firmach mających jakieś aspiracje.

Offline yarpen

  • Użytkownik

# Sierpień 13, 2007, 16:20:54
Osobiscie wcale nie jestem przekonany, ze Agile/XP nadaja sie do gamedevu, z powodow, o ktorych pisalem wyzej. Z tego co wiem, to stosuja to tak naprawde dwie firmy -- High Moon i, w duzo mniejszym zakresie, Radical Vancouver. Pewnie jest ich wiecej, ale na pewno nie mozna mowic o dominujacym trendzie.

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 13, 2007, 16:58:00
Cytuj
Osobiscie wcale nie jestem przekonany, ze Agile/XP nadaja sie do gamedevu, z powodow, o ktorych pisalem wyzej.
Jednak wiele rzeczy w Agile/XP nie ma bezpośrednio do czynienia z relacjami klient-developer, a zmierza do poprawienia jakości kodu (przykładanie szczególnej uwagi do testów, i na nieco innej zasadzie, pair-programming), czy dobrymi kontaktami między developerami (spotkania, inna odpowiedzialność za kod, możliwość pracowania nad modułem spoza swoich kompetencji). Zgadzam się jak najbardziej, że część rzeczy w gamedevie jest niepotrzebna (user-stories, karty CRC), ale jest to tylko kilka postulatów (wcale nie najistotniejszych) dlatego mnie takie podejście bardzo dziwi.
Zresztą wydaje mi się problemem nie są same postulaty XP (XP samo sugeruje jego modyfikację, jeśli nie uwzględnia specyfiki projektu), ale to czy programiści umieją się przestawić na trochę inny tok myślenia i pracy. Spotkałem wiele osób stosujących XP na codzień i chwalących sobie tę metodologię i pewnie równie wiele takich, które twierdzą, że tak się nie da programować ;) Da się, ale nie każdemu się to musi podobać.
« Ostatnia zmiana: Sierpień 13, 2007, 17:05:20 wysłana przez Riddlemaster »

Offline yarpen

  • Użytkownik

# Sierpień 13, 2007, 17:09:09
Cytuj
Osobiscie wcale nie jestem przekonany, ze Agile/XP nadaja sie do gamedevu, z powodow, o ktorych pisalem wyzej.
Jednak wiele rzeczy w Agile/XP nie ma bezpośrednio do czynienia z relacjami klient-developer, a zmierza do poprawienia jakości kodu (przykładanie szczególnej uwagi do testów, i na nieco innej zasadzie, pair-programming), czy dobrymi kontaktami między developerami (spotkania, inna odpowiedzialność za kod, możliwość pracowania nad modułem spoza swoich kompetencji). Zgadzam się jak najbardziej, że część rzeczy w gamedevie jest niepotrzebna (user-stories, karty CRC), ale jest to tylko kilka postulatów (wcale nie najistotniejszych) dlatego mnie takie podejście bardzo dziwi.
W tym ujeciu, to cale XP staje sie kolejnym buzzwordem na nazwanie praktyk, ktore funkcjonuja juz od wielu lat :). Co do przydatnosci w gamedevie, to z moich doswiadczen wynika, ze unit testy sa nie do wprowadzenia (wyjawszy niektore low-levelowe biblioteki), pair programming to kwestia gustu, u nas w firmie na pewno by nie przeszlo na dluga mete, natomiast doraznie jest jak najbardziej stosowane, glownie przy grzebaniu w cudzym kodzie. Reszte w zasadzie wiele firm stosuje, choc niekoniecznie nazywa to XP. No i pewnie w nieco innej formie, bo po co mam robic zebrania zespolu, jezeli siedzimy w jednym pokoju, biurko w biurko itd. Tak naprawde osobiscie lykam bez zastrzezen tylko CI :) Ale odchodzimy troche od tematu chyba.

Offline KriS

  • Użytkownik
    • KriS

# Sierpień 13, 2007, 18:44:43
Co do przydatnosci w gamedevie, to z moich doswiadczen wynika, ze unit testy sa nie do wprowadzenia (wyjawszy niektore low-levelowe biblioteki)

Dlaczego? I jakie to byly testy? Wydaje mi sie, ze testy porownujace screenshoty na roznych konfiguracjach sprzetu i z roznymi driverami sa w miare latwe do wprodzenia i sa calkiem uzyteczne.

BTW sporo juz bylo metodologii / jezykow, ktore mialy rozwiazac wszystkie problemy branzy :). Nie wydaje mi sie aby wpychanie wszedzie XP / Agile / innej aktualnie modnej metodologii / jezyka cokolwiek by poprawilo.

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 13, 2007, 19:12:54
Cytuj
W tym ujeciu, to cale XP staje sie kolejnym buzzwordem na nazwanie praktyk, ktore funkcjonuja juz od wielu lat
Ale tak przecież poniekąd jest ;) XP powstało w zasadzie jako formalne ujęcie 12 best practises (niektórzy je trochę rozszerzyli w ostatnich latach ;) ). A że formalizacji i nadania nazwy dokonał Kent, a nie ktokolwiek inny - cóż tak to jest ;)

Cytuj
to z moich doswiadczen wynika, ze unit testy sa nie do wprowadzenia (wyjawszy niektore low-levelowe biblioteki)
Inna sprawa, że to te low-levelowe biblioteki są często narażone na błędy (przez swoją naturę, bardziej złożony kod itp.). Ja nie widzę żadnych przeciwskazań dla stosowania ich w tym celu. Zresztą unit-testować da się praktycznie wszystko. Niestety napisanie dobrych testów bywa czasem bardzo trudne, i wymagana jest tu pomoc specjalistów z tej dziedziny.

Offline yarpen

  • Użytkownik

# Sierpień 14, 2007, 12:01:23
Co do przydatnosci w gamedevie, to z moich doswiadczen wynika, ze unit testy sa nie do wprowadzenia (wyjawszy niektore low-levelowe biblioteki)

Dlaczego? I jakie to byly testy? Wydaje mi sie, ze testy porownujace screenshoty na roznych konfiguracjach sprzetu i z roznymi driverami sa w miare latwe do wprodzenia i sa calkiem uzyteczne.
Takie testy akurat sa srednio sensowne, bo pomiedzy roznymi kartami zawsze beda roznice i nie jest to blad (mozna podwyzszac tolerancje, ale wtedy zanika sensownosc testu). Zreszta, akurat w renderingu ciezko jest cos zepsuc nie grzebiac tam, w przeciwienstwie do innych modulow, ktore sa od siebie zalezne. Nie wierze, ze mozna napisac unit testy sprawdzajace chocby czy walka nadal jest fajna, czy nadal jest zbalansowana itp, chocby wzial sie za to Beck z Cunnighamem. Raz na kilka lat pojawia sie nowa metodologia lansowana jako rozwiazanie wszystkich problemow, lacznie ze swiatowym glodem. Zazwyczaj "wymyslona" przez czlowieka, ktory nie programowal nic wiekszego od 15 lat, a zyje z konsultingu (=mowienia ludziom rzeczy, ktore juz wiedza). Minie troche czasu i wejdzie nowy "silver bullet", a o XP ludzie zapomna (zreszta juz sie od tego powoli odchodzi, glowny propagator w gamedevie opuscil HM i przestal pisac o XP). Sam bylem na etapie kiedy czytalem o czyms nowym i wydawalo mi sie, ze to rozwiazae wszystkie moje problemy, a pozniej praktyka brutalnie to weryfikowala.

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 12:43:06
Takie testy akurat sa srednio sensowne, bo pomiedzy roznymi kartami zawsze beda roznice i nie jest to blad (mozna podwyzszac tolerancje, ale wtedy zanika sensownosc testu).
Zgadzam się, jednak widzę sensowność :) Różnice były są i będą i o ile chodzi o piksele, jakieś tam drobne artefakty przy filtrowaniu itp to takie testy nie mają kompletnie sensu i takie odstępstwa można olać, ale jak się zaczyna kombinować z egzotycznymi formatami render targetów, hardcorowymi profilami, optymalizacjami na halfach czy po prostu zapomni się gdzieś jakiegoś unlock'a to dzieją się dosłownie cuda. Na jednej karcie może to wyglądać dobrze, na innej kompletnie źle. Wątpię żeby np. progrmista silnika czy shaderów miał pod ręką chociaż 2 kompy z różnymi kartami (hihi kiedyś zamieniałem Radka 9550 na GF 2MX żeby powalczyć z bugmai ^^) więc takie błędy nie wyjdą od razu, a dopiero w testach czy nawet po ukończeniu produkcji lol. Dlatego fajnie by było jakby jakaś farma robiła batch buildy popchniętych na repozytoria stabilnych wersji kodu, profilowała je na kilku konfiguracjach i przy okazji robiła takie ogólnikowe quality testy i udostępniała raport - wiele spraw możnaby w ten sposób błyskawicznie likwidować, oszczędzioby to nerwów programistom, uratowało życie kilku testerom (w końcu to maszyna zgłosiła blędy a nie oni xD). Niestety takie rozwiązanie to w sumie utopia ^^ Kto w Polsce będzie postawi farmemkę kompów tylko i wyłączanie do batchbuildów i autoprofilingu :)

Offline yarpen

  • Użytkownik

# Sierpień 14, 2007, 13:38:36
Takie testy akurat sa srednio sensowne, bo pomiedzy roznymi kartami zawsze beda roznice i nie jest to blad (mozna podwyzszac tolerancje, ale wtedy zanika sensownosc testu).
Zgadzam się, jednak widzę sensowność :) Różnice były są i będą i o ile chodzi o piksele, jakieś tam drobne artefakty przy filtrowaniu itp to takie testy nie mają kompletnie sensu i takie odstępstwa można olać, ale jak się zaczyna kombinować z egzotycznymi formatami render targetów, hardcorowymi profilami, optymalizacjami na halfach czy po prostu zapomni się gdzieś jakiegoś unlock'a to dzieją się dosłownie cuda. Na jednej karcie może to wyglądać dobrze, na innej kompletnie źle. Wątpię żeby np. progrmista silnika czy shaderów miał pod ręką chociaż 2 kompy z różnymi kartami (hihi kiedyś zamieniałem Radka 9550 na GF 2MX żeby powalczyć z bugmai ^^) więc takie błędy nie wyjdą od razu, a dopiero w testach czy nawet po ukończeniu produkcji lol. Dlatego fajnie by było jakby jakaś farma robiła batch buildy popchniętych na repozytoria stabilnych wersji kodu, profilowała je na kilku konfiguracjach i przy okazji robiła takie ogólnikowe quality testy i udostępniała raport - wiele spraw możnaby w ten sposób błyskawicznie likwidować, oszczędzioby to nerwów programistom, uratowało życie kilku testerom (w końcu to maszyna zgłosiła blędy a nie oni xD). Niestety takie rozwiązanie to w sumie utopia ^^ Kto w Polsce będzie postawi farmemkę kompów tylko i wyłączanie do batchbuildów i autoprofilingu :)
Nikt, bo to nie ma sensu. Takie rzeczy zleca sie na zewnatrz.

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 14, 2007, 13:39:16
Cytuj
Nie wierze, ze mozna napisac unit testy sprawdzajace chocby czy walka nadal jest fajna, czy nadal jest zbalansowana itp
No dobra to prawda. Ale tak samo w przypadku innych systemów nie testuje się czy np. gui jest dobrze przemyślane. Unit testy mają sprawdzać jedynie poprawność wyników, a nie dawać opinię czy te wyniki są fajne, przyjemne itd. Jeśli programista napisał kod i zwraca on z testów wyniki takie jakich się spodziewał, to wcale nie oznacza jeszcze że kod jest dobry.

Cytuj
Zazwyczaj "wymyslona" przez czlowieka, ktory nie programowal nic wiekszego od 15 lat, a zyje z konsultingu (=mowienia ludziom rzeczy, ktore juz wiedza).
Nie zgodzę się z tą tezą w nawiasie. Naprawdę wiele rzeczy, które piszą, mówią konsultanci jest dla większości programistów czymś zupełnie nowym. Często prezentują też jednak nowatorskie podejście, które zwiększa szanse zakończenia projektu z sukcesem (według statystyk to jednak projektu wdrażające Agile są najczęściej kończone w czasie). Wystarczy poczytać np. Cuttera czy Gartnera (nie pamiętam, czy tak to się pisze), żeby zobaczyć, o jak wielu rzeczach nie miało się pojęcia. Poza tym wiem co mówię, bo mój ojciec też się konsultingiem zajmuje ;)

Cytuj
zreszta juz sie od tego powoli odchodzi, glowny propagator w gamedevie opuscil HM i przestal pisac o XP). Sam bylem na etapie kiedy czytalem o czyms nowym i wydawalo mi sie, ze to rozwiazae wszystkie moje problemy, a pozniej praktyka brutalnie to weryfikowala.
Cóż sprawa gamedevu - poza nim XP ma się coraz lepiej, ewoluuje moim zdaniem w dobrym kierunku. Prawda jest taka, że nie ma metodologii na wszystko. Z tego trzeba sobie zdawać sprawę. Jednak połączenie kilku, dodanie do tego własnych pomysłów może być rozwiązaniem.

Offline mINA87

  • Użytkownik

# Sierpień 14, 2007, 13:53:36
Nikt, bo to nie ma sensu. Takie rzeczy zleca sie na zewnatrz.
Mówisz o fazie testów chyba, a ja mówię o fazie produkcyjnej :) Do małych produkcji faktycznie się nie opłaca, do dużych ciągnących się w nieskończoność też nie - w końcu coś musi wydłużać czas pracy nad produkcją :)

RageX

  • Gość
# Sierpień 14, 2007, 14:35:54
kurka... to jak programujesz bez testów?
Rozumiem że ci się nie chce szykowac testów które będą cały kod weryfikowały na zawołanie i gdy nadejdzie czas jakiejść refaktoryzacji to takie tesy są niezastąpione... ale tak jak już było to tutaj pisane, róznie to w biznesie bywa.

Ale nie rozumiem jak można cokolwiek większego napisać... nie tworząc testów (nawet banalnych) pod każdy krok budowy. Takim postępowaniem buduje się prowizorkę, która się rozsypie przy najbliższej okazji.
Kompilujesz... patrzysz "na oko" czy działa i voila?

Fizyki w ten sposób nie napiszesz(chyba że jakąś prymitywną na maxa).  ;)

Sam sobie pozwalam na coraz większe fragmenty kodu bez testów, po prostu pisałem to ileś tam razy testując i jestem przekonany że tym razem zadziała bez testu. Ale niektórych rzeczy bym nie puścił bez testu - ze strachu.