PsichiX

Ghost, Threef: przestańcie pierdolić - oba nie nadają się na publiczne pokazanie, ale threefa tworowi jednak bliżej koncepcji celu. i matrix i te skałki jakieś takie z dupy. deal with it, ale póki nie będzie nic lepszego i bliższego kampanii, puty użyjemy threefa grafik :)

threef: a wystarczyliby dac cien pod napisami, zeby sie nie zlewalo z tlem i lekko przyciemnic to tlo

nieco przerobione instrukcje i przyklad z dwoma programami ze wszystkimi instrukcjami w uzyciu: http://dl.dropboxusercontent.com/u/9759049/intuicio_test.zip z tego jutro bede zaczynal kodowac AI pierwszego robota :)

nie jest wymagany zaden level. BTW. w dwa dni zrobilem kompilator i cala architekture maszyny wirtualnej (dziala na watkach i wspolbieznych subwatkach, wiec bedzie smigac). Na razie assembler i tylko 2 testowe instrukcje. Jutro dorobie reszte instrukcji (tj. operacje arytmetyczne wzorowane na tych z shaderow, bo to podstawa, z ktorej mozna dalej liczyc wszystko), oraz dodam interfejs sterujacy robotem. Pojutrze zas zrobie symulator w wersji do testow programow i podepne wirtualke pod symulator. na weekend powinna byc gotowa wersja testowa dla Was. Parser jezyka wyzszego poziomu (tj. funkcje, zamiast komend assemblera) planuje dodac w weekend :)

Threef zapodał mi fajny pomysł na chwilowe rozwiązanie multi: podpięcie GameJolt API do przechowywania programów użytkowników i dzięki temu będzie można sprawdzić w walce roboty przeciwników. Co za tym idzie, będzie można swoje programy robotów chronić dzięki wbudowanej w wirtualke funkcjonalności kompilacji do bytecode'u - nie będzie można oszukiwać dzięki temu, bo nie będzie miało się wglądu i edycji w kod źródłowy robota przeciwnika :)

MULTIPLAYER *.* tak, jak wypali w singlu, to chetnie dodam multi <3

tak. no to normalnei jak bys programowal wlasny komputer pokladowy - bedziesz mial konkretna ilosc pamieci RAM do wypelnienia danymi i mozesz z nia zrobic cokolwiek zechcesz. Jedyne ograniczenie to bedzie rozmiar pamieci RAM, instrukcje jakie mozna uzyc i tyle :)

każdy robot będzie miał swoją jakby pamięć ram i program startowy do setupu i aktualizujący robota co klatkę. a więc oprócz swoich zmiennych jakie zdefiniujesz w programie startowym, będziesz miał do dyspozycji zmienne hardware'owe, takie jak aktualizowana co klatkę tablica widzianych przez radar, sonar i dotyk obiektów (przed uruchomieniem programu aktualizującego) i w programie aktualizującym będzie można przelecieć te tablice i wyciągnąć z nich odpowiednie dane. programując robota będziecie czuć się jak byście programowali prawdziwego robota. w sumie ten symulator może okazać się bardzo fajnym przygotowaniem do robotyki :)

git, zmysł "dotyku" będzie w standardzie w takim razie :)

dobra, faktycznie wzrok lepiej zrobic na zasadzie sonografu kierunkowego, a radar ograniczony do kilku metrow wokol bota.

Że jak? Objaśnij, albo rzuć refką ze strony YYG.

exigo dobrze gada!

dostaniesz interfejs do kol pojazdu, nadajac kazdemu z nich odpowiadnia sile obrotu, bedziesz mogl zrobic wszystko z poruszaniem pojazdu, nawet to, co podales.

małe info: z racji, że robie to w GMS, a tam nie działa odpalanie GML z plików, to symulator będzie wykorzystywał swój własny mały język skryptowy (może uda mi się podpiąć wirtualke to będzie szybszy) do interpretacji obliczeń matematycznych i wykonywania procedur do interfejsów robotów :) czyli jak dobrze pójdzie, to cudem skończe dziś, a jak nie to przeciągnie się to do paru dni.

huder: nie zajmie to masy czasu, zakladam, ze pare godzin do jednej nocy. w koncu to user bedzie budowal program kontrolujacy robota, ja buduje tylko jego szkielet i reakcje na swiat. amateratsu: tak, bedzie walka druzynowa, grunt zebys umial zaprogramowac robota tak, by nie atakowal swoich :) siadam do roboty! bedzie to swietna i rozwijajaca przerwa od robienia maszyny wirtualnej :D

mają to być i zachowywać się jak prawdziwe boty, stąd opis jak działać będą konkretne interfejsy: * interfejs sterowania: napęd na cztery koła osobno (każdemu z kół możemy ustawić prędkość dodatnią i ujemną), jak i funkcje upraszczające w stylu: jazda w konkretnym kierunku w przód i w tył, zmiana kierunku. * interfejs analizowanie przestrzeni: możliwe będzie zeskanowanie obiektów (inne boty, porzeszkody) w określonym zasięgu od bota (radar) i uzyskać ich listę, oraz upraszczające funkcje w stylu: sprawdź co stoi na drodze w konkretnym kierunku. * interfejs broni: ustaw działko w danym kierunku, wystrzel pocisk. to jest lista wszystkiego, czego potrzeba aby robot był w pełni autonomiczny i nie mógł robić wszystkiego (sandbox ograniczony do wymaganych funkcji).

wrócę z pracy, to zrobię symulator, boty będzie się opisywało skryptami GML w pliku tekstowym i wrzucało do odpowiedniego folderu, symulator załaduje i zbuduje boty, podepnie im skrypty GML i przeprowadzi symulacje. dostępne będzie wyłącznie używanie wystawionych przez symulator interfejsów sterowania, analizowania przestrzeni i broni identycznej dla każdego. Ocenicie, czy to odpowiada wymaganiom.

znaczy zrobić arene i coś, co będzie czytało skrypty botów, tworzyło je na scenie i wykonywało ich AI?

no ja to zrobiłem, w jednym starym przykładzie na główną GMClanu chyba nawet, sprawdze czy na pewno. Jest: https://gmclan.org/index.php?plik=175

yup, szyfrowanie pliku, czy wartoscijest jedyna opcja. Gnysek robil artykul na glownej o szyfrowaniu XORem, ale sa tez bardziej zaawansowane metody szyfrowania, zas XOR powinien wystarczyc na ochrone przed swiezakami.

o tym właśnie gnysku mówiłem - to są wbudowane w GMa macierze :) robie akurat w swobodnym czasie małą gierkę z użyciem animacji szkieletowej na tym, to mogę później zrobić z tego example na GMClan.

Za wczasu mowie: nie kloce sie, ani nie czepiam, ot poprawiam lub doinformowuje :P Spoko, to da sie osiagnac w GM < GM:S. mierzenie wydajnosci FPSami jest niewlasciwe - do tego stosuje sie Delta Time (roznica czasu, zwykle milisekund miedzy dwoma ramkami rysowania). Niewlasciwe z tego powodu, ze FPS nie jest liniowe tak jak Delta Time: roznica czasu miedzy 5-10 fps nie jest identyczna jak 55-60. wiedze optymalizacyjna wynioslem z bawienia sie w robienie crysisow i pisania gier na mobile i tam takie techniki sa bardzo potrzebne, bo to tworca gry ma za zadanie dostosoac sie do mozliwosci sprzetowych swoich odbiorcow, a nie odbiorcy do wymagan sprzetowych tworcy gry. zgadza sie i nie zgadza. animacja szkieletowa jest karkolomna do zrobienia jesli robi sie wszystko z kodu i od zera - dlatego zawsze przy pisaniu o szkieletach, pisalem rowniez o koniecznosci uzycia edytora i jakiegos API do gry. o ile jest to maly projekcik, to tak. jesli zas zaczynamy duzy, ogromny projekt, to warto zainwestowac wiecej czasu, aby dzialalo to na prawde kazdemu, bo w koncu o to tworcom chodzi, by kazdy mial szanse zagrac.

Propa, ja Cie bardzo, ale to bardzo lubie i ogromnie szanuje, ale pozwol, ze wytlumacze Ci dlaczego paplesz jak potluczony: wyzej opisane rzeczy to przyklad jak NIE robic animacji szkieletowej. Notabene, jest to bardzo amatorskie podejscie do problemu, tzw. na odwal. Dokladniej: bo nie robi sie tego na lengthdirach, a macierzach, ktore kosztuja znacznie mniej, i znacznie latwiej jest sie nimi poslugiwac niz lengthdirami. Grafiki animacji trzyma sie na jednej teksturze. w GM:S masz z automatu grupowanie sprajtow na jedna teksture, po to z reszta dodali ten ficzur, aby nie zmieniac sprajtow (fizycznie tekstur), tylko operowac na jednej tej samej, mimo ze rysujesz jej inne fragmenty. na jednym duzym spricie ze zmiana klatek animacji, czyli zmiana tekstur (bardzo, bardzo zle dla grafiki). Jesli robisz to dobrze, jak opisalem wyzej, to pamieciozernosc zdecydowanie mniejsza (GM nadal trzyma cale grafiki w RAMie, zanim wysle je do GPU, czyli zostaja w pamieci == sraja nam rozmiar apki w pamieci), a prockozernosc nie istnieje, bo kalkulacje sa stale (wykonujesz iles tam operacji na macierzach, nie robisz masy cudacznych sinusow/cosinusow i dodawan). zas tu sie czesciowo zgodze: Czesciowo, bo koniec koncow ilosc (a raczej ich powierzchnia zajmowana w pamieci) sprajtow wyjdzie zdecydowanie mniej, niz przy duzych animacjach. Na ten problem nie ma idealnego rozwiazania niestety.

Nie, nie jest bardziej optymalne. Rysowanie dużego czworokąta z masą pustych pixeli przegrywa z rysowaniem masy mniejszych czworokątów (za jednym zamachem) z minimalną ilością pustych pixeli. Na dodatek w GM < GM:S tekstury są osobno, więc i zmiany klatek animacji kosztują dodatkowo dużo. Wszystko przez to, że aby uzyskać przezroczystość, trzeba włączyć blending, a blending jest jedną z najkosztowniejszych operacji rysowania. Deal with it everyone :P Dlatego też robiąc animacje szkieletowe, odcina się także w edytorze elementy przezroczyste od solidnych, aby obie wersje narysować jedna po drugiej z blendingiem i bez, aby przyspieszyć rysowanie. Robiliśmy tak w A-man.

dlatego do animacji szkieletowej uzywa sie edytora, a nie klepie calosc z kodu