Bamse

Dawajcie glowy z Dragon Ball, to sie pewien pan z "Atari" ucieszy ;)

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% ;)

Wybacz, ale jezeli role programisty sprowadzasz do "znać realia i możliwości obecnego sprzętu" to moge jedynie pogratulowac wyobrazni. Jezeli na czele projektu nie stoi osoba posiadajaca doswiadczenie programistyczne, to zespol sam sie prosi o klopoty. Tworzenie gier jest nadal tworzeniem oprogramowania, i jak przyjrzysz sie zespolom pracujacym nad komercyjnymi grami, to zauwazysz, ze bardzo rzadko zdarzaja sie przypadki szefow, ktorzy wczesniej nie pracowali jako programisci. Na takie eksperymenty moga sobie pozwolic jedynie bogate firmy, bo ryzyko jest spore, a wynik niepewny.

Calkowicie zgadzam sie z Jagoda - szefem projektu MUSI byc programista i to najlepiej z kilkuletnim doswiadczeniem. To on powinien miec ostatnie slowo w kazdej kwestii i to on powinien temperować megalomanie reszty zespolu :P Jesli chodzi o kwestie prawdopodobienstwa zakonczenia przedsiewziecia powodzeniem, to mysle ze macie wieksze szanse na trafienie szostki w totku niz na ukonczenie gry ;) Dlaczego? Jako poczatkujacy rzuciliscie sie od razu na jeden z najbardziej pracochlonnych gatunkow gier - CRPG - to bardzo zla wrozba! Jezeli marzy Wam sie tworzenie gry future RPG to lepiej dolaczcie do jakiegos istniejacego zespolu, bo jezeli zabierzecie sie za nia samodzielnie, to pewnie zdolacie jedynie stworzyc stronke gry, wymyslicie jej nazwe i logo, opracujecie dokument z zarysem swiata, a moze nawet wydacie na swiat kilka rysunkow koncepcyjnych i modeli low poly. I na tym koniec. 99% amatorskich zespolow dochodzi do tego punktu i projekt upada. Wszyscy juz zdarzyli sie gra znudzic i zaczeli odczuwac zmeczenie praca, a prawda jest taka, ze nie zdolali wykonac nawet 1% pracy potrzebnej do ukonczenia takiej gry. Aha i jeszcze jedna kwestia. Z tworzeniem gier jest jak z praca ginekologa ;) Jezeli bierzecie sie za ich produkcje, to nie zdziwcie sie, jak przestaniecie odczuwac przyjemnosc z grania w inne gry :( Zastanowcie sie, czy realizowanie marzen jest warte utraty przyjemnosci plynacej z tego, jakze przyjemnego, sposobu spedzania wolnego czasu :D

Nie wiem w jakim formacie UT przechowuje tekstury, ale 2,5MB wychodzi dla teksturek 16-to bitowych. Przy trybie ARGB 5MB - troche za duzo jak na jedna kowbojke ;)

A jak z wydajnoscia renderingu? Cypher nie jest pod tym wzgledem demonem szybkosci, wiec czesto zdarza sie, ze nawet proste gry maja kiepski frame rate.

Chyba Shell-Pit :p

Na poczatek zerknijce tu: http://warsztat.mmogspot.pl/artykuly/3dsmaxplugin/3dstudiomax%20v2_0.pdf A zrodelka sa tu: http://warsztat.mmogspot.pl/artykuly/3dsmaxplugin/src.zip

Stronka jest duzo bardziej przejrzysta od poprzedniej, ale dwie rzeczy mozna poprawic. Po pierwsze brakuje mozliwosci powrotu do pierwszej strony (np. poprzez nacisniecie loga firmy). Druga sprawa jest fakt uzycia ramek. Co prawda sa one dosc wygodne, ale powinienes z nich zrezygnowac, jezeli zalezy Ci na dobrym spozycjonowaniu stronki w wyszukiwarkach internetowych.

Faktycznie, brak exit jest dosc dziwny, ale cala reszta jest spoko. Jak popatrzylem na czcionki menu to od razu zapachnialo mi Collinem ;)

Tak sobie patrze na zdjecia referencyjne, i wyglada na to, ze zrobiles zbyt krotkie nogi - czesc "udowa" jest za mala. Poza tym nie jestem pewny, ale Twoj model chyba moze przyjmowac tylko jedna pozycje, natomiast ten z referencji ma jakis podnosnik ktory unosi gorna czesc ponad "biodra", dzieki czemu znika problem uderzania kolanami w kabine.

Wyglada swietnie, tylko musisz poprawic wspolrzedne tekstur, bo widac szew przy polaczeniu przedniej prawej lapy z cialem.