nihilplures

Ok, dzięki - przy okazji kolejnych poprawek zmienię czcionkę. Tu jest coś podobnego, tylko system sterujący grupą botów powinien się uczyć drzewa planowania :) Jeszcze muszę w tym celu napisać drugą grę z dwoma konkurującymi zespołami :P

Cieszę się, że nie jest tak źle :P Ogólnie gra rzeczywiście nie jest w pełni doszlifowana, ale sądziłem, że dotyczy to innych elementów. Czy mógłbyś opisać, które elementy UI można poprawić - pomogłoby mi to :)

Jakiś czas temu pokazywałem tutaj minigierkę, nad którą pracowałem - ostatnio wprowadziłem poprawki zgodne z większością uwag. Gra jest dostępna za darmo, jeśli ktoś jest zainteresowany, to zapraszam: http://unity3ddev.net/smartblocks

Tutaj link pisze, że na początku trzeba wyrównać teren do wysokości większej niż 0.

No właśnie nie jestem pewien czy to nie podpada (zgodnie z prawem) pod rozkompilowywanie softu, które jest niedozwolone - ogólnie ciekawy temat i sam chciałbym mieć pewność. Kontynuując temat trawy domniemam, że proceder mógł dotyczyć sytuacji, w których bardzo ciężko stwierdzić czy coś było podprowadzone. Może też w przeszłości takie przypadki były częstsze, bo nie było dostępu do tak dużej ilości darmowych lub bardzo tanich zasobów. Zdarza się też, że ludzie nie zawsze się oburzają jak ktoś wykorzysta ich prace. Podsumowując, bardzo się cieszę i cenię jeśli firmy podchodzą do sprawy fair, ale na podstawie opinii, które do mnie docierają nie wykluczałbym opisywanego zjawiska. No i to, że ktoś znajdzie "kawałek trawy" w internecie nie oznacza, że rzeczywiście ma prawo wykorzystać - dlatego nie jest tu mowa wyłączenie o rippowaniu. Trzeba też pamiętać, że mały twórca gier, którego łatwo zdmuchnąć rynku nie może sobie pozwolić na tego typu wpadki, bo internet jest mściwy :)

Co do przykładu z trawą, to informacja ta nie dotarła do mnie od osoby z kręgu flashówek i telefonów. Nie chodzi też o konkretną jedną firmę. Nie namawiam to korzystania z nielegalnych zasobów, ale w obecnych realiach do świętości można na ogół dążyć, a nie ją osiągnąć. Z resztą widzę, że zawsze znajdzie się miejsce na mały wyjątek moralny: "co innego jeśli..." - nawet jeśli z punktu widzenia prawa, to to samo :)

Wiele rzeczy można zrobić przy użyciu darmowych programów - przykładowo jeśli coś da się zrobić przy pomocy Blendera, nikt Cię nie oskarży, że spiraciłeś 3Ds max. Słyszałem, że wśród profesjonalnych twórców gier rippowanie assetów jest nagminne - nikt na przykład nie będzie po raz tysięczny robił tekstury trawy, tylko spróbuje taką znaleźć. Ogólnie przy opublikowaniu gry na ogół nikt nie będzie dociekał, chyba że naprawdę postąpiłeś nie fair albo masz "przyjaciela" :)

Tak samo kiedyś dałem się nabrać na rozdzielczość tekstur :)

Dzięki za uwagi: - nad rozpoznawalnością kolorów na klockach jeszcze będę pracował - nad sterowaniem i kamerą pomyślę To jest wersja developerska i ta plansza nie ma stanowić wyzwania lub uczyć gracza gry, ponieważ utrudniłoby mi to testowanie.

Podczas pisania gry naszło mnie takie przemyślenie, ale optymistycznie przyjąłem, że coś takiego się nie przytrafi :P Gdyby jednak gra miała w jakikolwiek sposób zyskać popularność, to dodam jakiegoś helpera.

Ostatnio napisałem gierkę logiczną pt. Smart Blocks. Opublikowałem wersję testową, która uruchamia się w przeglądarce (Flash). Gdyby ktoś chciał potestować, to zapraszam: http://unity3ddev.net/viewtopic.php?f=18&t=671

We wcześniejszym swoim poście poprawiłbym Samsunga Galaxy S II na S I (mylą mi się). Na tych urządzeniach testowałem grę w pracy. Warto też pamiętać o sporej różnicy pomiędzy iPhonem 3 i 3GS. 3GS pociągnie Epic Citadel - tak jak iPhone 4.

Według mnie większość rynku można objąć robiąc gry na Samsung Galaxy S II, Samsung Galaxy Tab 10.1 i iPhone 3GS - wszystkie mają porównywalną moc, są popularne i dobrze przygotowane gry 3D nie będą na nich przycinać. Starszymi modelami nie ma co się przejmować. Z rozdzielczością można sobie bardzo łatwo radzić robiąc elastyczny interfejs (w Unity bardzo fajnie się to testuje). Dla niezależnych twórców gier mam jeszcze taką informację, że jeśli chcą to mogą za darmo reklamować swoje produkcje na UDK|Unity3D|CryENGINE|dev.net - wystarczy podesłać mi materiały dotyczące gry. Forma reklamy to obrazek w przewijanej liście projektów oraz artykuł na stronie głównej, współdzielone na wszystkich trzech sekcjach serwisu. Mile widziane zwiastuny, screeny i opisy. Zachęcam, bo jest tam całkiem sporo odwiedzin i będzie jeszcze więcej, gdy pojawią się informacje o waszych grach - twórcy gier interesują się tym co i jak aktualnie się robi. Na razie lista projektów jest pusta, ale jak się uzupełni (10 pozycji), to oprócz materiałów na temat gry będę prosił jeszcze o prosty tutorial na temat fragmentu wykonania gry - w każdym bądź razie nadal reklamowanie gry będzie darmowe.

Mi się tam podoba - jest realistycznie. Pamiętam grę Viper Racing i tam jeździło się podobnie. Gdyby dodać zniszczenia, to gra mogłaby trafić do grupy odbiorców, która lubi wyzwania. Zwróciłem uwagę na pewne artefakty graficzne - czasem jakieś czarne trójkąty i widoczne łączenia geometrii.

Po prostu należy korzystać z najnowszego dostępnego OSa i najnowszego XCoda jaki jest. Nie wiem jakie konkretne wersje są wadliwe, dla mnie to jedno wielkie gówno. Unity3D wypluwa projekt do skompilowania w XCodzie. W nim zaś ustawia się certyfikaty i provisioning (taki pliczek generowany na stronie konta deweloperskiego :)

Przeszedłem tę szaleńczą procedurę kompilowania gry z Unity na iOS, od której przybyło mi na głowie kilka siwych włosów. To co tam wybrałeś jest za drogie. W pracy posługiwaliśmy się Mac Mini (wołaliśmy na to "mydełko"). Jedyne co mydełko powinno potrafić, to uaktualnić się do najnowszego OSa z najnowszym XCodem - nie radzę eksperymentować ze starszymi wersjami, ponieważ produkty Apple nie wykształciły funkcjonalności informowania użytkownika o niezgodności wersji (np. projektu z Unity i XCoda). Mam nadzieję, że zacząłeś już załatwiać konto deweloperskie, bo to trwa długo.

W takim razie nie szukasz pracy tylko praktyk (na ogół bezpłatnych). Nigdy nie wspominaj, że chciałbyś pracować za darmo, bo Twoje życzenie się spełni :)

Zamiast "atrakcyjne" przydałaby się cyfra lub chociaż widełki :) Podejrzewam, że jest to najwyżej prawie średnia krajowa lub atrakcyjna wizja udziału w przychodach z gry :)

Chyba na początku musisz zainwestować trochę swojego czasu i uzupełnić portfolio o parę swoich projektów (albo uczestnicząc w projektach darmowych produkcji). Do pracy idzie się już z pewnym zasobem umiejętności - wiek tu nie jest aż tak istotny. Nieno jak znajdą sobie dokładnie osobę, którą opisali to projekt jak z bicza strzelił. Tak tylko się zastanawiam, bo jeśli ktoś ma skilla, żeby samodzielnie napisać i opublikować grę, to po cóż miałby dla kogoś pracować?

Godzinę temu tutaj pojawiła się taka oferta pracy: http://unity3ddev.net/viewtopic.php?f=17&t=642

Słyszałem, że te tutki są bardzo dobre, ale na początku nie polecam wydawać kasy

Nie trzeba za wiele pisać, wystarczy zmodyfikować istniejące skrypty do swoich potrzeb. W UDK są przykładowe pojazdy - w tym latający. Samochód jest trudny w wykonaniu, ale obiekt latający jest prosty, ponieważ jest specjalny typ fizyki dla obiektu latającego, który wystarczy ustawić. Ściągając UDK ma się dostęp do źródeł Unreal Tournament z pojazdami, ale tamte przykłady są dosyć rozbudowane. Tutaj jest przykład latającego słonia: http://forums.epicgames.com/threads/722623-Plug-and-Play-Flying-Elephant-Download A gdybyś chciał technicznie porozmawiać o kodowaniu, to zapraszam na http://udkdev.net/ :)

Po coś silnik daje taką możliwość posługiwania się bryłami wklęsłymi :) ale nie znam sytuacji kiedy zastosowanie ich byłoby najlepszym wyborem :(

Owszem zabrania stosowania brył wklęsłych jako collidery dla rigidbody - zdrowy rozsądek. To bardzo jedzie po wydajności. Praktycznie zawsze można sobie poradzić bez brył wklęsłych. Kapsuły nie ma co aproksymować - ją się bardzo łatwo liczy. Box wymaga policzenia przecięć z płaszczyznami. Ten tutek z UDK gdzie koleś mówi na temat brył kolizyjnych, o ile dobrze pamiętam, należy do serii oficjalnych tutoriali UDK od 3DBuzza na temat Unreal PhAT. W tym video tutku koleś przyporządkowywał częściom ciała collidery i zamiast boxów stosował kapsuły (oprócz samych stóp).

Z fizyką sprawa jest dosyć skomplikowana. Mesh collider można zastosować do obiektów statycznych. Inne collidery są przeznaczone dla obiektów dynamicznych. Wyjątkowo można zastosować mesh collider do rigidbody, ale musi być bryłą wypukłą (convex). Lepiej, żeby elementy otoczenia składały się z różnych elementów - wtedy silnik gry nie musi wszystkiego ładować do pamięci na raz. W przypadku podstawowych primitivów silnik fizyczny posługuje się równaniem bryły, kiedy jest to mesh collider, to obliczane jest collide by poly. UDK i Unity3D stosują PhysX i też oglądając tutoriale do UDK dowiedziałem się, że sphere i capsule wymagają mniej obliczeń niż box.