Jedną z najważniejszych rzeczy przy tworzeniu takich gier jest danie graczom miejsca i możliwości ekspansji. Głównym (chociaż nie jedynym) źródłem tych rzeczy będą w tym przypadku układy planetarne. Moglibyśmy pójść po najmniejszej linii oporu i użyć jednego, zrobionego “ręcznie” układu i dawać graczom po prostu jego kopie, ale jako że astronomia jest moim konikiem postanowiłem rozwiązać to bardziej realistycznie.

Jak? Biorąc pod uwagę nasze ograniczone zasoby jedynym realnym rozwiązaniem są generatory losowe. Słowo “losowe” sprawia, że brzmi to dość łatwo, wystarczy kazać komputerowi losować cyferki, ale w rzeczywistości wcale takie, niestety, nie jest. Jak ktoś nie wierzy to polecam poczytać development blog (wstrzymanej ;/) gry Subversion firmy Introversion Software. Tam mamy do czynienia z losowym generatorem miast. Wydawałoby się, że wystarczy wrzucić do generatora jakieś budynki i wylosować parę liczb, ale żeby miasto wyglądało realistycznie trzeba uwzględnić całą masę czynników.

Tak samo ma się sprawa z układami planetarnymi, chociaż jest tu o tyle prościej, że astronomia po prostu jeszcze nie dysponuje danymi na temat jakiegoś zewnętrznego układu planetarnego, choćby w dziesięciu procentach tak dokładnymi jak o naszym Układzie Słonecznym. Urbanistyka ma dużo więcej statystyk na temat miast, no i trzeba mieć jakąś wiedzę z zakresu architektury itd. Czemu to ułatwia sprawę? Ano temu, że nie mając danych porównawczych między róznymi układami nie dysponujemy tak naprawdę definicją “realistycznego” układu planetarnego, możemy więc pozwolić sobie na generowanie układów, które będą pasowały do mechaniki gry, bez ryzyka narażenia się na przesadną niezgodność z danymi naukowymi. Nie oznacza to jednak wcale wolnej amerykanki, bo chciałbym zachować zgodność z tym, co jednak wiemy.

Najwięcej wiemy o naszym własnym układzie, więc najlepiej zacząć od tego. Układ Słoneczny ma w centrum swoją gwiazdę, czyli Słońce i wiemy, że jest to podstawa istnienia układu planetarnego. Wcale nie ze względu na światło, czy ciepło, tylko ze względu na grawitację. Planety muszą krążyć wokół masywnego obiektu. Chcąc więc wygenerować układ planetarny musimy zacząć od gwiazdy. Trzeba więc napisać osobny generator, który stworzy nam realistyczną gwiazdę.

O gwiazdach wiemy sporo i trzeba tą wiedzę uwzględnić, najlepiej z zastosowaniem jednej, prostej zasady losowego generowania realistycznych obiektów złożonych (sam to wymyśliłem, nawet nie googlajcie), która brzmi: “losuj jak najmniej”. A ściślej – “nie losuj rzeczy, które możesz wyznaczyć”. A dokładniej – “określ jak najmniejszą liczbę parametrów, z których będzie można wyznaczyć wszystkie pozostałe”. Krótko mówiąc im mniej rzeczy w losowym generatorze jest stricte losowych, tym większy realizm. Jeśli zabrnęliście już tak daleko w ten wpis, to w nagrodę możecie zrobić sobie przerwę i spróbować (jeśli Was to interesuje) wymyślić które parametry gwiazdy są tymi podstawowymi, z których można określić wszystkie pozostałe jej cechy, przynajmniej w zakresie potrzebnym grze. Podpowiem, że są dwa. Jeśli wymyśliliście, albo nie chciało wam się tego robić, to zapraszam do następnego akapitu.

Pierwszy z tych parametrów jest dość oczywisty. Jest to masa gwiazdy, która pozwala określić między innymi siłę jej oddziaływania grawitacyjnego. Sama masa jednak nie wystarczy, gdyż gwiazdy ewoluują. Z wiekiem ulegają przemianom tak samo jak ludzie. Masa nie pozwoli nam określić wieku gwiazdy. Drugim niezbędnym parametrem jest więc… aktualnie spalany przez nią pierwiastek. Jeśli zgadliście, to szacun ;]

Co to w ogóle znaczy “aktualnie spalany pierwiastek”? Z fizyki w szkole powinniście pamiętać, że zjawiskiem powodującym jasne (i ciepłe) świecenie gwiazd przez miliardy lat jest fuzja. Większość gwiazd na początku swojego istnienia składa się z wodoru, który jest najlżejszym i najczęściej występującym pierwiastkiem we wszechświecie. Siła grawitacji wytwarza w jej wnętrzu wielkie ciśnienie, które z kolei powoduje wzrost temperatury. Atomy wodoru przyspieszają do olbrzymich prędkości, co sprawia, że zwykle odpychające się cząstki zaczynają się zderzać. Zderzenie dwóch atomów wodoru przy takiej prędkości powoduje, że łączą się one w jeden atom helu, wyzwalając przy tym energię. Dużo energii. Gdy kończy się wodór, fuzja zabiera się za hel. Kolejność spalanych pierwiastków jest stała i kończy się na żelazie, które zamiast wyzwalać – pochłania energię i powoduje śmierć gwiazdy w ciągu kilku sekund. Dotyczy to jednak tylko największych gwiazd, zdolnych wybuchnąć jako supernowe. Najcięższy możliwy do spalenia przez daną gwiazdę pierwiastek wyznaczamy z jej masy, mając w kodzie generatora stałą określającą jaka masa jest potrzebna do spalenia danego pierwiastka.

Tak więc mając te dwa parametry możemy wyznaczyć wszystkie pozostałe, a przynajmniej wszystkie potrzebne grze. To jednak nie wszystko, czego potrzeba do wygenerowania tysięcy gwiazd. Potrzebujemy jeszcze odrobiny statystyk i rachunku prawdopodobieństwa. Gwiazdy typu słonecznego nie występują z tą samą częstotliwością co supernowe, gwiazdy neutronowe, czy inne. Nie losujemy jednak typu gwiazdy, trzeba więc uwzględnić te statystyki przy losowaniu masy i spalanego pierwiastka (w tej kolejności, bo potrzebujemy masy, żeby określić najcięższy możliwy do spalenia pierwiastek). Można w miarę bezpiecznie założyć, że najczęściej występują najmniejsze gwiazdy spalające najlżejsze pierwiastki. Tutaj nie musimy się stricte trzymać realiów (chociaż wypada częściowo je uwzględnić) i możemy sobie pozwolić na dostosowanie tych statystyk do potrzeb gry (układy planetarne z mniejszymi, bardziej stabilnymi gwiazdami łatwiej skolonizować).

Do tego wszystkiego wystarczy dołożyć kilka stałych pomagających przy obliczeniach, jak na przykład diagram Hertzsprunga-Russela, rozpisać wszystko matematycznie i zacząć generatora używać, dostosowując jego parametry aż jego działanie będzie zgodne z oczekiwaniami, co oznacza długie godziny prób i błędów.

W następnym odcinku: generator planet.

P.S. Jeśli macie jakieś pytania/uwagi, to zapraszam do komentowania.

Pomimo iż technologia WebGL jest stosunkowo młoda, już dostępna jest bogata baza frameworków. W zasadzie jest ich tak dużo, że na początku trudno któryś wybrać. W ostatnim czasie miałem okazję spróbować kilku z nich i podzielę się z  wami moimi spostrzeżeniami.

Ostrzegam, że pewne cechy bibliotek, o których piszę mogą się zmienić w czasie (np. uwagi dot. niepełnych dokumentacji). Dodatkowo oceniałem ich możliwości pod kątem swoich potrzeb, ktoś inny może mieć inne wrażenia.

SceneJS

Dynamicznie rozwijany Framework z API sceny opartym na formacie JSON. Projekt zapoczątkowany przez Lindsay Key, aktualnie rozwijany przez kilka osób.

Framework poprzez specyfikę swojego API oddala nas od niskopoziomowego WebGLa.

Zalety:

• Dobrze zaprojektowane API.
• Dobra dokumentacja z wieloma przykładami.
• Bardzo dobre wsparcie poprzez grupę google, szybkie rzeczowe odpowiedzi.
• Bogata otoczka: facebook, youtube, Wiki, Google group, github.
• Sporo przydatnych feature’ów (świetny picking).
• Wydajna, wygodna przy tworzeniu statycznych scen.

Wady:

• Bardziej skomplikowana przy tworzeniu dynamicznych scen (duże modyfikacje grafu sceny w czasie rzeczywistym są mało wygodne oraz niezbyt wydajne).
• Brak narzędzi przydatnych przy tworzeniu gier (kolizje itp.).
• Trudno zaadoptować dodatkowe narzędzia wspomagające np. fizykę.
• Abstrakcja oddalona od niskopoziomowego API WebGL’a nie każdemu może odpowiadać.

Podsumowując biblioteka nadaje się do tworzenia raczej statycznych scen, schematów oraz wizualizacji. Jednak przy programowaniu gier, gdzie potrzebujemy łatwej możliwości modyfikacji sceny, może okazać się nieco toporna.

X3DOM

Ciekawy Framework umożliwiający opisywanie scen za pomocą znaczników, przy czym poszczególne elementy sceny stają się fragmentami drzewa DOM i można manipulować nimi za pomocą JavaScriptu w podobny sposób jak typowymi elementami strony.

Zalety:

• Ciekawe, wygodne API.
• Prostota, nie potrzeba posiadać szczególnej wiedzy o grafice, ani o WebGL aby stworzyć ładnie wyglądającą scenę.
• Export do formatu .x3d dostępny natywnie w blenderze.

Wady:

• Brak dostępu do niskopoziomowego API.
• Kiepska z dokumentacja.
• Zdecydowanie nie nadaje się do dużych, dynamicznych scen.
• Ani do gier.

CopperLicht

Framework tworzony przez firmę Ambiera, twórców popularnej biblioteki IrrLicht.

Zalety:

• Framework dedykowany do tworzenia gier komputerowych.
• Dużo przydatnych narzędzi przy tworzeniu gier.
• Kontakt przez Forum.
• Dość przyzwoita dokumentacja, kilka tutoriali oraz dem.
• Zintegrowany z edytorem CupperCube, który służy do tworzenia scen oraz eksportu do formatu obsługiwanego przez CopperLicht.

Wady:

• Powolny rozwój. Nad kodem pracuje jedna osoba.
• Zamknięty kod. Pełne, czytelne źródło biblioteki jest płatne.
• Mało przykładów w sieci.
• Narzędzie CupperCube (które zdaniem niektórych jest największą zaletą biblioteki) płatne.

Three.js

Ciekawy Framework zainicjowany na potrzeby projektu RO.ME “Three Dreams of Black”. Stale rozwijany przez mrdoob i wielu innych.

Zalety:

• Dynamiczny rozwój. Obecnie pracuje przy nim ponad 50 programistów.
• Spore możliwości (narzędzia przydatne przy tworzeniu gier).
• Bogata baza przykładów.
• Wiele imponujących dem oraz przykładów działania w sieci.
• Zaczynają powstawać stronki z tutorialami, dokumentacjami… threejs.org learningthreejs.com aerotwist.com/lab/getting-started-with-three-js na pewno będzie ich coraz wiecej.
• Wszyscy polecają

Wady:

• Brak pełnej dokumentacji. Mamy ‘tylko’ bogatą bazę z przykładami.
• API nie jest zamrożone. Każdy update w głównej gałęzi projektu może spowodować, że coś przestanie działać w naszym projekcie.
• Hmmm… To chyba tyle

Nie opisałem wszystkich frameworków WebGL, ponieważ nie wszystkich miałem czas/okazję spróbować. Pominąłem m.in.: PhiloGL, SpiderGL, GLGE, EnergizeGL, WebGLU, C3DL, J3D. Aktualną listę frameworków znaleźć można na stronie www.khronos.org/webgl/wiki/User_Contributions#Frameworks

Podsumowując do tworzenia gier najlepiej przystosowane są biblioteki CopperLicht oraz ThreeJS. Z tych dwóch wybieram ThreeJS – jest w pełni otwarta i darmowa, jest bardzo dynamicznie rozwijana przez wielu programistów i już teraz zawiera dużo przydatnych narzędzi. Trochę gorzej wygląda tutaj kwestia dokumentacji, ale w zamian Three.js udostępnia wiele ciekawych przykładów.

Dodatkowo na 3dgames.pl możecie zauważyć kilka innych drobnych usprawnień wizualno-techniczno-użytkowych. Wszystkie propozycje dotyczące poprawek, nowości będą mile widziane, więc jeśli coś leży Wam na sercu – walcie śmiało

Zadanie jest ambitne, a środki ograniczone, ale wspólnymi siłami damy radę. Chcemy zrobić strategiczną grę przeglądarkową przy wykorzystaniu najnowszych technologii dostępnych w specyfikacji HTML5 (WebGL, websockets, itp.). Mamy w tej chwili przygotowany wstępny design, który będzie rozwijany w miarę możliwości.

Ja (The_Lord) zajmuję się stroną serwera. Aplikacja powstanie w Ruby on Rails, bo ten framework najlepiej znam i przy okazji ma najlepsze (i najwcześniejsze) wsparcie dla pojawiających się nowinek, takich jak na przykład baza danych MongoDB, z której również będziemy korzystać.

Synchronizacja stanu między graczami odbywać się będzie przy użyciu websockets zrobionym w Ruby, ale jeśli popularność przekroczy nasze wszelkie marzenia i będziemy potrzebowali większej wydajności tego systemu – przesiądziemy się na Erlanga. To tyle ode mnie, oddaję głos kolegom

Natomiast ja (RecRoot) kodze silnik gry po stronie klienta (fizyka, grafika). Aby się nie zakopać z pracą postanowiliśmy wykorzystać któryś z frameworków WebGL. O tym który wybraliśmy i dlaczego napisze niebawem w osobnej notce.

Stworzyliśmy już wstępny model interfejsu dla silnika oparty na JSON. Będzie on służył do komunikacji ze stroną serwera oraz do generatorów. Silnik umożliwia obecnie stworzenie prostego ukladu planetarnego (gwiazda, planety, księżyce) oraz jego podstawowe modyfikacje. Działa również LOD dla sfer (siatki pregenerowane proceduralnie).

Pracy jest sporo więc jesteśmy otwarci na współpracę Pozdrawiam!

Karlos Wita!

Do tej pory w projekcie galactic_storm wymodelowałem prosty, roboczy statek kosmiczny. Na pewno nie będzie to jedyny obiekt przeze mnie stworzony. Przede mną duzo pracy. Całe przedsięwzięcie jest dla mnie wielkim wyzwaniem któremu, mam nadzieję, podołam. Cieszę się, że ludzie z którymi współtworzę ten projekt są otwarci na moje sugestie. Ja zaś jestem otwarty na ich sugestie.

Uważam, że jako część zespołu chcę (i muszę:) poddać się wizji i w niej uczestniczyć. Dlatego ważne są dla mnie konstruktywna krytyka i rady

Pozdro dla wszystkich!

Wykonaliśmy testy i wszystko wydaje się działać ok. Gdyby jednak ktoś zauważył nieprawidłowe działanie któregoś z modułów – będziemy wdzięczni za przesłanie informacji na adres admin@3dgames.pl lub zamieszczenie jej w komentarzu.

onGameStart
Konferencja dotycząca tworzenia gier w HTML5. Prelekcje będą prowadzone przez doświadczonych programistów z całego świata. Termin wydarzenia 22-23 września. Miejsce – Warszawa! Cena biletu 79 euro. Najnowsze technologie, frameworki, przykłady gier. Na pewno warto wziąć w tym udział!

IV Zjazd Twórców Gier.
Tegoroczny cykl konferencji odbędzie się w dniach 8-11 Września w Łodzi. Koszt uczestnictwa wynosi symboliczne 25zł. Tematyka prelekcji jest bardzo szeroka i na pewno każdy znajdzie dla siebie coś interesującego. Dodatkowo może poznać wielu ciekawych ludzi z polskiej branży gier.

Jak widać zapowiada się gorrący wrzesień

Jako nowo przyjęty (wnioskuję po tym, że dostałem passy do bloga ) członek ekipy pozwolę sobie poinformować, że zaczyna się tworzyć nowy, ekscytujący (designerzy uwielbiają to słowo), otwarty (Bill nienawidzi tego słowa) projekt. W związku z tym poszukujemy ludzi posiadających doświadczenie w takich dziedzinach jak grafika 2D/3D, programowanie WebGL (Javascript), względnie muzyka (ambient/battle) + efekty dźwiękowe.

Teraz kilka słów o samym projekcie – jest większy niż te, które dotychczas widzieliście w wykonaniu 3dgames.pl. Naszym celem jest pokazanie, że WebGL to nie tylko zabawkowa technologia dla introwertyków z zespołem Aspergera, ale pełnoprawna technologia, która szybko się rozpowszechni (w końcu jest już stabilny Firefox 4) i będzie miała szansę konkurować z Flashem, czy Silverlightem, a nawet pokonać je na polu tworzenia interaktywnych aplikacji, a przede wszystkim – gier.

Chcemy stworzyć kosmicznego (na razie w sensie środowiska gry – skala przyjdzie później) rts-a, w stylu Homeworlda, Hegemonii, czy Master of Orion. Nie myślcie, o tym jednak tak, że celujemy za wysoko i projekt umrze jak wypali się nasz słomiany zapał – wychodząc na przeciw takim obawom postanowiliśmy zacząć od implementacji najbardziej podstawowych mechanizmów gry i jak najszybciej udostępnić grywalną alfę, aby gracze mogli jak najszybciej przekazywać nam swój feedback – i żebyśmy mogli lepiej wykorzystać nasze zasoby i skupiać się na poprawianiu/dodawaniu tych rzeczy, które gracze uznają za najbardziej potrzebne.

Myślę, że taki model się sprawdzi (w końcu Minecraft daje radę ) i w połączeniu z tym, że gra będzie darmowa – uda nam się stworzyć coś ciekawszego i większego niż to co widzieliście do tej pory, a więc pełnokrwistego rts-a z bogatym interfejsem, statystykami, badaniami naukowymi, a może nawet fabułą i dialogami… ale na razie o tym sza…

Podsumowując – jeśli jesteście zainteresowani współpracą i macie potrzebne umiejętności oraz czas i chęci – zapraszam do pisania na adres mailowy podany w dziale współpraca. Przypuszczalnie zostaniecie poddani jakiemuś teścikowi sprawdzającemu zdolności, którymi się pochwalicie, a potem – mam nadzieję – powitamy was w zespole i przydzielimy pierwsze zadanie.

Pozdrawiam ;]

P.S. Mamy też w planach uruchomienie listy mailingowej, przez którą osoby zainteresowane poinformujemy o postępach w projekcie. Dodatkowo osoby, które w ten sposób zadeklarują zainteresowanie zostaną w przyszłości wynagrodzone wcześniejszym dostępem do nowych funkcji lub innymi fajnymi rzeczami w grze, więc wypatrujcie dalszych newsów

Lekcja ta jest modyfikacją poprzedniej lekcji. Efekt końcowy na rysunku poniżej lub na żywo tutaj.

JSON (JavaScript Object Notation) jest czytelnym i intuicyjnym formatem, który ma swoje korzenie w JavaScript (więcej możecie doczytać na wikipedii). JavaScript posiada wbudowany obiekt globalny JSON, który potrafi parsować ten format. Poniżej mamy zawartość pliku „file_functions.js”

// Zwraca zawartosc pliku tekstowego
var getSourceSynch = function(url) {
    var req = new XMLHttpRequest();
    req.open("GET", url, false);
    req.send(null);
    return (req.status === 200) ? req.responseText : null;
};

// Zwraca obiekt zawarty w pliku .json
var loadJSON = function(url) {
    return JSON.parse(getSourceSynch(url));
};
		

Pierwsza z funkcji, używając obiektu XMLHttpRequest, czyta zawartość pliku synchronicznie (więcej tu XMLHttpRequest), natomiast druga (loadJSON) zamienia zawartość pliku w obiekt JavaScript. Rozdzieliliśmy te dwie funkcje, gdyż pierwszej z użyjemy dodatkowo do ładowania shaderów z osobnego pliku (po prostu skopiowaliśmy shadery z pliku html i zapisaliśmy je osobno do plików „shaders/vertex.shdr” oraz „shaders/fragment.shdr”). Modyfikacja funkcji getShader wygląda teraz tak:

function getShader(gl, type, path){
	var shader = gl.createShader(type);
	gl.shaderSource(shader, getSourceSynch(path));
	gl.compileShader(shader);

	if (!gl.getShaderParameter(shader, gl.COMPILE_STATUS)) {
		alert(gl.getShaderInfoLog(shader));
		return null;
	}

	return shader;
}

– przyjmuje ona parametry: kontekst graficzny, typ shadera (gl.VERTEX_SHADERS lub gl.FRAGMENT_SHADER) oraz ścieżka do pliku z shaderem. Jest wywoływana więc dwukrotnie w funkcji initShaders:

function initShaders(){
	var fragmentShader = getShader(gl, gl.FRAGMENT_SHADER, "shaders/fragment.shdr");
	var vertexShader = getShader(gl, gl.VERTEX_SHADER, "shaders/vertex.shdr");

	shaderProgram = gl.createProgram();
	gl.attachShader(shaderProgram, vertexShader);
	gl.attachShader(shaderProgram, fragmentShader);
	...

Mając plik json (eksportowanie z blendera omówione jest niżej) z danymi modelu (koordynatami wierzchołków, wektorami normalnymi, koordynatami tekstur oraz indeksami wierzchołków) ładujemy go teraz w następujący sposób:

function g_Init()
{
    var monkeyData = loadJSON("objects/monkey.json");
    Sphere.init("textures/monkey.png", 0, 0,
            monkeyData.vertices, monkeyData.texCoords, monkeyData.indices, monkeyData.normals);
}

Z racji, że WebGL czyta odwrotnie obrazki (do góry nogami), w funkcji ładującej teksturę włączymy specjalną opcję przywracającą „normalność”:

tempImage.onload = function()
{
	gl.bindTexture(gl.TEXTURE_2D, that.Texture);
	gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true);
	...

Uwaga! Przeglądarka chrome / chromium, z powodów bezpieczeństwa, ma domyślnie wyłączoną możliwość ładowania plików z lokalnego dysku. Oznacza to, że w czasie testów na lokalnym komputerze będzie zgłaszał błąd (gdy umieścimy naszą aplikację na serwerze wliczając w to lokalny serwer http, wszystko będzie działać). Aby wyłączyć tą funkcję na czas testowania, należy dodać jako parametr uruchamiania przeglądarki(we właściwościach skrótu) –allow-file-access-from-files

Eksportowanie z blendera

Oprócz opisanego tutaj eksportera, znalazłem w sieci jeszcze dwa inne:

• jslibs
• kompleksowy eksporter (eksportuje do glge, scenejs lub natywnego JavaScriptu (z tego ostatniej opcji można trywialnie stworzyć JSONa)) – jednak nieekonomicznie eksportuje indeksy

Aby użyć skrypu:

1. ściągnij go stąd i zapisz w folderze skryptów blendera (w windowsXP domyślnie: C:\Documents and Settings\USERNAME\Dane aplikacji\Blender Foundation\Blender\.blender\)
2. przeładuj skrypty w blenderze (Script Window -> Scripts/Update Menus) lub prościej zrestartuj blendera
3. zaznacz wierzchołki obiektu, który chcesz wyeksportować (jeśli masz tylko 1 obiekt wciśnij A)
4. (opcjonalnie) usuń zduplikowane trójkąty – mesh/vertices/remove doubles
5. unwrap (U) – wcześniej trzeba porozcinać szwami obiekt i oczywiście otworzyć okno UV (więcej tu: UV unwrapping) – powinno wyglądać mniej więcej tak:
6. wymuś trójkąty (WebGL nie potrafi rysować czworokątów GL_QUADS) CTRL-T
7. export UV z menu UV/Scripts/Save UV face layout (blender zapisze siatkę w formacie .tga, którą można otworzyć np w gimpie)
8. wyeksportuj do JSONa z menu file/export/JSON by gliniak (w obecnej wersji niech nie zmyli was domyślne rozszerzenie .blend – po prostu zastąpcie je przez .json)

W razie pytań lub zgłoszeń błedów, czy propozycji poprawek, piszcie na naszym forum w tym temacie

Exporting from blender (english translation)

Additionaly to the one described here, I found 2 others:

• jslibs
• complex exporter (it can export to GLGE, SceneJs or to nativ JavaScript object – but indices are exported in wasteful way

To use our exporter script:

1. download it from here and save it in blender’s scripts folder (in windowsXP default path is: C:\Documents and Settings\USERNAME\Application Data\Blender Foundation\Blender\.blender\)
2. reload scripts in blender (Script Window -> Scripts/Update Menus) or just restart blender
3. select all vertices of object you want to export (if you have only one object on the scene just press A)
4. (optional) delete deplicated vertices (blender likes to create them f.e. when using extrude function) via Mesh/vertices/remove doubles
5. unwrap UV texture – press U – you have to have opened UV window and mark certain edges (just read: UV unwrapping) – it should look more or less like that:
6. force triangles (WebGL can not draw GL_QUADS) CTRL-T
7. export UV net via UV/Scripts/Save UV face layout (blender will save it as .tga that you can open and edit with f.e. Gimp)
8. export to JSONa via File/export/JSON by gliniak (in the current version you have to / should change extension from (default) .blend to .json)
   

If you found some bugs, have questions or improvement advice just drop me e-mail biegunka(at)op(dot)pl or post in this thread

Gra została wystawiona do konkursu Mozilla Labs – Game ON więc możecie trzymać kciuki i jeśli wam się spodoba – oddać swój głos Lista wszystkich gier zgłoszonych do konkursu znajduje się w galerii gier konkursu Game On.

Aby zagrać wystarczy kliknąć w screen, natomiast poniżej znajduje się krótkie podsumowanie projektu oraz użytych technologii.

Projekt ten jest w zasadzie prototypem tak samo jak standard HTML5, którego użycie było głównym założeniem. Przekonaliśmy się na własnej skórze, że nie wszystkie technologie wchodzące w jego skład są w 100% gotowe.

Największe problemy napotkaliśmy podczas programowania dźwięku z użyciem API HTML5 audio. Odtwarzanie krótkich sampli w pętli daje niezbyt ciekawe efekty. Mimo różnych technik, których próbowaliśmy użyć efekt zawsze był nieczysty. Poza tym API audio nie pozwala kontrolować wszystkich parametrów dźwięku, co jest niezbędne jeśli chce się zasymulować np. realistyczne odgłosy silnika samochodowego. Ostatecznie zrezygnowaliśmy z efektów dźwiękowych oszczędzając graczom nieprzyjemnych odgłosów.

Najlepiej z wypróbowanych technologii wypadł WebGL i to nas bardzo cieszy. Choć kilkukrotne zmiany w API zmuszały do przepisywania kodu – generalnie udało się tutaj osiągnąć bardzo dużo. Największym problemem technologii WebGL wydaje się być w tej chwili wydajność. Musieliśmy więc wybierać spośród efektów graficznych, jakich chcieliśmy użyć. Ucierpiało na tym m.in. oświetlenie.

Podsumowując gra jest w pełni grywalna i jej ukończenie uważam za sukces. Mimo sporych problemów technicznych, jakie napotkaliśmy na swojej drodze przekonaliśmy się, że używając nowych otwartych technologii webowych można stworzyć dość ciekawą produkcję.

Jeśli znajdziecie błędy w aplikacji – będziemy wdzięczni za informację. Czekamy również na wasze opinie o grze „Vehicle Soccer”.

Odzywamy się rzadziej, ponieważ pracujemy ciężko nad sporym projektem, który dostępny będzie już niebawem oczywiście na 3dgames.pl. Wczesny prototyp powstającej gry zobaczyć możecie na screenach poniżej. Narazie nie powiem nic więcej, poza tym, że będzie to gra przeglądarkowa ;P

Osoby, które chciałyby pomóc przy testowaniu gry prosimy o kontakt pod adresem krzysztofk@3dgames.pl

Pozostańcie na linii!!!