3r3se7ven

A nie lezą aby w oczy? Aby wszystko z nimi w porządku?

Kaptur, barki, ręce, dłonie?

To nie xboxowy, to taki normalny wykryty jako joystick. Tego xboxowego też nie mam.

A dziękuję, tydzień to dłubałem, bo to wyżej na trójkątach/mesh było za ciężkie. Teraz dodaję wąsy (dodatkowe punkty detekcji przestrzeni wokół postaci, żeby wiedziała kiedy kucać, kiedy czołgać, kiedy się wspinać). Będzie ze dwa tygodnie przerwy bo muszę wyjechać.

Zrobiłem tak: http://www.filedropper.com/3djoystickrunner Chodzi to pod pada wykrytego jako joystick. Teren jest z cubów, bo macierze obrotu ze skryptów robią wielką kupę w tle i dziesięciokrotny spadek wydajności, jak tego nie ma w bibliotekach to jest masakra, o kolizji siatek w ogóle można zapomnieć. Oczywiście w pro zastosowaniach ktoś by to wkleił i szło by z gotowców szybko :) Fizyka jest inkrementalna (mariowa) zamiast kwadratowej (rzeczywista). Ruch postaci, czas reakcji, prędkość, wysokość, zależą od jej masy i zebranych sił (tension na ekranie). Na razie można się obracać, chodzić, szybko obracać, strejfować w prawy i lewy tył, skakać z marszu i biegu. Postać zmienia kierunek tylko jeśli ma kontakt z podłożem (podstawka postaci) na końcu kroku (w połowie nie zmieni, noga musi być na glebie). Rozpędza się, zwalnia, jak zebrał siły to rozpoczyna ruch żwawo, im szybciej biegnie tym dłuższe i wolniejsze kroki robi. Jak spadnie z planszy to nie wróci, trzeba ESC- Reset. Do wysokości dopasowuje się automatycznie, ale będę mu dłubał wspinanie, wbieganie etc. Oczywiście te cone ludzika można podmienić na modele, tylko trzeba mieć czas zająć się wszystkim. Całość przetwarzania bazodanowa.

450 tys aktów prawnych to rzeczywistość samowykonalna? Czy raczej zestaw bugów pod exploity?

Kto płaci podatki sam winien własnej stracie.

Czyli taki magiczny kamień, który przechowuje właściwość, iż na kierunku jakiejś osi nie ma sąsiada :) No to ktoś musi tę informację zebrać, albo ten kamień, albo ten wróg... Albo trzeba zrobić specjalny kamień na koniec platformy, który zastąpi wszystkie kamienie na końcach platformy po przemieleniu całego levelu ^^ Ja bym jednak zajętość terenu próbkował wrogiem.

Aby wróg "widział" musisz zrobić próbkowanie terenu wkoło wroga. Tworzysz ds_grid, albo ds_list, i pakujesz tam wartości testu zajętości terenu wkoło wroga, im bardziej zajęty teren tym wyższa wartość. Następnie dodajesz heurystyczną odległość do celu/gracza do tych wartości, z danych pól testu. Obracasz wroga w kierunku najniższej uzyskanej wartości i do przodu. To taki najprostszy greed algorithm. Zatnie się na pewnych zawiniętych ścianach - pułapkach na chciwca, ale to się rozwinie później.

Za moich czasów telefon był wielkości plecaka, a nerdy handlowały płytami, a najszybsze nagrywarki miały speed x6 :D

Postaw wkoło krawędzi ścianę?

Pisać możesz, tylko kompilacja ma pewne wymagania odnośnie architektury procesora i adresowania pamięci. Używanie do tego telefonu jest po prostu niecelowe jak wkręcanie śrubek piłą.

Myślę że markerem albo korektorem można coś na telefonie napisać. A jak sobie wyobrażasz kompilator na telefonie?

Teraz tak... Wyciągasz wszystkie takie kwiatki jak if distance_to_object(obj_player)<90 i.speed = 10 Dopisujesz komentarz dla potomnych co to robi i po co tu jest. Zamieniasz 90 na zmienną "dystans_reakcji", "prędkość lasera" i wyciągasz tę zmienną w paczkę zdefiniowanych zmiennych sterujących zachowaniem wroga. z takich kwiatków: with instance_create(x,y,obj_entity_die) Wyciągasz "obj_entity_die" i używasz poleceń asset i predefiniujesz w paczce jaki asset. Tak żeby jak już uznasz że kod działa to zmieniać zmienne, a nie dłubać w kodzie. A z makaronem tak jest że czasem się zdarza, i wtedy trzeba coś z nim zrobić, najlepiej pociąć.

Ten papierek z promilami to nie był mandat?

Przede wszystkim tatuś był szycha a pozycję społeczna się dziedziczy niezależnie od ustroju. Dlatego w 360 milionowym narodzie po Bushu za jakiś czas rządzi mały Bush, tak jakby tam nie było kogo innego do wylosowania ^^

Oddziel obrót wroga jako virtual state i jego rysowanie jako drawing state. Jedna część jest istotna dla "fizyki" gry, druga dla wyświetlenia rezultatu. Jak to rozdzielisz to będzie Ci łatwiej przeprowadzić obliczenia po "fizycznej" kolizji i na ich podstawie dokonać korekt przed decyzją o rysowaniu. Czyli ustalisz pełny, niezgliczowany stan wroga, przeniesiesz go do stanu obliczenia grafiki wroga na tej bazie i dopiero dojdzie to to draw już poustawiane. Na razie upchnąłeś w jednej sekwencji ruch i zmianę grafiki, na początku to dobre, ale na dłuższą metę jak za tydzień wymyślisz inne, lepsze sposoby, to okaże się, że masz strukturę każdego elementu w grze inną i nie możesz wymienić jednego z elementów korekty stanu bez rozpruwania kodu obiektu. Po prostu oszczędzisz sobie zgrzytania zębami na później :)

Zamierzasz napisać dla wroga tłustsze ai niż w total war? Bo póki tego nei zrobisz to nie będzie mulić :)

A po lepszej szkole lepsza uczelnia, a po lepszej uczelni lepszy pośredniak, a po pośredniaku lepszy zmywak albo zającowanie na taśmie. Aleksander podbił największe ówcześnie imperium na planecie mając 17 lat. Ty szukając pracy w wieku 27 dowiesz się że brak Ci doświadczenia :) Więc się tak bardzo nie spinaj na wyniki, one są dla picu.

Bardzo słuszna koncepcja. U mnie z ds_list_of_all_list jest wyliczany fokus na które z list rzucić okiem i pobrać dane. Lista jest bardzo praktyczna, jeśli opisuje wyjątki w mapie. Przy dużych przestrzeniach można fraktalnie generować na bieżącą podłoże, las, a dopiero ważące rzeczy jak murki, domki, wrogów budzić z listy. Typowym zachowaniem na początku jest Niutonoza, opisanie całego świata absolutnie na raz, w całości dostępnego i w całości działającego w każdym czasie. Potem się człowiek robi wybredny i aktywuje części z ds grid i robi pierwsze patchfindery po krokach, ale przeskok z A* na JPS i wyższe sposoby organizowania dużych map wymagają bardzo minimalistycznego opisu bogatego świata.

A czemu nie dodawać? Nie ma co sobie żałować drzewa zachowań i podstępności u wroga. Po prostu podziel to na sekcje odpowiedzialne za stan, za interakcję, za grafikę i za decyzje W step event masz możliwość dodania wielu kartek z kodem, można porozdzielać je żółtymi wykrzyknikami z opisami :)

No to właśnie mnie boli., że jak mam sobie biblioteki robić i uruchamiać, to na co mi gms :) Macierz kamery można załadować, ale to są dane do mnożenia world matrix. Kaszan straszny. Zrobiłem to na mnożeniu xrotationM * yrotationM * ... translationxyzM tyle że... Pivot tyłka przez pivot postaci, pivot korpusu przez pivot tyłka pivot postaci, pivot barku przez... pivot ręki czy miecza to brazylijska telenowela o trygonometrii :)

Siekanka na całego. Na razie jeszcze można z tego coś wyrozumieć, a jak dodasz obsługę jeszcze 50 zachowań wroga? Zacznij już porządki w kodzie, oddzielnie STOMwroga, oddzielnie STOM wyświetlania wroga, oddzielnie obsługę zmiany stanu wroga względem wejść ze środowiska.

To tak zrobiłem, tylko że jest to ciężkie, jedzie po trygonometrii i zamula bo GMs nie bardzo nadaje się na matlab :) Generalnie to co robią macierze na d3d zdublowane w kodzie zamienia wyświetlanie w kolekcję pocztówek. A ten wynik tam jest w d3d, trzeba go tylko wyciągnąć z matrycy którą sobie d3d buduje zanim go przemnoży przez matrycę kamery.

Ponieważ w gridzie nie możesz przesunąć zawinięcia :) A niekoniecznie sqrt z liczby elementów musi mieć wartość całkowitą. A jeśli chcesz opisać przestrzeń nieciągłą cz nieeuklidesową to będziesz czesał zera z grida, bo część jego elementów będzie musiała coś zawierać mimo ich nieważkości w procesie.