witam
Od czego zaczac pisanie gier w javascript?
Probowalem troche pisac bardzo porste gry typu kolko i krzyzyk, zbijanie kulek itp. Chcialbym zabrac sie za tworzenike bardziej interaktywnych gier 2d typu mario - to jest moj aktualny cel.

Pare moich pytan/watpliwosci, ktore aktualnie mnie trapia:
1. Czy niezbedne jest poznanie canvas, czy moze divy+css3 wystarczy?
2. Co sadzicie o takim podejsciu, zeby elementy ktorymi trzeba sie przemieszczac bylyby oparte na wlasciwosci position w css przy zastosowaniu zdarzen onkey... oraz v++ i v--? Czy sa jakies lepsze metody?
3. Jak wyglada sprawa z kolizjami ograniczajacymi przestrzen poruszajacego sie elementu - czy przy stosowaniu css position plus jakis sztuczek w js jest to mozliwe?
4. Wiem ze sa framewarki specjalnie dla gier - ale czy na poczatek sa one konieczne, czy moze lepiej ile sie da poczatkowo ogarnac samym js'em?
5. Jak wyglada sprawa z umiejetnosciami pisania kodu js obiektowo? Czy nalezy zglebic ta tematyke czy same funkcje, DOM wystarcza?

http://www.youtube.com/user/GoogleTechTalk...uery=html5+game

nawet nie próbuj pisania gry za pomocą manipulacji dom bo zajedziesz komuś przeglądarkę - od tego służy canvas!

Skąd wiesz co jak i gdzie jest zoptymalizowane?

Herezje. Jak na ironię operacje na DOM są szybsze niż bliźniacze wykonywane na canvas.
Oczywiście canvas to przyszłość, jednak do czasu aż nie uzyska on wydajności przewyższającej flash, jest jego marną alternatywą.



To zależy. Biorąc na przykład wspomniane mario... całość na luzie możesz zrobić w div/css, canvas na obecnej fazie rozwoju (a raczej wydajności) nadaje się jedynie do efektów specjalnych jak ogień, woda, wirujace monety.


co to jest v++ i v-- ? Podejście dobre, lecz musisz dobrze to przemyśleć... napisz pierw edytor map, w nim zapewne musi być odpowiedni "grid", poruszanie po załadowaniu mapy zrobiłbym też na gridzie przy odpowiednim sprawdzaniu czy można + animacja.


Jeśli masz grid, tworzysz dodatkowe informacje o przestrzeni poruszania, to może być zwykła tablica w ktorej umieszczasz elementy zablokowane i przy poruszaniu, sprawdzaj czy aktualnie mozesz na niego wejść. To będzie dość prosty system kolizji, chyba że masz potrzebę jego wyliczania czy div A znajduje się w zasięgu div B.


Nie ma FW uniwersalnych i prawdopowodnie nigdy nie będzie do budowy gier przeglądarkowych. Chyba że ktoś kiedyś napisze uniwersalne API do budowy coś jak we flash.


To też zależy od podejścia i tego co chcesz z tym kodem robić w przyszłości. Przy pisaniu silnika gry, trzymałem się jQuery, a tam jest to wyjaśnione i praktycznie całość opiera się o wtyczki.

Poszukaj też forum, ponieważ było wiele tematów odnośnie tworzenia gier, szczególnie w dziale HP.

herezje? http://forrst.com/posts/Canvas_VS_HTML_FPS_Benchmark-J9a

Dzieki za odpowiedzi, jeszcze wszystkiego nie przegladnalem co podaliscie.


Chodzi mi czy takie podejscie jak ponizej w chodzi w gre jesli chodzi o przemieszczanie elementu czy to inaczej sie powinno robic?

[PHP] pobierz, plaintext 
<style>
#block {
background:red; 
width:100px; 
height:100px; 
position:absolute; 
}
</style>
 
<div id="block"></div>
 
<script type="text/javascript">
var x=100;
var y=100;
window.onkeydown = function(e)
{
 Key = e.keyCode;
 if(Key==39) //left
 {
   document.getElementById('block').setAttribute('style','top:' + y + 'px; left:' + x + ';');
   x+=1;
 }
 else if(Key==37)
 {
   document.getElementById('block').setAttribute('style','top:' + y + 'px; left:' + x + ';');
   x-=1;
 }
 else if(Key==38)
 {
   document.getElementById('block').setAttribute('style','top:' + y + 'px; left:' + x + ';');
   y-=2;
 }
 else if(Key==40)
 {
   document.getElementById('block').setAttribute('style','top:' + y + 'px; left:' + x + ';');
   y+=1;
 }
}
</script>
[PHP] pobierz, plaintext 

Z takim kodem świetlanej przyszłości ci nie wróżę (nawet jak na zwykłą stronę www jest to marne). GDzieś mam zapisane linki do fajnych gierek opartych o canvas, jak tylko wrócę do domu to wrzucę je tutaj.


chyba masz nieświeże informacje canvas z akceleracją GPU (IE i FF mają ją domyslnie włączoną) wydajnością przewyższył już flasha

@redok : wiem, że kod był pisany na szybko, ale używaj switch i addEventListener, jeśli już chcesz pisać to na poważnie

Tego nawet lepiej nie pokazuj


Szukaj pod frazą "silnik gier", oczywiście w języku ang. Jeśli chodzi o naukę to nie są konieczne. Do zaawansowanych gier jest niezbędny, można napisać swój, ale to trwa dość długo i jest trudne.


Na dobrą sprawę wszystko w JS jest obiektowe. Warto poznać trochę ten temat, ale głównie po to, żeby nie mieć burdelu w kodzie. Gdy wejdziesz w tematykę sam zobaczysz, że przyda Ci się ta wiedza


@!*!, Pawel_W, wNogachSpisz: Moim zdaniem do gier będzie lepsze canvas. Na dzień dzisiejszy obie metody są porównywalne( tak wynika z moich obserwacji( praktyki dużej nie mam, ale coś tam zdarzyło mi się napisać) ), jeśli chodzi o proste animacje. CSS3 jest odrobinę wydajniejszy, gdy chcemy robić animacje w stylu "przesuń 100px do góry", ale gdy w grę wejdzie matematyka + logika gry coraz większą przewagę będzie miał canvas. Przynajmniej tak wynika z moich ubogich obserwacji( nie tylko dotyczącego mojego kodu ).

Jeżeli bym był na miejscu autora to:
- wybrałbym CSS3 + DOM, jeśli ma to służyć nauce przez zabawę
- wybrałbym canvas, jeśli autor ma zamiar pójść w gry przeglądarkowe

zgadza sie, pisalem to na szybko, o addEventListener juz sie zapoznalem. Tez mi sie wydawalo, ze takie podejscie jest kiepskie i toporne. Myslelem tylko, ze moze da sie to jakos uplynnic - "podrasowac". Natomiast nie jestem pewny co konkretnie masz na mysli z setAttribute - jakies zle praktyki to stosowac? Jakies alternatywy? Czy moze chodzi ogolnie o skrypt?

if jest szybszy



zamiast setAttribute możesz odwołać się do style.top i style.left

Zanim weźmiesz się za silniki gier poczytaj o obiektowym JS, jak działają callback'i, w jaki sposób rozdzielić warstwy aplikacji oraz jak nimi zarządzać.

To bez jaj Jak chcesz mogę się z Tobą założyć, że napiszę kod, w którym switch będzie szybszy( w JS ).

Rozumiem, że to żart, a żeby nie mącić autorowi to podsumuję: używaj switch, bo kod jest wtedy czytelniejszy.

PS. Jest taki natłok emotikonów, że już nie można ufać czy to żarty czy poważana dyskusja. Wstawię sobie kolejny:

tak, to był żart, chociaż w przypadku ilości warunków < 3 switch jest wolniejszy