Okno główne Unity3D

1. Wygodny w użyciu edytor na który składa się:
   • Zakładka „Scene” – panel widoku sceny, w niej przemieszczamy obiekty, obracamy, skalujemy, „latamy” po scenie, ustawiamy kamery, światło, i co tam jeszcze potrzeba.
   • Zakładka „Game” – panel widoku gry, jeśli testujemy grę to „gramy” w tej zakładce
   • Zakładka „Project” – panel widoku projektu – czyli po ludzku tutaj widzimy hierarchię plików i katalogów wchodzących w skład projektu.
   • Zakładka „Hierarchy” – panel widoku hierarchii obiektów na scenie.
   • Zakładka „Inspector” – inspektor obiektów, tutaj ustawiamy „z palca” właściwości obiektów na scenie, pozycję, rotację, skalę, parametry skryptów, parametry fizyczne, renderingu, itp.
   • Zakładka „Console” – konsola projektu, widzimy wszystkie informacje które wyrzucamy do log’a (messages), a także ostrzeżenia (warnings) oraz błędy (errors).
2. Bogata pomoc
   • Unity Manual – manual do silnika, z dokladnym opisem każdego okna, opisanym sposobie poruszania się po edytorze, skróty klawiszowe, itp
   • Reference Manual – manual poszczególnych części edytora – do audio, fizyki, renderingu, itp
   • Scripting reference – opis wszystkich klas i funkcji Unity3D, do których możemy się odwoływać z poziomu skryptów. Większość funkcji oraz klas jest wsparta prostymi przykładami wykorzystania w trzech językach, JavaScript, C# oraz Boo
3. Klarowny podział na obiekty i komponenty (oraz skrypty)
   • Obiekty („GameObjects”) – Obiekt to bazowy obiekt (masło maślane) który ma transformacje (czyli pozycja, obrót, skala), nazwę, dzieci (childs), oraz może mieć rodzica (parent). Może to być pusty obiekt (w sensie nie ma żadnej reprezentacji na ekranie ani w fizyce, ani w audio, ani w niczym, poprostu nicość , może to być prostopadłościan, powierzchnia, światło, kamera, albo cały działający oskryptowany samochód
   • Komponenty („Components”) – Komponenty wchodzą w skład obiektów. Na komponentach opiera się praktycznie cała filozofia działania Unity. Komponenty przeważnie maja parametry. Wyobraźmy sobie wyrenderowaną na ekranie kulę. W filozofii Unity taki obiekt wygląda następująco: jest to obiekt GameObject (pusty), który zawiera komponent MeshFilter (odpowiedzialny za przetrzymywanie i obsługę geometrii, jako parametr ma ustawiony siatkę kuli), następnie obiekt ten zawiera komponent MeshRenderer (odpowiedzialny jest za renderowanie geometrii, którą pobiera z MeshFilter, jako parametr może mieć ustawiony materiał renderowania). Dodatkowo może zawierać komponent Rigidbody (więc zostanie mu przypisane ciało fizyczne z masą, gęstością, itp, na które będziemy mogli oddziałowywać siłą), oraz może zawierać SphereCollider (czyli fizyczny mesh kolizyjny w kształcie kuli, dzięki czemu nasza kula może się toczyć). Komponentem może być także skrypt.
   • Komponent Skrypt – najważniejszy element dla programisty, czyli komponent skryptowy. I tutaj tkwi siła Unity wg mnie. Piszemy jeden skrypt i możemy go „podpiąć” do każdego obiektu. Na dodatek możemy podpiąć kilka różnych skryptów pod jeden obiekt. A skrypty możemy pisać aż w 3 różnych językach: w JavaScript, C# oraz Boo. Wszystkei skrypty są kompilowane w locie, więc na bierząco widzimy czy nie popełniliśmy błędu. Dodatkowo nawet jak popełniliśmy karygodny błąd (NullPointer Exception) nie powoduje to zamknięcia Unity, tylko włączenie pauzy, i możemy na konsoli zobaczyć co się złego stało.
4. Elastyczność
   • Można łatwo rozbudować funkcjonalność edytora o pluginy lub skrypty
   • Można łatwo przenosić elementy między projektami poprzez eksportowanie/importowanie paczek assetów (packages)
   • Prefabrykowane elementy – specjalny typ obiektów. Jeśli zbudujemy scenę z 10 takich samych prefabrykantów a następnie zmienimy parametry jednego z nich, to automatycznie (jeśli tego chcemy) nowe parametry zostaną uaktualnione w pozostałych elementach tego samego typu. Przyspiesza to błyskawicznie prototypowanie oraz składanie leveli.
   • Unity ma wbudowaną bazę shaderów, ale jeśli chcemy możemy ją rozbudować pisząc swoje, własne.

Te kilka rzeczy spowodowały tak szybkie przeniesienie BoberTheBeaver z FemtoEngine do Unity3d, gdyż:
- napisałem skrypt, który importował modele z Bober’a do Unity i tworzył z nich prefabrykanty,
- napisałem skrypt, który importował levele z Bobera do Unity, automatycznie wstawiając na level odpowiednie prefabrykanty w odpowiednich miejscach i skali,
- napisałem kilka skryptów obsługi postaci
- napisałem kilka skryptów obsługi menu, dźwięków, animacji poklatkowych
- uruchomiłem wszystkie skrypty po kolei i gra była przeniesiona, następny etap to było już tylko tweakowanie i poprawianie błędów. Unity ma jeszcze jedną zaletę, a mianowicie można wygenerować projekt, który działa zarówno na PC’tach, komputerach Mac, oraz na stronie www (po zainstalowaniu pluginu).

Uff, to by było tyle wstępu dotyczącego zalet Unity3D. Co będzie w następnym odcinku ? Jeszcze nie wiem, ale na pewno coś ciekawego.

• ilość plików w paczce
• nazwę pliku
• offset pliku względem początku
• długość pliku

Wypakowanie wszystkich plików z paczki było pryszczem, ale okazało się, że są one zaszyfrowane, lecz za pomocą bardzo prostego klucza. Na klucz wpadłem analizując nazwy plików, założyłem, że pliki graficzne są plikami DDS, dźwiękowe WAV lub OGG. Szukając powtarzających się wzorców odkryłem klucz: każdy bajt został rozbity na dwa półbajty (starsza i młodsza część. Z takiego podziału otrzymujemy 4 bity (wartości od 0-15). Każdej wartości przyporządkowana została nowa wartość z tego samego przedziału (czyli szyfr Cezara). Raz dwa powstał programik, który wypakowywuje wszystkie pliki z paków, oraz je poprawnie dekoduje. Dwie małe próbki:

I kod źródłowy jakby ktoś chciał zobaczyć całą resztę:

 
#include <stdio.h>
#include <stdlib.h>
#include <vector>
 
struct SFile
{
	int filenameLen;
	char fileName[256];
	int offset;
	int fileLen;
};
 
char cryptoTab[]=
{
	0x0C,
	0x0D,
	0x0E,
	0x0F,
 
	0x08,
	0x09,
	0x0A,
	0x0B,
 
	0x04,
	0x05,
	0x06,
	0x07,
 
	0x00,
	0x01,
	0x02,
	0x03,
};
 
 
 
void CryptoBuff( char *buff, int bufLen )
{
 
	for(int a=0; a<bufLen; a++)
	{
		char msb=(buff[a] & 0xF0)>>4;
		char lsb=(buff[a] & 0x0F);
 
		buff[a]=(cryptoTab[msb]<<4) | cryptoTab[lsb];
 
 
	}
}
 
void DepackFile( const char *fileName )
{
	FILE *f=fopen(fileName,"rb");
 
	if(!f)
		return;
 
 
	char temp[4];
	fread( temp, 1, 4, f);
 
	int filesCount=0;
	fread( &filesCount, sizeof(int), 1, f);
 
	std::vector<SFile> files;
 
	for(int a=0; a<filesCount; a++)
	{
		SFile file;
		fread( &file.filenameLen, sizeof(int), 1, f);
		fread( file.fileName, sizeof(char), file.filenameLen, f);
		file.fileName[file.filenameLen]=0;
 
		fread( &file.offset, sizeof(int), 1, f);
		fread( &file.fileLen, sizeof(int), 1, f);
 
		files.push_back(file);
	}
 
	int startOffset=ftell( f );
 
	for(int a=0; a<files.size(); a++)
	{
		fseek( f, files[a].offset+startOffset, SEEK_SET );
 
		for(int n=0; n<strlen(files[a].fileName); n++)
			if(files[a].fileName[n]=='/')
				files[a].fileName[n]='.';
 
		printf("\nProcess file: %s ", files[a].fileName );
		FILE *nf=fopen( files[a].fileName, "wb" );
		char *tempBuff=new char[files[a].fileLen];
		fread( tempBuff, 1, files[a].fileLen, f );
 
		CryptoBuff( tempBuff, files[a].fileLen );
 
		fwrite( tempBuff, 1, files[a].fileLen, nf);
		fclose(nf);
	}
 
	fclose(f);
}
 
int main(int argc, char *argv[])
{
	for(int a=1; a<argc; a++)
		DepackFile( argv[a] );
 
 
 
	printf("\n");
	system("PAUSE");
 
	return 0;
}

W wirze pracy postał także system do robienia cutscenek, albo sekwencji zdarzeń w grze. Dzięki temu narzedziu możemy zmieniać położenie obiektów w czasie, zmieniać ich obrót w czasie, oraz uruchamiać specjalne funkcje obiektów. Wszystko edytuje się prosto i przyjemnie korzystając ze specjalnego okienka na którym mamy oś czasu i nanosimy klucze odpowiedzialne za dany typ zdarzenia. Opis na pewno jest bardzo enigmatyczny, ale niżej wszystko się wyjaśni. System ten jest systemem niezależnym , czyli może działać jako narzędzie do uruchamiania jakiś sekwencji lub funkcji w czasie, lub poprzez przejrzysty interfejs może być sprzęrzony z jakimś gotowym „gameplay framework”. Dzięki temu znów nie trzeba być programistą aby zaprogramować jak potworki wybiegają zza rogu, chowają się za przeszkodami i do nas strzelają, albo aby wykonać przerywnik filmowy w grze (tzw „cut scene”). Aktualnie wykorzystuje trochę system taglines, oraz także współpracuje z silnikiem Unigine i specjalnie przygotowanym przeze mnie n-tą generacją bazą skryptów do tego silnika. Aktualnie baza skryptów jest ciągle rozwijana poprzez zespół programistów, aby był jeszcze lepszy Podobnie jak system Taglines system cutscen może być bez problemu sprzężony z innym językiem skryptowym (np moja ulubiona chyba LUA )
Koniec bełkotu, czas na filmy

FemtoEngine

Prace nad silniczkiem idą jak przysłowiowa krew z nosa. Manager plików i katalogów został nieco rozbudowany, i jest juz prawie przygotowany do działania . Dodatkowo postanowiłem w koncu napisać renderer od początku (stary bazował jeszce na funkcjach z OpenGL 1.2). Oczywiście zostaję przy OGL’u bo dx’a trochę nie lubię, lecz nie zmienia to faktu że muszę nauczyć się kolejnych nowych rzeczy (pisanie shaderków). Spowoduje to na pewno opóźnienia w ukończeniu pierwszej produkcji, ale na szczęście ta produkcja jest grą 2D, więc shadery tez nie będa „Crysisowe” lecz maksymalnie proste. Przez czas od ostatniego wpisu do teraz edytor ma już opcję wstawiania nowych elementów do levelu, oraz możliwość ich przesuwania. Jeszcze by się przydała możliwość ich kasowania, grupowania itp, ale nie wszysto na raz. Hmm, tak w sumie piszę o produkcji i grze ale nie napisałem jeszcze co to będzie dokładnie. A będzie to STRIKE