RK: najwyrazniej mamy inne doswiadczenia :) ja zawsze stykalem sie z modelem w ktorym calym "cyrkiem" kierowal manager wywodzacy sie z "kasty" programistycznej ;) Oczywiscie najczesciej nie mial czasu na programowanie, i stanowisko glownego programisty zajmowal ktos inny, ale osoba ta doskonale rozumiala specyfike pracy programisty.
Przyklad Jasia Romero jest dosc skrajny :) Juz sam pomysl powierzenia takiej kasy mechanikowi samochodowemu ktory sklecil kilka leveli do gry jest dosc chory, i cale szczescie, ze za ta pouczajaca dla calej branzy "zabawe" zaplacil Eidos :)
Tymi technikami powszechnie znanymi to mnie troche rozbawiles :) To ze wiem jak wyglada postac czlowieka, nie oznacza ze jestem w stanie stworzyc jej ladny model 3D, oteksturowac go i zrigowac. To ze Ty znasz pojecie Morphingu, i wiesz jak ta technika dziala, nie oznacza, ze bylbys w stanie ja zaimplementowac. Wielu grafikom, i generalnie ludziom ktorzy nie zajmuja sie programowaniem, wydaje sie, ze skoro kupilismy gotowy Engine, to od strony programistycznej nie ma juz nic do roboty. A prawda jest taka, ze to dopiero poczatek dlugiej drogi - udalo nam sie zaoszczedzic troche czasu, ale nadal czeka nas strasznie duzo pracy i nauki. Wyjatek stanowia gry z kategorii budget, bo w ich przypadku z reguly nie wprowadza sie zadnych inowacyjnych pomyslow, nie dba sie o wyrafinowane AI, a o optymalizacji nikt nawet nie mysli - bo po co :P
To co opisales jako tworzenie logiki i algorytmow, to tez jest praca programistyczna. Ludzie piszacy skrypty sa tanszymi wersjami programistow. Nie maja takiej wiedzy, i pracuja wykorzystujac idiotoodporne jezyki skryptowe, ale specyfika ich pracy jest bardzo podobna. Stworzony przez designera opis zachowania zolnierza moze zmiescic sie w kilku zdaniach, ale jego zaimplementowanie moze wymagac setek, albo i tysiecy linijek kodu.
Raven: problem tkwi w tym, ze wiekszosci ludzi wydaje sie, ze skoro jakas technologia jest powszechnie opisana i ze wszyscy znaja jej nazwe, to jej implementacja powinna byc dziecinnie prosta i spokojnie mozemy ja dodac do gry. I takich "prostych" rzeczy wrzuca sie do worka setki, a pozniej mamy klopoty :) Musisz wziac pod uwage, ze programisci znajduja sie pod OGROMNA presja calego zespolu, i w przypadku, gdy przedsiewzieciem kieruje osoba nie znajaca specyfiki ich pracy, moze sie okazac, ze "zgodza" sie na podjecie wyzwania ktoremu nie sa w stanie sprostac :( Oni po prostu ulegaja pod naciskiem przyjaciol, szefa, itp, a reszta zespolu moze nawet nie byc swiadoma tego ze wywarla presje ktora moze zagrozic calemu przedsiewzieciu.
Jezeli chodzi o nadzor nad poszczegolnymi dzialami to tez sie z Toba nie zgodze, bo efekty pracy grafika sa widoczne, efekty pracy muzyka sa slyszalne, efekty pracy designera mozesz przeczytac, ale na efekty pracy programisty musisz czesto czekac wiele tygodni, a nawet miesiecy! Dlatego tak wazne jest, aby na czele projektu stala osoba potrafiaca skontrolowac prace programistow, zanim jej efekty stana sie widoczne dla innych czlonkow zespolu. Juz pomijam sytuacje patologiczne, gdy programisci naduzywaja zaufania szefostwa, piszac w godzinach pracy programy zaliczeniowe na uczelnie, badz fuchy dla innych firm.
I tu dochodzimy do glownego argumentu za tym, aby na czele projektu stala osoba z doswiadczeniem programistycznym :) Kto jest glowna przyczyna opoznien projektow, a nawet ich upadku?
a) Graficy?
b) Muzycy?
c) Designerzy?
d) Programisci?
e) PROGRAMISCI!!!
f) odpowiedzi d) i e)
Czy ktos ma w tym wzgledzie jakies watpliwosci? :) Kierownik projektu majacy doswiadczenie programistyczne ma najwieksze szanse na szybkie wychwycenie zagrozenia plynacego ze strony najbardziej zawodnych czlonkow zespolu ;) Jezeli nie rozumiesz pracy programisty, a jestes szefem firmy tworzacej gry, to nie zdziw sie, gdy bedziesz musial sobie poradzic z projektem ktory juz od pol roku jest skonczony w 99% ;)
